Manifest V3 - Persistent Background page deprecation

[Michael Yaroshefsky]

To Devlin and the Chromium team considering Manifest V3 changes:

While there is a dedicated thread to discuss the webRequest API changes, the change that will impact my company's product most substantially would be the removal of the persistent background page.  I wanted to outline for you and the team a few of the unique ways our team has leveraged the flexibility of the persistent background to contribute to the chromium platform and the improved experience of our mutual customers. 

This particular change is a P1 in the current document, and I understand the concerns about performance stated by the chromium team as well as unifying with the open web standards of Service Workers. I hope the team will review this and consider if there are ways to meet the same ends without removing the persistent background from the future of chrome extensions.  

Removing the persistent background capability reduces the value that extension developers like us can deliver to chromium users through extensions. Based on some preliminary ideation for how to port existing functionality to a new Service Workers scheme, I believe that the necessary workarounds to deliver existing functionality via Service Workers may inadvertently come with an even higher performance cost that reduces the quality of user experience for our shared customers.  In an attempt to improve user experiences, this change may drive development patterns with consequences contrary to that objective.

As it stands right now, the most costly processing done by our extension occurs at startup in the background as data is retrieved from local memory and the cloud.  Having dozens or hundreds of these initializations occur for activation of a Service Worker during a standard lifetime of a browser process is likely to be more costly than maintaining the persistent background process.

Beyond this additional cost of computational resources that would be possible from such a change, it may also call into question my company's broader vision for improving the future of work via this promising platform.

Our Vision for Improving the Future of Work

Our company was founded on the belief that the Chrome extension platform enabled an entirely new segment of intelligent, context-aware application software that could make working in the browser more intuitive, collaborative, and productive. While the Chrome extension platform has been around for years, it is our vision that with the recent tipping point of work to the browser, we're approaching an explosion of valuable innovation in this platform.  Many are surprised to hear that in Q1-2016 Chromebooks began outselling Macs.  This is a testament to the powerful capabilities provided by the chromium platform.  The web is the operating system of the future, the hard work of the chromium developers is a huge part of that reality, and extensions are a powerful part of that ecosystem.

This is because Chrome extensions have 2 critical advantages over building traditional web apps.

• Guidance through context
  We envision a future of working in which an artificially intelligent "agent" in the browser (via an extension) has awareness of the current pages a user is on and can provide guidance, automation, and quantified measurement.  
  
  Here is a video demonstration of how our chrome extension guides new employees.
  
  The ability to guide workers through their jobs can open up the labor pool, making it possible for less skilled workers to fill positions that would otherwise have required greater education or experience.  This could be a powerful force for democratization of skills, especially helping blue collar workers displaced by automation transition to other roles that would have otherwise been beyond their training.
  
  With such a platform, new hires can be more easily guided through work.  The intelligent agent can infer (e.g. based on an inbound email or Slack message) what task they user is likely to do next and guide them through it.  As SaaS stacks grow more complex, this agent can guide the new employee through the applications needed to accomplish a task.  This can reduce the time it takes for new employees to begin creating value and feeling empowered.  
  
  A critical factor in delivering such an experience is having a centralized "brain" in the browser to maintain background state and process information coming in from the tabs.  While a large portion of this can be offloaded to the cloud, there is a critical role played by the on-device portion of the intelligence.  The centralization of the background page makes this possible.  With the exciting work being done in Web Assembly, there are very exciting possibilities ahead.
  
  Having such a central "brain" that must be able to shut down and come back again via the activation-idle-termination lifecycle of a transient Service Worker would incur a heavy startup cost of loading information back into memory and performing initialization work.  It would also add complexity to the development of such technology, reducing the pace of innovation and the rate at which users can begin benefiting.
  
  
• Faster access, anywhere
  The number of web apps used by the modern knowledge worker has skyrocketed in the recent few years, improving capabilities but also increasing cognitive burden.  The accessibility of chrome extensions for lightweight functionality is a big improvement.
  
  According to a "Business at Work" report by Okta, the single sign-on provider, the number of apps used by an average company has doubled over the course of 3 years.  As employees jump back and forth between tabs, there is a substantial cognitive cost.  By contrast, browser extensions are always one click away, making certain often-accessed functionality faster to find and less burdensome to engage.  This is a substantial improvement for the average worker.
  
  Beyond easier access, Chrome extensions can provide access to functionality without leaving the current page.  Whether delivered via the Browser Action popup or an in-page overlay UX, a user can interact with a Chrome extension without leaving behind what they were working on.  This is particularly important for functionality that is intended to be referenced side-by-side with the current tab.  
  
  Just like the convenience of mobile devices created a whole new segment of capability because of easier access to lightweight experience, so too can Chrome extensions deliver more convenient, lightweight access to a new class of applications.  
  
  One of the major hurdles to delivering great experiences, however, is maintaining a fully synchronized state across all tabs in the browser.  Users should not be expected to refresh pages to update state based on actions taken in other tabs.  Our team has invented a solution to this problem by using ES6 proxies to automatically synchronize data across tabs.  By pairing this with a reactive UX framework, like Vue, we've been able to deliver a premium user interface.  This is in-part enabled by the persistent background script being able to maintain synchronization across the tabs.  
  
  Without a persistent background page available instantaneously to respond with requests for in-tab state or synchronization, the user experience could be slowed down considerably.
  
  In fact, our team built an in-memory proxy for the persistent local storage to avoid the heavy performance costs of the slower reads and writes.  Data in local storage is brought into JavaScript runtime variables for faster sub-millisecond reads, and changes are written back lazily.  Because of the number of transactions involved in each page reload, this in-memory proxy shaved approximately 50 milliseconds off of our time-to-responsiveness in the tab.  I am concerned that the facilities available for state management in the Service Worker scheme will substantially reduce our performance and degrade the quality of user experience.
  

Sample of use cases that may be difficult, resource-intensive, or impossible to solve using Service Workers

• Using Vue.js in the background for data reactivity
  Impressed by the power of using a reactive library on our frontend, our team has included Vue.js in our persistent background page.  By tapping into Vue's powerful lifecycle hooks and lightweight observer engine, we've been able to synchronize data very reliability.
  
  Without access to a DOM, such as is available in the background page, libraries like Vue would never be able to run.   
  
  Without data persistence, this Vue reactivity could never work.  The best workaround may involve setting up a system for writing back state data to IndexDB or local storage and then reading it out again when the server worker is initialized, but this would incur a very high startup cost each time an event occurred.
  
  
• Live Graph Database
  As a solution to the synchronized state problem across tabs, our team built a realtime graph database that uses message passing to keep in-use JavaScript objects in synchronization across tabs (and also persists to the cloud).  
  
  Without a persistent background state, it would not be possible for this implementation to work (as currently designed).  
  
  Without persistent state, the cost of initialization would be rather high.  The wrapping of these objects in proxies and initialization work would need to occur each time a Service Worker was activated.  

Rather than provide a laundry list, I just wanted to provide 2 critical examples that apply to us.  

For a use case like ours, where the content script calls into the background on every new page load to get context and load state, a persistent background page was ideal for our use case.  The number of requests and communications that involved the background justifies having the process running persistently, especially for quickly responding to requests with in-memory data.  It's also a convenient place where we can offload work that would otherwise lock up the main thread.

Here is a screenshot of the concept of our product, guiding an employee through their job -- all via an easy-to-use overlay in the browser.

Conclusion

When founding a company whose primary vision included building a new type of software solution on the browser extension platform, many laughed at us.  "What major company was built as an extension?" they would ask.  In my mind, the answer was -- none... yet.  

The platform provides powerful opportunities to improve how people work, and it was my opinion that a company such as ours dedicated to this cause could innovate on the platform and show the world what is possible.  We really believe in the capabilities of chrome extensions, and we want to show the world what's possible.  

While the risk of developing on any platform is deprecations and changes such as this, I had assumed a certain stability of Chrome's web extension platform.  That was further supported by the relatively recent votes of support by Firefox and now Edge.  I know it's early days yet with the Manifest V3 draft, but if these changes do go through, our team may have to reconsider whether the platform risk is too high to justify substantial further investment.  As disappointing as that would be to us, given excitement of our vision, we have a duty to our investors and our customers.

Seeing over two years of passionate engineering work (and millions of dollars of investor capital) at risk from deprecations of such the persistent background page, a defining component of chromium's extension standard, I am very concerned about our ability to continue down this path confidently.  It also makes me concerned that I may have been wrong about believing the extension platform was stable enough to build a business on it.

We are very proud of the innovation we've brought to this platform, and we would be happy to discuss more with the chromium team.  We want this platform to thrive, because we believe extensions hold the promise of a future of work that is simpler, more collaborative, and more accessible to people of a variety of skill levels.   I hope the team will reconsider the deprecation of persistent background pages, which is a crucial enabler of this vision.

Sincerely,

Michael and the RocketVisor team

email: michael @
New York, NY

[ibrah...@gmail.com]

Currently I'm working on an extension that loads encrypted data (a user profile) into the background script for use between all tabs.  The data is only decrypted while in memory and it's used between all open tabs.  I've been reading the V3 and trying to find a way to keep a global memory state but it seems impossible and intended.  I really don't think this is a good idea.  There needs to be a persistent state for some web extensions.

[wOxxOm]

Stylus, Stylish, and other web highly popular CSS theme extensions that implement @-moz-document (not supported by Chrome natively) need a persistent page to store the regexp rules used by the styles. Recompiling all regexps every time the background page loads could take up to a half second or maybe even more for a lot of users. There's no alternative in Chrome as its event filters don't support the full regexp syntax and there'll probably never be because RE2 syntax that's implemented currently in Chrome covers most of the needs.

[wOxxOm]

One of the disastrous deal-breakers is the lack of DOMParser API inside service workers because DOMParser is allegedly not thread-safe. If Chrome abandons the classic extension page (persistent or dynamic) in favor of a worker, it'll instantly kill the entire class of extensions that fetch various dynamic data from external pages like news tickers and so on. Distill Web Monitor is one example of such an extension. Extension authors would have to use a third party HTML/XML parser, which is not as reliable or guaranteed to produce the correct result compared to the DOM API implementation in DOMParser. It'll be a huge step backwards.

The V3 proposal says:

Most importantly, the platform will evolve with the open web; as improvements to ServiceWorkers and the web platform are made, the extensions platform benefits from those same improvements.

But we all know that the open platform may take years (of doing nothing) or sometimes decades to move forward on even a single topic.

Please don't force an inferior open standard on us (in this particular case the lack thereof) hoping it'll catch up eventually.

Or do you think it'll possible to expose an asynchronous DOMParser thunk connector just in Chrome?

[Vasco Gomes]

Hi, I also have the same opinion on this. I already wrote about this on the Web request changes thread.

If background persistent pages with DOM are gone it will break dozens of thousands of extensions. No doubt about this.

In a world where computers and notebooks have CPUs with 4-8-16 cores, SSD's and 8-16gb of ram the impact of a persistent background page is reduced from zero to nothing.

Since 2011 and 2014 computing power have increased like moore law said so: https://en.wikipedia.org/wiki/Moore%27s_law

I don't understand why in 2019 we want to go back 20 years in time to a technology that removes the power to do beautiful things with software. On Android platform Google is giving each time more powerful API's and pushing forward what is possible to do. On Chrome I don't understand why it's the oposite.

I was expecting with Manifest V3 even more powerful background persistent pages, not the oposite.

Greetings.

[Scott Fortmann-Roe]

To add to this list of things that you can't do in a service worker; here are a few things that are important functionality of Background Scripts:

- Having a persistent application that can load and cache data and respond instantly to content script requests

- Playing sounds

- Using a contentEditable's execCommand to read/write styled text from/to the user's Clipboard

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To post to this group, send email to chromium-...@chromium.org.
Visit this group at https://groups.google.com/a/chromium.org/group/chromium-extensions/.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/03a360b6-93ca-4fac-9c15-ea79ba9ca0bd%40chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.

[Aleksandr G.]

I'm developer of Sticky Password (further as "SP" word) and it's Chrome extension which is ~15 years old with thousands of active users.

I re-posting part of my message from main V3 thread here, because it's the most significant and dramatic change in the Manifest V3 draft for our and tons on other extensions with millions active users in total.

I can't imagine how to migrate our code from persistent background script to Service Workers, I even still not sure Service Workers will fit for our extension logic. We definitely need persistent background script for making our extension work secure and in the form it exists now with all its features. Currently Chrome with Native Messaging API under Windows does not provide any security layer in the communication between extension and host, even OSX platform is thought everyone as secure and it's more secured than Windows. We do use persistent background script for communication between the extension and SP application in a secure way, using encryption and authentication, this could be done only in the persistent background script. Otherwise using offered in the V3 Service Workers it could be more time-costly that our current implementation on persistent background script. Could you imagine that each your page load, page submit events before normal handling by the SP application initiate new connection and performs TLS protocol connection? Instead of having only single and secure transport located in the persistent background script should we move it to Service Workers? OK, but on each event from content script we should performs TLS protocol connection again and again?

You offer to save the state of Service Workers to browser storage? Sorry, but neither localStorage (which in fact disallowed in Service Workers according to V3 draft) nor chrome.storage API are secure and documentation strongly recommends not to save there any secure info! Therefore it would be a crazy idea to store the connection info there to speed up the communication to SP application while the Service Workers is killed by Chrome (idle state if I'm not wrong?).

Talking about absence of the DOM in Service Workers am I correctly understand that we would be unable to use neither JSON nor XML parser there? JSON is the primary data format for our protocol between extension and SP application, XML also partially used. How can we implement such usage in Service Workers?

Just abstract question to Chromium team - you said you want significantly improve the memory usage in Chrome browser by removing persistent background scripts from extensions? I don't wan't to offend you, but guys I do have 7 tabs opened (couple simple and short pages, 2 google docs: Manifest V3 and my comments to it, 2 google groups including this one and google translate), I have about 6 small extensions including SP one - all this takes 1.8GB of my PC memory! Don't you think it's too much for my case? Note our Native Messaging Host takes only 1.2MB. I definitely sure that the web pages itself and "one page = one process" architecture eat the memory. It's small off-topic, but hope you understand my point of view that in slice of normal web pages usage the occupied memory by the extensions comparing to web pages tends to zero as fast as user opens more and more pages.

Service Worker APIs are also hidden and cannot be used when the user is in private browsing mode. Not a big problem, but what if our user want to use the SP in the private session? Just think of it in abstract way - what if the user of any abstract extension want to use it in private mode? Currently everything works fine - he just allow the extension usage in private browsing mode and became happy. What about Service Worker and why?

[ibrah...@gmail.com]

I'm not happy about this but the only way I see to provide duplicate functionality is to create a new master tab and use chrome.tabs.sendMessage/chrome.runtime.sendMessage from other tabs to the "master" tab.  Because of the limitations of service workers what we're going to end up with for the extensions that need to preserve their state are newly created pinned tabs stacked at the top left of the browser.  That's exactly what I would be forced to do and I think that's a method many others are going to discover sooner or later.  All to save some ram.

This is dumb.

On Friday, January 25, 2019 at 8:32:25 AM UTC-8, Michael Yaroshefsky wrote:

[Conrad Irwin]

At Superhuman we're building the fastest email client in the world, on top of Gmail + Chrome.

To re-echo the requests from above: in order to move from a background page to a service worker we would need:

• A DOM implementation in service workers. We are building an email client, and it's important that our access to data is secure. To this end we download emails directly from the Gmail API to the browser, so we do not need our servers to download people's emails. In order to display emails to users we first need to sanitize them (using DOMPurify) and pre-process them. We've prototyped a version that uses jsdom instead of the built in DOM parser, but it is significantly slower; and because the security of DOMPurify relies on using the same DOM implementation to sanitize as it does to display, much less secure.
  
• Better notification support. It's essential that when you open your email client your inbox is up to date. How this works today is that we send silent push notifications to the clients (using GCM for Chrome, or APNS for iPhone) to let them know to sync.  This approach is not viable in service workers as not every change should show a notification, particular if users have disabled notifications. (Background sync seems unviable as we'd need to ping every few seconds, which is hugely resource-wasteful).
  
• WebSQL access in service workers. I've had a few threads with the storage team about why we're using WebSQL, but the TLDR is that it's orders of magnitude faster than indexedDB for full-text-search, and significantly faster for most other operations. It's also (in my opinion) much easier to use if you have a non-trivial data model.
  

I'm happy to talk through these requirements more — I love the quality of experience we're able to deliver using a Chrome extension today and fully support moving to a world where we could deliver this experience using web standards. That said, I'm scared of a transition period where Chrome takes a step backwards before the web standards have caught up.

Conrad

Sent via Superhuman

--

You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extensions+unsubscribe@chromium.org.
To post to this group, send email to chromium-extensions@chromium.org.

Visit this group at https://groups.google.com/a/chromium.org/group/chromium-extensions/.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/a155e755-9ec2-4e36-8e6f-bff2c575417f%40chromium.org.

[Michael Yaroshefsky]

It's funny you mentioned this.  This is one of those patterns that I also thought about quickly as a way to migrate to the new standard:

• Build a small "relay" script in the Service Worker that would allow code in the content scripts to access privileged APIs via message-passing.
• Move our current "background.js" file into a tab that runs / pins itself when the user wants to use our product, and use the above relay for making privileged API calls through the Service Worker
• The "relay" Service Worker would also receive any calls in from the tabs that currently go to our Background and route them to whichever tab is the designated "background" at that time.
• Put up a simple UI in that designated persistent tab that shows some useful info to the user (but warns them not to close the tab)
• If they click the browser action on a tab and we detect the pinned tab isn't available (via the Service Worker), have the Service Worker set it up again and run the startup process all over 

I'm sure there are other problems I've yet to think of with this implementation, but at least in practice it would work.  

[Alex]

For Privacy Badger's response, please see https://github.com/EFForg/privacybadger/issues/2273#issuecomment-458697088

Note that we cover all aspects of Manifest V3, not just persistent background page removal, because it makes more sense to address them together.

[Dennis]

It should work but I don't think it should be necessary.  Since we're going to try to do it anyway the background page should just be left alone.

One big thing I'm worried about is that they're going to see this work-around and then instead of undeprecating the background page they're just going to break the method because it's too effective, too many devs will use it, and too many users will have a cluttered tab bar.  They'll probably use the argument "our goal is to provide a simple browser" or something.  Safari is a simple browser.  People don't like safari.  What they need to do is give us more power and options for how we can modify the browser, not limit what we can do.  Is this some kind of 4D chess move where they're trying to push more people to Firefox for a more diverse browser ecosystem?  I dunno.

[Aleksandr G.]

Dennis, Safari is so simple browser so some developers should send empty messages using small timeouts to keep the Safari Companion (Native Host in Chrome) always running instead of being killed by OSX system. The solution with empty tabs and Service Workers is great proposal, as a joke I offer to add also sending empty messages to Service Workers to keep them always running. Having for example 10 extensions with always opened 10 tabs with text "please do not close this tab..." - is this our Chrome browser feature?

[wOxxOm]

We can also hijack one of the existing tabs - insert an iframe that points to a file declared in web_accessible_resources that rebuilds the state from storage and listens to messages sent by chrome.runtime.sendMessage (that is there's no need to send directly to this tab). Whenever the hijacked tab is closed or discarded due to memory pressure (or unloaded by another extension), we could hijack another open tab. When I think about the retarded hacks we'll have to use it reminds me of IE6. I wonder if its project managers also thought they're doing all those weird things IE6 is known for in the best interest of their users.

[Hr Gwea]

I find all this (planned) breaking changes a PROFOUND DISRESPECT towards developers like me who give our time and effort to develop extensions, without which the Chrome browser would be quite annoying to use.

We, developers, come up with an idea for an extension, we investigate how to realize that idea, we conceptualize the idea into a design, we implement that design, we test it thoroughly to make sure it works well. We go to the extent of paying US$5 to make the finished product available for everyone, and for free. And we do all that by spending significant time and effort of our lives, without receiving a single dime for it.

I you (Google and whoever is in charge of these decisions) expect us to do all that for your browser, you should show A MINIMUM OF RESPECT by keeping the browser BACKWARDS COMPATIBLE.

You seem to believe that we are part of your business model somehow. That it's us who have to deal with the consequences of your bad engineering decisions, like if we were your employees or something. Well...no. It's you who have to deal with the consequences of your past decisions. That's exactly what backwards compatibility means. Decisions made in the past, no longer seem right today, but you deal with them because the world has to keep rolling.

Look at what Microsoft does with their flagship product. Software that was developed for Windows 20 years ago, still works today. They understand with perfect clarity how important it is that EXISTING SOFTWARE MUST KEEP WORKING.

You, on the other hand, can't make your browser to support software made for it 3 years ago. You keep breaking backwards compatibility time and time again.

I will not spend a minute of my time re-designing and re-implementing my extensions. They were made in the good faith that they would serve people for years and years to come. They were not made thinking that I would have to redo them entirely every few years because GOOGLE CAN'T MAKE A BACKWARDS COMPATIBLE BROWSER.

[Simeon Vincent]

Hey all,

I just wanted to pop in real quick to say that I really appreciate the constructive feedback we've been getting here. In particular, I'd like to call out Michael Yaroshefsky's original email and the follow-ons that described specific use cases and the functionality missing form service workers.

There are a couple issues folks have raised that I'd like to better understand so that I can advocate for effective solutions.

• How and when are your (or other's) extensions using audio in background pages?
  
• Folks have shared some compelling use cases for parsing HTML and XML, but I could use some more context on how/why folks are using DOM in (persistent) background pages. 
• A few folks have mentioned security concerns with storing sensitive data to disk with the chrome.storage.local and chrome.storage.sync APIs. I want to follow up with folks around here to better understand Chrome's threat model and expectations for extensions developers that need to persist sensitive data. To that end, I'd appreciate any additional details you can share about your specific concerns and use cases here.
  
• A couple of folks voiced concern about service worker startup time. I'm curious how much of this is rooted in observations of current event pages (aka lazy background pages) or service workers. Hard data makes a much more compelling argument than philosophical objections.

Cheers,

Simeon

Chrome Developer Advocate

[wOxxOm]

It'd be nice if you describe the level of your knowledge in the discussed area and how you can influence the V3 plan.

 

> How and when are your (or other's) extensions using audio in background pages?

> Folks have shared some compelling use cases for parsing HTML and XML, but I could use some more context on how/why folks are using DOM in (persistent) background pages. 

I think the provided info should have been sufficient so it's not clear to me what exactly needs clarification here. There are tons of use cases. Too many to even guess by those few of us who knows about the V3 plan. If you honestly care about extensions and intend to be really constructive, not just maintaining a good PR front that would allow you to say sincerely "we discussed this publicly and did not see any compelling use case", consider adding the usage metrics to Chrome and collect the statistics over a month for the mentioned APIs like DOMParser, audio playback, and others. Or better yet, run a search query on all the extensions in the Web Store and see how many are using various DOM-related APIs in their background pages and what for, and how many users those extensions have. This is something that one would expect to have been already done by a seasoned team. Please don't rely entirely on the feedback from us, a few developers who accidentally happened to be aware of the impending change in time to give the said feedback.

> A couple of folks voiced concern about service worker startup time. I'm curious how much of this is rooted in observations of current event pages (aka lazy background pages) or service workers. Hard data makes a much more compelling argument than philosophical objections.

Like any other experienced extensions developer, certainly not an abstract condescending philosopher who tries to downplay the concerns voiced by other experienced extension developers here, I know that even the simplest lazy event page script takes a huge amount of time to start compared to 0 ms of an already running persistent page even in Canary that has NativeCrxBindings and V8 Snapshots preloading as tested on a 4.4GHz four-core i7 computer - anywhere between 75ms and 750ms (first time in the session), which could be much much worse on an average computer especially if the browser is busy. It was 75ms for a one-line script with one onMessage listener, and of course it'll grow *considerably* for a realistically complex event page script. Add the time needed to read the storage and rebuild at least some parts of the state needed to make a decision on a request. The negative impact of such a delay should be evident to any developer without the need to explain it. If there's such a need, we the extensions developers are in much more trouble than we thought could be possible.

[wOxxOm]

There was a good point mentioned by Simeon Vincent which I've missed and I am sorry about that - a service worker that has no DOM bindings would probably start much faster than an extension event page that has to establish DOM bindings at startup. Well, that might work for us if you provide some way like an API to create a sandboxed sub-worker to do the DOM stuff using the native DOM APIs.

[Dennis]

Hi,

There are many possibilities that are being cut off with the removal of the background page.  I wouldn't know about all of them so I'll speak about the single one that concerns me at this point in time.

• A few folks have mentioned security concerns with storing sensitive data to disk with the chrome.storage.local and chrome.storage.sync APIs. I want to follow up with folks around here to better understand Chrome's threat model and expectations for extensions developers that need to persist sensitive data. To that end, I'd appreciate any additional details you can share about your specific concerns and use cases here.

I need to save decrypted data in memory so that when the browser closes there is nothing left in plaintext.  In my extension trying to load the encrypted data from local storage requires a username and password.  Saving the decrypted data to disk at any time means that it could be recovered by non-users.  In order to avoid signing in for every single tab the content script sends a message to the backend script for decrypting items on the page.  The backend script and page hold the user configuration necessary to do everything.  The following are dead ends when it comes to supporting what I want to do:

1. Cookies with no expiration dates (session cookies) aren't actually removed when users have "Restore browsing session" or something, This also goes for the clear on exit option setting.

2. There's no way to trigger removal of certain keys in local extension storage on browser exit.  The threat is from physically losing control of your computer.  The feature I'm trying to support is security via closing your browser that works both in normal browsing and incognito browsing..

3. IndexedDB doesn't allow triggering a removal on browser exit.

4. The "keep local data only until you quit your browser" option is too broad.

If there's a standard way to do what I want that I've missed then great I'll use that.  But I'm against using anything that stores sensitive data to disk.

[wOxxOm]

Continuing my rant about the service worker startup time.

Even NativeCrxBindings (native extensions API bindings) setup takes a lot of time which defeats the fast startup time of the service workers. There are histograms for that timings e.g. Extensions.ApiBindingGenerationTime and Extensions.Bindings.NativeBindingCreationTime - and from what I see in chrome_debug.log when running Canary with "--enable-logging --v=1" the minimum time for the latter is 75ms. Assuming the measurements are correct it means that a service worker using any chrome API will have that added to its startup time. It appears we do have yet another valid reason to be really concerned about the deprecation of the persistent background pages so it would make sense if Chrome devs tried to implement a PoC and see how much time is actually added by the extensions API bindings - maybe it can be improved, maybe even considerably, maybe not, maybe it'd possible to do by the time V3 launches, maybe not, but before going ahead with such a huge breaking change it seems like a mandatory thing to test a PoC first and share the results instead of downplaying or invalidating our concerns.

[Scott Fortmann-Roe]

@Simeon, following up on your asks for additional information

- We use sound to convey information to the user. Specifically, our extension monitors user inputs for a specific sequence of characters. When they occur, we replace them with a user specified replacement (so instead of typing 'Chrome Extension' I could just type 'cx' and have it be replaced with 'Chrome Extension'). When these replacements occur, we play a short sound to ensure the user knows their text was modified.

- We use the DOM in a background page to enable styled-text copy and pasting. We do this by maintaining a contenteditable field which we then call execCommand on. There are some relatively recent JS API's to manipulate the clipboard (e.g. https://www.chromestatus.com/features/5861289330999296) but they don't support styled text.

- Startup for us requires making network requests to load user-specified replacement mappings. This is simply too slow for us as our use case needs to respond almost instantly to user key presses. Note that the mappings may be shared amongst multiple users, so we _have_ to make the network requests rather than simply caching the mappings as another user may have changed the mappings since they were cached.

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To post to this group, send email to chromium-...@chromium.org.

Visit this group at https://groups.google.com/a/chromium.org/group/chromium-extensions/.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/6935118d-4628-4895-8437-5cd24a4102fd%40chromium.org.

[Dennis]

Simeon,

So is the only way to get rid of the idea of removing background pages to present reams and reams of data proving it's a bad idea?  Is it even possible or would I just be arguing with a brick wall?  I've just reread the P1 portion of the v3 draft and from my perspective it's going to complicate development and slow down extensions in the long term for little gain in overall browser performance, especially when both persistent background pages and service workers can coexist.

I seriously just want to know whether the person who is spearheading this proposal will actually listen. or whether I'm screwed before I begin.

On Wednesday, January 30, 2019 at 11:23:14 PM UTC-8, Simeon Vincent wrote:

[Hr Gwea]

If anyone from Google is paying attention to this thread, can you answer the following, please.

Given that you are determined to remove all forms of background persistence,

1. Are you planning to remove the "background" permission as well?

That permission allows an extension to keep running in the background while all other tabs and windows are closed.

2. The API chrome.runtime.connectNative() establishes a persistent connection with a messaging host. This, of course, requires a persistent process on both sides of the communication link. Are you planning to get rid of the persistent connection port as well?

Can we get a straight answer please?

The extensions I develop are deeply dependent on this kind of persistence, and there's really no point in investing more time if they have a death sentence already.

[Vasco Gomes]

I'm absolutely sure that if background pages are removed it will cripple or make nonfunctional >80% of the extensions in Chrome Web Store. Basically Google can shut Down it's Chrome Web Store because it will be almost useless and/or empty.

Event Pages are the foundation of all Chrome Extensions, that's for sure.

There is no tutorial, extension that was made in the last 4 years that doesn't rely on persistent background pages.

It impossible to give particular examples (some were given) but there are thousands of examples, the Developers imagination is the limit. 

Today with machines with 4-8-12 cores, 8Gb ram and SSD's the background pages are a drop in the ocean. 

There is no impact in performance and there is no study of pratic test to support this ever made. We are in a field of theories.

Greetings.

[wOxxOm]

The new official response, which is primarily focused on the declarativeNetRequest API, doesn't say anything new about the concerns raised in this thread except that they're still evaluating it and will keep us posted, but here's a quote I find interesting:

Similarly, background pages were a major inspiration for ServiceWorkers.  Completing this cycle involves moving the extensions platform to use the open web alternatives when they exist. Maintaining separate APIs has very real cost for the Chromium project (through ongoing maintenance), for developers (through confusion between similar-but-different APIs), and for users (through increased resource consumption and binary size).

Let's look at the points of "Maintaining separate APIs has very real cost"

• for the Chromium project (through ongoing maintenance)
  
  Judging by the activity on https://crbug.com and https://chromium-review.googlesource.com it looks like the extensions API team that consisted of many developers 5-10 years ago is down to one or two who actively develop/review now (Devlin Cronin and Karan Bhatia).
  
  So what does it mean and why should we care, the third-party extension developers and users? Does it mean Google doesn't have the money to hire new talented developers? Or does it mean there are no developers in the world today who want to work on maintaining the extensions-related code in Chrome?
  
  It'd be nice if this point is clarified in a more technical fashion in the next official announcement.
  
  
• for developers (through confusion between similar-but-different APIs)
  
  Which APIs exactly?
  We are developers here so please be technical and specific, otherwise it looks bogus. Also this was worded really poorly.
  Like "Google thinks the extension developers are too dumb to understand the difference", probably?
  
  I haven't seen any of extensions-related Chromium developers participating on StackOverflow over the last years (the only one I know of who was doing it several years ago is Rob Wu, now one of the many developers of the WebExtensions API in Firefox), so the quoted opinion must be based on the posts in the Chromium Extensions Google Group and their bug tracker. But that's not representative. As someone who've posted hundreds of helpful answers and thousands of short hints in comments on extensions-related questions on StackOverflow I can say that StackOverflow has orders of magnitude more extensions-related questions and the most knowledgeable users post there anyway, not in the group I've linked above.
  
  Probably half of the people who start with the extensions development seem to not have read the intro about the overall extensions architecture.
  Deprecating the background page in favor of a ServiceWorker won't help them.
  
  A much much bigger problem than the quoted confusion and that's apparently not evident for the superknowledgeable developers of the extensions API internals like Devlin Cronin is that the official documentation is still convoluted, even after the recent rewrite, and is lacking in the examples of code/usage, the demo extensions being linked in an obscured fashion, the explanatory pictures being actually confusing - why is popup.js a separate entity like it's not a part of the popup environment? Overall it's quite evident that whoever did these pictures didn't observe the thousands of questions I've been seeing on StackOverflow. Compare that to the examples and documentation in any other popular project and you'll see a lot of similarly embarrassing things.
  
  
• for users (through increased resource consumption and binary size)
  
  Again, please be technical, give us the numbers, otherwise "resource consumption" looks bogus as anyone can see in their Chrome's task manager that a background page of an extension consumes several times less memory than a typical modern web page. Even if the user has 10 extensions with persistent background pages installed it would amount to just one or a few modern web pages opened.
  
  As for the binary size, I guess the point was the size of the Chrome binary that contains the necessary code to maintain the separate extensions API related to the background pages. Please be technical, and give us at least an estimate.

There's also a quote "Good performance on low-end devices is critical.", which also looks bogus, as we can already run extensions on mobile phones in a Chromium-based Yandex browser and the performance is good even on budget mobile phones with just 2GB of RAM. Note, the official mobile Chromium/Chrome for Android can't run extensions, which doesn't add credibility to the official statement.

[Radiant One]

Well said.

I think one of the most glaring holes in Google logic here is using the security and "protection of the user" as its key platitude for removing features. Yet if we use firefox as a "canary in the coal mine" are malware extensions really a big problem over there? With the userbase firefox have you could easily use it as a population sample to extrapolate how big of a problem it really is. The answer? Not that big really.

--

You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To post to this group, send email to chromium-...@chromium.org.
Visit this group at https://groups.google.com/a/chromium.org/group/chromium-extensions/.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/3c66ca6e-bb0e-4a8e-a75a-58fac6f9c991%40chromium.org.

[PhistucK]

Just my two cents regarding one of the points -

> for the Chromium project (through ongoing maintenance)

Remember that while the extension team might be small (I do not know how many they really are), the maintenance cost of extension features is not limited to that team. Background/event pages (for example) probably require some special handling in the web engine itself (Blink), and more edge cases to consider when maintaining it, as well as process handling code, scheduling code and more. So while the extension code itself might be written and maintained by the team, it is disruptive and has maintenance costs in parts of the code that are not specifically extension code, but might exist only to cater for extension features.

I am not advocating that they should stop maintaining it (I doubt this part of the plan would actually be executed at this stage, too many use cases), just putting things in a different perspective.

☆PhistucK

--

[wOxxOm]

That's a valid guess, and indeed I saw more than once that a newly added browser feature has broken something in the related extensions code. This guess also allows us to translate the entire V3 plan to a more honest "We the developers of Chromium got tired of maintaining extensions-related code so instead of expanding the team to rework the API internally while making sure we're not crippling it - which is likely impossible to justify to our management - we find it'd be easier for us to just neglect those millions of more-or-less advanced users who had been using Chrome/Chromium only because of the powerful extensions as we believe only a negligible amount will be affected and those aren't our target audience anyway so... whatever".

This is why I'm waiting for a proper technical announcement, preferably devoid of buzz-words such as "moving forward", "completing the cycle" and similar corporate fluff.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extensions+unsub...@chromium.org.

[wOxxOm]

Chromium team is working on hooking up extensions API in a service worker context (https://crbug.com/925918) so I guess there's a 99% chance the deprecation of the extension background pages is final.