Consider requiring mitigation of script injection attacks.

[mikewest]

In #109, @RByers noted that mandatory encryption could be a path towards mitigating the risk that unexpected/injected code on a site could enable an attacker to extract details of a user's identity.

I'd suggest a) that that risk is real, and b) that you could mitigate it to some extent by requiring the page on which the API executes to have at least minimal defenses against injection attacks by requiring a sufficiently-strong CSP along the lines of https://mikewest.github.io/injection-mitigated/.

[RByers]

This is certainly interesting to me, but the details really matter here. I'm OK imposing some burden on adoption, but it's got to be a bar that many would already find reasonable, understandable and achievable.

Is the [InjectionMitigated] idea being used for any web platform APIs today? Do you have HTTP Archive (or UMA) data indicating what fraction of the web is already meeting the criteria you've outlined?

If you show us a pragmatic bar which many security-sensitive sites already meet, then I'm open to exploring if we could make it a requirement for this API - even if we're the first such API to do so. But precisely defining that pragmatic bar, keeping track of the fraction of the web already meeting it and doing the evangelism for common infrastructure to try to drive up compatibility with the criteria seems like to me to be an independent (and possibly substantial) effort that would need to be a pre-requisite to any API taking a hard dependency, right?

[mikewest]

Is the [InjectionMitigated] idea being used for any web platform APIs today?

Chromium has an implementation of the attribute that we're using for getAllScreensMedia() (see media_devices.idl) to lock in some of the security properties of IWAs (strict CSP + Trusted Types enforcement) while that feature is in an IWAless OT.

Do you have HTTP Archive (or UMA) data indicating what fraction of the web is already meeting the criteria you've outlined?

UMA suggests that ~10% of top-level pages have a strict CSP, and ~4% of top-level pages enforce Trusted Types. I suspect there's strong overlap between the two, given the folks involved.

But precisely defining that pragmatic bar, keeping track of the fraction of the web already meeting it and doing the evangelism for common infrastructure to try to drive up compatibility with the criteria seems like to me to be an independent (and possibly substantial) effort that would need to be a pre-requisite to any API taking a hard dependency, right?

Yes, that's quite fair.

[InjectionMitigated] is not a solidly agreed-upon proposal at the moment. It's an evolution of the "secure context" concept that we've discussed on and off for the last few years that I'm planning to poke people about at TPAC now that there's broad vendor agreement on Trusted Types. I think it matches the security community's general guidance around how developers can effectively mitigate the risk of XSS, so I don't expect a whole lot of pushback on the general concept (though of course there will be robust discussion around where we'd reasonably draw a line between APIs that benefit from such a restriction, and APIs for which it's an unreasonable burden).

[RByers]

Ah that's great, thanks Mike! I didn't realize this had gotten that far along. I can point our potential customers at strict CSP and trusted types and get their feedback on how hard they would be to adopt. I assume those two links are the best resources to get developers started with, but let me know if there's anything better. It seems like it would be a tough sell to completely block an API like this on those at the moment, but maybe? Or maybe we can start with a middle ground like altering Chromium's credential presentation risk engine (and so UI behavior like user warnings) based on the presence of these features?