request: don't standardize around lowest common denominator platform (e.g., mobile)

[twschiller]

Context

With the growing ubiquity/importance of mobile, and the Safari team announcing support for mobile extensions. There's a need to account for the unique needs of the mobile form factor in the standardization process

Some efforts, e.g., moving the background processing to an ephemeral service worker, will have positive resource impacts on all platforms. And, if designed properly, will not be at the expense of functionality

In the first meeting, #23, @dotproto raised the idea of including stricter resource guarantees into the manifest to account for mobile

Request

Account for the unique needs of mobile (e.g., energy consumption), but do not constrain desktop extensions to meet those needs

[dotproto]

Small correction: the point I raised in the meeting was specifically about maximum execution time for service workers, then I opined a bit about potentially not spinning up a service worker when an extension might expect it. I think it would be more accurate to say, "@dotproto raised the idea of including stricter resource guarantees into the spec to account for mobile."

@twschiller (or other supporters of this request), could you expand on what you're asking for? I confess that I'm struggling to reply because I see a wide variety of possible motivations and desired outcomes. It may help if you could share more about what you're after or how you imagine this request being fulfilled.

One of the things that I keep tripping over is the scope of the word "constrain" in this request. The intro of the original issue tentatively supports adopting an ephemeral background environment, but I know some other developers that feel this is an unacceptable constraint. After all, not allowing extensions to execute script for an unbound period is a limitation they didn't have before. So, when I read "unique needs of mobile" and "do not constrain desktop", the impression I get is that you are asking for multiple parallel extension platforms tailored to different devices. This in turn implies fragmentation of the ecosystem and different pools of extensions across devices. I think it's fair to say that's an outcome we (Chrome) aren't particularly keen on.

So, what does "but do not constrain desktop extensions" mean to you?

[Jack-Works]

So, what does "but do not constrain desktop extensions" mean to you?

Allow the Worker to keep running on the desktop if they want. (and really please consider #11)

[twschiller]

@dotproto I apologize if I mischaracterized your comment from the meeting! I tried going back to the minutes but the information was incomplete. Thank you for clarifying!

My intention wasn't to solicit a response from you, and I don't have specific requests/proposals at this time. ​The issue was primarily meant to capture a proposed approach/spirit/philosophy. That is, recognizing that platforms are different vs. designing for the lowest common denominator

For example, suppose someone proposed an extension storage cap aimed at low-end smart phones (say 5MB, as with local storage). I would argue it's an undue restriction on other form factors. A standard that fits with this approach may provide a way for an extension to request more storage

I agree that the whole debate of "constrain"ing functionality is related. I think of this request as a lens/frame with which to evaluate those concerns. For example, if requiring ephemeral background workers was introduced solely as a way to better support mobile, this request would be against requiring it for desktop. If it were a real requirement for mobile, a strawperson compromise might be to have "universal" vs. "desktop-only" extensions

I also agree that fragmentation is a real concern. The whole point of this group is to try to standardize and reduce unnecessary fragmentation in order to make the extension ecosystem better!

In general, I err on the side of waiting to hear what more specific proposals come up as mobile and other form factors are discussed. I encourage everyone to add their thoughts on constraints to this thread!

P.S. I personally have no problems with ephemeral background workers as long as the practical issues (e.g., high performance session storage, dropped messages, etc.) get worked out through browser and library support

[dotproto]

@dotproto I apologize if I mischaracterized your comment from the meeting! I tried going back to the minutes but the information was incomplete. Thank you for clarifying!

No apologies needed! We covered a lot of ground and it's easy to get the details on this stuff mixed up. I just happen to have a more specific recollection here because I happened to be the one sharing my half-baked thoughts. 😄

My intention wasn't to solicit a response from you…

Sorry for the confusion. To clarify, I didn't think you were trying to solicit a response form me specifically. I was compelled to reply because I wanted to engage and share my view, but I was struggling to do so because I wasn't clear on what you or people 👍🏻 -ing the issue had in mind.

To that end, I'd like to encourage other members that support this request to share more information about their concerns.

[xeenon]

With the growing ubiquity/importance of mobile, and the Safari team announcing support for mobile extensions. There's a need to account for the unique needs of the mobile form factor in the standardization process

To comment from the Safari side, we did require non-persistent (ephemeral) background pages on iOS. However, we don't require it on macOS Safari. We acknowledge there are differences between platforms, however there are still benefits to non-persistent background pages on macOS with regards to battery life for MacBooks.

[dotproto]

@Rob--W, during our 2021-07-08 meeting I believe you briefly indicated that Firefox supports persistent background pages on Android. Can you share a bit more about this? Offhand I'm curious about your team's thoughts on persistent resource consumption, site isolation, the intersection with the recommended extensions program, whether this approach is scalable to all extensions, and how the Android app lifecycle affects extensions.

[ghostwords]

Firefox might only support persistent background pages: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/background#browser_compatibility

Privacy Badger has over 150,000 users on Firefox for Android. I have received no indication thus far of performance or battery issues.

[zombie]

Privacy Badger has over 150,000 users on Firefox for Android. I have received no indication thus far of performance or battery issues.

Privacy Badger is one of only a few dozen extensions available to Firefox on Android. A major reason is that Mozilla needs to review each update to each extension for security and privacy, because all extensions run in the Firefox main process (as opposed to a dedicated extensions process on desktop), which goes against the recommended practice of defense-in-depth and running code with least privilege.

We're unable to run existing extensions in a separate extension process because Android can kill app's child processes without warning, since extensions were not written expecting that, and may misbehave if we simply restarted their background page (double-injecting content scripts, data loss, etc).

[patrickkettner]

Appreciate you opening the issue, it is being closed as there is nothing actionable for the group to do from this issue.
It will be kept in mind throughout our work, however.