JD on EP

The JavaScript in modern browsers is pretty darn safe -- we've had a decade's experience of parasites seeking to exploit others, and by now the core security structure is quite sound.

But the basic premise of a browser is to be able to browse among various network resources, safely... to be able to click a link and not worry. This works directly against the desire to have in-browser applications match the full range of functionality available in native desktop applications.

Clicking a link implies a different permissions level than does downloading and installing an application. We don't usually want to install things from strangers, but we definitely do want to visit the webpages of strangers. If I visit a sketchy site I don't want them able to read my local spreadsheets, but I definitely want trusted applications to be able to manipulate files on my local drive.

There's a reasonable desire to treat WWW browsers as application hosts, and lots of people are (quite validly) doing brilliant things with applications in browsers. But that desire to have in-browser apps emulate desktop apps will always run into the counter-desire to not worry when browsing strangers' sites. To browse is not necessarily to trust.

Seen in this light, the need for AIR is clear.

But there's another security/privacy issue with third-party content -- one affecting site visitors, rather than site owners -- which Nat didn't touch on in this post. Every third-party request in a webpage initiates an HTTP transaction between the person viewing the page and that third-party server. When you view Nat's page at radar.oreilly.com, you're also requesting content from google-analytics.com, maps.yahoo.com, recaptcha.net and more... these third-party servers send content to your IP address. Put enough of these web beacons on the world's websites, and a service can track an IP address as it surfs among serviced sites.

Your IP address may be dynamically re-assigned each session, and your current IP address doesn't automatically correlate with your realworld name, but your browsing across the Web is a lot less private than most people think. The advertisers and social widgets log the requests they serve. Whether they actively mine the referral pages, or whether they actively attempt to correlate an IP address with a realworld identity or device, both are indeterminate to you and me -- we know they have the capability to do so, but cannot tell whether they currently process their databases in this way. The advertisers' databases about our habits are private, proprietary, opaque.

Many worry about government databases being vulnerable to intrusion and exploitation, but commercial databases are subject to similar risks. If a database of citizen habits becomes valuable enough, skanks will attempt to exploit it -- good intentions on the part of the cross-site servers do not suffice. Right now you and I can't inspect what the advertisers and social sites track about us, much less edit these records.

With more websites including third-party content, and with those third-party servers not providing transparency into their proprietary databases of your habits, it seems a reasonable defensive tactic to monitor and control the third-party requests your own browser makes. Tools such as Adblock Plus, although controversial, do give you transparency into, and control over, the third-party requests that the world's webpages make of your browser.

When you're reading Nat's blogpost, check out the comment from Niall Kennedy... Niall is a great resource on the widget scene... here he mentions Flash in a way I hadn't thought of before: "The good news: the industry is aware of the problems presented by cross-site JavaScript includes. We have to operate within the constraints of the language, the runtime (browsers), and associated objects such as a parent web page. Other embed formats such as Flash allow definition of permissions at embed -- meaning Perl.com could limit some of the features available inside the ActionScript run-time." Variable permissions, controlled by the invoking domain, as a useful step forward for in-browser apps....

Anyway, I think Nat Torkington raised a very important issue here. Connecting websites together isn't necessarily bad, but we need to be more careful about how we do so. We need to monitor and inspect the programming we receive... we can't just blithely run around and Obey Alien Orders. We need to consider how we're being programmed.

Copyright © 2009 Adobe Systems Incorporated. All rights reserved.
Use of this website signifies your agreement to the Terms of Use and Online Privacy Policy (updated 07-14-2009).