- From: Paul Libbrecht <notifications@github.com>
- Date: Fri, 18 Feb 2022 08:14:38 -0800
- To: w3c/editing <editing@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/editing/issues/393@github.com>
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