Just a guy in Vermont trying to connect all the dots...
Dan York
Author's posts
Apr 21
Call For Participation – ICANN 50 DNSSEC Workshop on 25 June In London
Are you planning to attend the ICANN 50 meeting in London in June? If so, would you like to share your experience with deploying DNSSEC? As noted below, we are seeking proposals for presentations to be given during the DNSSEC Workshop that will happen on Wednesday, June 25, 2014, during the ICANN week.
The full list of topic areas for which we are seeking proposals is included below. If you have an idea for a presentation, please send a brief (1-2 sentence) description of your proposed presentation to dnssec-london at shinkuro.com as soon as possible – but no later than by Friday, 09 May 2014. You can send an idea now if you would like… even if you have an idea you are not sure about, you are welcome to send it in and ask if it is appropriate. These are great sessions and the agenda tends to fill up pretty quickly, so if you want to be included please do send in a proposal as soon as possible!
Thanks,
Dan
Call for Participation — ICANN DNSSEC Workshop 25 June 2014
The DNSSEC Deployment Initiative and the Internet Society Deploy360 Programme, in cooperation with the ICANN Security and Stability Advisory Committee (SSAC), are planning a DNSSEC Workshop at the ICANN meeting in London on 25 June 2014. The DNSSEC Workshop has been a part of ICANN meetings for several years and has provided a forum for both experienced and new people to meet, present and discuss current and future DNSSEC deployments. For reference, the most recent session was held at the ICANN meeting in Singapore on 26 March 2014. The presentations and transcripts are available at: http://singapore49.icann.org/en/schedule/wed-dnssec.
We are seeking presentations on the following topics:
1. DNSSEC Activities in the European region:
For this panel we are seeking participation from those who have been involved in DNSSEC deployment in the European region and also from those who have not deployed DNSSEC but who have a keen interest in the challenges and benefits of deployment. In particular, we will consider the following questions: What can DNSSEC do for you? What doesn’t it do? What are the internal tradeoffs to implementing DNSSEC?
2. The Operational Realities of Running DNSSEC:
Now that DNSSEC has become an operational norm for many registries, registrars, and ISPs, what have we learned about how we manage DNSSEC? What is the best practice around key rollovers? How often do you review your disaster recovery procedures? Is there operational familiarity within your customer support teams? What operational statistics have we gathered about DNSSEC? Are there experiences being documented in the form of best practices, or something similar, for transfer of signed zones?
3. DNSSEC Automation:
For DNSSEC to reach massive deployment levels it is clear that a higher level of automation is required than is currently available. Topics for which we would like to see presentations include:
- What tools, systems and services are available to help automate DNSSEC key management?
- Can you provide an analysis of current tools/services and identify gaps?
- Where in the various pieces that make up DNSSEC signing and validation are the best opportunities for automation?
- What are the costs and benefits of different approaches to automation?
4. When Unexpected DNSSEC Events Occur:
What have we learned from some of the operational outages that we have seen over the past 18 months? Are there lessons that we can pass on to those just about to implement DNSSEC? How do you manage dissemination of information about the outage? What have you learned about communications planning? Do you have a route to ISPs and registrars? How do you liaise with your CERT community?
5. DANE and DNSSEC Applications:
The DNS-based Authentication of Named Entitites (DANE) protocol is an exciting development where DNSSEC can be used to provide a strong additional trust layer for traditional SSL/TLS certificates. There is strong interest for DANE usage within web transactions as well as for securing email and Voice-over-IP (VoIP). We are seeking presentations on topics such as:
- What are some of the new and innovative uses of DANE and other DNSSEC applications in new areas or industries?
- What tools and services are now available that can support DANE usage?
- How soon could DANE and other DNSSEC applications become a deployable reality?
- How can the industry used DANE and other DNSSEC applications as a mechanism for creating a more secure Internet?
We would be particularly interested in any live demonstrations of DNSSEC / DANE applications and services. For example, a demonstration of the actual process of setting up a site with a certificate stored in a TLSA record that correctly validates would be welcome. Demonstrations of new tools that make the setup of DNSSEC or DANE more automated would also be welcome.
6. DNSSEC and DANE In The Enterprise:
Similar to ISPs, enterprises can play a critical role in both providing DNSSEC validation to their internal networks and also through signing of the enterprises’s own domains. We are seeking presentations from enterprises who have implemented DNSSEC on either or both validation and signing and can address questions such as:
- What are the benefits to enterprises of rolling out DNSSEC validation? And how do they do so?
- What are the challenges to deployment for these organizations and how could DANE and other DNSSEC applications address those challenges?
- How should an enterprise best prepare its IT staff and network to implement DNSSEC?
- What tools and systems are available to assist enterprises in the deployment of DNSSEC?
- How can the DANE protocol be used within an enterprise to bring a higher level of security to transactions using SSL/TLS certificates?
7. Guidance for Registrars in Supporting DNSSEC:
The 2013 Registrar Accreditation Agreement (RAA) for Registrars and Resellers requires the support of DNSSEC beginning on January 1, 2014. We are seeking presentations discussing:
- What are the specific technical requirements of the RAA and how can registrars meet those requirements?
- What tools and systems are available for registrars that include DNSSEC support?
- What information do registrars need to provide to resellers and ultimately customers?
We are particularly interested in hearing from registrars who have signed the 2013 RAA and have either already implemented DNSSEC support or have a plan for doing so.
8. Implementing DNSSEC Validation At Internet Service Providers (ISPs):
Internet Service Providers (ISPs) play a critical role by enabling DNSSEC validation for the caching DNS resolvers used by their customers. We have now seen massive rollouts of DNSSEC validation within large North American ISPs and at ISPs around the world. We are interested in presentations on topics such as:
- What does an ISP need to do to prepare its network for implementing DNSSEC validation?
- How does an ISP need to prepare its support staff and technical staff for the rollout of DNSSEC validation?
- What measurements are available about the degree of DNSSEC validation currently deployed?
- What tools are available to help an ISP deploy DNSSEC validation?
- What are the practical server-sizing impacts of enabling DNSSEC validation on ISP DNS Resolvers (ex. cost, memory, cpu, bandwidth, technical support, etc.)?
9. APIs Between the Registrars and DNS Hosting Operators:
One specific area that has been identified as needing focus is the communication between registrars and DNS hosting operators, specifically when these functions are provided by different entities. Right now the communication, such as the transfer of a DS record, occurs primarily by way of the domain name holder copying and pasting information from one web interface to another. How can this be automated? We would welcome presentations by either registrars or DNS hosting operators who have implemented APIs for the communication of DNSSEC information – or from people with ideas around how such APIs could be constructed.
10. Panel Discussion/Demonstrations on Hardware Security Modules (HSMs):
HSMs are a key element in DNSSEC deployment, particularly in maintaining the security of the Zone Signing Key (ZSK). We are interested in demonstrations of HSMs as well as presentations on HSM challenges and benefits.
11. Preparing for Root Key Rollover
For this topic we are seeking input on issues relating to root key rollover. In particular, we are seeking comments from vendors, ISPs, and the community that will be affected by distribution of new root keys.
In addition, we welcome suggestions for additional topics.
If you are interested in participating, please send a brief (1-2 sentence) description of your proposed presentation to dnssec-london at shinkuro.com by Friday, 09 May 2014
We hope that you can join us.
Thank you,
Julie Hedlund
On behalf of the DNSSEC Workshop Program Committee:
- Steve Crocker, Shinkuro
- Mark Elkins, DNS/ZACR
- Cath Goulding, Nominet UK
- Jean Robert Hountomey, AfricaCERT
- Jacques Latour, .CA
- Xiaodong Lee, CNNIC
- Luciano Minuchin, NIC.AR
- Russ Mundy, Sparta/Parsons
- Ondřej Surý, CZ.NIC
- Yoshiro Yoneya, JPRS
- Dan York, Internet Society
Apr 21
FIR #752 – 4/21/14 – For Immediate Release
Interview with JerryGarcia.com developers is up; Quick News: US Court says blogs are media, General Mills backpedals on new online terms of service, LinkedIn releases Slideshare app, Americans are optimistic about upcoming technology advances; Ragan promo; News That Fits: US Airways doesn't fire staffer who sent objectionable tweet, Dan York's Tech Report, monetizing your blog content, Media Monitoring Minute from CustomScoop, listener comments, how advertisers and marketers are using mobile messaging apps, the past week on FIR, Michael Netzley's Asia Report, Igloo Software promo, enterprise social networks need to do more than assimilate new-hires; how to comment; music from Plastic Sky; and more.
Apr 18
Hello world!
Welcome to DeepDark.blue. This is an experimental site created purely for me to experiment with a newgTLD (.blue). The site is, of course, signed with DNSSEC and is also available over IPv6.
Apr 17
Call For IPv6 Case Studies For World IPv6 Launchiversary
Have you already deployed IPv6 in your network? Have you migrated your application to work over IPv6? Have you made your website or online service available over IPv6?
If so, WE WANT YOUR EXAMPLE AS A CASE STUDY!
Friday, 6 June 2014, marks the 2-year “Launchiversary” of World IPv6 Launch, the day when sites and networks all across the Internet turned on IPv6 permanently. To celebrate, we want to promote stories about what people have done to make IPv6 “the new normal” within their network, service, application or device.
In the time around 6 June, we want to publish and promote many different kinds of “case studies.” So we want to hear from you! We want to help tell your story of what you did to move to IPv6. In some cases, the story might be how incredibly easy it was to make the move – in other cases the story might be how difficult it was and what steps you had to take.
Now, when we say we want to promote a “case study” we are not necessarily talking about some long whitepaper full of charts and diagrams. That could be the form it takes, if you already have such a document – or if you and we have the time to do that. But a “case study” could also be in the form of:
- A guest blog post here on Deploy360 with several paragraphs walking through what you did.
- A video interview posted up on YouTube or another video service.
- A slide deck that outlines the steps of your transition and the lessons learned.
- An audio interview posted on our site.
- A recording of a presentation you have given at a recent industry conference where you talked about your transition.
It could be any of those forms!
If you have a story to tell, please email us at deploy360@isoc.org or fill out our feedback form.
We already have a number of case studies we’re intending to publicize, but we want more! We’re interested in hearing from many different types of people, too, including:
- Operators of small, medium and large Internet Service Providers (ISPs)
- Network operators at enterprises
- Operators of networks for small businesses
- Consumer electronics vendors
- Application developers
- Manufacturers of home routers and other devices for home networks
- Cloud service providers
- Data center network operators
- ???
Basically… if you’ve done anything to move a product/service/application/network over to IPv6, we’d like to hear from you. In the case studies, we’re looking to answer questions such as these:
- What was involved in making the move to IPv6? What was your business case?
- What did you need to do to prepare?
- Was it easy/hard? What was the most challenging aspect of the move? What was the easiest aspect?
- Was there anything you wish you had known before you started?
- What advice would you give anyone in a similar situation looking to make the move?
Again, we could capture that in text… in a video interview… in an audio interview… or whatever other form we can think of. We’re ready to work with you to help create that content – and if you already have existing content we’re open to pointing to that, too.
IPv6 deployment has come a long way in the two years since World IPv6 Launch on 6 June 2012. We want to help spread the word about all the great work that has happened. Please join us!
If you would like to participate, please email us at deploy360@isoc.org or fill out our feedback form so that we can find out more.
We’ll highlight the best case studies we get, and may start doing that before 6 June, so the earlier you submit yours, the better! We’d like to have all submissions in by no later than 30 May so that we can get everything ready for the big day. But, to start, just fire us a message letting us know you are interested – why not do that NOW?
Thanks for your help – and we look forward to celebrating the 2-year Launchiversary with you all on 6 June!
Apr 16
R.I.P. Simon Gwatkin
I came to know Simon when I worked at Mitel Networks in Ottawa from 2001-2007, although it wasn't really until the later years when I wound up working in Mitel's Office of the CTO and looking more strategically at what the future might hold for companies like Mitel. A lot of my research and time wound up being spent looking at social media and the changing communication landscape. With Simon's role as head of strategic marketing at Mitel we wound up having any number of quite lengthy conversations about where things were going. We didn't always agree, which led to very useful and valuable discussions. Simon also got me engaged with industry analysts and helped set me down a path that was quite useful in many later years.
I also spent a good bit of time interacting with some of the startups that were being nurtured under the umbrella of Wesley Clover, the investment vehicle of Sir Terry Matthews. Simon was involved with Terry's investments there and had this intense passion for helping new entrepeneurs. (And starting in 2008 had a more permanent role with Wesley Clover.) He was fascinated by the communications business (both the telecom kind of "communications" as well as the marketing/PR kind) and by all the different ways we communicate.
When I was part of the large layoff that happened when Mitel purchased Inter-Tel in 2007, Simon helped with his vast network of contacts to try to find a place for me to land. While I ultimately wound up at Voxeo by virtue of some of the blogging I was doing, a couple of his leads were ones that I explored.
After that we stayed in touch over the years and increasingly found ourselves interacting more with each other through Facebook and social networks. One of his sons was doing something with security work at one point, and I'd shared some VoIP security resources I knew of. A few years back when my wife was dealing with breast cancer, a good friend of Simon's was battling it, too, and so we shared information - and shared with each other that intense frustration of being unable to do a whole lot to help someone we care about.
Along the way we had fun teasing each other about language and many other topics. Being a Brit with his very dry wit, he could always rise to the bait of commentary about the English language (versus "American") or other similar topics.
Simon was a gentleman and just a great guy in so many ways. I never knew his children but knew from his comments and posts that he was quite proud of them. He will be missed - and my thoughts and condolences are certainly with his family right now.
For those in the Ottawa region, or able to get there (and I am not able to do so), the obituary says a memorial service will be held tomorrow, April 17, 2014, at 2:30pm. An online guestbook is available for those who wish to leave messages for his family.
R.I.P., Simon. Thank you for all that you did.
If you found this post interesting or useful, please consider either:
- following me on Twitter;
- adding me to a circle on Google+;
- following me on App.net
- subscribing to my email newsletter; or
- subscribing to the RSS feed
Apr 16
Verizon Wireless Approaching 50% IPv6 In Latest World IPv6 Launch Measurements
The latest World IPv6 Launch measurements of network operators were published yesterday and among the charts available for the top 10 networks was this great one showing Verizon Wireless’ network as almost hitting 50% IPv6 deployment:
The actual measurement this month was 48.71% but on that growth path I expect we should see it climb over the 50% mark by next month.
As we have written about in the past, and as mentioned on the bottom of the World IPv6 Launch measurements page, the measurements are for the % of IPv6 deployment that is seen from each registered network by the four companies participating in the measurements program: Google, Facebook, Yahoo! and Akamai. The different methodologies used by the four companies are explained at the bottom of that World IPv6 Launch page.
Very cool to see this amount of IPv6 deployment happening within a mobile network. How about you? Are you ready for IPv6? If not, you may want to start with our IPv6 resources and please do let us know how we can help you!
Apr 14
As Of April 15, Yammer Will Be Effectively Dead To Me
Sadly, as of tomorrow, April 15, 2014, Microsoft's Yammer service will be effectively dead to me. For that is the day when the Yammer desktop client dies:
Yes, indeed:
This app is out of date and will be discontinued on Apr 15, 2014. For the best Yammer experience, please use your web browser.
Except, of course, that the web browser isn't the "best" Yammer experience for me.
This change was first announced earlier this year with a brief statement on Office365 site that had this as an answer for "why?":
We are refocusing our desktop efforts on creating a companion app to our web experience, rather than a replacement for the website. We’ve seen that our users prefer our desktop experience for real-time alerts, but prefer our web experience to post messages and share content. We’ve developed our Windows Notifier with this in mind - the app will provide real-time notifications on desktop to complement and serve as a companion to the Yammer web experience.
As noted by multiple people in the comments to that page, I'm not sure who Microsoft asked, but for many of us the desktop app was the way we preferred to post and share content.
Microsoft notes that they offer a "Desktop Notifier" app for Yammer, which they do, but it has one wee little problem:
Yep, it's only for Windows. I'm a Mac user. They apparently don't care about me.
That app also seems to only generate notifications... not let you actually interact with the Yammer feed. It is very definitely NOT a "replacement". As stated in one of the community support threads on Microsoft's site by a user named Rob Sparre:
A decision has already been made by MSFT to kill the nice streamlined and useful Yammer desktop app and replace it with the horrible desktop notifier and force us to keep a web browser open with a busy and bulky screen layout. It is disappointing to lose the nice app and have to use a big fat confusing web page.You may as well close this thread as I do not foresee any good news about it in the future.
Exactly.
Even if I had the new "app" on my Mac, my only choice now is to use the web interface to interact with Yammer.
The problem with using a web interface is that at any given moment I've typically got 57 zillion web browser windows and tabs open on my system and... somewhere ... buried in all those windows and tabs is going to be Yammer.
Yammer is already "yet-another-place-to-check" that isn't fully part of my workflow, and so I don't check it all that much... but having the separate desktop application provided several benefits on my Mac:
1. A SEPARATE APP I COULD SWITCH TO - If I ever wanted to see what was being posted in Yammer I could just click on the Dock icon or Alt+Tab over to Yammer and check in on the flow of messages.
2. A DOCK ICON WITH NOTIFICATIONS - Similarly, Yammer has its own icon in my "dock" on the bottom of my Mac's desktop where it can get a little red circle with the number of new messages in it. A visual indicator that I might want to go check it out.
3. A SIMPLE, COMPACT WINDOW - As the user Rob Sparre pointed out above, the Yammer Desktop client provides a nice easy way to keep track of the feed and interact with messages there. Simple. Easy.
Now judging from other comments I'm guessing that keeping up another desktop client - and one based on rival Adobe Systems' AIR technology, at that - was too much effort for the current staffing level that Microsoft has for Yammer developers.
I understand. You have to prioritize and part of that involves looking at what you remove. I get that. I'm a long-time Apple user... I'm used to having functionality stripped away. :-)
But it's just a disappointment, particularly that they offer no other replacement for Mac users (and a shadow of a replacement for Windows users).
Yes, there are the mobile apps for iPhone, iPad and Android... but the thing is that when I most post to Yammer it is when I am on my work computers... NOT when I am mobile. I often want to share links to things I am working on or articles I find interesting. I'm not going to switch to a mobile device to do that!
So as of tomorrow I don't expect I'll be using Yammer nearly as much as I have been. Sure, I can login to the bloated, Facebook-like web interface... and sure, I can bookmark it or make a pinned tab or something like this... but as I said, Yammer was already "yet-another-place-to-check". The app just made that easier.
Goodbye, Yammer Desktop... 'twas nice knowing you...
UPDATE, April 15, 2014 - As promised, the Yammer Desktop app is dead today:
If you found this post interesting or useful, please consider either:
- following me on Twitter;
- adding me to a circle on Google+;
- subscribing to my email newsletter; or
- subscribing to the RSS feed.
Apr 14
FIR #751 – 4/14/14 – For Immediate Release
Critical Mass interview coming; no correspondent reports this week; Quick News: FTC investigates a Pinterest contest, Staples wants to bring 3D printing to the masses, journalists are mining anonymous secret-sharing apps, 44% of Twitter accounts have never sent a tweet; Ragan promo; News That Fits: journalist's jaundiced view of PR's value, decline in serious reading as brain adapts to scanning, Media Monitoring Minute from CustomScoop, listener comments, Igloo Software promo, the past week on the FIR Podcast Network, are social media pundits hypocrites when it comes to engagement?; music from Matt Shenk, and more.
Apr 11
What Can App Developers Learn From Heartbleed?
What lessons can application developers take from the Heartbleed bug? How can we use this experience to make the Internet more secure? Unless you have been offline in a cave for the past few days, odds are that you’ve seen the many stories about the Heartbleed bug (and many more stories today) and, hopefully, have taken some action to update any sites you have that use the OpenSSL library. If you haven’t, then stop reading this post and go update your systems! (You can test if your sites are vulnerable using one of the Heartbleed test tools.) While you are at it, it would be a good time to change your passwords at services that were affected (after they have fixed their servers). There is an enormous list of the Alexa top 10000 out there, but sites like Mashable have summarized the major sites affected. (And periodically changing your password is just a general “best practice”, so even if the site was not affected, why not spend a few minutes to make the changes?)
Client Applications Need Updating, Too
For application developers, though, it is also important to update any client applications you may have that use the OpenSSL libraries to implement TLS/SSL connections. While most of the attention has been focused on how attackers can gain access to information stored on servers, it is also true that a malicious site could harvest random blocks of memory from clients visiting that site. There is even demonstration code that lets you test this with your clients. Now, granted, for this attack to work an attacker would need to set up a malicious site and get you to visit the site through, for instance, a phishing email or link shared through social media. The attacker could then send malformed heartbeat messages to your vulnerable client in an attempt to read random blocks of memory… which then may or may not have any useful information in them.
Again, the path for an attacker to actually exploit this would be a bit complex, but you definitely should test any client applications you have that rely on any OpenSSL libraries.
With all that said, since we have started this “TLS For Applications” topic here are on Deploy360, what are some of the important lessons we can take away from this experience? Here are a few I see coming out of this – I’d love to hear the lessons you take from all of this in the comments.
Security Testing Is Critical
It turns out that this was an incredibly trivial coding error. As Sean Cassidy points out in his excellent Diagnosis of the OpenSSL Heartbleed Bug, the issue boils down to this:
What if the requester didn’t actually supply payload bytes, like she said she did? What if pl really is only one byte? Then the read from memcpy is going to read whatever memory was near the SSLv3 record and within the same process.
There was no checking on the input and this allowed reading from other parts of the computer’s memory. As Cassidy later writes about the fix:
This does two things: the first check stops zero-length heartbeats. The second check checks to make sure that the actual record length is sufficiently long. That’s it.
Today’s XKCD comic shows this all in an even simpler explanation.
This is the kind of trivial mistake that probably every developer has made at some point of his or her life. I am sure that if I were to go back through many lines of code in my past I’d find cases where I didn’t do the appropriate input or boundary testing. It highlights the importance of doing security testing – and of setting up security unit tests that are just done as part of the ongoing testing of the application. It also highlights the need for ongoing security audits, and for reviewers of code submissions to also be testing for security weaknesses. But again, this is a common type of error that probably every developer has made. You need testing to catch things like this.
In this instance it just happens that the mistake was in a piece of software that has now become critical for much of the Internet! Which leads to a second lesson…
Having A Rapid Upgrade Path/Plan Is Important
As people learned about this bug earlier this week there has been a massive push to upgrade software all across the Internet. Which raises the question: how easy is it for your users to upgrade their software in a high priority situation such as this?
In many cases, it may be quite easy for users to install an update either from some kind of updated package or a download from an online application store. In other cases, it may be extremely difficult to get updates out there. In the midst of all this I read somewhere that many “home routers” may be vulnerable to this bug. Given that these are often something people buy at their local electronics store, plug in, and pretty much forget… the odds of them getting updated any time soon are pretty slim.
Do you have a mechanism whereby people can rapidly deploy critical security fixes?
UPDATE: A ZDNet post notes that both Cisco and Juniper have issued update statements for some of their networking products. I expect other major vendors to follow soon.
Marketing Is Important To Getting Fixes Deployed
Finally, Patrick McKenzie had a great post out titled “What Heartbleed Can Teach The OSS Community About Marketing” that nicely hits on key elements of why we’re seeing so much attention to this – and why we are seeing fixes deployed. He mentions the value of:
- Using a memorable name (“Heartbleed” vs “CVE-2014-0160″)
- Clear writing
- A dedicated web presence with an easy URL to share
- A visual identity that can be widely re-used
His article is well worth reading for more details. His conclusion includes this paragraph that hit home for me (my emphasis added):
Given the importance of this, we owe the world as responsible professionals to not just produce the engineering artifacts which will correct the problem, but to advocate for their immediate adoption successfully. If we get an A for Good Effort but do not actually achieve adoption because we stick to our usual “Put up an obtuse notice on a server in the middle of nowhere” game plan, the adversaries win. The engineering reality of their compromises cannot be thwarted by effort or the feeling of self-righteousness we get by not getting our hands dirty with marketing, it can only be thwarted by successfully patched systems.
Exactly!
We need to make it easy for people to deploy our technologies – and our updates to those technologies. (Sound like a familiar theme?)
What other lessons have you taken from this Heartbleed bug? What else should application developers be thinking about to make TLS/SSL usage more secure?
Please do leave a comment here or on social media sites where this article is posted. (And if you’re interested in helping us get more documentation out to help app developers with TLS/SSL, how about checking out our content roadmap for the TLS area? What other items should we include? Do you know of existing documents we should consider pointing to? Interested in writing some documents? Please do let us know.)
P.S. There’s now a post out about the process the Codenomicon team went through in disclosing the bug that is worth reading.
Apr 07
FIR #750 – 4/7/14 – For Immediate Release
Quick News: Google Glass app interprets emotions, SEC okays third-party endorsements for investment advisers, Audicity Unconference 2014 announced, NPR expeeriments with voice-recognition-enabled ads; Ragan promo; News That Fits: does it matter if third-party reports are more credible than branded content?, Michael Netzley's Asia Report, five ways local customers get from your blog to your business, Media Monitoring Minute from CustomScoop, listener comments, is Facebook still a viable channel for brands seeking organic reach?, Dan York's Tech Report, Igloo Software promo, last week on the FIR Podcat Network, the evolving conversation ecosystem; music from Stars and Skylines; and more.
