Just a guy in Vermont trying to connect all the dots...
Author's posts
May 06
The Power of SoundCloud As A Podcast Publishing Platform
Why do I like SoundCloud as a podcast hosting platform? What advantages can SoundCloud offer podcasters? Why should you consider SoundCloud as a place to distribute your podcast?
Last week SoundCloud announced that its podcasting features were now publicly available to everyone [1]. Given that I've been using SoundCloud's podcasting feature in their beta program since May 2012, I want to share some of my reflections on why I think SoundCloud has great potential as a powerful platform for podcast publishing and promotion.
To set the context for my comments below, I started using SoundCloud three years ago to see how it could work for the "rapid creation of audio content". I wanted to just be able to push record in an app and then publish and promote my podcasts. I wanted it to be super easy. The result has been my "The Dan York Report (TDYR)" podcast that I publish now at:
From the start it's been an experiment to try out SoundCloud as a platform because I have several other podcasts I'd like to start. So TDYR has been my testbed to try out ideas and tools. I do pay for their SoundCloud Pro Unlimited plan which at $135/year works out to what I consider a reasonable $11.25/month for the hosting of my audio files.
As a result of all of this, here are 10 reasons I find SoundCloud powerful for podcasters.
1. Speed And Simplicity Of Creating And Sharing Podcasts
Here's all I do to create a new podcast episode:
- Open up an app on my iPhone.
- Press "Record" and record whatever I want to say.
- Press "Share to SoundCloud" (or "Upload"), enter in a title and hit the button to start.
Boom!
That's it. The podcast is uploaded to SoundCloud and then shared out via the RSS feed to iTunes and also via social media to Twitter, Facebook and Google+.
That's seriously it.
Super fast creation and sharing/promotion of audio podcasts.
Now, of course, you could make the process more complex if you want to. I record my TDYR episodes as just raw audio without any kind of post-production and without an intro, outro or any other kinds of audio segments. In my case, I want the simplicity and rawness. But the beautiful fact is..
2. Many Applications to Create/Record Podcasts
... there are many, many, MANY applications that yet you create audio and share it up to SoundCloud. Applications are available for iOS, Android, Mac OS/X, Microsoft Windows and many other operating systems. SoundCloud has a whole directory of applications that can be used. Although many of them are for consuming/listening, they do have a whole list for creating/recording. Many of these are targeted at music producers, but many can also work for podcasters.
Because I am aiming for speed, I typically record on my iPhone and find that I'm generally using either:
- Opinion - an app targeted at podcasters that I reviewed before and like for its simplicity.
- Hindenburg Field Reporter - a more expensive but insanely powerful app with strong editing features, multiple sessions and more.
I've been primarily using Opinion for the past while but recently they rolled out their own podcast hosting (competing with SoundCloud) and now give that preference in the export/sharing part of the app. I'm a bit concerned that they may continue to promote that service and make it harder to publish out to other services. On the other hand, the Hindenburg Field Reporter app doesn't seem to be frequently updated... although that may not be necessary, really. It's a rock solid app!
I've also used AudioCopy, a free app that SoundCloud started recommending when they removed recording from their own SoundCloud app. It's fine, but I like the editing capabilities of the other two apps.
The key point is that there are many choices of apps that will connect and share to SoundCloud.
And, of course, SoundCloud just lets you upload an audio file in a variety of different formats. So you can record your episode using any kind of device or application. I've recorded some episodes using one of my Zoom Handy audio recorders and then just copying the MP3 file from the SD card onto my laptop and uploading to SoundCloud through their web interface.
3. Automatic Sharing Out To Social Media
A great part of the simplicity is that when I post an episode to SoundCloud it gets automagically shared out to whatever services I've configured. I've set up a default configuration and then can override that sharing from the apps during the upload process. The beautiful thing is it supports multiple accounts for Facebook, Twitter, Tumblr and Google+:
And, as noted below, you can use services like IFTTT to distribute podcasts out to even more sites and social networks!
4. Insanely EASY Embedding of Podcasts
Another huge advantage of SoundCloud is that it is incredibly easy to embed podcasts in a blog post or web page. SoundCloud supports "oEmbed" and so very often all you have to do is drop the URL of your SoundCloud episode into your software and... ta da... that's it! This works great for all my WordPress sites. It also works great in chat clients such as Wire.
If your site/application doesn't support oEmbed (such as TypePad, the site I use for this blog), it's trivial to get a snippet of HTML code that you can then drop into your post (as I will do at the end of this post):
This also works with social networks, too. Drop a URL for a SoundCloud episode into Facebook or Ello, for example, and the embedded player will automagically appear so that people can listen right there in their feeds.
5. Comments At Specific Points In The Podcast
Engaging with listeners is always a critical part of building a community around your podcast. Typically you get comments as replies to the blog post about your podcast or as replies on social media.
But what's cool about SoundCloud is that you can get replies AT THE POINT IN TIME within your actual podcast. If someone wants to reply to something specific you said, no longer are you trying to get to the point in the episode where you said whatever it was to remember what you said - the comment can be left right at that point of the episode.
Now, this DOES require a SoundCloud account. And so many of your listeners may not want to register for a (free) SoundCloud account just to be able to leave you comments at specific times. But some of your listeners might, and so for them it becomes a great way to build interaction.
6. Open API Makes Integration Easy
SoundCloud understands the power of becoming a platform for developers and they provide rich support through a SoundCloud developer program and much more. One result is the many applications I pointed out in #2 above, but another result is services such as IFTTT (If This, Then That) that allow you to easily set up actions involving SoundCloud. There are many IFTTT "recipes" for SoundCloud that are already available:
As the screen capture shows, the integration can go both ways - in or out of SoundCloud. For instance, I had a recipe for a while that would trigger whenever I published an episode to SoundCloud that would post a link out to my App.net account (until I pretty much stopped using App.net). I also plan to set one up that will post to a specific WordPress site every time I publish a new post. Going the opposite direction, you can see that there are recipes that will publish to your SoundCloud account every time you put a file in, say, a Dropbox folder.
Now, IFTTT is just one site. There are many other sites that have their own integration with SoundCloud... all because of this open application programming interface (API).
7. Search and Discovery
SoundCloud as a web site / service is all focused around the consumption and listening to music and audio. Like any social network, people with an account can "follow" you and get all your recent episodes. SoundCloud makes it very easy to search and find episodes. It supports hashtags.
Now obviously this is again using the SoundCloud site, which your listeners may or may not do... but this becomes a way that you can potentially find new users.
8. Downloads
Just as the embedding of a podcast is easy, so is the downloading of a podcast IF you enable people to do so. This is a choice. But if you want to allow people to download an episode, all they need to do is to go to the episode page (an example) and the download button is right there.
9. Spotlight
If you create a good number of episode and want to highlight some of the episodes you think are the most important, SoundCloud lets you put up to 5 sounds in the "Spotlight" area of your SoundCloud profile page. A nice way to help people coming to your site to see what you think are your best or most important episodes
10. Statistics
Typically as a podcaster you want to know how many people are listening, right? As I've written about before and we've talked about over on the FIR podcast, statistics are difficult because you can know how many people downloaded a podcast, but not whether they in listened.
SoundCloud has many statistics and can perhaps obviously give more statistics about user behavior when your podcast episode is played from the SoundCloud site or apps. For regular "RSS downloads", you still do get a good bit of information, although, as mentioned above, it's challenging to know what the stats truly mean. Here's the "RSS downloads" of my last week of TDYR stats:
Apparently I'm interesting to people (or someone) in Kuala Lumpur, Malaysia! Who knew? And then Southbury, CT... (but I have family and friends in that region :-) )
Anyway, a good number of statistics are available
Others...
There are other reasons why podcasters may like the platform. For example, it's great that Creative Commons licensing is available for those who want to allow others to share their audio content under a CC license. There are also monetization options available that I, quite frankly, haven't explored yet (since I don't see TDYR as something that people would want to advertise on). The whole "social network" aspect of SoundCloud can be compelling, too, for building an audience. For example, people can "repost" your episodes and share them out with followers.
I'd note, too, that you don't have to use SoundCloud as your exclusive hosting platform. A friend, Donna Papacosta, primarily hosts her podcast on Libsyn[2] and then also uploads it to her SoundCloud account as an additional distribution channel. C.C. Chapman also posts some of his episodes to his SoundCloud account. So it doesn't have to be an all-or-nothing thing. You can experiment!
Issues
While I'm obviously rather pleased with SoundCloud, there are still a number of issues I would love to see them address:
- Support for IPv6 - Given the work I do with the Internet Society, I'm looking for hosting platforms that realize that all the new mobile networks and the efforts to bring the next 4 billion people online are going to need to use IPv6 in their networks. YouTube, Facebook and all of Google's properties all work over IPv6. SoundCloud needs to get there, too.
- Use HTML5 instead of Flash - Similarly, SoundCloud really needs to ditch their Flash player and use HTML5 audio instead. Flash creates so many issues on my various systems. We now have HTML5 audio support in most modern browsers. SoundCloud has had experimental support for HTML5, but they need to move that out of beta, too, and make it the default.
- Finish the transition to their new website user experience - SoundCloud has been in this strange transition from their "classic" website to the "new" website for a year or more now and it still provides a strange and bizarre user experience. You click some link in your account settings and... ta da... you are back in an old user experience... and then you have to find your way back to the regular "new" view. They need to just finish this up.
Hopefully those are all things they will continue to work on to make the platform even stronger.
Getting Started with Podcasting On SoundCloud
If after reading all this you want to get started with a podcast on SoundCloud, they provide a very simple guide to begin:
http://on.soundcloud.com/creator-guide/podcasting
Basically, you create an account, set up the RSS feed settings, get some app that will upload to SoundCloud... and start publishing!
That's it!
If you are already using SoundCloud, all you should need to do is go into your "Settings" and to the "Content" tab where you will see your RSS feed and can set up any specific fields you want to configure:
As you can see at the bottom of that image you can configure your defaults for all uploads in terms of the license and whether uploads are automatically in the RSS feed.
Again, the Creator Guide for podcasting has more info.
I was admittedly rather skeptical of SoundCloud in the early years of my experimentation. Their "support" of podcasting in their beta program was pretty weak three years ago and it seemed all they wanted to do was build their own "walled garden of audio" and try to get everyone to come onto their platform.
But with this public launch of "podcasting" (which really amounts to exposing RSS feeds!) they've finally opened up those walls and made it so that you can use the SoundCloud platform for hosting your podcast - giving you all the advantages I've outlined above - but then making your content available to everyone out there to consume in whatever applications and systems they choose.
I look forward to hearing many more podcasts on SoundCloud... including yours! Please do feel free to follow me on SoundCloud as I continue with my experimentation. I'd love to hear from you what you think about all of this, either in the comments here or, of course, on the accompanying audio version (TDYR 243) of this post up on SoundCloud.
[1] For more stories about the launch, see Techmeme and Mediagazer.
[2] In full disclosure I also use Libsyn for hosting some of my podcasts (and have since 2005) and find their services very useful, too.
Photo credit: A merger of a Flickr CC-licensed image from Colleen AF Venable and SoundCloud's logo.
May 04
The Hobson & Holtz Report – Podcast #806: May 5, 2015
Intro: Neville is in Boston, Gini Dietrich is guest co-host; Steve Rubel is hosting a new podcast, Content Convergence; Geeks Bearing Gifts book review coming this week;
Quick News: Converse knows how to work with fans, bad tweets from the Houston Rockets and the City of Cleveland prompt different apologies, Johns Hopkins University students will no longer eat chicken, a change to Promoted Tweets gives more ammunition to native advertising’s critics; the Media Monitoring Minute with CustomScoop;
News That Fits: Bud Light promotes misogyny, Virtual Reality is coming to journalism, listener comments discussion, Walmart laid off employees and then provided well-being health advice to them, Igloo Software promo, Dan York’s Tech Report (including ISOC support for Nepal earthquake victims, how to test your website, certificate pinning, WebRTC voice chat web app, and Soundcloud as a podcast platform), the last week on the FIR Podcast Network, PR needs more SEO (and vice versa);
Music from David Peck; and more.
For Immediate Release: The Hobson and Holtz Report for May 4, 2015: An 80-minute podcast recorded live from Chicago, Illinois, and Concord, California, USA.
Links to websites, blog posts and other content we discuss in the show are posted as Delicious bookmarks to facilitate your connection with the discussions and sharing of that content.
Messages from our sponsors: Save time with the CustomScoop online clipping service: sign up for your free two-week trial, at www.customscoop.com/fir; Igloo Software, providers of an intranet you’ll actually like, delivered securely with our cloud platform: learn more at www.igloosoftware.com/fir.
So, until Monday May 11…
The post The Hobson & Holtz Report – Podcast #806: May 5, 2015 appeared first on FIR Podcast Network.
May 04
FIR #806 – 5/4/15 – For Immediate Release
May 03
TDYR 243 – The Power of SoundCloud As A Podcast Publishing Platform
May 01
New RFC 7469 on Certificate Pinning – HTTP Public Key Pinning (HPKP)
A couple of weeks ago those of us interested in Internet security formally received a new tool in our toolbox to improve the overall security of the TLS infrastructure that we use for pretty much all secure communication across the Internet. RFC 7469, “Public Key Pinning Extension for HTTP” was published and is available at:
http://tools.ietf.org/html/rfc7469
I say “formally” because in practice what is more commonly known as “HPKP” or “PKP” has been implemented for some time now by Google Chrome and Mozilla Firefox (see ticket) as the Internet-Draft worked its way through the WEBSEC Working Group within the IETF on its way to becoming a formal RFC.
At a basic level, “certificate pinning” is a fairly simple concept: once you connect to a site and receive its TLS certificate (i.e. you switch to using HTTPS and have the “lock” icon in your browser), “pin” that certificate inside your application for a specified period of time and ONLY accept connections that use that exact TLS certificate. This removes the possibility of an attacker succeeding with a Man-In-The-Middle (MITM) attack where the attacker can fool your browser into thinking you are connecting to the correct secure site. (If you want a deeper dive, OWASP has a long description of certificate pinning.)
Certificate pinning is a concept that has been around for a while but this new HPKP header makes it easier for sites to implement.
RFC 7469’s abstract doesn’t put it quite so simply as I did above, but you get the idea:
This document defines a new HTTP header that allows web host operators to instruct user agents to remember (“pin”) the hosts’ cryptographic identities over a period of time. During that time, user agents (UAs) will require that the host presents a certificate chain including at least one Subject Public Key Info structure whose fingerprint matches one of the pinned fingerprints for that host. By effectively reducing the number of trusted authorities who can authenticate the domain during the lifetime of the pin, pinning may reduce the incidence of man-in-the-middle attacks due to compromised Certification Authorities.
Now in practice it turns out that pinning the exact TLS certificate can cause operational problems in some website configurations and so the specification allows for the pinning of the key of the entity that issues the TLS certificates for your site, such as a certificate authority (CA). This allows you, for instance, to specify that a browser should only accept TLS certificates from a specific CA. This reduces the risk of a MITM attack where an attacker uses a TLS cert from a different CA who they were able to get to issue the bogus cert.
This new RFC 7469 dives into all the details of HPKP, but if you want a higher level view, Joseph Bonneau gave a talk in March 2015 at IETF 92 in Dallas about HPKP and its companion, HTTP Strict Transport Security (HSTS – RFC 6797). The slides are available:
and you can listen to the presentation starting at about 24:30 in the recording of the SAAG session.
Certificate pinning is a great tool that we have now, although it does have a few challenges to be aware of:
- Trust-On-First-Use (TOFU) – Certificate pinning relies on you connecting to the correct server on the first connection in order to get the TLS cert that you are now going to pin in the browser. As noted in the RFC 7469 Introduction, the issue is that if you were to connect to an attacker’s site first you could in fact wind up pinning the false certificate and thereby being blocked out of connecting to the correct site until the time of the pin expires (what is called in the spec “max-age”).
- Blocking a site due to certificate changes – If you need to change a TLS cert, or if a TLS cert should be compromised or a private key is lost, you could potentially wind up in a situation where people using browsers that perform cert pinning would not be able to get to your site. This could happen if you pinned to an exact cert and had to change the cert, or if you pinned to a CA and then switched to a new CA, and in either case were unable to provide enough notice to manage the migration. The Security Considerations section of RFC 7469 discusses this issue.
On the TOFU issue, one way to deal with having to trust the site on first use is to “pre-load” the certificate to be pinned into the web browser or other application. This is being done by both Chrome and Firefox (see Mozilla’s list). The only concern here is that if you need to change the certificate in the pre-loaded list, you need to wait for an update to the browser to be available (and for users to install that update).
In various conversations I’ve suggested DNSSEC could help here because if the local system performed DNSSEC validation on a signed domain, the browser would then have a high level of assurance that it was connecting to the correct IP address where it could then receive a HPKP header with the correct TLS cert to be pinned. So DNSSEC could help bootstrap the pinning process and get around the TOFU concern.
Whenever I’ve raised this point, the response has typically been that if you have DNSSEC validation available you could simply use DANE to ensure you are using the correct TLS certificate. This is true, and I’d like to hope we’ll someday get there, but: 1) DANE requires the creation and usage of TLSA records, which is one more step people have to take; and 2) web browsers don’t have full support of DANE yet (although plugins are available). In the meantime, I still see DNSSEC as a powerful way to help with ensuring cert pinning works correctly.
Regardless, the key point is that RFC 7469 is now out there and certificate pinning via the HPKP header is now possible. It’s another tool we have and one that anyone interested in TLS security should definitely understand.
I’d love to hear your comments on this – please do feel free to leave them here. Tell me why cert pinning is great… tell me why it’s not. Tell me I’m wrong (or right!). Please do note that we do moderate comments because of spam but we approve basically very comment that isn’t abusive or spam.
Apr 30
Wire Launches WebRTC Voice/Chat Web App For Windows, Linux, more – Includes High TLS Security
https://app.wire.com/If you already have an account you simply sign in with your credentials. If you don't have an account you can easily create one.
I've been running both the native Mac OS X client and the web client for a bit now (I was part of web beta program for Wire) and it is truly amazing how well the team has made the web experience to be seamless between the web and native client. Here's a screenshot showing both side by side (click/tap for a larger image):
In the web view on the right you have the browser bars at the top and one of the images did not go the full width of the column, but otherwise the experience and visual display has been essentially identical between the two platforms. The synchronization between the two is nearly instantaneous and all the features work really, really well.
Notifications in the web browser (if you allow them) work great to alert you to new messages.
And the voice calls from within the web browser have the same outstanding audio quality I've come to expect from Wire.
All in all the web implementation is quite excellent.
This new web app also addresses a concern I had from the initial launch of Wire back in December - the lack of a client for users on Microsoft Windows. With this web app Windows users - and Linux users - can now equally participate in communication over Wire. This is all courtesy of WebRTC that allows modern browsers to be able to use voice and chat from directly within the browser. Wire co-founder and CTO Alan Duric published a post about how they use WebRTC.
Alan also clued me in to the strong degree that the Wire team takes security extremely seriously. In fact I would say they take it more seriously than many other similar web apps I've seen. If you go over to Qualys SSL Labs and plug in "app.wire.com" you get a result of an "A+":
The same can NOT be said of other similar web interfaces that I tested from similar services.
I've been writing about Wire for a bit now (see my various articles) and I have it running on my Mac all the time, primarily because of the great value I get out of a couple of group chats that I am in. From a chat / messaging perspective it's one of the best I've seen and I find it extremely useful.
Curiously, I don't find myself using Wire as much for actual calls, primarily because I find that much of my interaction has moved to video calls, and Wire doesn't support those yet. When I do use Wire the audio quality is truly amazing, but that has to do with the audio pedigree of the team behind Wire, and the fact that they are using the Opus codec. On a larger level, there is also the continued "directory dilemma" that I've written about, namely that Wire has the same struggle as most other new tools in that you need to gather a strong "directory" of people who are actually using the app for it to be an app that people regularly use. Most of the people with whom I regularly communicate aren't users of Wire ... yet.
Still, the release of this "Wire for Web" gives me hope that Wire may be able to build some momentum now that, for example, Microsoft Windows users can now join in. Time will tell... but this will definitely help!
Kudos to the team at Wire for this very excellent web release?
P.S. If you are using Wire, or try it out, you should be able to find me on Wire as "Dan York".
Note: an audio podcast about this topic is also available:
Apr 30
TDYR 242 – Wire.com Launches WebRTC-based Web App
Apr 29
nTLDStats Adds DNSSEC Statistics for New Generic Top-Level Domains (newgTLDs)
Hooray! The folks over at nTLDstats have now added a new tab that lets you see which of the 100s of new generic top-level domains (newgTLDs) are seeing the most second-level domains signed with DNSSEC. You can see the stats at:
Here is a view of how it looks right now:
The site shows a number of interesting stats, including:
- the percentage of newgTLDs with signed second-level domains in them (60.80% at the time I write this)
- the number and percentage of signed zones as it relates to the overall number of registered domains within the newgTLDs
- the number of zones (of those signed) that failed DNSSEC validation (indicating a configuration issue)
- a trend line over time
- the distribution of signed domains across the number of newgTLDs
- breakdowns of signed domains by both newgTLD and also by registrar
While the overall number of signed domains today within the 5.2 million domains registered in the newgTLDs is a very small 0.95%, we now have a very easy way to see where DNSSEC signing is being actively used – and a way to measure which of the newgTLDs and also registrars are doing the most to support DNSSEC deployment.
I was intrigued to see that the leader of the newgTLDs is the .OVH TLD sponsored by a French hosting provider, OVH, with Afnic providing the back-end registry. According to their site, the OVH domain started as an April Fool’s joke in 2009 and then became a reality due to the interest. Clicking through to their registrar site (they are apparently the only registrar for the .OVH domain), you can see why they have so many domains signed – they have a “Activate DNSSEC on this extension!” link directly on their registration page!
Looking at the Registrar Breakdown column, the OVH registrar leads in the number of DNSSEC-signed newgTLDs, presumably because they are again offering DNSSEC-signing to anyone who uses them for DNS hosting, regardless of what newgTLD they register under.
I was also curious as to why “.paris” was the second-highest newgTLD with 2,347 signed domains, but the probably answer could be quickly found by clicking through to the .paris page. It shows the top 2 registrars as “Gandi SAS” and “OVH sas”… my guess would be that many/most of the 2,347 signed domains could come from the 4,000 domains registered by OVH, given that they are actively promoting DNSSEC.
Another interesting element of this new page is that you can change the slider underneath the trend line to see more stats over time. By moving the slider all the way to the left you can get a view of the trend in the newgTLDs:

There’s a huge jump in October 2014. Given the other stats and the information on the OVH web site, my guess would be that this was a result of the launch of the .OVH newgTLD.
Anyway… there’s probably a lot more we can learn from exploring the statistics in this way. The key point is that now there is a very easy-to-use web interface that lets us track and be able to show which of the newgTLDs are doing the most to provide registrants the security provided by DNSSEC. I’d note that this is all possible because all of the new gTLDs are required by ICANN to submit their zone files to the Centralized Zone Data Service (CZDS), allowing sites like nTLDstats to query the CZDS and build views such as these.
Kudos to the nTLDstats team for adding this page! I will be adding it to our DNSSEC Statistics page and look forward to using it over time.
P.S. Want to get started with signing your domain? Visit our Start Here page to learn how!
Apr 29
TDYR 241 – It Would Have Been Easy To NOT Run Today
Apr 27

