Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cannot read clipboard from service worker in a MV3 chrome extension (2020)

bugs.chromium.org

Post reply on HN
Print view View original

51–56 of 56 posts

Re: Cannot read clipboard from service worker in a MV3 chrome extension (2020)

#51

Post by [deleted] »

xg15 wrote: post #42
nightpool wrote: post #14

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 som…

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.

[deleted]

Re: Cannot read clipboard from service worker in a MV3 chrome extension (2020)

#52

Post by xg15 »

PeterisP wrote: post #49
xg15 wrote: post #41

Earlier quoted context omitted.

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.

Re: Cannot read clipboard from service worker in a MV3 chrome extension (2020)

#53

Post by desindol »

SquareWheel wrote: post #44
desindol wrote: post #5

Earlier quoted context omitted.

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.

Re: Cannot read clipboard from service worker in a MV3 chrome extension (2020)

#54

Post by nightpool »

fosefx wrote: post #25
nightpool wrote: post #14

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 som…

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…

> 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.

Re: Cannot read clipboard from service worker in a MV3 chrome extension (2020)

#55

Post by egfx »

xg15 wrote: post #42
nightpool wrote: post #14

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 som…

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.

Re: Cannot read clipboard from service worker in a MV3 chrome extension (2020)

#56

Post by dotproto »

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...

Post reply on HN