tag:blogger.com,1999:blog-16614218671768556812024-03-13T23:01:16.616-07:00Sporadic DispatchesStuff that wants to get out of my head.Adam Roachhttp://www.blogger.com/profile/02812244850745930161noreply@blogger.comBlogger9125tag:blogger.com,1999:blog-1661421867176855681.post-77916580343474074922016-03-23T11:15:00.000-07:002016-03-23T11:15:51.178-07:00An Open Letter to Tim Cook: Apple and the EnvironmentDear Mr. Cook:<br /><br />I watched your March Event 2016 Keynote speech with great interest, and applaud your principled stance on encryption, as well as the amazing steps Apple is taking toward environmental stewardship. For me, the high point of the entire event was <a href="https://www.youtube.com/watch?v=AYshVbcEmUc">the introduction of Liam</a>, which I think serves as a beacon of responsibility for other manufacturers to aspire to.<br /><br />However, my enthusiasm for this environmental trail-blazing was dampened later in the day when I downloaded iOS 9.3 and installed it on my iPhone. Immediately after installation, I eagerly went looking for the Night Shift settings in the control panel. After a frustrating search, I finally found mention online that the feature was only available to newer devices.<br /><br />As a lifelong environmentalist, I believe in making use of things as long as they retain their basic utility. To that end, I still carry an iPhone 5 in my pocket. It’s a truly amazing device, and it still works as well now as it did when I got it three years ago.<br /><br />But the absence of Night Shift support is the latest in a string of unnecessary disappointments. When WiFi calling was introduced in iOS 8, we were told that the iPhone 5 was not powerful enough to support the feature (despite its presence in low-end Nokias for years, and rumors that it worked fine on the iPhone 5 during the beta period). When content blocker support was introduced in iOS 9, we were told that 64-bit processors were required for the feature, which is completely non-sequitur. Now, when iOS 9.3 comes out, we’re told the same thing for its new and shiny features.<br /><br />I’ve been a software engineer for decades, and I recognize artificially manufactured limitations when I see them. Look, I get it. Apple sells hardware, and it’s good business sense to artificially choke off older equipment to induce people to buy new devices. But when you pair this behavior with environmental messages, it sends mixed signals. It tells us that the environmental push isn’t as sincere as it’s being held out to be.<br /><br />And I think Apple is better than that.<br /><br />Sincerely,<br />Adam RoachAdam Roachhttp://www.blogger.com/profile/02812244850745930161noreply@blogger.com0tag:blogger.com,1999:blog-1661421867176855681.post-4414748295753646492016-02-19T11:03:00.000-08:002016-02-19T11:03:53.029-08:00Laziness in the Digital Age: Law Enforcement Has Forgotten How To Do Their JobsIn all the hubbub around <a href="https://www.washingtonpost.com/world/national-security/us-wants-apple-to-help-unlock-iphone-used-by-san-bernardino-shooter/2016/02/16/69b903ee-d4d9-11e5-9823-02b905009f99_story.html?tid=a_inl">the FBI and Apple getting crosswise with each other</a>, there's a really important point that's been lost, and it's not one that the popular press seems to be picking up on.<br />
<br />
From initial appearances, the public as a whole seems to support Apple's position -- of protecting the privacy of its users -- over the FBI's. <a href="http://money.cnn.com/2016/02/18/technology/apple-fbi-taking-sides/">But there is still a sizeable minority who are critical of Apple as obstructing justice</a> and aligning themselves with terrorists.<br />
<br />
What the critics are overlooking is that the very existence of this information -- the information the FBI claims is critical to their investigation -- is a quirk of the brief era we currently live in. Go back a decade, and there would be no magical device that people carry with them and confide their deepest secrets to. Go forward a decade, and personal mobile devices are going to be locked down in ways that will be truly uncircumventable, rather than merely difficult to break.<br />
<br />
But during the decade or so that people have been increasingly using easily exploitable digital devices and communication, law enforcement has become utterly dependent on leveraging it for investigations. They've simply forgotten how to do what they do for a living.<br />
<br />
When James Oliver Huberty shot 21 people at a San Diego-area McDonald's in 1984, there was no phone to ask Apple to unlock. Patrick Edward Purdy in Stockton, CA in 1989? No phone. George Jo Hennard in a Texas Luby's in 1991? He wasn't carrying a digital diary with him for police to prowl through. I could go on for much longer than any of you could possibly bear to read. In none of these cases did law enforcement have a convenient electronic device they could use to delve into the perpetrator's inner thoughts. They pursued their cases the same way law enforcement has for the centuries prior: they applied the hard work of actual physical investigation. They did their job.<br />
<br />
Law enforcement agencies developed investigatory techniques before the ubiquity of digital devices, and those techniques worked just fine. Those techniques will continue to work just fine after everything is finally locked down, and that day is coming soon. All the FBI needs now is to re-learn how to employ these techniques, rather than pushing companies to weaken privacy protections for people worldwide.<br />
<br />
And they need to re-learn these techniques before digital snooping becomes completely worthless, or they're going to be in a world of hurt.Adam Roachhttp://www.blogger.com/profile/02812244850745930161noreply@blogger.com2tag:blogger.com,1999:blog-1661421867176855681.post-86669337760575592672015-11-28T16:26:00.000-08:002016-02-01T08:41:59.802-08:00Better Living through Tracking ProtectionThere's been a bit of a hullabaloo in the press recently about blocking of ads in web browsers. Very little of the conversation is new, but the most recent round of discussion has been somewhat louder and more excited, in part because of Apple's recent decision to allow web content blockers on the iPhone and iPad.<br />
<br />
In this latest round of salvos, the online ad industry has taken a pretty brutal beating, and key players appear to be rethinking long-entrenched strategies. Even the Interactive Advertising Bureau -- who has referred to ad blocking as "robbery" and "an extortionist scheme" -- has <a href="http://www.iab.com/news/lean/">gone on record to admit</a> that the Internet ads got so bad that users basically had no choice but to start blocking them.<br />
<br />
So maybe things will get better in the coming months and years, as online advertisers learn to moderate their behavior. Past behavior shows a spotty track record in this area, though, and change will come slowly. In the meanwhile, there are some pretty good tools that can help you take back control of your web experience. <br />
<br />
<h2>
How We Got Here</h2>
While we probably all remember the nadir of online advertising -- banners exhorting users to "punch the monkey to win $50", epilepsy-inducing ads for online gambling, and out-of-control popup ads for X10 cameras -- the truth is that most ad networks have already pulled back from the most obvious abuses of users' eyeballs. It would appear that annoying users into spending money isn't a winning strategy.<br />
<br />
Unfortunately, the move away from hyperkinetic ads to more subtle ones was not a retreat as much as a carefully calculated refinement. Ads nowadays are served by colossal ad networks with tendrils on every site -- and they're accompanied by pretty sophisticated code designed to track you around the web.<br />
<br />
The thought process that went into this is: if we can track you enough, we learn a lot about who you are and what your interests are. This is driven by the premise that people will be less annoyed by ads that actually fit their interests; and, at the same time, such ads are far more likely to convert into a sale.<br />
<br />
Matching relevant ads to users was a reasonable goal. It should have
been a win-win for both advertisers and consumers, as long as two key
conditions were met: (1) the resulting system didn't otherwise ruin the web browsing experience, and (2) users who don't want to have their personal movements across the web could tell advertisers not to track them, and have those requests honored.<br />
<br />
Neither is true.<br />
<br />
<h2>
Tracking Goes off the Rails</h2>
Just like advertisers went overboard with animated ads, pop-ups, pop-unders, noise-makers, interstitials, and all the other overtly offensive behavior, they've gone overboard with tracking.<br />
<br />
You hear stories of overreach all the time: just last night, I had a friend recount how she got an email (via Gmail) from a friend that mentioned front-loaders, and had to suffer through weeks of banner ads for construction equipment on unrelated sites. The phenomenon is so bad and so well-known, <a href="http://www.theonion.com/article/woman-stalked-across-8-websites-obsessed-shoe-adve-51519">even The Onion is making fun of it</a>.<br />
<br />
Beyond the "creepy" factor of having ad agencies building a huge personal profile for you and following you around the web to use it, user-tracking code itself has become so bloated as to ruin the entire web experience.<br />
<br />
In fact, on popular sites such as CNN, code to track users can account for somewhere on the order of three times as much memory usage as the actual page content: <a href="https://www.youtube.com/watch?v=DJLoq5E5ww0">a recent demo of the Firefox memory tracking tool</a> found that 30 MB of the 40 MB used to render a news article on CNN was consumed by code whose sole purpose was user tracking.<br />
<br />
This drags your browsing experience to a crawl.<br />
<br />
<h2>
Ad Networks Know Who Doesn't Want to be Tracked, But Don't Care.</h2>
Under the assumption that advertisers were actually willing to honor user choice, there has been a <a href="http://donottrack.us/">large effort</a> to develop and standardize a way for users to indicate to ad networks that they didn't want to be tracked. It's been implemented by all major browsers, and endorsed by the FTC.<br />
<br />
For this system to work, though, advertisers need to play ball: they need to honor user requests not to be tracked. As it turns out, advertisers aren't actually interested in honoring users' wishes; as before, they see a tiny sliver of utility in abusing web users with the misguided notion that this somehow translates into profits. <a href="https://www.govtrack.us/congress/bills/112/hr654">Attempts to legislate conformance</a> were made several years ago, but these never really got very far.<br />
<br />
So what can you do? The balance of power seems so far out of whack that consumers have little choice than to sit back and take it.<br />
<br />
You could, of course, run one of any number of ad blockers -- <a href="https://adblockplus.org/">Adblock Plus</a> is quite popular -- but this is a somewhat nuclear option. You're throwing out the slim selection of good players with the bad ones; and, let's face it, someone's gotta provide money to keep the lights on at your favorite website.<br />
<br />
Even worse, many ad blockers employ techniques that consume as much (or more) memory and as much (or more) time as the trackers they're blocking -- and Adblock Plus is one of the worst offenders. They'll stop you from seeing the ads, but at the expense of slowing down everything you do on the web.<br />
<br />
<h2>
What you can do</h2>
When people ask me how to fix this, I recommend a set of three tools to make their browsing experience better: Firefox Tracking Protection, Ghostery, and (optionally) Privacy Badger. (While I'm focusing on Firefox here, it's worth noting that both Ghostery and Privacy Badger are also available for Chrome.)<br />
<br />
<h3>
1. Turn on Tracking Protection</h3>
<a href="https://support.mozilla.org/en-US/kb/tracking-protection-firefox">Firefox Tracking Protection</a> is automatically activated in recent versions of Firefox whenever you enter "Private Browsing" mode, but you can also manually turn it on to run all the time. If you go to the URL bar and type in "about:config", you'll get into the advanced configuration settings for Firefox (you may have to agree to be careful before it lets you in). Search for a setting called "<b>privacy.trackingprotection.enabled</b>", and then double-click next to it where it says "false" to change it to "true." Once you do that, Tracking Protection will stay on regardless of whether you're in private browsing mode.<br />
<br />
Firefox tracking protection uses a curated list of sites that are known to track you <i>and</i> known to ignore the "Do Not Track" setting. Basically, it's a list of known bad actors. And <a href="http://ieee-security.org/TC/SPW2015/W2SP/papers/W2SP_2015_submission_32.pdf">a study of web page load times</a> determined that just turning it on <i>improves page load times by a median of 44%</i>.<br />
<br />
<h3>
2. Install and Configure Ghostery</h3>
There's also an add-on that works similar to Tracking Protection, called <a href="https://www.ghostery.com/">Ghostery</a>. <a href="https://addons.mozilla.org/en-US/firefox/addon/ghostery/">Install it from addons.mozilla.org</a>, and then go into its configuration (type "about:addons" into your URL bar, and select the "Preferences" button next to Ghostery). Now, scroll down to "blocking options," near the bottom of the page. Under the "Trackers" tab, click on "select all." Then, uncheck the "widgets" category. (Widgets can be used to track you, but they also frequently provide useful functions for a web page: they're a mixed bag, but I find that their utility outweighs their cost).<br />
<br />
Ghostery also uses a curated list, but it's far more aggressive in what it considers to be tracking. It also allows you fine-grained control over what you block, and lets you easily whitelist sites, if you find that they're not working quite right with all the potential trackers removed.<br />
<br />
Poke around at the other options in there, too. It's really a power-users tracker blocker.<br />
<br />
<h3>
3. Optionally, Install Privacy Badger</h3>
Unlike tracking protection and Ghostery, Privacy Badger isn't a curated list of known trackers. Instead, it's a tool that watches what webpages do. When it sees behavior that could be used to track users across multiple sites, it blocks that behavior from ever happening again. So, instead of knowing ahead of time what to block, it learns what to block. In other words, it picks up where the other two tools leave off.<br />
<br />
This sounds really good on paper, and does work pretty well in practice. I ran with Privacy Badger turned on for about a month, with mostly good results. Unfortunately, its "learning" can be a bit aggressive, and I found that it broke sites far more frequently than Ghostery. So the trade-off here: if you run Privacy Badger, you'll have much better protection against tracking, but you'll also have to be alert to the kinds of defects that it can introduce, and go turn it off when it interferes with what you're trying to do. Personally, I turned it off a few months ago, and haven't bothered to reactivate it yet; but I'll be checking back periodically to see if they've tuned their algorithms (and their yellow-list) to be more user-friendly.<br />
<br />
If you're interested in giving it a spin, you can <a href="https://addons.mozilla.org/firefox/addon/privacy-badger-firefox/">download Privacy Badger from the addons.mozilla.org website</a>. Adam Roachhttp://www.blogger.com/profile/02812244850745930161noreply@blogger.com0tag:blogger.com,1999:blog-1661421867176855681.post-76624427929091615602013-08-12T20:43:00.003-07:002013-08-13T07:43:07.096-07:00Web Apps as the new Lingua Franca<div class="moz-text-html" lang="x-western">
I've recently been involved in some conversations around the "lock-in" provided by the mobile system development platforms: once you start working towards (for example) an Android app, it's going to be an Android app. Deploying it on another platform generally means that you have a lot of porting work to do, and multiple codebases to maintain.<br />
<br />
I think that's yesterday's model. I think the model for the <i>future</i> is "web apps," by which I mean applications developed using HTML5, JavaScript, and the various APIs coming out of the W3C.<br />
<br />
An objection I've heard raised here -- actually, two different objections, but with the same root -- is (1) people don't want to open their web browser and surf to a web page to run their programs, and (2) the mobile web browsing experience is not terribly convenient.<br />
<br />
What's critical to realize is that "web
apps" aren't necessarily bound to the experience of "opening up a web
browser as an explicit action, navigating to an application's web
site, and then interacting with it as if it were a web page."
Web-apps-as-first-class-apps is a viable model for development and deployment. And there is a team of people inside Mozilla who are working really hard to make this work as seamlessly as possible.<br />
<br />
Both FirefoxOS and BlackBerry 10 <i>inherently</i> treat
HTML5/JavaScript applications as "first class" apps. In FirefoxOS,
it's the sole means of developing applications; and BlackBerry 10
uses it as one of <a href="http://developer.blackberry.com/develop/platform_choice/index.html">several native development environments</a>. In both cases, the user's experience is
indistinguishable from what they're used to apps doing: there isn't
even an intermediating browser anywhere in the mix. The HTML5 and
JavaScript engines are an inbuilt part of both operating systems. <br />
<br />
I recognize that neither platform has the penetration to be a real game changer; at least, not at the moment. I'm holding them up as existence proofs
that the approach of "web app as native app" is viable. But let's
talk about how these technologies can be leveraged for native webapp deployment on Android, iOS, and Desktop systems.<br />
<br />
All of these systems have their own idea of "installed applications."
To be successful, we need some way to make these
HTML5/JavaScript applications look, act, and feel like every other
kind of application (rather than "something running in a web browser").<br />
<br />
This is where the work that Mozilla has been doing for web app deployment comes into play, and it's easier to demonstrate than it is to explain. If you have Firefox installed on your desktop (or
Firefox Aurora on your Android device), you can go to
<a class="moz-txt-link-freetext" href="https://marketplace.firefox.com/">https://marketplace.firefox.com/</a>, find apps that amuse you, and
click on "install." At that point, Firefox takes the steps necessary
to put an icon in whatever location you're used to finding your
applications. On your Android device, you get an application icon. Under OS X, you get a new application in Launchpad. For Windows, you get... well, whatever your version of Windows uses to access installed apps.<br />
<br />
From that point forward, the distinction between these web apps
and native applications is impossible for users to discern.<br />
<br />
Interestingly, iOS was both a bit of a pioneer in this space, and
also remains the most frustrating platform in this regard. If you
recall Apple's stance when the original iPhone first launched, they
didn't allow third-party applications at all. Instead, their story
was that HTML and JavaScript were powerful enough to develop
whatever applications people want to write. Presumably as part of
this legacy, iOS still allows users to manually save "bookmarks" to
their desktop. If the content behind those bookmarks is iOS-aware,
then the bookmarks open in a way that hides the browser controls --
effectively acting like a native app. If you have an iOS device, you
can play around with how compelling this experience can be by going
to <a class="moz-txt-link-freetext" href="http://slashdot.org/">http://slashdot.org/</a> -- select the box-and-arrow icon at the
bottom of your browser, and click "Add to Home Screen." Now,
whenever you open the newly-created icon, it acts and feels exactly
like you downloaded and installed a native "Slashdot" application
onto your device. It even appears in the task management bar as a
separate application.<br />
<br />
The reason the iOS experience remains frustrating is twofold. First,
and primarily an annoyance to developers: the only HTML5/JavaScript
rendering engine allowed on the platform is Apple's own webkit
implementation. This frustrates the ability to add new APIs, such as
may be required for new applications. So, new APIs are only added at
whatever pace Apple's product plan gets them added. Secondly -- and
of actual concern to users -- there is no programmatic way to add
web app icons to the desktop. Creating these icons requires a
relatively arcane series of user steps (described above). Basically,
Apple is playing the role of the napping hare in this
tortoise-and-hare race: they were very fast out the gate, but have
been asleep for quite a while now.<br />
<br />
But that covers all the bases: it's possible to develop HTML5/JavaScript apps that truly run
cross-platform for iOS, Android, Blackberry, FirefoxOS, and a variety of desktop systems
-- even if the Apple experience is somewhat less than satisfying
(for both developers and users).<br />
<br />
I suspect most of what's holding developers back is predominantly a
lack of knowledge that this is a viable technical model. I've heard developer feedback that one major reason they aren't targeting JavaScript environments involve concerns about
the speed of execution in a JavaScript environment. It's not yet clear whether these problems are merely perception or reality. I've seen some impressive
things like <a href="http://polycrypt.net/">usable cryptography</a>, <a href="https://brendaneich.com/2013/05/today-i-saw-the-future/">high-def video codec decoding</a>, <a href="http://www.unrealengine.com/html5/">and high-performance first-person 3D environments</a> (including
<a href="https://developer.mozilla.org/en-US/demos/detail/bananabread"> viable multiplayer first-person shooters</a>) implemented in pure JavaScript, so I suspect it's more a perception problem based on very outdated experiences. I'd love feedback from anyone who has run into performance problems trying to use this model with a modern JavaScript interpreter.</div>
Adam Roachhttp://www.blogger.com/profile/02812244850745930161noreply@blogger.com7tag:blogger.com,1999:blog-1661421867176855681.post-87095764589808697982013-08-02T07:59:00.001-07:002013-08-02T07:59:48.182-07:00It's official: No SDES in the browsers.I wanted to follow up on my earlier post regarding WebRTC security. In that post, I mentioned that RTCWEB was contemplating what role, if any, SDES would play in the overall specification.<br />
<br />
At yesterday's RTCWEB meeting, we concluded what had been a rather protracted discussion on this topic, with a wide variety of technical heavy hitters coming into express opinions on the topic. The result, as recorded in the <a href="http://www.ietf.org/proceedings/87/minutes/minutes-87-rtcweb">working group minutes</a>, is:<br />
<br />
<blockquote class="tr_bq">
<pre>Question: Do we think the spec should say MUST implement SDES,
MAY implement SDES, or MUST NOT implement SDES. (Current doc
says MUST do dtls-srtp)
Substantially more support for MUST NOT than MAY or MUST
**** Consensus: <b>MUST NOT implement SDES in the browser.
</b></pre>
</blockquote>
<br />
So, what does this mean? The short version is that we just avoided a very real threat to WebRTC's security model.<br />
<br />
I'd like to put a finer point on that. There was a lot of analysis during the conversation around the difference in difficulty of mounting an active attack versus a passive attack, the ability to detect and audit possible interception, and a variety of other topics that would each require their own article (although I think <a href="http://www.ietf.org/proceedings/87/slides/slides-87-rtcweb-5.pdf">Eric Rescorla's slides</a> from that session do a good job of summarizing the issues rather concisely). Rather than go into that level of detail, I want to share a brilliant layman's description of SDES by way of an anecdote.<br />
<br />
One of the RTCWEB working group participants brought along a companion to Berlin for this weeks' meeting. She sat in on the RTCWEB encryption discussion. When she asked what the lively conversation was all about, the working group participant directed her to the relevant portions of <a href="http://tools.ietf.org/html/rfc4568">the SDES RFC</a>.<br />
<br />
Yesterday evening, when we were talking about the day's events, she summarized her impression of SDES based on this lay reading: "It's like having the most state-of-the-art safe in the world, putting all of your gold inside, and then writing the access code on the outside."Adam Roachhttp://www.blogger.com/profile/02812244850745930161noreply@blogger.com0tag:blogger.com,1999:blog-1661421867176855681.post-68230547442742148502013-06-07T14:44:00.001-07:002013-06-07T21:08:25.730-07:00WebRTC: Security and Confidentiality<br />
One of the interesting aspects of WebRTC is that it has encryption baked right into it; there's actually no way to send unencrypted media using a WebRTC implementation. The developing specifications currently use <a href="http://tools.ietf.org/html/rfc5764">DTLS-SRTP</a> keying<sup>[1]</sup>, and that's what both Chrome and Firefox implement. The general idea here is that there's a <a href="http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange">Diffie-Hellman key exchange</a> in the media channel, without the web site -- or even the javascript implementation -- being involved at all.<br />
<br />
<h3>
But who are you talking to?</h3>
<br />
This is only part of the story, though. While encryption is one of the tools necessary to prevent eavesdropping by other parties, it is in no way sufficient. Unless you have some way to demonstrate that the other end of your encrypted connection is under the control of the person you're talking to, you could easy be sending your media to a server that is capable of sharing your conversation with an arbitrary third party. One important tool to help with this problem is the <a href="http://dev.w3.org/2011/webrtc/editor/webrtc.html#identity">WebRTC identity work</a> currently underway in the W3C. This isn't ready in any implementations that I'm aware of yet, but it's definitely something that needs to happen before we consider WebRTC done.<br />
<br />
The general idea behind the identity work is that, as part of key exchange, you also get enough information to prove, in a cryptographically verifiable way, that the other end of the connection are who you think they are. Of course, there are still some tricky aspects to this (you have to, for example, trust Google not to sign off on someone other than me being "adam.roach@gmail.com"<sup>[2]</sup>), but you can at least reduce the problem from trusting one party (the website hosting the WebRTC application) to trusting that two parties (the website and the identity provider) won't collude.<br />
<br />
The other tool necessary to ensure the confidentiality of contents is making sure
that the media isn’t being copied by the javascript itself and being
sent to an alternate destination. This isn’t part of any current
specification, but we’re working on adding a standardized mechanism that
will allow specific user media streams to be limited so that they can
only be sent, over an encrypted channel, to a specified identity (and
nowhere else).<br />
<br />
On top of this, web browser developers have a very difficult task in presenting this to users in a way that they can use. The nuances between (and implications of) "this is encrypted but we can't prove who you're talking to" versus "this is being encrypted and sent directly to adam.roach@gmail.com (at least if you trust Google)" are very subtle. Rendering this to users is a thorny challenge, and one that's going to take time to get right.<br />
<br />
<h3>
And who knows who you are talking to?</h3>
<br />
Of course, none of this is perfect. The recent Verizon brouhaha is about a database of who is communicating with whom (known in the communications interception community as a "<a href="http://en.wikipedia.org/wiki/Pen_register">pen register</a>"), not actually listening in on phone calls. It uses telephone numbers as identifiers, which are pretty easy to correlate to an owner. WebRTC can't prevent this kind of information from being collected, using IP addresses where Verizon uses phone numbers. IP addresses aren't much harder to correlate to people than phone numbers are, as has been demonstrated by numerous MPAA and RIAA lawsuits.<br />
<br />
Even with a good encryption story, WebRTC has no inbuilt defenses to collecting this kind of information. Anyone with access to the session description is going to be able to see the IP addresses of both parties to the conversation; and, of course, the website is going to know where the HTTP requests came from. Beyond that, your ISP (and every backbone provider between you and the other end of the call) can easily see which IP addresses you're sending information to, and picking media streams out (even encrypted media streams) is a trivial exercise for the kinds of equipment ISPs and backbone providers deploy.<br />
<br />
The problem is that it's fundamentally difficult to mask who is talking to whom on a network. There are approaches, such as <a href="http://en.wikipedia.org/wiki/Anonymizer">anonymizers</a> and <a href="http://en.wikipedia.org/wiki/Onion_routing">Onion Routers</a>, that can be used to make it more difficult to ascertain; but such approaches have their own weaknesses, and most simply shift trust around from one third party to another.<br />
<br />
In summary, WebRTC is taking steps to allow for the contents of communication to remain confidential, but it takes a concerted effort by application developers to bring the right tools together. The less tractable problem of masking who talks to whom is left as out of scope.<br />
<br />
____<br />
<i><sup>[1]</sup> There's been recent talk in the IETF RTCWEB working group of adding <a href="http://tools.ietf.org/html/rfc4568">Security Descriptions</a> (SDES) as an alternate means of key exchange. SDES uses the signaling channel to send the media encryption keys from one end of the connection to the other. This would necessarily allow the web site to access the encryption keys. This means that they (or anyone they handed the keys off to) could decrypt the media, if they have access to it. In terms of stopping some random hacker in the same hotel as you from listening in while you talk to your bank, it's still reasonably effective; in the context of programs like <a href="http://en.wikipedia.org/wiki/PRISM_%28surveillance_program%29">PRISM</a>, or even the pervasive collection of personal data by major internet website operators, it's about as much protection as using tissue paper to stop a bullet.</i><br />
<i><br /></i>
<i><sup>[2]</sup> Whether you choose to do so mostly comes down to whether you trust <a href="http://googleblog.blogspot.com/2013/06/what.html">this blog entry</a> more than <a href="http://en.wikipedia.org/wiki/File:Prism_slide_5.jpg">this slide</a>.</i>Adam Roachhttp://www.blogger.com/profile/02812244850745930161noreply@blogger.com3tag:blogger.com,1999:blog-1661421867176855681.post-37965242082056073412013-05-16T09:17:00.000-07:002013-05-16T10:46:53.822-07:00Google Hangouts testing WebRTC-based, pluginless implementation?A sharp-eyed <a href="http://www.tobytes.com/">Toby Allen</a> recently <a href="https://twitter.com/tobyallen/status/335003519167905793">brought the following code to my attention</a>:<br />
<br />
<blockquote class="tr_bq">
<div class="syntax">
<div class="javascript" style="font-family: monospace;">
<div class="de1">
Qg.<span class="me1">prototype</span>.<span class="me1">init</span>=<span class="kw2">function</span><span class="br0">(</span>a,b,c,d<span class="br0">)</span><span class="br0">{</span><span class="kw1">this</span>.<span class="me1">ca</span><span class="br0">(</span><span class="st0">"pi1"</span><span class="br0">)</span>;var e=window.<span class="me1">location</span>.<span class="me1">href</span>.<span class="me1">match</span><span class="br0">(</span><span class="re0">/.<span class="me1">*</span><span class="br0">[</span>?&<span class="br0">]</span><span style="color: red;">mods=</span><span class="br0">(</span><span class="br0">[</span>^&<span class="br0">]</span>*<span class="br0">)</span>.<span class="me1">*</span>/<span class="br0">)</span>;if<span class="br0">(</span>e=<span class="br0">(</span>e==m||<span class="nu0">2</span>>e.<span class="me1">length</span>?<span class="nu0">0</span>:/\b<span style="color: red;">pluginless</span>\b/</span>.<span class="me1">test</span><span class="br0">(</span>e<span class="br0">[</span><span class="nu0">1</span><span class="br0">]</span><span class="br0">)</span><span class="br0">)</span>||Z<span class="br0">(</span>S.<span class="me1">Xd</span><span class="br0">)</span><span class="br0">)</span><span class="br0">{</span>t:<span class="br0">{</span><span class="kw2">var</span> e=<span class="kw2">new</span> Ad<span class="br0">(</span>Uc<span class="br0">(</span><span class="kw1">this</span>.<span class="me1">e</span>.<span class="me1">l</span><span class="br0">)</span>.<span class="me1">location</span><span class="br0">)</span>,f;f=e.<span class="me1">K</span>.<span class="me1">get</span><span class="br0">(</span><span class="st0">"lantern"</span><span class="br0">)</span>;if<span class="br0">(</span>f!=m&&<span class="br0">(</span>f=Number<span class="br0">(</span>f<span class="br0">)</span>,Ka<span class="br0">(</span>Og,f<span class="br0">)</span><span class="br0">)</span><span class="br0">)</span><span class="br0">{</span>e=f;break t<span class="br0">}</span>!Fc||!<span class="br0">(</span><span class="nu0">0</span><=ta<span class="br0">(</span>dd,<span class="nu0">26</span><span class="br0">)</span><span class="br0">)</span>||<span style="color: red;">webkitRTCPeerConnection</span>==m?e=<span class="nu0">-1</span>:<span class="br0">(</span>Pg.<span class="me1">da</span><span class="br0">(</span><span class="br0">)</span>?<span class="br0">(</span>f=Pg.<span class="me1">get</span><span class="br0">(</span><span class="st0">"mloo"</span><span class="br0">)</span>,f=f!=m&&<span class="st0">"true"</span>==f<span class="br0">)</span>:f=q,e=f?<span class="nu0">-3</span>:<span class="nu0">0</span>==e.<span class="me1">hb</span>.<span class="me1">lastIndexOf</span><span class="br0">(</span><span class="st0">"/hangouts/_/present"</span>,<span class="nu0">0</span><span class="br0">)</span>?<span class="nu0">-4</span>:<span class="nu0">1</span><span class="br0">)</span><span class="br0">}</span>e=<span class="nu0">1</span>==e<span class="br0">}</span>e?Rg<span class="br0">(</span><span class="kw1">this</span>,q<span class="br0">)</span>:Sg<span class="br0">(</span><span class="kw1">this</span>,a,b,c,d<span class="br0">)</span><span class="br0">}</span>; </div>
</div>
</div>
</blockquote>
<br />
That's an excerpt from the Google Hangouts javascript code. It's a bit obfuscated (either by design; or, more likely, because it's the output of another tool), and I haven't taken the time to fully dissect it. But the gist of the code appears to be to test for the presence of a "mods=pluginless" string in the URL; and, if one is present, to check whether the browser supports the use of WebRTC's RTCPeerConnection API (or, at least, Google's prefixed version of it). It then looks like it calls one of two different initialization functions based on whether such support is present.<br />
<br />
Alas, with this preliminary analysis, I couldn't get Hangouts to do anything that looked plugin-free, even on a recent copy of Chrome Canary. But it's pretty clear that the Hangouts team has started playing around with a WebRTC-based implementation.<br />
<br />
The downside is that they're checking for Chrome's specific prefixed version of RTCPeerConnection rather than attempting to use a polyfill like most WebRTC demos on the web nowadays. So it appears that this functionality, when it's deployed, is most likely going to be Chrome-only -- at least, initially.Adam Roachhttp://www.blogger.com/profile/02812244850745930161noreply@blogger.com1tag:blogger.com,1999:blog-1661421867176855681.post-74682986104593817962013-05-07T09:26:00.000-07:002013-05-07T09:29:49.765-07:00WebRTC: Welcome to the party! Please watch your head.<i>This is a republication of my section of <a href="https://hacks.mozilla.org/2013/04/webrtc-update-our-first-implementation-will-be-in-release-soon-welcome-to-the-party-but-please-watch-your-head/">a blog post from the Mozilla hacks blog</a>.</i> <br />
<img alt="" src="https://hacks.mozilla.org/wp-content/uploads/2013/03/hardhat.png" style="float: right; margin: 0px 0px 10px 10px;" /><br />
About three years ago, my dear friend and VoIP visionary Henry
Sinnreich spent some time over lunch trying to convince me that the real
future of communications lay in the ability to make voice and video
calls directly from the ubiquitous web browser. I can still envision him
enthusiastically waving his smartphone around, emphasizing how
pervasive web browsers had become. My response was that his proposal
would require unprecedented cooperation between the IETF and W3C to make
happen, and that it would demand a huge effort and commitment from the
major browser vendors. In short: it’s a beautiful vision, but Herculean
in scope.<br />
<br />
Then, something amazing happened.<br />
<h3>
</h3>
Over the course of 2011, the groundwork for exactly such IETF/W3C
collaboration was put in place, and a broad technical framework was
designed. During 2012, Google and Mozilla began work in earnest to
implement towards the developing standard.<br />
<br />
Last November, San Francisco hosted the first WebRTC expo. The
opening keynote was packed to capacity, standing room only, with people
spilling out into the hallway. During the following two days, we saw
countless demos of nascent WebRTC services, and saw dozens of companies
committed to working with the WebRTC ecosystem. David Jodoin shared
with us the staggering fact that half of the ten largest US banks are
already planning their WebRTC strategy.<br />
<br />
And in February, Mozilla and Google drove the golden spike into the WebRTC railroad by <a href="https://hacks.mozilla.org/2013/02/hello-chrome-its-firefox-calling/">demonstrating a real time video call between Firefox and Chrome</a>.<br />
<h3>
</h3>
With that milestone, it’s tempting to view WebRTC as “almost done,”
and easy to imagine that we’re just sanding down the rough edges right
now. As much as I’d love that to be the case, there’s still a <i>lot</i> of work to be done.<br />
<br />
Last February in Boston, we had a joint interim meeting for the
various standards working groups who are contributing to the WebRTC
effort. Topics included issues ranging from the calling conventions of
the WebRTC javascript APIs to the structure of how to signal multiple
video streams – things that will be important for wide adoption of the
standard. I’m not saying that the WebRTC standards effort is
struggling. Having spent the past 16 years working on standards, I’m can
assure you that this pace of development is perfectly normal and
expected for a technology this ambitious. What I <i>am</i> saying is
that the specification of something this big, something this important,
and something with this many stakeholders takes a long time.<br />
<br />
<h3>
</h3>
Even if the standards work were complete today, the magnitude of what
WebRTC is doing will take a long time to get implemented, to get
debugged, to get right. Our golden spike interop moment took substantial
work on both sides, and revealed a lot of shortcomings in both
implementations. Last February also marked the advent of <a href="https://www.sipit.net/SIPit30_summary">SIPit 30</a>,
which included the first actual WebRTC interop testing event. This
testing predictably turned up several new bugs (both in our
implementation as well as others’), on top of those limitations that we
already knew about.<br />
<br />
When you add in all the features that I know neither Mozilla nor
Google has begun work on, all the features that aren’t even specified
yet, there’s easily a year of work left before we can start putting the
polish on WebRTC.<br />
<br />
We’re furiously building the future of communications on the
Internet, and it’s difficult not to be excited by the opportunities
afforded by this technology. I couldn’t be more pleased by the warm
reception that WebRTC has received. But we all need to keep in mind that
this is still very much a work in progress.<br />
<br />
<h3>
</h3>
So, please, come in, look around, and play around with what we’re
doing. But don’t expect everything to be sleek and finished yet. While
we are doing our best to limit how the changing standards impact
application developers and users, there will be inevitable changes as
the specifications evolve and as we learn more about what works best.
We’ll keep you up to date with those changes <a href="http://hacks.mozilla.org/">on the Hacks blog</a> and
try to minimize their impact, but I fully expect application developers
to have to make tweaks and adjustments as the platform evolves. Expect
us to take us a few versions to get voice and video quality to a point
that we’re all actually happy about. Most importantly, understand that
no one’s implementation is going to completely match the rapidly
evolving W3C specifications for quite a while.<br />
<br />
I’m sure we all want 2013 to be “The Year of WebRTC,” as some have
already crowned it. And for early adopters, this is absolutely the time
to be playing around with what’s possible, figuring out what doesn’t
quite work the way you expect, and — above all — providing feedback to
us so we can improve our implementation and improve the developing
standards.<br />
<br />
As long as you’re in a position to deal with minor disruptions and
changes; if you can handle things not quite working as described; if you
are ready to roll up your sleeves and influence the direction WebRTC is
going, then we’re ready for you. Bring your hard hat, and keep the
lines of communication open.<br />
<br />
For those of you looking to deploy paid services, reliable channels
to manage your customer relationships, mission critical applications: we
want your feedback too, but temper your launch plans. I expect that
we’ll have a stable platform that’s well and truly open for business
some time next year.<br />
___ <br />
<i>Credits: Original hardhat image from <a href="http://openclipart.org/">openclipart.org</a>; Anthony Wing Kosner first applied the <a href="http://www.forbes.com/fdc/welcome_mjx.shtml">“golden spike” analogy</a> to WebRTC interop.</i>Adam Roachhttp://www.blogger.com/profile/02812244850745930161noreply@blogger.com0tag:blogger.com,1999:blog-1661421867176855681.post-91966196383683301392012-11-15T08:26:00.001-08:002012-11-15T08:26:22.979-08:00Dispatches PendingI have things to say, but no time to say them at the moment. Please stand by for transmission...Adam Roachhttp://www.blogger.com/profile/02812244850745930161noreply@blogger.com0