Should the spec require site isolation?

[jonathanKingston]

As discussed in the privacy review, I'm not clear if the following points should make this spec a candidate for isolation.

• The API has a high bandwidth
• Has a unique memory model
• Has inter process communication and sharing of memory

I've raised this for a discussion as I'm not clear on the risks here.

[dalecurtis]

Is there an explainer or other documentation about when an API should be limited to site isolation? Are you worried about data leakage from other processes? Largely I would expect WebCodecs to communicate exclusively in process or with other already dedicated processes (GPU, codecs) that don't have high value information to leak.

As noted on https://github.com/w3c/webcodecs/issues/234#issuecomment-836924246 some of these concerns are likely the same as we have for existing APIs like MSE, MediaRecorder, and WebRTC. I can't think of any timing you'd get with WebCodecs that you wouldn't get there. I.e., at best you I think you can get round trip time for encoding/decoding of some attacker controlled value -- which is already available with the other APIs.

[chcunningham]

Triage note: tentatively marking 'breaking', as any outcome where additional isolation requirements are imposed would break sites that don't currently meet those requirements.

Purely a triage note. We haven't resolved to take up any change yet. Please continue discussion w/ questions raised by Dale above.

[camillelamy]

On the Chromium security side, we don't see this as requiring crossOriginIsolation. While the high bandwidth of the API could be a concern, it doesn't seem that it could be used in practice to create a reliable high precision timer to exploit a Spectre vulnerability.

[chcunningham]

@jonathanKingston is there more to discuss for this issue? Good to close?

[dalecurtis]

Bump @jonathanKingston , was there anything more here?

[jonathanKingston]

I think we are good here thanks for checking in with the relevant team.