Require human readable "title" for each periodic background sync registration?

[asutherland]

It seems useful for browser UX to surface to the user what the ServiceWorker claims it is doing similar to Background Fetch's title mechanism. Especially since the SW presumably would perform different actions for different tags and it's otherwise problematic for the browser to expose the tags as they would almost certainly not be localized and probably have a tendency to remain constant over time while an accurate human-readable description would change. This could allow the user to control the different sync registrations separately as well, altering their run frequency/etc. to their own desires.

[asutherland]

Note that "title" is optional for Background Fetch, but Background Fetch also explicitly has a bunch of fetch requests that are fundamentally self-descriptive if not necessarily human readable or understandable.

[beverloo]

I quite like that idea—we haven't figured out a clear way of listing the events, but I can definitely see this being useful. @mugdhalakhani @engedy FYI

[mugdhalakhani]

Thanks for this suggestion, asutherland@.
Here are my thoughts:
1.Browsers generally don't trust strings provided by the website. There's a lot of input sanitization we'll need to do, and even when a string passes this sanitization, we may see strings like:
"This is due to a browser bug, just click allow" or “CLICK ALLOW TO PREVENT THE BROWSER DELETING YOUR DOCUMENTS" to manipulate user decision.
How would you prevent that? And if we can't, is this title string still effective for the original purpose?
2. Background Fetch can have really long running downloads, that can last longer than service worker execution timeout. periodicsync events will be limited by this timeout. Also, a good browser implementation will cap the frequency of these events, per origin, and across origins. In addition, the user can turn on a data saver mode, in response to which, the browser should skip firing periodicsync events. Is data consumption still a big concern then?
3. If we choose to surface this title as a notification, it'll add to the deluge of notifications a user gets once they connect to a network. May I ask how you're planning to surface these title strings?
4. If the browser has implemented caps on how often it fires periodicsync events, and how often it wakes the browser up to fire them, letting the user override this frequency through the UI can have an adverse impact on resource usage. Would the user realize this? Isn't it more likely the browser will get blamed for this resource usage?