clarifications for the pickling design proposal

Hello authors of the pickling clipboard api extension design,

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...

Start by reading the pickling design proposal in docs/clipboard-pickling, then review the questions about user consent, consent expiration, format-count limits, binary storage, and app discovery. Done means the proposal's open points have clear, agreed answers or corresponding clarifications in the design document.