Re: [w3c/clipboard-apis] Make async clipboard APIs (read/write) to sanitize interoperably with setData/getData for text/html (#150)

> > Sure. This is a trade off between that and user privacy and we chose to value user's privacy more than those concerns.
> 
> Well, broken functionality is worse than user "privacy".

That's just your opinion.

> Quoting "privacy" because I haven't seen any real-world examples of the privacy risks that you are citing in all your responses. We have discussed this in the Editing WG meetings as well and we are yet to see an example of sites exposing user mailing address. Local file path that you referred to in your earlier response is a temporary folder exposed by Office native apps to support image pasting because converting into base64 encoded image has other issues related to perf, clipboard payload size restriction, delay rendering issue related to resources being available at a later point in time, which I think is orthogonal to this issue.

I've mentioned how to get this time and time again. You can literally launch Microsoft Office products on macOS and copy stuff and see what kind of markup is put into the pasteboard.

I'd emphasize my point once again: **_Different browser vendors have different priorities and as such, we're not interested in standardizing copy & paste sanitization behavior at this point_** since we clearly have differing opinion about what the proper level of protection for user's privacy or how much value should be put into the web & app compatibilities.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/clipboard-apis/issues/150#issuecomment-974236367