Conversation

This Tweet was deleted by the Tweet author. Learn more

I was a bit wrong here. this was only for write-acces.

Quote Tweet

twitter.com/freddyb/status A permission is still required to read the clipboard. There are multiple APIs for accessing the clipboard. One of those APIs required a user interaction with the page such as clicking on anything, scrolling, etc. for each read or write. The other did not.

Show this thread

Replying to

Nothing really changed because there's another API without the requirement of arbitrary user interaction with the page. The other API is forbidden by the standard from requiring user interaction since the intended privacy model is using permissions for API-based read and write.

Replying to

and

Since they removed the user interaction requirement from one of the APIs, it can be used to read (with the permission granted) or write without the user clicking on something, scrolling, etc. The other API allowed it already. Not a real restriction without both APIs doing it.

Replying to

and

I think part of what's needed is a one-time permission grant system, similar to what Android shipped in Android 11 and also displaying a notice when clipboard is read when the permission is granted, similar to iOS where that was introduced and also Android 12.

4:40 AM · Aug 31, 2022Twitter Web App

Replying to

and

Should also be a default-enabled site setting for clipboard write access so it's possible to disable globally by default and enable it on a case-by-case basis for sites. Requiring arbitrary page interaction would only help if they did both APIs, and current standard forbids it.

Replying to

and

From my perspective, implementing a restriction intended to improve privacy only for one variant of an API is very problematic and is actually a privacy flaw since people who don't know about the other API would think that it's a privacy restriction that's not actually there.