- From: Darwin Huang <notifications@github.com>
- Date: Tue, 20 Jul 2021 17:44:02 -0700
- To: w3c/editing <editing@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/editing/pull/316/review/711170436@github.com>
@dway123 commented on this pull request. > @@ -115,11 +115,33 @@ Sites can read or write pickled versions of sanitized formats, by providing the ### OS-Interaction: Format Naming Native applications will only be able to interact with these formats if they explicitly add support for these pickled formats. Different platforms / OS’s often have different conventions for a clipboard format’s name, so formats will be named accordingly per OS. Payloads will be unaffected/unmodified between different OS’s. -On MacOS (and iOS), clipboard formats are named using the UTI reverse-DNS naming convention. Therefore, a MIME type `"custom/format"` will be transformed to `"com.web.custom.format"`. Note that the pickling prefix `"com.web"` precedes the transformed format name `"custom.format"`, and the slash is converted to a period. +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, so nobody will 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 we are proposing a new approach for custom format namings and payload serialization/deserialization format which will be safer from a security prespective and also deterministic as to how many custom formats are guranteed to be available in the clipboard inserted via pickling APIs. Generation of clipboard formats dynamically risks exhaustion of the atom pool. On a more macro level, we're describing the issue of dynamically generating formats in this paragraph, so I'd start with that for easier skimming and comprehensibility -- 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/editing/pull/316#discussion_r673582741
Received on Wednesday, 21 July 2021 00:44:14 UTC