Cannot read clipboard from service worker in a MV3 chrome extension (2020)(bugs.chromium.org) |
Cannot read clipboard from service worker in a MV3 chrome extension (2020)(bugs.chromium.org) |
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.
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
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.
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.
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.
Erm. Have you read the link? There are extension authors in the comments that talk about their specific use cases
What? By choosing to install the extension you are activating it.
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.)
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.
> 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.
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.
> 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.
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.
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.
I don't know if there is a readClipboard permission as well.
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...
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.....
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.
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.
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.
For instance “Did you just…unplug and replug the machine?”
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.