Cannot read clipboard from service worker in a MV3 chrome extension (2020)
bugs.chromium.orgI know there are a lot of valid complaints about Manifest v3, but I don't understand this one. You're telling me that browser extensions should be able to read and write to my clipboard silently at all times, with no user activation or notification? Honestly, that's kind of horrifying, and I'm shocked to hear it existed on v2 extensions. It sounds like a great way to build a keylogger for user passwords.
What are some valid usecases for this permission? I guess "syncing clipboards between two operating systems" is one of them? But why build that as a browser extension? It seems like the wrong tool for the job.
What is true is that if you remove all features that chrome extensions can do then you won't have any problem as extensions will be useless.
Are you too going to be shocked that any js analytics tags could record all passwords if they wanted?
Should all extensions be able to read the clipboard? No. Should some be able to? Of course
Well an extension can also just send your session tokens home. In the end it's software running on your computer, but people unfortunately often times underestimate the power of add-ons (read the permissions screen folks!). Mozilla requires a manual code review before allowing add-ons into the store because of this afaik.
In my example there was direct user interaction (clicking a context menu) but the service worker (background script) has no API to interact with the clipboard at all.
I guess my point is not that it's an easy thing to fix, but the fact that it looks like nobody at Google has thought about this before forcing everybody to migrate is concerning.
> Well an extension can also just send your session tokens home
Only if I give it access to the browsing origin in question, which Chrome has done a lot of work to limit and crack down on recently
> Mozilla requires a manual code review before allowing add-ons into the store because of this afaik.
This is unfortunately not actually true. They tried it for a while, but scrapped the idea after the review backlog got too unmanageable. Now all of the addons just say "This add-on is not actively monitored for security by Mozilla. Make sure you trust it before installing."
> In my example there was direct user interaction (clicking a context menu) but the service worker (background script) has no API to interact with the clipboard at all.
That makes sense—the limitation is just that nobody has built out the clipboard API in a way that it can register a context menu item as a transient activation and therefore allow access to the clipboard. This does sound like ultimately something that's possible to fix with the right plumbing, it just requires someone to take a look at it and hook up the right security plumbing.
The thread contains lots of mentions of clipboard manager extensions which are apparently quite popular.
It should probably be put behind a permission, but generally I don't see how this is more problematic than an extension gaining full access to the page you're viewing.
This. When an extension is installed the privacy sandbox is removed. Google manually audits each extensions code and looks out for bad behavior. You cannot call out to external scripts or use mangled source code.
> What are some valid usecases for this permission?
Erm. Have you read the link? There are extension authors in the comments that talk about their specific use cases
>with no user activation or notification
What? By choosing to install the extension you are activating it.
Do you also apply this logic to all other forms of hardware and software? For example TVs that spy on what you're watching.
When I install any piece of software I assume it could do anything and everything on the system.
I don't think most people operate under this assumption, or do not reckon with this.
We all do. A native app you install on a phone or desktop can do all sorts of things.
A native app you install on a phone has a strictly limited sandbox and a permission model, and if it can silently read all clipboard without user interaction, that would be a bug that needs fixing.
A native app on Android can install OS hooks for all sorts of things (such as, "you connected to a WIFI network", "you took a photo", etc) and thereby can silently react to events while it is not even running.
This is intended and requires the appropriate permissions to be given. In the same way, I don't see the problem with an extension monitoring the clipboard as long as the user has to give explicit permission for it.
> You're telling me that browser extensions should be able to read and write to my clipboard silently at all times, with no user activation or notification?
Well, the user has to activate the extension in the configuration menu, and it should include the notification that this feature is enabled, in the configuration menu. (If the user disables this feature but the extension is otherwise enabled, then the extension can have its own private clipboard instead. This can also be the case for web pages, too.)
More than 10 years ago I built a Firefox extension that was using the clipboard. It was for Multilanguage users that accidentally type in the wrong language, once they notice they type in the wrong language, they clicked a button/hot-key, and the text would switch to an alternate language in their OS.
I was eventually in the process of switching it to a Windows app, so it could also work outside the browser, but never actually finished it.
Now that I think of it, I'm pretty sure something like a password manager would also need the clipboard.
Sounds like a punto switcher tool
When you log into a site using bitwarden, and the site has 2FA, bitwarden stores the code automatically in the clipboard. It's pretty convenient.
1Password manages to autocomplete the 2FA code in the next screen, for what it's worth.
I think Chrome's reasoning for this is completely fair:
> navigator.clipboard is only intended to be used in a focused document, which is not possible for service workers. Therefore, I don't anticipate any intended support for navigator.clipboard.read on service workers
I don't think a browser extension, which I personally consider it sit in between "native app" and "website" in terms of privilege hierarchy, should be able to arbitrarily read the operating system clipboard silently in the background.
My use case: A background script, sorry, Service Worker registers a Context Menu Entry. When the user clicks on it it fetches some stuff an copies a link to clipboard.
Using MV3 as it is this is not possible.
As someone in the thread said, it is not really feasible to try to find all ways that user interaction can trigger code that requires clipboard access. If that is the route Google want to go down it will take years of people reporting new ways the system does not work until it is usable imo.
"User interaction to perform an action" im pretty sure is a part of the HTML/JS spec. For example, browsers on iOS will not let you play a video unless in response to a "user action".
Read farther
> historically when I've tried using navigator.clipboard from the MV2 background page, it would pop up a separate permissions dialog (presumably the one that would appear for standard non-extension contexts that are requesting clipboard access), despite the extension having clipboard permissions.
Does any one have a sense of the likelihood that Google extends the original timeline for this changeover? How can you force everyone to update their software (in some cases overhaul) to a new system that isn't fully built yet?
My company has two Chrome extensions, one of which is partly updated, and the other of which we haven't started yet. We have no idea what we'll discover when we begin the process of updating the second one, and we've been burned by Google's 'upgrades' in the past (Google Docs canvas-based rendering comes to mind). The worst-case scenario is that it is either impossible to migrate, or that it would cost so much that it would wipe out years of revenue.
I've talked with others in the accessibility space, and they are concerned about how this forced migration will impact the market for 'niche' tools like accessibility extensions. They may simply cease to exist. Hopefully Brave or other Chromium browsers will continue to allow legacy extensions.
It's google the graveyard and 69 chat apps memes are real. If you have the chance don't build anything on google services. Remember AMP? There were like AMP agencies popping up when it was introduced lol
I'm not sure where this idea came from, but AMP hasn't been discontinued. It also hasn't strictly been a Google project for quite some time.
Nobody is asking for it anymore and most corps that implemented it are getting rid of it.
How can you force everyone to update their software (in some cases overhaul) to a new system that isn't fully built yet?
Big Tech has been behaving like this for a while now. It's clear that they only care about their own interests (partly $$$, partly ideological), not yours.
Firefox did it. It's extension market never fully recovered. I don't expect the same to happen to Chrome though -- different situation.
If I'm reading this correctly, extension developers want a way to read the user clipboard with a separate permission dialog than having to also request the ability to inject scripts into pages? If that is the case I can partially see why this is the way it is. The clipboard reading permission is part of the privacy controls built into the browser. So with page injection, the extension would have to request permission for sites that it wants to read the clipboard from. Otherwise, a separate dialog would give unhindered access to read from the clipboard. Am I understanding that correctly?
I came across this because I wanted to port an addon over to MV3. It simply used navigator.clipboard.writeText(). That by itself only works as a reaction to a user interaction (so not in bg scripts), unless you declare the "writeClipboard" permission in the manifest.
I don't know if there is a readClipboard permission as well.
My company had a chrome extension they used for making twilio phone calls. V3's service worker focus made that a complete nonstarter. Ended up writing a thing to make phone calls in a background tab, use the Broadcast channel Api to communicate between the background tab and the active tab, and wrote instructions on the background tab for allowing sound permissions explicitly. The plus side is that we likely won't be dependent on chrome anymore, but I expect I'm not at the only company who got a rude awakening from the v3 transition. And yes, you can use v2 extensions with chrome enterprise, which I have no interest in doing.
Hi, Simeon from the Chrome Extensions team here. Clipboard access is one of the browser capabilities that currently requires a document to use. We're planning to address this use case (and others that require DOM) by introducing a new capability called offscreen documents[1].
In short, an offscreen document is a temporary headless page that is instantiated for a given reason that requires DOM access. It is not meant as a long-lived background context.
[1]: https://bugs.chromium.org/p/chromium/issues/detail?id=133938...
What I think is that what should be needing for browser extensions is to be able to write extensions in C, and available only for manual install by advanced users (so that it is not available to the official catalog of extensions).
However, additional capabilities to interact with the browser are also needed, including to implement new and intercept existing: protocols, MIME types, character encodings, HTML commands, CSS commands, JavaScripts in web pages (and the API they have access to), ARIA, menus, user interface elements, etc. (I think things will need to be rewritten to make this work efficiently, including moving many features to extensions which are then included by default, instead of being core features.)
Making C APIs for purposes would be helpful, although even if the existing API are with JavaScripts, JavaScript functions can be accessed by C codes by implementing N-API, I suppose.
> Thanks for the issue....
> Thanks.....
Aside: Do people know that trailing "..." tends to communicate annoyance or sarcasm? I think the people writing it think it means something else, like some sort of intermission before the next thing they write, but I wouldn't include it in professional comms at all.
I think it has a different tone to different people? I had a friend who used to put it after most messages and I thought they were upset with me until I asked. It was just how they wrote. I've also noticed more people using it to indicate a trailing off of voice, not necessarily with any annoyance emotion.
Maybe it’s a cultural thing cause even a trailing voice does communicates the same connotations of being upset. I know of only two buses of the triple dots: showing there’s more content in a quote or to express annoyance.
Some people use it to let an expression breathe a bit, modifying a period to be more like a paragraph break, or a paragraph break to be even a bit wider.
In some cases, that may represent emphasis, and might take it as an invitation to think on what was said because it was especially earnest or important.
In other cases, it might just a cleanser between ideas that don’t have a clear bridge.
> tends to
Online communication styles might be more diverse than you assume.
If something you receive feels stylistically out of place to you, you’ll get more value (and less frustration) by expanding your own dictionary rather than prescribing a narrower one to the author.
It's an age and geographic location difference. Young people see it as sarcasm, old people don't. Similarly in other countries its also not seen as sarcasm.
No, I don’t think people think that… because that isn’t what it means. People aren’t annoyed or sarcastic towards you… they are just pausing for a second.
I feel as though a comma and the end communicates a pause better. Especially since it use in formal English is similar.
Another name for ellipses (…) is “suspension point” and doesn’t have any true grammatical purposes, unlike a comma. A comma doesn’t necessarily indicate a pause and makes no sense to insert randomly… wherever you’d like the reader to pause.
For texting I meant specifically at the end of a sentence to indicate a possible continuation
My personal use for trailing ‘…’ is precisely to escape formal language and hint at something that is more complex or emotional than a simple pause.
For instance “Did you just…unplug and replug the machine?”
Ah I forgot about it’s usage ! For me it still takes on a negative connotation when used at the end of a sentence
It's like "loading....", but they are unloading.
My otherwise high-EQ boss does this all the time and it drives me bonkers.
I definitely think it's a generational thing, my mum loves ending sentences with '...' and honestly O don't know why. Reading it makes it seems like annoyance but I know that it isn't, so I don't know if it was just something they were taught?
This bug hasn't received a comment from another @chromium.org in >1 yr. Feels like so many of Google's bugs related to functionality many users relied on
It's extremely frustrating how some chrome extension apis such as chrome.tabCapture simply are no longer background context compatible, since they aren't in service workers. And they're just completely silent, don't even acknowledge the shortcomings. Just a hugely frustrating developer experience. Shame on Google, and this whole MV3 fiasco has permanently soured my view on Chrome developer Relations.