Restrict background-fetch to first party contexts

[youennf]

Background fetch might require displaying User Agent UI to show ongoing background fetch states.
Displaying such information is particularly hard to do for third-party contexts which origin the user may never have seen before. One possible mitigation is to restrict background fetch to first party origin only.
The notion of quota is also much simpler in the context of first party origins.

[jakearchibald]

This seems reasonable, although difficult to spec as double-keying is unspecified, or has this changed?

I guess we could say that the permission state for "background-fetch" starts as "denied" until the user visits that origin as top-level.

This would prevent all double-keyed origins from using background fetch, since they're never visited as top level.

In browsers that don't double-key, it would also prevent iframed origins from using background fetch unless the user had visited them top-level, but that seems like a good thing. As you say, it's weird to show downloads from origins the user hasn't seen before.

Would that work? I'm not entirely sure how to spec it, but I guess it could be hand-waved.

[jakearchibald]

Fwiw, Safari currently seems to allow iframes to trigger downloads: https://jsbin.com/tevedur/quiet.

It triggers a permission prompt, but that seems equivalent to an auto-paused download in bgfetch.

[youennf]

Since this is a new API, I think we should get inspiration from downloads wherever appropriate.
On the other hand, we might not need to cover all download cases.

@annevk might know more but work is on going for double keying:

• Double-keyed HTTP cache whatwg/fetch#904 is keying the HTTP cache
• https://w3c.github.io/mediacapture-main/#dom-mediadeviceinfo-deviceid is describing double keying of device ID where appropriate.

Also, if we have BackgroundFetchManager.fetch exposed to Window only, this probably makes things much simpler.

[jakearchibald]

Would the solutions in my first comment work?

[annevk]

Using the top-level origin concept we can define first-party. Though we haven't quite agreed on whether that's same-site or same-origin so perhaps it's best not to use it formally. I think Feature Policy uses the latter and some other stuff (including current storage partitioning efforts) the former.

I'm not sure your solution works as the origin itself isn't necessarily the one that's double-keyed (that would also affect CORS and such). It's more that various other checks end up taking more into account.

[jakearchibald]

@youennf

Also, if we have BackgroundFetchManager.fetch exposed to Window only, this probably makes things much simpler.

That would prevent downloads being started from a push message, which seems bad. I'd rather keep the API, and allow UAs to start downloads paused (effectively asking the user for permission), started (if the user has expressed permission), or auto-deny (if the user has denied 'background' downloads from the site).

I'm happy to prevent bgfetch from contexts that aren't first-party though, if we've got a definition somewhere I can use.

[youennf]

Maybe we could spec it for window contexts and have a note stating we would like to apply the same restriction for service workers?
For window contexts, we could use https://html.spec.whatwg.org/multipage/webappapis.html#top-level-origin

[jakearchibald]

I'm happy to use language like "first party" along with a note/issue saying we're waiting on real spec terms to use. Would that work?

[annevk]

privacycg/storage-access#29 introduces a definition, but I think we need to have both concepts around "first-party site" and "first-party origin" and whenever we can we probably want to use the latter, which would check environment's origin and environment's top-level origin and do a same origin comparison on them.

[jakearchibald]

Are there any cases where a top level document isn't "first party"? Eg, cases where there's a window.opener

[annevk]

I think thus far popups are considered first party.