Agenda discussion for public meeting on 2022-03-03

[dotproto]

Please comment on this issue to add topics for our next meeting. The agenda will be finalized two days before the actual meeting and migrated to our meeting notes doc.

Current topic list

• @tophf, Produce evidence/statistics on why persistent background scripts are bad for performance
• @oliverdunk, Proposal: browser.secureStorage API #154 and Add browser.secureStorage proposal #167
• @dotproto, Off-screen Documents Proposal

[tophf]

It's time for Google/Chromium to produce a real and verifiable evidence on why persistent background scripts are bad for performance, be it on a desktop or on a low-power device. From what I've been seeing in practice for ~10 years, all extensions installed by an average user combined consume much less resources (memory, CPU, etc) than a page like youtube.com or twitter.com or facebook.com or Chrome's own processes, especially the GPU process. There's also no evidence on why DOM-based background pages are bad for performance or security etc. The only verifiable evidence tells the opposite: restarting the background script/page frequently is bad for overall performance and power consumption e.g. https://chromium-review.googlesource.com/c/chromium/src/+/2510431.

[craiglurey]

Hi team, on Thursday I would like to discuss the same topic as @tophf has mentioned. One of the things which has also come up by our engineering team in respect to persistence is the fact that our product requires an encryption key (derived from a user Master Password) or SSO to be held in memory, in persistence. Storing the encryption key in local storage is a non-starter. Having to install a companion native desktop app is a poor user experience and non-starter. We are aware of the use of CryptoKey objects, however this has its own set of issues.

[tophf]

@craiglurey, maybe you can use chrome.storage.session, which was created specifically for this purpose with a limit of 1MB for the entire storage. There's no documentation yet, but it has the same API as chrome.storage.local.

[oliverdunk]

If it isn't in beforehand, we should discuss merging the secureStorage PR: #167

[craiglurey]

@oliverdunk we agree the secureStorage feature would be awesome. We would love to collaborate on that spec.

@tophf we will consider using chrome.storage.session to store the key.

[tophf]

@dotproto, you're sidestepping the issue: we don't need a clarification, we've already seen it in the previous minutes, but it contradicts the real experience of multiple extension developers and users. We need a real and verifiable evidence. It would be either an instruction on how to replicate the adverse affects or a disclosure of the measurements performed across the entire userbase of the Chrome browser, i.e. histograms, statistics.

[dotproto]

@tophf, you seem to be assuming malintent where there is none. The summary I added to the agenda was a good faith attempt to condense your comment into one sentence. If you'd like to provide a topic title that more actually represents your concerns, I'd be happy to use that instead.

On the other hand, if you'd like to start a separate discussion that does not require face to face conversation, I'd encourage you to open a new issue.

[tophf]

you seem to be assuming malintent where there is none

I definitely didn't assume anything of the kind from you so I'm sorry if that appeared that way.

Sidestepping doesn't imply malintent. Still, the result is that in your description the essence of the request is completely different, possibly because you have a bias to trust your team's judgment so you're assuming this to be just a matter of clarification. It's not. Good faith is not good enough, we also need to be precise and diligent.

[craiglurey]

@dotproto we appreciate that there's a public discussion, and I understand @tophf's frustration.

A company (especially a privately held or bootstrapped organization) is spending most of its time around getting a product to market, hiring engineers, building out a roadmap, working with customers, doing all the things we do to maintain a quality product. Browser Extensions are a huge part of some companies product portfolio. They also eat up a lot of time in user support, debugging, etc.

It's very unusual for a platform to throw developers into a frenzy and force them to rewrite their core product, or risk having the app just shut off for all their customers on some arbitrary date. This is not just consumers, this is also enterprise users.

Browser extensions are a tough platform. It takes years to optimize and fine tune the user experience and all the complexities of dealing with the gazillion websites out there. Not to mention debugging with end-users, releasing updates, all that.

To make things even more challenging, Google Chrome Store's "staged rollout" doesn't really work. Their review process is sometimes slow and gives very little control to developers for slow rolling, beta testing, etc.

So now you're combining a huge product change, hard deadline, and poor developer store tools to manage the release.

The right thing to do would be giving developers the ability to maintain their v2 extensions with users until such time that they have the tools and time to get this migration done the right way.

[tophf]

If you'd like to provide a topic title that more actually represents your concerns, I'd be happy to use that instead.

My bad, I thought I did just that in my first comment's first sentence. I guess it's too long? Well, a shorter alternative might be "Produce an evidence/statistics on why persistent background scripts are bad for performance", just make sure that all the involved parties understand what's actually being asked e.g. either an instruction on how to replicate the adverse affects or a disclosure of the measurements performed across the entire userbase of the Chrome browser, i.e. histograms, statistics.

[dotproto]

@tophf, I've update the agenda to use your suggested summary.

[dotproto]

I'd like to discuss the Chrome team's Off-screen Documents Proposal, which would "allow Manifest V3 extensions to open minimal, scoped, and relatively un-permissioned offscreen documents at runtime through a dedicated API."

[tophf]

Chrome team's Off-screen Documents Proposal,

Nice. Requesting to clarify the following:

1. Will it run in the same main thread as the extension's tabs/popups?

   If it's same-thread, it would make sense to expose it via chrome.extension.getViews with its own type so the visible extension tabs/popups can access it. AFAICT, such exposure won't grant it more abilities than it already has, but it will make the migration less painful as many MV2 extensions were relying on getBackgroundPage API.

2. Will an extension page (popup or tab) be able to access this document directly?

   Primarily to get non-serializable content like DOM elements of the scraped web page or a huge ArrayBuffer after muxing/demuxing a captured video file, which would take a long time to transfer even via web API like postMessage with a transferrable object.

   Something in the vein of synchronous chrome.extension.getBackgroundPage() and asynchronous chrome.runtime.getBackgroundPage().

3. Direct messaging from visible tabs/popups or a content script?

   I'd like to avoid broadcasting to the entire extension via chrome.runtime.sendMessage or BroadcastChannel or waking up the service worker just to find the page in its clients. A somewhat awkward workaround would be broadcasting a unique "id", which the offscreen document will use in chrome.runtime.connect({name: id}) to handshake with the correct chrome.runtime.onConnect listener of the calling page.

   Note: broadcasting is bad here because it wakes up the service worker in case it also has an onMessage listener.

4. Will it have its own content_security_policy entry in manifest.json?

5. Will it have a link in chrome://extensions UI to open it in devtools?

[Jack-Works]

Will it run in the same main thread as the extension's tabs/popups?

I think making the background run as the same thread is not a good thing. For example, in our extension, when the background page is doing a heavy work, the options page will be frozen.

[Jack-Works]

Primarily to get non-serializable content like DOM elements of the scraped web page or a huge ArrayBuffer after muxing/demuxing a captured video file, which would take a long time to transfer even via web API like postMessage with a transferrable object.

If it is possible, you can use URL.createObjectURL to convert blob into a string and post it to the background.

[tophf]

@Jack-Works, a same-thread environment may be much faster to create, whereas for heavy work we can create a nested worker inside. As for blob URL, it creates a temporary file, which in certain situations may get written to the disk, and it won't help with non-serializable data anyway.

[dotproto]

Closing as the meeting starts in about 15 minutes. Topics have been migrated to the meeting doc.

[ghostwords]

Just want to note that since the offscreen documents proposal was only shared last night, the community didn't get a proper chance to digest and discuss it before this morning's meeting.