I intended the "resistant to malice and incompetence" definition of safe, not the idempotent definition of safe. Thanks for clarifying.<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Linus</div><div><br><br><div class="gmail_quote">On Wed, Jul 29, 2009 at 11:15 AM, Drew Wilson <span dir="ltr"><<a href="mailto:atwilson@google.com">atwilson@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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"). <div>
<br></div><div>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?</div>
<div><br></div><div>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.</div>
<div><br></div><div>-atw</div><div><div></div><div class="h5"><div><br><div class="gmail_quote">On Wed, Jul 29, 2009 at 10:48 AM, Linus Upson <span dir="ltr"><<a href="mailto:linus@google.com" target="_blank">linus@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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:<div><br></div><div>1. All links are safe to click</div><div>
<br></div><div>2. When a page is closed, the only artifacts left behind are items in various caches</div><div><br></div><div>3. The user agent is free to evict items from its various caches at any time</div><div><br></div>
<div>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.</div>
<div><br></div><div><div><div>Linus</div><div><br><br><div class="gmail_quote"><div>On Tue, Jul 28, 2009 at 10:58 PM, Maciej Stachowiak <span dir="ltr"><<a href="mailto:mjs@apple.com" target="_blank">mjs@apple.com</a>></span> wrote:<br>
</div><div><div></div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
On Jul 28, 2009, at 10:01 AM, Drew Wilson wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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<br>
</blockquote>
<br>
Here's some security risks I've thought about, for persistent workers and persistent background pages:<br>
<br>
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.<br>
<br>
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.<br>
<br>
3) If they have notification capabilities, they can be used for advertising spam.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Regards,<br><font color="#888888">
Maciej<br>
<br>
</font></blockquote></div></div></div><br></div></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>