Comments (11)
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.
from background-fetch.
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.
from background-fetch.
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:
- 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.
from background-fetch.
Would the solutions in my first comment work?
from background-fetch.
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.
from background-fetch.
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.
from background-fetch.
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
from background-fetch.
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?
from background-fetch.
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.
from background-fetch.
Are there any cases where a top level document isn't "first party"? Eg, cases where there's a window.opener
from background-fetch.
I think thus far popups are considered first party.
from background-fetch.
Related Issues (20)
- Gate background fetch on user activation HOT 8
- background fetch can start service workers HOT 21
- backgroundfetchclick event handler is optional HOT 4
- Should web pages without service workers be able to use bgfetch? HOT 1
- [CHROME ANDROID] responseReady still pending, no progression, upload locked HOT 1
- Status? HOT 7
- Content-Range header parsing HOT 2
- single byte content-range prefix HOT 1
- Content-Range header parsing * comparison
- ok status vs 200/206 HOT 1
- Move generic range bits into Fetch?
- Guard for Headers object
- Make bikeshed complain less HOT 5
- Don't require Cache API to have a secure context HOT 6
- Does bgFetch does not support PUT method?
- Broken references in Background Fetch HOT 5
- WPT background fetch do not seem aligned with background fetch specification
- Should request stream be aborted if the upload is failing HOT 1
- option to defer until NetworkInformation type change HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from background-fetch.