Re: [w3c/editing] Security Review (#315)

> I propose instead that the specification should say that implementations MUST pickle any clipboard contents that they don't already sanitize. (And then you can remove the unsanitized field from the ClipboardItem constructor.)

Building on this, requiring sites to provide the unsanitized list allows sites to support both a unsanitized (for reading by the site) and sanitized (for reading by other sites/native apps) version of the same payload, in case a site requires information removed by sanitization. Therefore, writing unsanitized data by default (rather than via the unsanitized list) would also make addition of sanitized payloads by browser implementations be web-incompatible, as previously unsanitized content would become sanitized, potentially wiping metadata a site relies on.

> Existing OS And Application Expectations

This API is not compatible with existing native apps / software, so this should partially bypass the issue. That said, @snianu  please clarify in the explainer potential danger of unsanitized, web-originated content, and recommended defense (ex. Fuzzing), to protect from native apps simply adding pickling support and associated malicious content from the web without reconsidering their security model. It seems we could use additional discussion around potential dangers/defense in general (though explainers are intended to be brief, so I'm not sure if this may be better suited to a design document instead... either way)

-- 
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/issues/315#issuecomment-880180250