Blocking annotations by origin feels like CSP

[jeremyroman]

Is there a reason this aspect of the problem shouldn't be solved with Content Security Policy, which already provides great ways of limiting the origins which can be used to fetch subresources (which it feels like these functionally are)?

[bokand]

I remember looking into it at some point and leaning against it but I can't find where that was and don't really remember the reasoning. I think it was because CSP seems really specifically related to security and fetch which this wouldn't block either.

In this case, when a site says "block" annotations - really we'd still fetch them and present the user but with more friction (e.g. maybe the user sees a badge in the omnibox that they have to tap to see the annotations).

I may also be wrong about this but IIUC CSP is only allowlist - I think it may be useful to be able to say things like "allow all annotation sources but block these known bad actors" (but maybe not?)

[JamesNJep]

I think having some controls for Annotations in a CSP or Feature-Policy would be good to have at some point.
But I think in practice CSP and Feature-Policy work best when set in the page header, and these are ofter set side wide and not adjusted for individual pages. In my experience, these are normally something built in by the software developer or set by the maintainer of the web server, but the person that is going to be in the best position to make decisions on allow or dis-allow list will be the person that is editing the content.

I think you may also want to make the allow or dis-allow options more granular in the future. So maybe you allow annotations for "spellcheckers.example.com" on your article because your happy for the feedback, but not on your users comments section of the page. And that might be easier to do with tags in the page/content.