Re: [w3c/editing] clarifications for the pickling design proposal (Issue #393)

@polx 
> Nope. I am asking if there could not be a UI offered/conceived/discussed at browsers or OSs that say: "Ah, you have a clipboard-pickle of type zzz; you could open it at the website x/a/b and using app zz/zz."

Sorry, I'm still confused. Maybe I'll ask specific questions that I have which might be helpful:
1. Chromium browsers require permission prompts to read/write clipboard formats regardless of whether its custom or well defined. It is only required once per origin, so I don't think we would want to show UIs for each format as that would be intrusive and not a good experience for the user. Also, I'm not sure how having yet another UI for custom formats improves security? If a web author chooses to display a custom dialog during a copy or paste operation, then they are free to do so, but I don't think we would want this experience on our platform.
2. If a destination app doesn't support a format, then how is this new UI going to help the user? We don't know the paste target during copy, so how could a browser generate this custom message?

> I am still not convinced by the 100 limit but it will not be a fight subject.

Having this per origin doesn't address the security issues listed [here](https://github.com/w3c/editing/blob/gh-pages/docs/clipboard-pickling/explainer.md#os-interaction-format-naming).

`On Windows & Linux, generation of clipboard formats dynamically risks exhaustion of the atom pool. On Windows, there is room for around [16,000 registered window messages and clipboard formats](https://devblogs.microsoft.com/oldnewthing/20150319-00/?p=44433). Once those are exhausted, things will start behaving erratically because window classes use the same pool of atoms as clipboard formats. Applications will not be able to register window classes until the user logs off and back on. Linux has a limitation on the atom space as well, so an approach to overcome these limitations needs to be devised.`

This could just be UA specific and doesn't have to be in the spec, but our internal security reviewers want a restriction per user session as this affects the OS and not just the browser or origin.

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

Message ID: <w3c/editing/issues/393/1064370835@github.com>