Support navigator.clipboard inside of Service Workers

[patrickkettner]

Hiya folks, I work in devrel for Chrome Extensions. I have been helping folks migrate to manifest v3, and one thing that has come up a number of times in clipboard access. In the past, a background page made it easy to use standard DOM interactions with the clipboard. But with extensions moving to a service worker based background in manifest v3, it becomes a lot more complicated. While there are workarounds¹, it would greatly reduce complexity of a number of extensions if the platform had access to navigator.clipboard.

In practice, I believe this would mean exposing Clipboard onto WorkerNavigator, as that is what is inherited by the service worker.

1. Here is a code example. We have chrome.offscreen, which gives the developer access to a HTML document they provide that is rendered offscreen. To copy the clipboard, you need to create the offscreenDocument singleton, send an event over RPC to the HTML document they provide, which listens for the event, then executes document.execCommand (offscreen documents don't support navigator.clipboard as of now), then responds with another RPC back to the service worker with the data they requested, and then shut down the offscreenDocument. Its a lot of indirection.

[snianu]

@patrickkettner Just a heads up that we will be discussing this issue in this week's EditingWG meeting which is scheduled on Thursday 8am PST. Link to the meeting: https://www.w3.org/groups/wg/webediting/calendar/

[patrickkettner]

thanks! I will be in attendance.

[smaug----]

How would the API work for web pages when used in service worker? There is no user activation or anything, so clipboard.read(), as an example, wouldn't ever work.

[patrickkettner]

@smaug---- great question! That is correct, without user activation, it wouldn't work. So it would only be useful in situations where the user activation could happen outside of the service worker, like in the case of Web Extensions. The base of extensions in manifest v3 is a standard service worker.

[smaug----]

But user activation is defined to be bound to Window object, and clipboard requires that. I'm missing to see how this could work.

[patrickkettner]

On the web, it wouldn't. In a Web Extension, there is a separate permissions model for the user to knowingly allow for the action to take place and way to receive user inputs. A common usecase is an extension that listens for a command key or click of the action button to copy a shortened/templated/more-than-just-the-standard URL of the currently viewed tab.

[snianu]

deleted my previous comment as it was not related to service workers

[smaug----]

But Web Extensions aren't part of the web platform. See for example https://github.com/whatwg/html/issues/8362#issuecomment-1271048474 (and which is why https://github.com/w3c/webextensions/issues/287 was filed)

[css-meeting-bot]

The Web Editing Working Group just discussed Support navigator clipboard inside SW.

The full IRC log of that discussion

<dandclark> topic: Support navigator clipboard inside SW
<dandclark> github: https://github.com/w3c/editing/issues/458
<dandclark> PatrickKettner: I'm part of webextensions group
<dandclark> ...: focused on standardizing extensions across webplat
<dandclark> ...: Move to manifest V3 is a major focus. Move background script from dom to ServiceWorker.
<dandclark> ...: One of the difficulties with migrating is clipboard access
<dandclark> ...: Would be great if navigator.clipboard was exposed for use in extensions
<dandclark> ...: I have a collection of use cases for web and extension-based SWs
<dandclark> smaug: I'd be curious to know use cases for web
<dandclark> ...: Without those we can't move anything through spec
<dandclark> ...: Discussed this with Rob from Mozilla
<dandclark> PatrickKettner: We could extend it, want to try inheriting from the web first
<dandclark> ...: Recent use cases were enterprise-focused. E.g. clipboard exfiltration
<dandclark> ...: Sync data that's been copied to their backends. Not user-focused, it's site focused.
<dandclark> ...: It's polyfillable. SW allows a more centralized place though
<dandclark> ...: Other use case is clipboard syncing
<dandclark> ...: Useful for education, certain cooporate environments. Tutorial where it's useful to push complex stuff to clients' clipboards.
<dandclark> ...: Polyfillable without SW but simpler if exposed on SW.
<dandclark> ...: Last one is about data security, encrypting clipboard contents.
<dandclark> ...: If it's sensitive, encrypt it with a key
<dandclark> ...: Only the owner of certain content could understand secure content being copied, or doesn't work outside secure environment
<dandclark> ...: Or, automation based of clipboard content. Things happen automatically when copy certain types of content. E.g. rewrite link to markdown.
<dandclark> ...: Or rewrite rich text content
<dandclark> ...: Checking current value of text is, certain website can make sure you're copying it to certain format
<dandclark> ...: There's lots of examples, I can go over more.
<dandclark> smaug: Many of the use cases you can do without SW.
<dandclark> ...: Everything we can do without this change. This change is about improving developer experience.
<dandclark> PatrickKettner: Everything we can do without this change. This change is about improving developer experience.
<whsieh> q+
<dandclark> ...: This is about reducing complexity, ensuring things are more well-built, less code has to be written.
<dandclark> whsieh: I'm not too familiar with Chromium implementation, do they show prompt when you access clipboard without user gesture?
<dandclark> PatrickKettner: For extensions, you have separate permissions model. Extension dev has to request clipboard read and write. There is standard and optional permission.
<dandclark> ...: Current message mentions can read/write all contents on clipboard.
<dandclark> ...: We encourage people to use optional, which is jit. User gets a prompt they can approve/reject
<dandclark> ...: On the web there's a popup prompt. User can rescind at any time.
<dandclark> ...: There isn't a prompt every time. That's just my understanding, could be incorrect
<dandclark> whsieh: Our model (webkit) is prompt every time
<dandclark> ...: That data is read off clipboard
<dandclark> ...: If you copy password, could be problematic
<dandclark> ...: May want a policy where if you've granted permissions through webextensions, with higher bar for user trust, we could take that as hint of trust to let the page read/write
<dandclark> PatrickKettner: My understanding is that's how it works now with execCommand in WebKit
<dandclark> whsieh: Depends on how you trigger paste. cmd-v is one case, if you trigger via button it's different. Depending on where user mouse is, show an option to paste. Doesn't seem this works well for SWs.
<dandclark> PatrickKettner: For extensions, we have UI affordance
<dandclark> ...: In Chrome, it's like other extensions permissions prompts. Not modalized, it's just a popup
<dandclark> ...: From dev point of view, you can check if you have permission, do something in accordance with that.
<dandclark> whsieh: That sounds good
<dandclark> PatrickKettner: That could be a requirement
<dandclark> smaug: But SWs don't need to be bound to any UI
<dandclark> PatrickKettner: If no UI, you could reject, say if you don't want to trust ServiceWorker if there's no UI
<dandclark> ...: Microsoft did work to have clipboard permission prompting be supported in Chrome
<dandclark> ...: If you dont' want to trust that a background SW is trustworthy you can automatically reject
<dandclark> estade: Don't think we'd allow access to clipboard without UI affordance, and no way to have affordance with ServiceWorker.
<dandclark> estade: Blanket access doesn't require user gesture. But regardless of what you press, page has to be focused. That's by design. Difficult to get stakeholders to align on changing that.
<dandclark> ...: Having something constantly monitor your clipboard seems open to abuse.
<dandclark> ...: There are other ways to do this, e.g. in enterprise you could have an app that monitors this (not web app)
<dandclark> ...: E.g. we just made it so extensions when they have extensions permission can use web api because it's effectively the same thing. But we've historically moved back and forth on the exact behavior we want with respect to permissions. Pretty sure the focus requirement is a pretty hard one.
<dandclark> ...: Comparing to DataTransfer, stance of security team has been that we'd unlaunch it if we could.
<dandclark> ...: It seems tough to me to extend this to offscreen, invisible pages.
<dandclark> PatrickKettner: That's fair. And we can solve these problems without work in this group. But we'd like to have reduced the code devs write from hundreds of lines to 1.
<dandclark> johanneswilm: You mentioned execCommand to get access to clipboard. Is there any alternative to that?
<dandclark> PatrickKettner: No that's the only option
<dandclark> ...: Extensions have a number of services; content scripts, background scripts...; if you are content script, they have full DOM access. So can get navigator.clipboard.
<dandclark> ...: But non-DOM surfaces (workers), you don't have access. YOu only have execCommand, through a special invisible-DOM thing where you have an RPC connection into the DOM environment. Offscreen document is a hack to get things that don't exist in SW available in SW.
<dandclark> ...: In Google there's extensions that are clipboard managers, they have to use offscreen document and execCommand.
<dandclark> johanneswilm: I understand the security concerns but getting rid of that usage of execCommand seems good to have on the horizon somehow.
<dandclark> smaug: I don't know why that needs to be use, you'd stiill have clipboard API access in hidden document
<dandclark> PatrickKettner: Don't have access.
<dandclark> ...: The read/write permissions don't get passed to navigator permissions. In Chrome 122 this changed; you need document focus, and we can't have that in this case. Have access to it, but can't use it because don't have focus.
<dandclark> snianu: If authors can get accesss to clipboard somehow, what's the security concern? It's not like with focus command you're preventing web authors from accessing clipboard. Authors will just use execCommand.
<dandclark> ...: and we won't be able to remove them. We're trying to move partners to clipboard APIs by giving them more capabilities.
<dandclark> estade: clipboard API is more ergonomic, want to switch. But just because you can do something with execCommand it's very insecure. The fact you can make an extension that monitors clipboard state without using browser is bad, shouldn't continue. It's a sec vuln that could blow up on HN or a blog somewhere. Have to find some way to have equivalent to the intent behind user focus to narrow this down.
<dandclark> ...: Good use case is when user clicks button and that accesses clipboard. But current proposal allows much wider use cases. Need to look at making things more restrictive over time, not more lax.
<dandclark> ...: Have to capture the fact that the user clicked the button, make sure they know what's going on.
<dandclark> ...: There's a way to achieve this but I don't think it's as easy as just exposing the API
<dandclark> PatrickKettner: Agree, we'd love to get rid of execCommand. Would block it if we had another way. In Chrome, certain APIs are tied to user-generated events. Can restrict that here. Where would that be defined?
<dandclark> estade: Sounds promising. Guessing it's a webextensions thing. Document itself doesn't have context of user interaction
<dandclark> PatrickKettner: You can tie to user action though event chain
<dandclark> ...: Not sure about requirements are needed to proceed on that.
<dandclark> smaug: Right now the clipboard api is on user activation which is tied to <missed>.
<dandclark> PatrickKettner: It's running in offscreen doc, like invisible tab. WIthin that it's a standard docuemnt that has RPC back to server
<dandclark> smaug: There are APIs in serviceworker that would require user interaction?
<dandclark> PatrickKettner: Yes
<dandclark> estade: Lots of extension APIs, why does this need a separate page? Why is that not directly an extension API <missed>
<dandclark> PatrickKettner: Say you wanted to copy current crbug URL to clipboard. Content script could inject that into page, but now it has full access to page. SW doesn't have full access to page, only to clipboard. So scope is reduced security-wise.
<dandclark> ...: Today when you're implementing that, have to do iwth off-screen document and execCommand.
<dandclark> estade: So only two actions can be triggered when press button are inject content script...there's not long list of APIs that can be triggered
<dandclark> ...: When you have page action icon and user selects it, I would guess that there's 50-100 extension APIs you can just call in response to that. But sounds like all you can do is run some JS.
<dandclark> PatrickKettner: You can call extension APIs when you do those things, and run arbitrary JS.
<dandclark> PatrickKettner: The only non-web-standard thing in offscreen document is send message to SW.
<dandclark> PatrickKettner: Dev flow is you do something in content script, send message to SW, everything has to be serialized
<dandclark> johanneswilm: How do we proceed? Question is should web extensions group be involved in this?
<dandclark> PatrickKettner: I can represent that group and Google extensions team as intermediary.
<dandclark> ...: Main concern is understanding if this is definite no, definite yes, or not sure yet
<dandclark> ...: If this group doesn't like this we can look into extending extensions API
<dandclark> smaug: So far I haven't heard too convincing use cases for the web.
<dandclark> ...: Based on discussion with Rob earlier, think it makes more sense to do this on webextensions side first, bring it back if there are more compelling use cases for web.
<dandclark> PatrickKettner: Webkit position?
<dandclark> whsieh: I agree with Olli.