Contact emails
na...@chromium.org, kenji...@chromium.org
Explainer
http://wicg.github.io/BackgroundSync/explainers/periodicsync-explainer.md
Spec
Spec: https://wicg.github.io/BackgroundSync/spec/PeriodicBackgroundSync-index.html
Tag review. (Positive signals)
Summary
Periodic Background Sync is a continuation on Background Sync, which is in the charter for the Service Workers Working Group and expected to move over soon. It allows websites to register tasks to be run in a service worker at periodic intervals with network connectivity.
Link to “Intent to Implement” blink-dev discussion
Intent to Implement: https://groups.google.com/a/chromium.org/d/topic/blink-dev/iaAyTxWmx7o/discussion
Link to Origin Trial feedback summary
https://docs.google.com/document/d/1mCd5ygZHgx7Kejk6QwtI05quI_gR80eXPTdCMRW9eag/edit?usp=sharing
Intent to Experiment: https://groups.google.com/a/chromium.org/d/topic/blink-dev/aHdERJoKYh8/discussion
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes, except WebView. This is because there are difficulties with the lifetime of a WebView client, and with identifying the right WebView client on a page to which the Periodic Sync event should be dispatched.
Demo link
https://webplatformapis.com/periodic_sync/periodicSync_improved.html
Debuggability
The following debuggability tools have been added to Chrome DevTools behind a Devtools Experiment:
Recording of important Periodic Background Sync events like registration, unregistration, dispatch and completion of a periodicsync event with extra information wherever appropriate, like the computed next event delay.
A button to dispatch a one-off periodicsync event, which will help the developer test their response to the event.
These will be released along with the API.
Details can be found at https://web.dev/periodic-background-sync/#debugging
Risks
Interoperability and Compatibility
The API has been designed to be flexible and allows the user agent to define their own security and privacy model around the `periodic-background-sync` permission. We’ve made the API future-proof by making one of the input parameters to the register() method an `options` dictionary, which can be extended with more inputs from developers, without breaking existing usage.
Chrome’s implementation restricts the API to installed web apps. Chrome grants the permission on behalf of the user for any installed web app. The API is not available outside of installed PWAs. There is a risk that developers will code their web apps to expect this permission to be granted.
Edge: Positive signals.
Firefox: Consider this ‘harmful’, stating concerns around privacy. Discussion here, and here.
Safari: No public signals. Feedback requested here.
Web / Framework developers: The feature won the award for the best anticipated Chrome feature at CDS 2019. Very encouraging feedback from Origin Trials, with everyone who signed up for the API finding it easy to use, and intending to use it once it’s shipped. Strong positive signals from Gaana. Encouraging feedback from early explorations by Hatena.
Ergonomics
Developers should use the Permissions API before registering a Periodic Sync. In the event listener, we expect them to use Fetch API for fetches, or Background Fetch API for any large downloads/uploads.
Activation
Documentation with examples should help make understanding usage easy. A detailed guide has been published at: https://web.dev/periodic-background-sync
Both the spec and the explainer have code examples. A demo site has been published with code on GitHub.
Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.
Minimal WPT tests here.
Web-platform-tests Issue explaining what’s needed from the Infra to test this more thoroughly here.
Entry on the feature dashboard
https://www.chromestatus.com/feature/5689383275462656
On request, here's some clarification on Mozilla's stance:
The concern is that the browser may surprise the user by running JavaScript code in the background when the periodicsync event is fired long after the user has navigated away from the page. This concern also applies to one-off Background Sync (explainer).
Here’s why we think the API allows them to handle their concerns:
1. Because the API gates the capability on the newly-introduced "periodic-background-sync" permission, the user agent can build their own privacy story for the API, including deciding for the user when the capability should be blocked. The user agent can also show any UI around the API for attribution of background activity.
2. The user agent is in control of when and how often the periodicsync events fire, and what execution time is allowed each time they do.
3. Beyond designing the API to allow for any security and attribution model, we've also restricted the ability to create registrations to top-level frames to further de-risk future compatibility.
Chrome's implementation gates the capability on installation and continued engagement with the site, while providing an opt-out mechanism to the user. Here's a summary of Chrome's privacy reasoning (write-up by msr...@chromium.org).
We thus believe what we have is sufficiently conservative in exposure, more resource-efficient than synchronizing through Web Push. The API gives us the opportunity to align the web with native capabilities, significantly improving on existing workarounds for the capability. The overwhelmingly positive developer feedback demonstrates clear value-add.
On request, here's some clarification on Mozilla's stance:
The concern is that the browser may surprise the user by running JavaScript code in the background when the periodicsync event is fired long after the user has navigated away from the page. This concern also applies to one-off Background Sync (explainer).
Here’s why we think the API allows them to handle their concerns:
1. Because the API gates the capability on the newly-introduced "periodic-background-sync" permission, the user agent can build their own privacy story for the API, including deciding for the user when the capability should be blocked. The user agent can also show any UI around the API for attribution of background activity.
2. The user agent is in control of when and how often the periodicsync events fire, and what execution time is allowed each time they do.
3. Beyond designing the API to allow for any security and attribution model, we've also restricted the ability to create registrations to top-level frames to further de-risk future compatibility.
Chrome's implementation gates the capability on installation and continued engagement with the site, while providing an opt-out mechanism to the user. Here's a summary of Chrome's privacy reasoning (write-up by msr...@chromium.org).
We thus believe what we have is sufficiently conservative in exposure, more resource-efficient than synchronizing through Web Push. The API gives us the opportunity to align the web with native capabilities, significantly improving on existing workarounds for the capability. The overwhelmingly positive developer feedback demonstrates clear value-add.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ae09379f-9056-4acd-87da-0d8d26e99125%40chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEiFxnNREzwn-N%2BAuAHW%2BwB_cXOTjxBpM%2B4hRYafo%3DtkbQ%40mail.gmail.com.
LGTM2
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ae09379f-9056-4acd-87da-0d8d26e99125%40chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
On Wed, Dec 4, 2019 at 3:21 PM Mugdha Lakhani <na...@chromium.org> wrote:
> Here’s why we think the API allows them to handle their concerns:
>
> 1. Because the API gates the capability on the newly-introduced "periodic-background-sync" permission, the user agent can build their own privacy story for the API, including deciding for the user when the capability should be blocked. The user agent can also show any UI around the API for attribution of background activity.
>
> 2. The user agent is in control of when and how often the periodicsync events fire, and what execution time is allowed each time they do.
>
> 3. Beyond designing the API to allow for any security and attribution model, we've also restricted the ability to create registrations to top-level frames to further de-risk future compatibility.
To be clear, it doesn't.
1. Having a permission that allows for any UI doesn't mean that a
reasonable UI can be made. Similar arguments keep being made for
various features, but that doesn't mean they're valid or true.
2. This sounds like a potential interoperability nightmare.
3. Restricting to first-parties is table stakes these days.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADnb78hSPhWZ8kpCSkBp%3DJowTy0R4nCBKgdw-YwiOxFJgJTCpg%40mail.gmail.com.
On Thu, Dec 5, 2019 at 6:05 PM Anne van Kesteren <ann...@annevk.nl> wrote:On Wed, Dec 4, 2019 at 3:21 PM Mugdha Lakhani <na...@chromium.org> wrote:
> Here’s why we think the API allows them to handle their concerns:
>
> 1. Because the API gates the capability on the newly-introduced "periodic-background-sync" permission, the user agent can build their own privacy story for the API, including deciding for the user when the capability should be blocked. The user agent can also show any UI around the API for attribution of background activity.
>
> 2. The user agent is in control of when and how often the periodicsync events fire, and what execution time is allowed each time they do.
>
> 3. Beyond designing the API to allow for any security and attribution model, we've also restricted the ability to create registrations to top-level frames to further de-risk future compatibility.
To be clear, it doesn't.
1. Having a permission that allows for any UI doesn't mean that a
reasonable UI can be made. Similar arguments keep being made for
various features, but that doesn't mean they're valid or true.Is this a foregone conclusion? What is the evidence?Which situations do you think are impossible to address neither via UI nor point #2.
2. This sounds like a potential interoperability nightmare.In what ways? Periodic Background Sync is a best effort affair. There shouldn't be any expectation of this feature behaving in an exact precise way that developers would depend on.
On Thu, Dec 5, 2019 at 1:37 AM 'Kenji Baheux' via blink-dev <blin...@chromium.org> wrote:On Thu, Dec 5, 2019 at 6:05 PM Anne van Kesteren <ann...@annevk.nl> wrote:On Wed, Dec 4, 2019 at 3:21 PM Mugdha Lakhani <na...@chromium.org> wrote:
> Here’s why we think the API allows them to handle their concerns:
>
> 1. Because the API gates the capability on the newly-introduced "periodic-background-sync" permission, the user agent can build their own privacy story for the API, including deciding for the user when the capability should be blocked. The user agent can also show any UI around the API for attribution of background activity.
>
> 2. The user agent is in control of when and how often the periodicsync events fire, and what execution time is allowed each time they do.
>
> 3. Beyond designing the API to allow for any security and attribution model, we've also restricted the ability to create registrations to top-level frames to further de-risk future compatibility.
To be clear, it doesn't.
1. Having a permission that allows for any UI doesn't mean that a
reasonable UI can be made. Similar arguments keep being made for
various features, but that doesn't mean they're valid or true.Is this a foregone conclusion? What is the evidence?Which situations do you think are impossible to address neither via UI nor point #2.We can't assume that every API design can have an effective UX. (See, e.g. https://www.usenix.org/conference/enigma2019/presentation/stark) If knowledgeable people have put in a good-faith effort to design a solution and have failed, that's evidence that it's at least too difficult to handwave away.Now, I'm not sure that applies here. "It might surprise users" is not inherently a privacy problem. "It might use too much battery life/data" can probably be mitigated by limiting battery execution/data use to 0.X% of total browser execution time/data use. "It might expose your location via IP" is the most difficult, but I see Mozilla just announced a product to solve that: https://fpn.firefox.com/. But we have to actually go through the exercise of sketching solutions to the known privacy problems instead of just saying that a permission-request-based API solves everything.
2. This sounds like a potential interoperability nightmare.In what ways? Periodic Background Sync is a best effort affair. There shouldn't be any expectation of this feature behaving in an exact precise way that developers would depend on.Hyrum's law says they'll wind up depending on whatever Chrome does, even if the specification (which they won't read) says other behaviors are allowed. Chrome has to "grease" any behaviors we want to leave open for other or future implementations to adopt.
Jeffrey
Safari: No public signals. Feedback requested here.
I frankly don't understand why native apps may behave in almost any way they want, while installed web-apps are always looked at in terms of abuse and security concerns. I absolutely hope that Google will implement the periodic background sync in a usable way for installed web-apps.
Though browsers add an additional layer of protection around web-apps, we still have arbitrary restrictions that native apps don't have. And this has very little to do with people's safety and privacy. Take web-push for example: I can install a random app from any app store and it is perfectly able to receive push notifications even if the device is in doze. Web-apps can't do that. I still haven't found a single reason why. Same with video/audio auto play or the new timed notification API. Now if those restrictions would be in place for normal web sites, I wouldn't even argue with you. But those restrictions are enforced regardless if a webapp is installed or not.
And I can't help but wonder, if there are other or additional reasons why web-apps aren't allowed to compete with native on a level playing field.
We're trying to make sure the safety, privacy, and control mechanisms are not arbitrary, and that they don't seem arbitrary to users or to developers. Toward that end, some people on the Chrome team have written up an explanation of how we try to apply the mechanisms that are available to us. Note in particular that "Installation or engagement alone should not act as a vote of trust for either granting access or enabling the ability to ask for access to powerful APIs."
The Chromium project's specific goal is to make the web as useful an application platform as possible. But we do also have to meet a high bar for safe usability and usable safety. We're in a new era of platform design requirements, and the problems and tensions are just plain hard.The old days of developers having unfettered access to everything all the time are over — and, again, I think you'll find that's gradually but increasingly true for native platforms, too. We live in a different world now.
To not lose scope: Periodic background sync might have been a great idea, but the time frame of 12 to 36 hrs
and the lack of control or influence the developers have makes this API makes it just another meh kind of thing.
Like web-push. Like a Tesla with a flat. Sure you can drive it, but ...
@Kenji ..I am not sure with whom you are talking, but most of my peers think this API is severely lacking. First: It completely depends on the app not being in doze.
Second the sync is not guaranteed to happen at specific times
or at all - because the time frame 12 - 36 hrs is flexible and the web-dev has no influence about it. Let's say an app has a very active user interacting several times a day. So each time the app is started, it needs to download the complete content-update - which might not even be possible because of 'no network' situations.
We would have hoped the the periodic background sync would allow us to set something like 1hr intervals to really keep a web-app 'up to date' and the user happy, even if she's currently not connected.
m.
On Wednesday, December 11, 2019 at 5:50:42 PM UTC-6, Kenji Baheux wrote:On Thu, Dec 12, 2019, 03:35 <roll...@gmail.com> wrote:To not lose scope: Periodic background sync might have been a great idea, but the time frame of 12 to 36 hrsFor the use cases we heard about, this doesn't feel like a non starter. It's possible that we missed an important set of use cases though. What's the user story for which this wouldn't work at all?and the lack of control or influence the developers have makes this API makes it just another meh kind of thing.We've heard requests from developers around this. Concretely, a lot of the use cases need the ability to get their sync fire during a specific timeframe to work well, e.g. having the sync event fire early mornings before a user goes on their commute to fetch the latest batch of news through the home wifi, etc.This is being worked on as a follow-up. Would that cover your needs? If not, would you mind filing an issue with the use case at: https://github.com/WICG/BackgroundSync/issuesThanks!Like web-push. Like a Tesla with a flat. Sure you can drive it, but ...I heard that the Cybertruck has puncture-proof tires.... nevermind :)
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/39e969b2-f013-4f30-9169-6ee8c613e5c4%40chromium.org.