Dan: reprises discussion from breakout C

Amy: there is info in the explainer about privacy levels and also user activation...

Jeffrey: the fact that several applications like excel and google docs - want to show "you have this data to paste" - they can probably do that without access to the data. It's important that remote desktops be implementable on the web... but they can probably do this and also meet privacy goals... Also google and apple have been active on the spec...

Hadley: that's good news

Sarven: is there any doucmentation on the same category of things being a threat? As far as I know, clipboard is managed in the RAM. You can always come with a use case... Should there be any room for having any access in the RAM?

Martin: I agree with Dan. Lots of things go across my clipboard, and if arbitrary webistes could access that, it's terrible. there are constraints around the use of hte clipboard: it has to be foregrounded, etc. But I think there is a difficult question about what it means to be an agent, to be your computer. A random website acting as your computer is difficult for me, that it might be ok for this website to do that and not others. And remote desktop apps need that capability. When we were talking about access to ubikeys and local passkeys, the remote computer is now wanting to access local computer things to act as your computer and I'm not comfortalbe with that. Just saying "that's ok, this is an important use case" hides the difficulty here. Sarven's point about accessing RAM is putting a sharp point on it. I think no website should have that capability.

Dan: It feels like that capability, like ubikeys and access to local drives etc, would/could be appropriate if you've installed and given permission to a complete client environment. But it may be that it shouldn't be something the web should do. Maybe it's too powerful for the web.

When it comes to pasting, and access to the clipboard, I still don't see... it doesn't degrade the experience that much to have to wait for the user to press paste before the contents of the clipboard are pasted into the other environment. It's not like you're denying access, just making sure the user really intends to transfer that thing to the other side. Otherwise it could be passwords, urls, any kind of ino in your clipboard.

jeffrey: The thing the user does to tell a site they want to paste may not be ctrl+v, it may be a button. We could use a user gesture, but we can't be sure the user did it all... Also, there are persistent differences between UAs on this question. Chrome and chromium browsers are not going to stop chasing remote desktop as a use case, and firefox and safari and not going to pursue the use case in the same way. So the design question: how to make an api that doesn't create a bad user experience across browsers? I think the clipboard API has been designed successfully. The read event ... If we arrange it so the same code works in all places and degrades gracefully, we will have succeeded. Might be able to say "do this only in IWAs". I don't think chromium will accept "just don't do it"

Torgo: Thinking through the UX, the user might still have access to a paste menu option. It may be that the remote desktop environment has to lead the user through a permission request experience in order to get them to request that permission.

Jeffrey: that permission is what some browsers don't think is a good idea.

torgo: This is why I installed hte clear clipboard thing on MacOS to clear my clipboard regularly. I don't want the text in my clipboard to be siphoned off for other use cases. I don't agree that the current API has been designed well. We are lowering the bar re keeping users safe on the web.

Jeffrey: They present 2 use cases in their explainer. Pressing paste in a remote app doesn't always work, which I think is a bug in the system and not a web issue. 2: they want to know the types of data in the clipboard. I think that's much safer to expose than the data.

I suspect mozilla and safari will be happy with that. probably still worth gating behind a permission, but doesn't seem dangerous like the content seems dangerous.

Tess: interesting weird custom types could be fingerprinting info. But if it's limited to ... distinct from arbirary media points -- not as bad.

Not obvious to the user that granting permission to occasionally paste means this web app will learn that I have photoshop installed on this computer. Or whatever domain specific software I have installed.

Torgo: probably less directly harmful, but there might be some harms just knowing the types.

Tess: domain specific application with a proprietary format

Matthew: For background info, the file-type fingerprinting issue came up earlier in the year with respect to Delayed Clipboard Rendering

Martin: You can send messages across domains, since it's easy to put content on the clipboard. It's another channel that shouldn't exist.

Torgo: I don't know if we'll resolve this here

Martin: "Chromium wants it, therefore we need to accept that, no matter the moral value" -- I'm tired of this.

Torgo: I don't know that I agree with that wording, but in some cases we have pushed back hard on APIs that have been presented to us for design review such as the managed device API... we said we can't stop anyone from writing something in their own software, but this shouldn't be part of the web platform.

"XYZ company, you have business requirements to do a particular thing, but that doesn't mean we have to put it in the web platform. You can deal with it iwith your own business partners." It was intended for IT people to manage and monitor what the users in their enterprise were doing, and it's not something we need to do on the web.

the tension between not reviewing things that we think are not a good idea and trying to push back on things to make a difference where we can - harm reduction

...Let's defer this to next year. No consensus now.

Jeffrey: I can draft a comment for the private-discussion thread.

Dan: we had a discussion a while ago about clipboard access and whether tehre should be any requirement to use the paste command in order for the web app to gain access to the contents of the clipboard. I still feel that is the case. A web app should never have access to the clipboard unless I explicitly tell it I want to paste something from my clipboard. It seemed like.. this issue still has not been resolved.. there are people who feel there are circumstances even without a permission grant that a web app should be able to access clipboard contents. I guess because some applications can access it without user interaction. Which is also frightening.

Amy: what's the use case? why is immediate clipboard sync useful?

Matthew: it can be a convenience...

Tristan: I use cross-device copy-paste all the time...

Amy: I'm skimming the user stories and they don't feel like user stories. Also worried about information leak.

Dan: I don't expect that the remote client automatically syncs the contents of my clipboard. What I expect is that I copy something from Mac and go to the Windows environment, press paste, and and then at that point content is pasted. There's an action required. I'm concerned with anything that's polling or event based. I can understand if you've gone through the situation of having installed a remote desktop client but in the web context I'm extremely worried about it because it can provide access to information that you wouldn't expect. It's an attack vector.

Matthew: I see those concerns. You can do the magic cross device copy paste, just make it a pull rather than a push, on a user action. Also concern about things that involve events or polling - implication I'm seeing you can already do it with polling.

Dan: that's exactly where my mind has gone

Amy: It does say "It provides an efficient alternative to polling the clipboard for changes."

Dan: let's discuss async and then decide what to do at the plenary.

Matthew: we discussed last year and Jeffrey made a comment - the concern we had was that we don't need as much as info as they say they do to do the things they want to do... Jeffrey's proposed comment puts that across... As a separate issue it shouldn't be possible to do this by polling and that's a bug.

we ask Jeffrey to leave his comment

Dan: let's discuss at the plenary.

Matthew: we're saying "privacy beats convenience for remote desktop users" and they say the other way around. They want it to be a seamless experience. We want the user to have control over their clipboard.

Dan: And I still feel that we need to look outside of the remote desktop case.. There is no argument that in that case, the seamless experience is greatly aided by their approach. However, the issue is with other developers who might seek to take advantage of this ... "bad actors" - but there is also a grey area... Everyone thinks their application is the only application people are using and everyone thinks their application is the most important application.

Matthew: I like Dan's approach - let's look at the general abuse cases, and how they could be mitigated. This will allow us to make some progress. We're not against remote access apps, but we are for preventing abuse cases. I think this will help us reach some common ground on where the risks are.

Xiaocheng: who's responsibility is it to raise abuse scenarios?

Dan: we have prompted scenarios ...

Matthew: they don't have an explicit privacy & security section in their explainer, but they do talk about privacy & security in each sub-proposal section, and aligning with existing clipboard API. Our concern is partly with the existing clipboard API too. We have some abuse scenarios from recent minutes here. Has W3C done any thread modelling on this?

Hadley: something about remote desktop as a use cases .. crosses out of the browser and out of the web... not just looking at the browser but looking at what is going on in another OS, which crosses out of the privacy/security boundaries of the web... We keep having this problem when we look at remote desktop use cases. I don't see a way around it.

<blockquote> First a bit of context: The TAG feels the whole clipboard API platform is more permissive regarding permission than it should be. And we have fed back and will feed back on this in more detail in due course. Also to be clear, we understand that your position is that this is required for the remote desktop scenario in order to allow for seamless clipboard access. The concern we have is about abuse of this API in *other* scenarios. Remember that web users will also be using other web applications, visiting other web sites, and will be subject to the same risks and attacks as any other web users.

For example: user receives a text message from a scammer purporting to be their bank; user clicks on the URL in the text message; now they are interacting with a web page that looks like their bank but it's really a scam web site; the web site uses this API to scrape any info off the user's clipboard.

...

</blockquote>

we agree to come back to this after Matthew looks through our minutes for other abuse cases we've talked about

<blockquote> First a bit of context: The TAG feels the whole clipboard API is more permissive regarding permission than it should be. Also to be clear, we understand that your position is that this is required for the remote desktop scenario in order to allow for seamless clipboard access. The concern we have is about abuse of this API in *other* scenarios. Remember that web users will also be using other web applications, visiting other web sites, and will be subject to the same risks and attacks as any other web users.

For example: user receives a text message from a scammer purporting to be from a trustworthy site; user clicks on the URL in the text message; now they are interacting with a web page that looks benign but it's really a scam web site; The web site convinces the user to paste something into the page; the web site shows the permission prompt, which of course the user accepts, and thereafter it's able to scrape any info off the user's clipboard any time it gets focus.

We also think the remote desktop use cases would work fine if it only works on paste, and without the clipboardchange event, websites don't know when a copy happens and so are incentivized to only read the clipboard on paste. With clipboardchange, they get a new incentive to be incompatible with Firefox and Safari, which isn't good for the Web. Before endorsing clipboardchange, we'd like to see an explanation for why that won't happen.

</blockquote>

Jeffrey: not convinced by the abuse case... They are going to update their explainer to describe why clipboard change is useful even if you don't assume chrome's UI model for clipboard... And I think the TAG is fine with the Firefox & Safari UI model.

discussion of an explicit permission grant

Jeffrey: in Firefox the browser pops up somehting and in Chrome there is an explicit permission grant.

Dan: leaves comment

Matthew: [summarises the discussion thus far] We are awaiting feedback, but they haven't yet. At the plenary, we can ask Jeffrey if he knows anything procedurally.

Xiaocheng: if the current API is to permissive, what is our appraoch to further restrict it?

Matthew: we're still working it out. If it's an existing API which we don't expect is going away, we can file a bug on it. In this case, the intention is for this new stuff to replace the old, so we are concentrating on making the new stuff safe for users. Once that's been implemented, we would advocate for removing the old and unsafe stuff. But we haven't had a concensus fro mthe TAG on this.

Xiaocheng Hu: I see. So, another decade's work.

Hadley: Yes

Matthew: let's check this again at the plenary.

Jeffrey: still waiting on an expainer update... But that shouldn't block the TAG from leaving a comment...

we agree ball is in their court

Jeffrey: Dan Clark and I are too close to the contributors. DanA has concerns.

Yves: It'd be good to know how the browsers ???

Jeffrey: {explains background on the issue / explainer} This matches what iOS does. Gets a toast sayin the webapp is being sketchy but with ??? you don't get it. Firefox / Safari are okay with this design. Am excited about this because it'd enough to get remote desktop apps. Because it opens the use case for Firefox/Safari.. we could push Chromium to not read the clipboard all the time.

Sarven: Piecing together from a couple meetings. I thought the concern was that there's a permission being given to the app, that once they have it, there's no way the user can know when to revoke that permission. So the app/site has continuous access to the clipboard. Also, the original issue was giving read access to RAM. What precautions are being taken? Or reasoning? There's a lot the user is asked about accessing hardware; can understand the argument that this falls into that category, and the UX can be designed so the user is aware, and you have the right to revoke it. Is just making that a possibility, good in itself? Laptops have an indicator that the camera is on, via a light. Clipboard: is there such an indicator? Understand the concerns that are raised. What steps are taken to ensure that it's safe and/or even if the user is tricked into granting permission, they have ways of backtracking.

Jeffrey: This particular API doesn't fix any of those problems. Chromium permission model for clipboard allows persistent access. I think there are ways for Chromium to indicate those but they haven't implemented the mitigations. So that bad state is still ther.e The reason I'm still excited about this is that it give a route to fixing that. Doesn't make it better or worse. Firefox/Safari have shipped nearly the same API without a problem, without a permission. This allows the use cases for Chromium where they have permission quality ... We should scope our review to this API and what it enables. Chromium has the status quo but this at least gives a process to improving that situation.

Matthew: For context, we've discussed this before and realised that the status quo isn't acceptable but this is narrow in scope. Why do we need to know the types on the clipboard on copy as opposed to paste.

Jeffrey: 1) there is a lot of spreadsheed apps, they give you the kind of things you can paste (value, formula, format etc.) And in order to what to enable you have to know what's on the clipboard. Need to know that when the user enables, before pasting.

Matthew: Native apps similar?

Jeffrey: This is why iOS allows type-x without warning.

Matthew: re Sarven's permissions, you said iOS popup with toast before permission, if you give permission, how long is the permission?

Jeffrey: Safari, or at least iOS doesn't. So what they did was to pop up a toast. The UI they have for the async API, thwn then wesite asks to read the clipboard, one item with paste item in it. If you trigger it with keyboard, it'd be under the mouse - bad accessibility / UI problems - kind of works.

Matthew: This clearly is an improvement over the status quo but some TAG's understanding is that the status quo is already really bad. Ack improving things for the future. What can we do if we say go for this? e.g., To encourage Chromium's model to change.

Jeffrey: https://github.com/w3ctag/design-principles/pull/563 . Directly relevant. Don't improve API unless mitigating problems. A path toward fixing them. I don't know how we can push Chrome to fix this. The sketch I had in mind is all three browsers ship this API. Remote desktop app that uses this could use all three. Maybe we take a page from iOS to show the toast. Right now it shows if you pasted in current sessions - that can be louder. Don't know for sure which way would have traction.

Dan: UI more aggressive to push those measures if we have this as off ramp.

Matthew: We don't say how their UI should be. I guess once we okay this as TAG, then need to push on it hoping that it changes.

Jeffrey: We can file Chromium bugs for example. Suggest a UI along the lines of x,y,z.

Matthew: We also talked about this is writing to the clipboard. That seems also free for all. Perhaps of the lesser of the two evils.

Jeffrey: We could toast on write. Same paste surfaces do this. They warn you like finger-pasting can do bad stuff for you. Windows-command ought to be doing that. We should be telling people the stuff in the clipboard is not necessarily safe.

Matthew: Good example of annoying but not malicious and user doesn't know until pasting.

Jeffrey: They immitate recaptcha.

Jeffrey: So what's next? Sarven's been most skeptical on the call, so what do you think?

Sarven: You mentioned Dan A has a concern, so from my end, I'd like to catch up. Everything said has been sensible, but I don't understand it well enough.

Dan: I can write a draft proposal. Can write a summary based on today in the private brainstorming.

Matthew: Yes, and, like Sarven want to check out the edges. Mention the direction and also file bugs that needs to be followed up to address the root problem.

Martin: I think the new draft is great. Let's give Torgo one more chance to review, and post tomorrow.

[General agreement]

Matthew: no new comments on the issue... but we talked about this. ..

we move it to proposed close and we have a draft closing comment we will revisit at the plenary and hopefully close