- From: Linus Upson <linus@google.com>
- Date: Wed, 29 Jul 2009 13:31:01 -0700
I intended the "resistant to malice and incompetence" definition of safe, not the idempotent definition of safe. Thanks for clarifying. Even in a world of exceptionally sophisticated applications, now and in the future, I think it is worth preserving the safe and stateless properties of the web. The challenge is exposing new capabilities in a way that is compatible with those properties. Naively bringing over APIs from desktop apps may not always work. For example, a typical desktop app can, at any time, read all of my files. Web apps need access to files too, but I don't want every web page see all my files. The <input type="file"> API and UI were designed to grant access to only the files I want to make available, and do so in a way that is natural. Even in this simple case there were subtle security issues that took years to emerge and address. We need to take a similar approach with other new capabilities without adding a new install escape hatch to the web. For capabilities where we aren't yet clever enough to come up with a safe and stateless solution, using the existing install mechanism of extensions and their attendant security features seems like a good way forward. Linus On Wed, Jul 29, 2009 at 11:15 AM, Drew Wilson <atwilson at google.com> wrote: > I'd agree with #1, for some given value of "safe" - we've all heard tales > of search engines inadvertently deleting data on people's sites by following > links. Note that web storage violates #2 and #3 (and even cookies could be > viewed as a violation of #2, depending on how broadly you view "caches"). > But I would agree that what you've mentioned below are characteristics of > traditional web browsing. If we went back in time several years, we might > have added in some restrictions about how "data is only posted to the server > in response to explicit user activity/form submittal". I think we should be > open to the possibility that the characteristics of web browsing today are > not necessarily inherent to the web browsing experience, and may change over > time. Should web browsing in 2020 look like web browsing in 2010? Will web > pages still be restricted to a sandbox with a close button? > > It seems like the tenets below are quite appropriate for the "browser as > content-delivery platform". But they are already starting to change for > "browser as application platform". The challenge is to balance the safety of > a content-delivery platform while still giving applications the power they > need. > > -atw > > On Wed, Jul 29, 2009 at 10:48 AM, Linus Upson <linus at google.com> wrote: > >> This is a good analysis. I agree that it is important for the web to >> maintain some important properties that are in conflict with persistent >> background processing: >> 1. All links are safe to click >> >> 2. When a page is closed, the only artifacts left behind are items in >> various caches >> >> 3. The user agent is free to evict items from its various caches at any >> time >> >> For apps that desire capabilities that are not "safe and stateless" I like >> your suggestion to use the browser's extension mechanism (or runtimes such >> as prism or air). Those services usually involve some combination of >> multiple affirmative steps, vetting, reputation and revocation. >> >> Linus >> >> >> On Tue, Jul 28, 2009 at 10:58 PM, Maciej Stachowiak <mjs at apple.com>wrote: >> >>> >>> On Jul 28, 2009, at 10:01 AM, Drew Wilson wrote: >>> >>> I've been kicking around some ideas in this area. One thing you could do >>>> with persistent workers is restrict network access to the domain of that >>>> worker if you were concerned about botnets. That doesn't address the "I >>>> installed something in my browser and now it's constantly sucking up my CPU" >>>> issue, but that makes us no different than Flash :-P >>>> >>> >>> Here's some security risks I've thought about, for persistent workers and >>> persistent background pages: >>> >>> 1) If they have general-purpose network access, they are a tool to build >>> a DDOS botnet, or a botnet to launch attacks against vulnerable servers. >>> >>> 2) If they do not have general-purpose network access, this can be worked >>> around with DNS rebinding. Note that ordinarily, DNS rebinding is only >>> considered a risk for content protect by network position. But in the case >>> of a DDOS or attempt to hunt for server vulnerabilities, this doesn't matter >>> - the attack doesn't depend on the DDOS node sending credentials. >>> >>> 3) If they have notification capabilities, they can be used for >>> advertising spam. >>> >>> 4) If they have general network access only while a page from the same >>> domain is displayed, then they can use a misleading notification to trick >>> the user into going to a page on that domain, to gain network general >>> network access at the moment it's needed. >>> >>> 5) Even if they only have same-domain network access, they can be used to >>> create a botnet for computation - for example for purposes like distributed >>> password cracking. >>> >>> 6) They can be used to greatly extend the window of vulnerability from >>> visiting a malicious site once. Consider the model where a browser patches a >>> security vulnerability, and users apply the patch over some period after >>> it's released. Assuming the vulnerability wasn't already known to attackers, >>> users are at risk if they visit a malicious site in the period between >>> release of the patch and install of the patch. But with persistent workers >>> (or background pages) in the picture, users can be vulnerable if they have >>> *every* visited a malicious site - because it could have installed a >>> persistent worker that periodically "phones home" for exploit code to try. >>> This can greatly increase the number of people who can be affected by a >>> malicious web page, and therefore greatly increases the incentive to try >>> such a thing. This works even with just same-doman network access. I think >>> this risk is really serious because it makes every future browser >>> vulnerability much more dangerous. >>> >>> 7) Even with only same-domain network access, the persistent worker could >>> periodically "phone home" to allow tracking of the user by IP, which can be >>> mapped to an approximate physical location. Normally, a page you don't have >>> open can't do that to you. >>> >>> This list isn't necessarily exhaustive, I'm sure there's more risks I >>> haven't thought of, but note that most of these problems are not resolved by >>> limiting networking to same-domain. >>> >>> I don't think a permissions dialog could possibly adequately explain >>> these risks, and in any case many users blindly click through alert dialogs. >>> The risks are subtle but nonetheless outside user expectations for a web >>> application. >>> >>> I do think offering a feature like this in the context of an application >>> or extension style install experience might be acceptable - specifically an >>> experience that is explicitly initiated by the user with multiple >>> affirmative steps. But web features are not usually designed around such an >>> expectation, usually this is the hallmark of a proprietary platform, at >>> times also including central vetting and revocation capabilities. >>> >>> Regards, >>> Maciej >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090729/c44f0841/attachment.htm>
Received on Wednesday, 29 July 2009 13:31:01 UTC