I 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.
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.
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.
> 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.
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.
> 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
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.
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.
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.
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.
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.
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.
nightpool|3 years ago
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.
polote|3 years ago
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
fosefx|3 years ago
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.
xg15|3 years ago
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.
lelandfe|3 years ago
Erm. Have you read the link? There are extension authors in the comments that talk about their specific use cases
unknownaccount|3 years ago
What? By choosing to install the extension you are activating it.
zzo38computer|3 years ago
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.)
drorco|3 years ago
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.
shaky-carrousel|3 years ago
fzfaa|3 years ago
[deleted]
madeofpalk|3 years ago
> 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.
fosefx|3 years ago
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.
cobertos|3 years ago
> 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.
gnicholas|3 years ago
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.
desindol|3 years ago
userbinator|3 years ago
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.
wvenable|3 years ago
encryptluks2|3 years ago
fosefx|3 years ago
I don't know if there is a readClipboard permission as well.
joecot|3 years ago
dotproto|3 years ago
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...
zzo38computer|3 years ago
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.
hombre_fatal|3 years ago
> 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.
cobertos|3 years ago
swatcoder|3 years ago
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.
cercatrova|3 years ago
withinboredom|3 years ago
ffhhj|3 years ago
mmmpop|3 years ago
cobertos|3 years ago
aeharding|3 years ago
unknown|3 years ago
[deleted]