Re: [w3ctag/design-reviews] "credentialless" embedder policy. (#582)

> Briefly, Private Network Access and https://github.com/annevk/orb seem needed and we need an explicit opt-in for nested navgiations one way or another (either the rather attractive "reverse-XFO" or something else).

I agree that some ORB variant is necessary. We ship CORB in Chromium, which seems Good Enough to start with. I know there's interest in hardening CORB into something ORB-like if we can get away with it (@anforowicz was looking into it, I believe).

I also agree that embedded contexts should opt-into the embedding. I think there's a good conversation to be had around the ways in which opt-in could work in the credentialless case, and I don't think we need to block that on the broader attempt to invert XFO (which y'all, dear TAG, closed out happily(?) in #578); we could certainly require specific embedding permission in these cases. Alternatively, we do the same thing we do for `COEP: require-corp` by requiring these resources to CORP themselves, and assert a COEP compatible with the top-level. That's possibly safer, at possibly higher deployment cost.

Private Network Access is, IMO, simply a question of ordering. It seems like a reasonable approach to the problem, but not one that we're going to be able to ship tomorrow (and certainly not cross-vendor). I think it might be reasonable for credentiallessness to enable cross-origin isolation even in its absence, and for us to use that remaining hole as additional pressure to justify backwards incompatibilities. Note also that COI just makes side-channel attacks faster. I think we need to ship private network access generally, COI or not.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/582#issuecomment-768140139