Re: [w3c/clipboard-apis] Make async clipboard APIs (read/write) to sanitize interoperably with setData/getData for text/html (#150)

> But your primary point is that we need some special way of initializing the fragment parser...

I'm glad you brought that up.  Actually, the discussion on the fragment parser is a bit of a tangent and a means to an end.  The primary point is captured in Anupam's first sentence in [this comment](https://github.com/w3c/clipboard-apis/issues/150#issuecomment-909405090):

> We want to standardize the clipboard sanitization procedure...

I do think it's possible to standardize what authors should expect to be sanitized away from the data that they supply to navigator.clipboard.write for our well-known mime-types.  So the key point in Anupam's post is really this:

> ...we want to use the Sanitizer API to strip out harmful contents...

I believe his initial thinking is to sanitize clipboard using the [Sanitizer's default configuration](https://wicg.github.io/sanitizer-api/#default-configuration), which leaves things like `style` and `meta` tags but removes harmful `script` tags and `javascript:` URLs etc. (more detail available in the [Sanitizer spec](https://wicg.github.io/sanitizer-api)).

@whsieh covered today in the [Web Editing WG meeting](https://www.w3.org/2021/09/10-editing-minutes.html) that Safari prefers to also remove content that would be invisible like comments, display:none, opacity: 0, etc.  So maybe we could define a configuration and/or upgrades to the sanitization algorithm that does that too if we decide that's important aspect to keep.

Any objection to standardizing what a "sanitized copy" means to remove ambiguity from the [clipboard API's write algorithm](https://w3c.github.io/clipboard-apis/#dom-clipboard-write)?

-- 
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/clipboard-apis/issues/150#issuecomment-917261849