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

Hello authors of the [pickling clipboard api extension design](https://github.com/w3c/editing/tree/gh-pages/docs/clipboard-pickling),

The document was called to my attention thanks to a comment about the clipboard APIs which definitely suffer from a very strict set of sanitized formats and sanitization procedure (and that some security aware people would even call not engouh, e.g. for html inclusions where, for example, a picture that was not shown starts to be shown when pasted inside the mail composition window). I very much appreciate the possibility of opening the boundaries of clipboard exchanges and would love to help make it a reality for mathematical content at least.

One clarification that would be useful is the amount of user consent that would be needed. Each consent is one more rejection chance for a newbie user. Only then would the security considerations be complete, I think.
I seem to understand that some consents are going to be "I, the geometry app Xyz, want to accept any mathematical expression (application/mathml) offered from site a.b.c". Is this a correct interpretation? The problematic of representing the type to an end-user seems open.

Are we running into a dangerous archive of consents that users would forget about? Maybe expiring them would be useful.

The problem of counting the formats' names is a bit strange to me. 100 sounds too small for extreme cases... I would prefer several hundreds.

In the pickling format, I am not sure I understood how binary formats will be stored... but I guess it's ok for a design.

Finally, would the set of (web and desktop) apps that have been visited by a user not be something useful for the user itself? E.g. so as to explore the possibilities? I guess that this is just speculation...

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

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

Received on Friday, 18 February 2022 16:14:50 UTC