ClipboardChange event spec: Callout transient user activation should be applied for focus requirement.

[ragoulik]

Document being in focus is called out as a pre-requisite.
We propose to apply transient user activation to this, that is, event would fire even when document is currently not in focus if user had interaction in last 5 seconds.

It's important to call this out to avoid different implementations by UAs. Example today Firefox implements transient user activation for Async clipboard write but Chromium does not yet.

[johanneswilm]

From TPAC 2024 minutes:

w3c/clipboard-apis#225

Rohan: In the spec the clipboardchange event, the event is only fired when the user has docs on the webpage.

Proposing that the events are still allowed as long as the window had focus within the last 5 seconds.

Firefox already supports has a timeout associated with user gestures.

To restate: For the clipboardchange event, you need to have transient user activation.

Olli: What is the proposed model

Rohan: Event won't fire if you don't have focus. But they want it to be able to fire for 5 seconds after the user leaves focus.

Olli: There should not be transient user activation if the page doesn’t have focus anymore. As soon as focus is lost user activation should expire, if it doesn’t that’s a bug in HTML.

Sanket: If I understood Olli's question correctly, we check for user activation and don't fire if it's not present.

Maybe it's 2 separate things in this issue, we can focus on the user activation.

Olli: would you require transient user activation, would the event fire?

No

Sanket: Are we OK with the event firing if we have transient user activation.

Olli: ...maybe.. but it's a very different model than what Firefox and Safari do

Megan: Safari has a pop-up, so this wouldn't really work. Expect users to have clicked on a "Paste" button.

Sanket: The clipboardchange event does not contain the clipboard contents, it only indicates that the clipboard contents have changed.
Relevant info for potential mitigations.

Since this is mostly useful for identifying clipboard changes that occur outside the user agent, when is the event fired? Does it wait until focus is returned to the page?

Current spec - clipboardchange event must fire when the user agent regains focus.

Mostly useful in the case where you can access the clipboard (with permission) without a user gesture. So this is less useful for FF and Safari.

How did this even get into the spec in the first place!

Gary: It was added to the spec at the same time as the Async Clipboard APIs were added, however it was not implemented at the time.

The spec currently states that clipboard read permission is based on the result of a user interaction with a "Paste" element activated.

Async clipboard demo: https://glitch.com/edit/#!/async-clipboard-text?path=index.html%3A1%3A0

Example: On iOS, if JavaScript initiates a paste, the OS pops up a small paste button to get confirmation before allowing the paste.
Keyboard combos are considered to be the same as the user opting into a paste.

Etienne:Is that the same on iOS with an external keyboard?
Yes, because there is user interaction there.

Sanket: We need to think more about how this could be done in a way that could be supported by FF and Safari. Perhaps we can brainstorm for a bit.

Sanket: Safari already has a permission pop-up, could that be leveraged for this?
Megan: Maybe

Sanket: Olli do you have thoughts on the permission
Olli: Since we don't have permissions for paste, it would be challenging. We think our current model is the best for clipboard, so it would be hard to come up with an alternative.

Olli: Since there is only 1 implementation, it should be removed from the spec

Sanket: Actually 0 implementation, so that makes sense to remove.

Sanket: What about parallels with Camera access? You ask for permission for that?
Olli: Yes
Sanket: You don't do it for clipboard, because instead of permission, you prefer to rely on a user action
Olli: Yes and it's short lived. Because the info is soooooo privacy sensitive.

Sanket: What about a permission for the clipboard change?
Olli: Not useful if you can act on that event and access the clipboard.

Johannes: Could you show a notification to the user?
Olli: that's not what the event is for?
Johannes: But could you use it for that?
Olli: The user isn't trying to paste anything at that time, so it doesn't really make sense.

Sanket: Re: comparison with Camera permission model
If you block the camera API, then the camera does not work
In this case, if you block the permission, then the event doesn't happen.

Ryousuke: What is the use case for it, if you can't access the clipboard.

What about having a new permission for something like: "Monitoring the Clipboard". Would that be reasonable?

Ryosuke: I don't think so.

Megan: On iOS, each JS-initiated clipboard action results in the pop-up. There is no 5 second window. It applies to each action.

Megan: iOS does have some site-specific permissions (like Geolocation) that will last for some time (24-hours), but there is no option to grant a site permission in perpetuity.

Megan: Speaking hypothetically. In theory, if there was a site-level permission (like Geolocation) would that make sense for this? Yes. But we don't think such a permission is something we're going to add.

Sanket: Is that something we could reconsider? It would allow privacy to be controlled by the user and allow this feature to be added.

Sanket: Is there room for discussion about this.
Olli: Basically, we'd need to change our model for Paste.

Sanket: I don't think you'd have to change your model, but we'd all have to agree on a permission for this.

Scenario:
Permission to allow clipboardchange
Website tries to read clipboard, an (OS) "Paste" bubble pops up, which grants access

Olli: You know nothing about the clipboard, you can request types.

Gary: Are the types needed?

Sanket: Is it worth continuing with the other issues?

Sanket: Probably not. This is important. We need to digest this info and revisit.

Olli: We should make sure to remove the clipboardchange event from the spec.

Megan: Wenson says you can get clipboard type info without a permission, but this doesn't work for custom types.
Later clarification: This requires a simple user action. For read access, a click allows you to prompt for access (with native UI)
So you can only get clipboard types as part of a paste

Sanket: So something like this could work (in theory) for native types.

*** Welcoming Wenson and bringing him up to speed. ***

Relevant scenario:
Clipboard change event
Get clipboard types
Update the UI elements

Megan: Is there any appetite in Webkit for having a paste permission model (for the websites ) like what we have for native apps?

Wenson: The reason why we have this per-session model is that we don;t know if you've copied malicious text from a website, and paste into a doc. It might be fine today, but maybe tomorrow you have a password on your clipboard, so you might not want to share it

Megan: Compare to Geolocaiton where it's only available for 24 hours. How about that? Or is this something we ever want to do.

Wenson: We certainly don't want the permission to stick around. Probably allow it as long as the clipboard hasn't changed

Megan: Not useful for this particular case.

Wenson: What about reading custom data

Sanket: Let's say yes for the sake of argument

Wenson: That has a bunch of risk associated with it.

Sanket: OK. How about restricted to native types? Would that be acceptable?

Megan: My suggestion was for a time-based permission. Would we be OK doing this for a period of time. I'm not necessarily advocating for this, just exploring whether there would be an appetite for this. If not, we don't need to discuss further.

Wenson: Lots of privacy concerns. Hard to make end-users understand the implications.

Wenson: It's worth exploring, but we need to be cautious. We would try to expose the most restricted set of information as possible.

Wenson: We're not talking about exposing any info. Just that the clipboard has changed

Wenson: That seems fairly safe.

Olli: Concerns about how useful this is.

Sanket: Maybe we should explore options further for this.

Sanket: Any further questions

Kagami: If we can get the type when we get user activation, would it still require a clipboardchange event? (or the scenario of showing the available menu options)

Sanket: If the clipboard changed after the menu was shown.

Marijn: But the clipboard change would have been initiated by a user action.

Johannes: You could show this menu after the paste, right?

Sanket: Yes

Rohan: Can we look at it from the perspective of a native app?
What protections do we have there? Can we duplicate that? Have a similar model for websites?

Johannes: And with that, we're done with clipboard.

Johannes: No need to discuss the remaining issues because they are dependent on resolving the above discussion.