Maciej, thanks for sending this out. These are great points - I have a few responses below. The main thrust of your argument seems to be that allowing web applications to run persistently opens us up to some of the same vulnerabilities that native (desktop and mobile) apps have, and I agree with that. The question (as with native apps) is whether we can mitigate those vulnerabilities, and whether the functionality that persistence provides is worth the larger attack surface.<div>
<br><div class="gmail_quote">On Tue, Jul 28, 2009 at 10:58 PM, Maciej Stachowiak <span dir="ltr"><<a href="mailto:mjs@apple.com">mjs@apple.com</a>></span> wrote:<br><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.</blockquote><div><br></div><div>Indeed. There are mitigations against this (basically, leveraging some of the same infrastructure we have in place to warn users of malware), although not all browsers have this protection currently. But, yes, this (intentionally) makes the browser more similar to the desktop environment, and so more vulnerable to desktop-style attacks.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<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.</blockquote>
<div><br></div><div>That's an interesting point. Basically, once I've gotten a farm of people to install persistent workers, I can just rebind my domain to any arbitrary IP address, and now that domain could get a flood of HTTP connections.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
3) If they have notification capabilities, they can be used for advertising spam.</blockquote><div><br></div><div>Yes, although the point of notifications is that 1) they are opt-in and 2) they are easy to opt-out (there's a "block" button on the notification). So I don't know that this is a real issue - the point of notifications is that it's really easy to undo your decision to grant access. I'd say that rather than this being a security issue, it's a UX issue to make sure that users have a way to get rid of annoying notifications easily and permanently.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<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.</blockquote>
<div><br></div><div>Good point, although I don't think this would be an acceptable restriction anyway. One of the whole points behind persistent workers is that they can keep a local data cache up-to-date (i.e. "list of upcoming calendar events") regardless of whether a page is open.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<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>
</blockquote><div><br></div><div>Agreed. Once you have your software running on many machines, there are many things you could do with those cycles. Attackers probably won't be folding proteins :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<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.</blockquote>
<div><br></div><div>Agreed that this is a big deal, and is a problem I hadn't considered previously. I would assume that browser malware detection would blacklist these sites, but I hate to lean on some magical malware detection infrastructure too heavily. This seems like an issue that Apple and Microsoft have dealt with for years in their OS offerings - how do they handle this?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><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.</blockquote><div><br>
</div><div>And as you say, since the worker author assumedly controls the domain DNS, a "same-domain" restriction is pretty meaningless. Clearly not a well-thought-out suggestion on my part. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<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>

</blockquote><div><br></div><div>Yeah, I'm not sure whether permissions dialogs are the right solution here. I do think it's a UX challenge to accurately portray what's happening - it may run counter to the expectations of some users. I do find it interesting that we allow users to install and run native applications with at most one or two warning dialogs (which can often be disabled) but feel that these same users can't be trusted to make this decision when the content of that application is javascript instead of x86 binary.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><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>

</blockquote><div><br></div><div>That's another option - using extensions to enable this, although it's somewhat heavyweight for someone who just wants to get google calendar event notifications, and doesn't extend cross-browser. I'm starting to think more about a user-initiated install process, to help mitigate some of the social engineering attacks by an application-initiated "click here to install me"-type process.</div>
<div><br></div><div>Agreed that my reference to malware detection is essentially your "central vetting and revocation capabilities".</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Regards,<br><font color="#888888">
Maciej<br>
<br>
</font></blockquote></div><br></div>