Re: Background sync & push messaging: declarative vs imperative

On Jan 2, 2014, at 9:33 AM, John Mellor <johnme@google.com> wrote:

> On Thu, Dec 19, 2013 at 9:32 PM, Maciej Stachowiak <mjs@apple.com> wrote:
> 
> On Dec 19, 2013, at 9:02 AM, John Mellor <johnme@google.com> wrote:
> 
>> [cross-posted to public-webapps and public-sysapps]
>> 
>> A couple of us from Chrome have taken a holistic look at how we could add standardized APIs for web apps to execute/sync in the background.
>> 
>> This is an important capability, yet can be safely granted to low-privilege web apps, as long as battery consumption and metered data usage are (very) carefully limited.
> 
> Running arbitrary JS in the background, without the relevant page open, and with full networking capabilities, does not seem safe to me. How did you conclude that this capability can safely be granted to low-privilege web apps?
> 
> Good question (and great examples!). Low-privilege is relative - I did not intend that any website could use this without asking; instead some combination of heuristics like the following might be required:
> user added webapp to their homescreen (or bookmarked it?)
Bookmarking doesn't give the feel of an "install" operation so it seems poor to tie it to elevated privileges (as opposed to something like an install operation from a curated store).
> user frequently visits webapp domain
That's frighteningly implicit and would also prevent webapps from using this mechanism for sync until after the user has used the webapp more than some threshold, which gives a poor out-of-the-box experience if sync is a key feature.
> user accepted permission dialog/infobar
Explicit permission seems poor for this because the consequences are too subtle to understand easily (unlike, say, granting access to geolocation where the consequence is obvious and understandable).

> Some of the specific threats I'd be concerned about include:
> 
> (1) An attacker could use this capability to spread a botnet that can be used to mount DDOS attacks or to perform offline distributed computations that are not in the user's interest, without needing a code execution exploit or sandbox escape.
> 
> Some mitigating factors:
> The same-origin policy would apply as usual, so you'd only be able to DDOS hosts that allow CORS (and the apps own host).
The network request is issued before the browser knows whether CORS is allowed, so that would not be a mitigation (unless DDOS specifically requires non-GET methods or reading the response).
> Both network requests and computations (Bitcoin mining?) would be heavily throttled by the browser in order to conserve battery; if we base the throttling on how often the webapp is used, and penalise expensive background syncs, it would be possible to enforce that total execution time in the background is limited to some small multiple (possibly even 1x or below) of the total execution time in the foreground.
It seems like such a limit would make it hard to use the feature for the posited use cases because it would be unreliable.
> 
> (2) An attacker could use this capability to widely spread an innocuous looking background service which, based on remote command-and-control, attempts zero-day exploits against the user's browser at a time of the attacker's choosing. This can happen without visiting the malicious site, indeed, while a user doesn't have a browser open, and can possibly happen faster than even the fastest-updating browser could plausibly patch.
>  
> Yes, this is a subtle downside of the imperative approach. For frequently used apps it probably doesn't make a huge difference; conversely if we stopped syncing completely for apps that haven't been used in a long time, this concern might be minimized.

For the posited use cases, the time limit probably needs to be long enough that your apps won't stop working after a reasonable but long vacation. That would still be a bigger window of opportunity for attack than a one-time visit.

>  
> These both seem unsafe to me, compared to the security of the Web as it stands today. And I don't think a permissions dialog would be a sufficient mitigation, since it is hard to explain the danger to users.
> 
> On the other hand, native apps can already do both of the above unsafe activities, and installing them is effectively just a permissions dialog away. App store review processes may filter out undesirable behavior in the static parts of apps, but struggle to keep up with dynamically-updating content, e.g. in embedded WebViews.

There's a few relevant differences between apps (particularly installed via an app store) and webpages besides review:

(1) Users have different expectations of what apps and webpages can do.
(2) Apps generally have a way to uninstall, after which they stop affecting your system. For webpages, there generally isn't an uninstall operation other than just closing the page.
(3) At least app stores require personally identifying information such as a credit card to get a developer account, this could potentially allow perpetrators to be tracked after the fact.
(4) App stores allow further propagation to be prevented once a problem is discovered.
(4) Some app stores may allow remote kill of a misbehaving app.

For these reasons, I think a feature to run arbitrary JS code in the background is best limited to webapps that follow an "install" type model. I could see the case for a more declarative approach specifically limited to sync-style use cases.

Regards,
Maciej