Open Bug 1564436 Opened 5 years ago Updated 4 years ago

Web backgroundsync syncing on a different network after user close the page.

Categories

(Core :: DOM: Workers, defect, P2)

defect

Tracking

()

People

(Reporter: edenchuang, Unassigned)

References

(Blocks 1 open bug)

Details

https://github.com/WICG/BackgroundSync/issues/107

Service worker could handle sync event even there is no page under its control.

Web site could track users' location or other private data by Web backgroundsync mechanism even user is not browsing the related pages.

Blocks: 1547906

Bugbug thinks this bug is a task, but please change it back in case of error.

Type: defect → task
Priority: -- → P2

For the issue https://github.com/WICG/BackgroundSync/issues/107

According to discussions, I think the issue is users don't know the website registers background syncs, and the execution background syncs surprises users. And service worker can access the user's data when handling sync event.

I think it is hard to limit the access only in the sync event handler scope, especially limit what service workers can access in fetch or other event handlers. So the idea what I want to propose is letting users know the background sync registration and give them a chance to deny it.

I want to introduce new permission, "ReigsterBackgroundSyncOffline."
To allow the website register background syncs in the offline state. And it could be "ask," "allow," and "block."

We needn't consider the online case because the background sync should be performed immediately after registration, and the background sync should not surprise users.

Before performing the registration, checking what the permission value is.
If the value is "allowed," performing registration directly. If the value is "block", resolving the registration promise with AbortError or NotAllowedError to inform developers to handle the case.
If the value is "ask," popping up a notification to inform the user that the website might do something when the network backs to online. And also provide "Allow"/"Block" buttons on the notification to users to choose to continue the registration or not. The same if the user rejects the registration, resolving the registration promise with AbortError or NotAllowedError.

I want to consider the issue https://github.com/WICG/BackgroundSync#37 in this bug, too.

According to discussions, this issue is a special case for mobile platforms.
Since service worker could consume energy and network data volume in the sync event handler, users do not want to perform the background sync when the device is low energy or network data volume. So the network state is not enough for judging if dispatching sync events.
I want to add a new preference "dom.backgroundsync.networktypes" for mobile platforms. The value describes in what network types users want to perform the background sync. And when the network state backs to online, dispatching sync events when the network type fits the preference value.

Anne, could you give some comments? Or ni someone for comments. Thanks.

Flags: needinfo?(annevk)

I'm going to restate it to make sure I understand it correctly.

When the register() API is invoked, if the user is online and on a network state where battery/data usage is not an issue, we let it succeed and perform a one-time sync immediately. Feedback: the specification suggests there wouldn't be active clients when synchronization happens, so I guess it should not be immediately, but instead when the tab closes? Taking some seconds after the tab closes seems acceptable.

If the user is offline or on a network state where battery/data usage is an issue, we prompt the user and resolve/reject the API invocation with the decision made by the user. Feedback: "NotAllowedError" would make sense to me, but please file a specification issue to discuss this; I filed https://github.com/WICG/BackgroundSync/issues/152 on some wording the specification has around permissions, but this is probably best discussed separately.

Overall this seems good, but the "network state" idea needs some more clarity. Since Martin commented on the specification also adding him here so he's aware this is ongoing.

Johann can probably suggest who can help with designing a new permission dialog for this.

Flags: needinfo?(mt)
Flags: needinfo?(jhofmann)
Flags: needinfo?(annevk)
Type: task → defect

Thanks for looping me in Anne.

I'm not really all that happy with the idea of having a new permission prompt, especially for something as opaque and difficult to understand as this. More so without having a system of accountability in place.

My preference leans toward us refusing dispatch of the event if circumstances change significantly. Yes, that reduces the reliability of the API, but we need to ensure that we establish proper expectations about that reliability rather than try to bully our way into making this "just work".

A new permission is still likely a decent idea, and we might use that where we have other signals about trusting sites (like the "installation" process we have been contemplating). But a prompt is, to me, not acceptable.

Flags: needinfo?(mt)

Without trying to be negative about it, I agree with Martin that a simple prompt for this sounds incredibly hard to understand for the user, so I would recommend trying to find an alternative solution.

If we really want to do a prompt, there's not a lot to design, the prompts follow a pretty default UI pattern. We will need to loop in UX for copy, but since it's only a few lines that can probably happen around the time we actually start working on it.

For a new permission, it's advisable to make sure that spam-protections are built in from the start, such as requiring user interaction.

The front-end for the "regular" promise based web permission prompt like geo or notifications is here: https://searchfox.org/mozilla-central/source/browser/modules/PermissionUI.jsm

If you need to do something more fancy (doesn't sound like it) reach out to me. :)

Flags: needinfo?(jhofmann)

So, what's the next step here? Are we blocked by something to move on?
Eden, would you please summarize to help everyone aligned? Thanks!

Flags: needinfo?(echuang)

After discussed with Anne, I think the current conclusion is this bug is still a blocker for Background Sync API.
Permission prompt for offline-sync-registration seems not to be an acceptable solution, since followings

  1. Prompt is annoying. Most users always click close or denied it directly, and doesn't care about what it describes.
  2. Even for the users cares the prompt description, it is hard to explain to users what the permission is. Because we can only tell users is the
    website wants to do something in background once backs to online.

So we need another solution.

Anne told me that Background Fetch API UI might be a possible solution for the Background Sync API. Where the spec: https://wicg.github.io/background-fetch. It describes a UI for background fetch and how the UI interacts with users and websites.

I just took a look at the spec quickly. I am not sure if the UI is also suitable BackgroundSync API since the UI postpones the user decision to the timing when dispatching or handling the sync event. Sync actions might not like fetching can be dropped or canceled easy. Canceling the sync action could make problems because users might expect all the things are done when they close the tab or navigate to another website.

If we want to apply a UI solution for Background Sync, we need to update its rules on the spec, since to support UI solution, we probably also need to interact with websites.

Flags: needinfo?(echuang)

Just summarize the offline discussion and above comments.

We treat this bug as a blocker of BackgroundSync API shipping.
To resolve the user tracking issue, here is another proposal for it.

A specific UI to manage background synchronizations.

When the website/webapp registers a sync offline for a top-level origin, UA just follows current spec and finishes the registration steps.
When the user closes all tabs for the top-level origin and the sync still in the origin's sync registration list, we show the sync registration UI indicating that top-level origin is doing something in the background. Users could dismiss and keep the sync through UI.

We agree that if we want the specific UI for BackgroundSync, we need to update the Spec for the sync canceling.

However, because the UI solution is much more complicated than a simple permission prompt, we'd like to get some feedbacks from the Product side. Since whatever solution we apply, we still can not protect users from tracking. It is just giving users a chance to deny/cancel. So, we want to know if we have a strong reason for shipping BackgroundSync? If we still want to ship BackgroundSync, how does Product think about this UI solution and the permission prompt?

The detail of the permission prompt solution is in Comment 2 and Comment 7.

Flags: needinfo?(mconca)

I have a few thoughts:

  1. The initial push for BackgroundSync came from Facebook and their desire to roll out service workers ... back in 2016. I've asked our partner group to reconfirm that this feature is still important and/or desired by that group.

  2. Usage in Chrome and adoption by websites has been very, very low. I do not believe the lack of BackgroundSync is causing significant web compatibility issues for Firefox at this time.

  3. BackgroundFetch could possibly be considered a replacement for BackgroundSync, and since that spec requires a UI, it may make sense to simply jump to BackgroundFetch. Or, alternatively, implement BackgroundFetch and release both it and BackgroundSync at the same time (sharing a UI).

  4. BackgroundSync matters to mobile, and mobile is increasingly important to Firefox. It would be ideal to offer a good mobile experience in a privacy-protecting way as a market differentiator.

I'd like to know the answer to #1 before proceeding. And I'd rather not land on a UI decision at this point - we have a tremendous UX group and I think we'll end up with a better solution if we outline the desired goals and let them propose the design.

(In reply to Mike Conca [:mconca] from comment #9)

  1. The initial push for BackgroundSync came from Facebook and their desire to roll out service workers ... back in 2016. I've asked our partner group to reconfirm that this feature is still important and/or desired by that group.

We've been in contact with Facebook and it seems this is still desired. backgroundSync is important in low-bandwidth and poor-connection areas (i.e. mobile, especially in AsiaPac).

  1. BackgroundSync matters to mobile, and mobile is increasingly important to Firefox. It would be ideal to offer a good mobile experience in a privacy-protecting way as a market differentiator.

As both Fenix and Firefox Lite continues to grow, this becomes more important.

I'd like to know the answer to #1 before proceeding. And I'd rather not land on a UI decision at this point - we have a tremendous UX group and I think we'll end up with a better solution if we outline the desired goals and let them propose the design.

At this point I'd like to formally engage UX to explore what design options we have to land both backgroundSync and backgroundFetch with perhaps a common UI that is both intuitive and not annoying.

Flags: needinfo?(mconca)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.