-
Notifications
You must be signed in to change notification settings - Fork 85
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
User Permission for Background Sync #141
Comments
Hi @RichardMaher! This is the repo for spec issues, concerns about particular implementations should be posted in the bug tracker for that particular browser. I'll respond anyway…
On desktop you click the security chip in the URL bar (where the other permission options are). This doesn't appear to be there on mobile, so I've filed https://bugs.chromium.org/p/chromium/issues/detail?id=729539 to see if it's an oversight.
The "P" standards for progressive as in progressive enhancement which background sync is entirely compatible with. See https://developers.google.com/web/updates/2015/12/background-sync#progressive_enhancement for how to apply it in this situation.
Quoting from https://developers.google.com/web/updates/2015/12/background-sync#permissions
There's also #80 which has some permission API discussion.
Is there a particular attack you think background sync exposes users to? Closing, but will reopen if this turns out to be a valid concern. |
This is wrong and two wrongs don't make a right. I am extremely surprised to see Mozilla implement this but the analytics bullies must be too strong. But such is the power of precedent. I will get on to marketing and ask for some serious sounding security-mitigation clauses and sufficient fluff and before you know it "Prompting for permission for Background Geolocation" will be a poor user experience. Add that to "sendBeacon and BackgroundSync already do this" and we're over the wire! |
You can't simply state these things, you need to give reasoning. By showing your working, it may become obvious that your understanding of these features is incorrect.
This kind of "slippery slope" reasoning is lazy. If you can't explain how one directly enables another, all you have is FUD. |
WRT the spec. The following privacy vulnerabilities are sufficient to warrant user-awareness, indeed to facilitate user-sanction, in the eyes of any casual observer: - 4.2 Location Tracking My interest here OTOH stems from the need to bolster the argument that the Capability Permissions model cannot solve all requirements and that background-synch and background-fetch are two such requirements. WRT a specific implementation (Chrome) I find the following text coercive and potentially misleading regarding "recently" : - WRT to "This doesn't appear to be there on mobile, so I've filed [a bug]" My guess is that bug will never be triaged and that statement is equivalent to "These are very serious issues and we've formed a committee to investigate fully. I couldn't possibly preempt their findings by commenting here." Finally, I don't think that many Ultimate Web App and SPA users have the URL chrome on their displays so that some dicky options for BackgroundSync can be located? Do you seriously expect users to type in browser-security domain-exceptions with their virtual keyboard? "Poor" user experience? |
Can you demonstrate how those are leaked compared to
This is the repo for spec issues, concerns about particular implementations should be posted in the bug tracker for that particular browser. |
WRT privacy considerations how can a user "opt-out" of Background-Sync from a fullscreen PWA when there is no way to get at esoteric and obscure browser options?
Also isn't is going against the grain of the "P" in PWA to expose a user to privacy risks by default and force them to "opt-out" of the danger zone?
Why has the Permissions API been completely bypassed here?
The text was updated successfully, but these errors were encountered: