Intent to Ship: Periodic Background Sync

[Mugdha Lakhani]

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:

1. 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.

2. 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

[Michaela Merz]

I think this is a great idea. Thank you. Just to clarify (from the explainer): The Push-API can (IMHO) currently not deliver any content at least not without bothering the user

with op-up messages. I assume the periodic background sync will not cut through doze?

m.

[Mugdha Lakhani]

Thanks Michaela.

Yes, Chrome's implementation will not fire periodicsync events in doze mode on modern versions of Android, but rather will fire in the recurring maintenance window the OS allows to apps.

[Mugdha Lakhani]

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.

[sligh...@chromium.org]

Glad to see this restricted to installed PWAs; LGTM1

[Yoav Weiss]

LGTM2

On Wed, Dec 4, 2019 at 3:21 PM Mugdha Lakhani <na...@chromium.org> wrote:

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.

Thank you for the detailed explanation! Gating on permission + installation makes perfect sense in order to make sure user expectations are aligned. Keeping the UA in control also makes sense.

 

--
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.

[Chris Harrelson]

LGTM3

This is a great addition, glad to see it shipping! Also happy that you've thought through the permissions story carefully.

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.

[Mugdha Lakhani]

Thanks everyone!

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.

[Anne van Kesteren]

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.

[Kenji Baheux]

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.

 

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.

--

Kenji BAHEUX

Product Manager - Chrome

Google Japan

[Jeffrey Yasskin]

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

[Kenji Baheux]

On Fri, Dec 6, 2019, 04:53 Jeffrey Yasskin <jyas...@chromium.org> wrote:

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.

Indeed. I'm interested in hearing more details like these.

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.

My assumption is that the key differences would be if and when the sync event triggers if at all. It's already out of direct control of the developers. Further changes shouldn't create weird interoperability issues. But if there is a scenario that I'm missing, I'd love to hear about it.

Jeffrey

[mac...@gmail.com]

On Tuesday, December 3, 2019 at 10:35:47 AM UTC-8, Mugdha Lakhani wrote:

Safari: No public signals. Feedback requested here.

After discussion with colleagues, I've entered the Apple position on the WebKit bug cited. It is negative.

For future reference, filing a feature request in our bug tracker is not the best way to obtain a standards position for Safari (or Apple or the WebKit project). I would recommend tagging a relevant WebKit person on an existing spec GitHub issue, emailing webki...@webkit.org, or asking myself or Tess O'Connor to provide a public position somewhere.

Also for reference, since this is coming late and the position was originally "no public signals", our objections are inline below. I've also filed the security risks as an issue against the spec, since they don't appear to have been raised already. <https://github.com/WICG/BackgroundSync/issues/169>

-----------------------

We oppose this feature and will not implement it.

Reasons:

(1) We are opposed to Service Worker Background Sync and this extends Background Sync.

(2) We agree with all the reasons that Mozilla stated in considering this specification to be “harmful” <https://github.com/mozilla/standards-positions/issues/214#>.

(3) To be more specific there is a significant privacy risk. 

(a) Without a solution for hiding IP addresses, this enables persistent IP-based tracking any time the user grants the permission, and it’s difficult to word a permission dialog in a way the user would understand.

(b) Background Sync allows a web app granted the permission to “phone home” with any sensitive information it obtains through another powerful capability, even if that information is only available temporarily due to a bug, and even if the user doesn’t launch the web app during the exploitability window of the bug.

(4) In addition, we believe there is significant security risk.

(a) Periodic BackgroundSync could be used to build BotNets along the lines in this paper: https://www.ndss-symposium.org/wp-content/uploads/2019/02/ndss2019_01B-2_Papadopoulos_paper.pdf

(b) More specifically, a mechanism to periodically phone home could turn an installed base of apps into an active BotNet at any time with no prior warning. Even with no further vulnerabilities, it could be used for purposes such as DDOS, CryptoMining or mass fraud (albeit somewhat mitigated by limits on execution time and time).

(c) A mechanism to periodically phone home can be used to greatly extend the attack scope of 0-day vulnerabilities and can make it more efficient to abuse n-day vulnerabilities. Assume a sandbox escape vulnerability usable from a Service Worker is revealed. Periodic background sync allows it to be used against the whole pool of users who have granted the permission right away, perhaps before they have had time to install the patch.

(d) I pointed out a number of similar risks for models with persistent background content (then called "persistent workers") in 2009: https://lists.w3.org/Archives/Public/public-whatwg-archive/2009Jul/0868.html

(e) All these vulnerabilities are exacerbated by the fact that domains and websites can be purchased. Even if the actor registering for periodic background sync is trustworthy at the time, their assets could be purchased at a later time by a malicious entity. For a website, users can simply stop visiting, but with periodic background sync, they may continue to be vulnerable even if they don’t visit/launch any more.

(f) Concerningly, the specification does not even have a Security Considerations section, even though these types of risks have been known for years. Perhaps mitigations to these threats exist, but one wouldn’t know it from reading the spec.

(5) Periodic background execution is likely to harm mobile device battery life, and would be difficult for the user to notice and disable.

(6)  Background Sync and Periodic Background Sync appear to be Chromium-only technologies. Background Fetch serves some of the same use cases in a safer way and has wider consensus.

[Michaela Merz]

The periodic background sync would be very helpful in keeping users up2date. I understand the security concerns but providing an IP number, cookies or other elements necessary to authenticate is of course necessary. 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.

Michaela

[Mugdha Lakhani]

Thanks Maceij!

I have responded to the security concerns you raised on the spec Issue you filed.

[na...@google.com]

Thanks for raising the security concerns, Maciej.

I have responded to them on the spec Issue you raised.

Best,

Mugdha

On Monday, December 9, 2019 at 9:42:25 PM UTC, Michaela Merz wrote:

[ThAnks I]

To most responses you or me can't get an answer to the problem of the sync grounded providers requested to do so. Simply solved in summary i'll prevail getting the solution u know works for u in the same problems using empathy not the other sympathy then only then resolving issues can be done cause of ur helping them learn how to do it more effiently in virtaul sastained meta hands then theirs. Let them learn from watching then doing. After knowingly creating the thing their watching teach them. Ones A.I ui Child into Productivehood.

On Tuesday, December 3, 2019 at 12:35:47 PM UTC-6, Mugdha Lakhani wrote:

[roll...@gmail.com]

Mugdha: So I understand that periodic background sync works only in 12hrs - 36hrs time frames? In other words: Even a highly used installed web app only gets to a sync every 12 hrs? And the developer can't influence any part of it? I don't find that convincing. Let's consider a news or weather app a user is using 6 or 7 times a day. Every time the app has to download the new content, because the periodic background sync hasn't fired yet. The 12hr restriction severely limits this otherwise interesting API to very, very limited use cases.  So, frankly, I don't see us investing resources to implement this. Sad - I was hoping for something exciting. 

m.

[Chris Palmer]

On Monday, December 9, 2019 at 1:42:25 PM UTC-8, Michaela Merz wrote:

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.

 Thanks for raising this point, Michaela. Let me see if I can speak to it a bit.

There's some (necessary, unavoidable) tension between competing goods: developer ergonomics, user ergonomics, user safety and privacy, platform and application usefulness, and generality. Finding the right set of trade-offs is very much an open question.

The Priority Of Constituencies requires us to center the concerns of the people who use the web, which means that when there is tension between developer ergonomics and people's safety and privacy, we should favor the latter. Of course, we can't and don't want to make it too hard to develop useful applications — that doesn't serve people well, either. What you're seeing in this thread is a collective attempt to thread the needle.

Other platforms have historically tended to center the needs of developers, with the aim of maximizing the platform's utility. That is not a bad thing! But it is going to change. I think every platform is trying to improve the state of the art in safety and privacy, and that's a good thing. I expect you will continue to see safety- and privacy-protective change in APIs on other platforms, too.

[roll...@gmail.com]

Thank you Chris for your thoughts. I can appreciate everything you said as it relates to general web sites. Nobody wants to run into privacy or security risks while casually surfing the web. But installed web apps in my opinion require a different approach. Steve Jobs himself envisioned an environment where we can use a general language, Javascript, to create applications that would run on the iPhone and .. of course .. on competing platforms. It took many years for his vision to come true and we are now very close. 

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.

A few weeks ago, I wrote an app in Cotlin that updates the location of it's user in every maintenance window. It's meant to do it this way because I wrote it for a friend who likes to hike and he wanted me to keep an appropriate location fix in case of problems. Sorry - he didn't want to use Google tools ;) There are no restrictions and I assume the app would also run perfectly fine if I would have programmed it in Swift.  

So - I know both sides, web- and native apps.

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.

But if it is truly 'just' a matter of privacy and/or security, let's discuss ways how we (you!) are able to confer a higher trust level to web-apps and to allow us developers to bring webapp technology to its fullest potential.

Michaela

[Chris Palmer]

On Tue, Dec 10, 2019 at 7:35 PM <roll...@gmail.com> wrote:

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.

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."

If you have specific application use cases that don't work or don't work well on the web, it's definitely a good idea to bring them up here and/or by filing new Chromium bugs.

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.

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.

[roll...@gmail.com]

On Wednesday, December 11, 2019 at 10:54:23 AM UTC-6, Chris Palmer wrote:

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."

That's why users are asked if they want to accept push notifications. But even if they accept, push-notifications are still not displayed when the device is in doze. So we have installation, we have engagement, but we also have authorization - yet we can't get push during doze. How is this not arbitrary ?

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.

I am doing development for over 25 years. There was NEVER a time where "developers having unfettered access to everything all the time" - well maybe in the days of MS-DOS or Windows 3.x. Unix and Linux systems were restricted by user- and file system permissions, so any application was limited to the user's environment. Web services didn't have anything that could be accessed until just a few years ago so your statement is somewhat misleading.

In general - I find your arguments unconvincing. Auto-play, as an example, might have been a nuisance for the users, but it was a valid W3C standard and it was shelved for no other reason than 'users complained' about it. Again - an arbitrary decisions that broke hundreds of web-sites that had been working for years and no comparable restriction was made for native apps. 

Freezing tabs in a browser is (was?) the latest SNAFU. Someone arbitrarily decides that it would be a good idea without even researching the impact it might have on web-sites and web-applications. Though I loathe freezing tabs on general principal, I could understand the reason on battery powered devices (although - if folks are concerned about draining battery - maybe they should make the screens less power hungry? Just a thought ... ) . There is no valid reason to freeze tabs on desktops.

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 ...

In the 'old days' the browser was a general and transparent tool that allowed web-developers to create a vibrant and engaging web-universe. The 'old ways" served us well for more than 20 years. Here's how I see it: The enormous flexibility of the web-environment and the (perceived) simplicity of creating web-apps are threatening business models and deeply entrenched 'old day' structures. That is why web-apps are limited (to avoid another term from the livestock environment) in the ways they are allowed to compete with native. Let me again give you an (excerpt) list of otherwise unexplainable inconsistencies: 

• web RTC enables us to make and receive audio/video calls: But there's no way of signaling a call when a device is in doze or a tab is frozen;
• a web-app generally falls into a coma when device is in doze or tab is frozen, no activities other than service workers allowed;
• no way of sending silent web-push (without notification) and even the normal web-push doesn't work when in doze (and even the 'limited' web-push doesn't work on iOS);
• no autoplay, not even on installed web-apps;
• ...

Needless to say: No such restrictions apply for native apps. Y'all are the guardian of OUR (as in .. everybody's) web. You should not try to defend limitations that are inexplainable and indefensible. The open web - as web-pages or web-apps is the only defense we have against corporate interests (for profit or not) or government overreach. You guys are the super-heroes we have to rely on when our web is threatened. Act like it.

Michaela

[Kenji Baheux]

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 hrs

For 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/issues

Thanks!

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 :)

[roll...@gmail.com]

@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.

[Kenji Baheux]

On Fri, Dec 13, 2019 at 2:50 AM <roll...@gmail.com> wrote:

@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.

We expect that this API would work well for daily commutes, lunch breaks, which represent a fairly large impact.

 

Second the sync is not guaranteed to happen at specific times

While specific times are out-of-scope, we do want to follow-up on a request to have the sync happen in specific timeframes (e.g. early morning) as I said.

If there are use cases where hitting a specific time is important, I'd love to hear more concrete details with user stories as this could motivate a different effort.

 

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.

If most of your users are indeed using your app almost every hour, then yes this could be valuable.

But otherwise, it feels inefficient (wasting power and sometimes data).

Does your data suggest that the majority of your users launch your app almost every hour during the day? 

What are the most common usage patterns in terms of frequency and time of day?

Feel free to follow-up privately if you can't share a lot publicly (kenjibaheux @ google dot com)

 

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 hrs

For 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/issues

Thanks!

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.

[roll...@gmail.com]

Thanks for your reply. However - your answer is significant as it describes a "top -> down" approach that just isn't the way the web is supposed to work. 

There are so many different use cases, that it is nearly impossible to come up with something that might be useful for a variety of applications. While the current spec might be useful for a news or weather service, it has no relevance to any services that is updated more frequently, like social media, email- , stock- messaging or cloud services. A frozen webapp has no way of communicating with it's host. It doesn't even receive web-push. But even IF it would be able to get web-push, we don't want to bother the user for every updated stock quote or soccer game score.  As we can't do silent web-push (e.g. push that doesn't trigger notifications), there is simply no way to communicate any update to the web-app. Here's where the periodic background sync would have been a great help: With more frequent updates (if there are any) thus relieving the user or app to download the updated content again and again whenever she starts the app.

Needless to say - native apps are able to do just that and there's no limitations as to how often it can download stuff. Native apps can use the maintenance windows to do whatever they like to. Webapps are limited to whatever the devs allow. I find this situation very hard to accept.

Michaela