Sketch out a CORP-only mode. #893
Conversation
As discussed in whatwg/html#4175 (comment).
There was a problem hiding this comment.
My main worry here is still that depending on how things shake out long term this could effectively be CORS, without it being clear and without the additional credentials opt-in we require there. (I.e., this is as simple to configure as Access-Control-Allow-Origin: * while potentially having greater risk.)
| <var>request</var>'s <a for=request>tainted origin flag</a> is not checked. | ||
| <li><p><var>request</var> is a <a>navigation request</a> whose <a for=request>reserved client</a> | ||
| is an <a for=/>environment</a> whose <a for=environment>target browsing context</a> is neither a | ||
| <a>nested browsing context</a> nor an <a>auxiliary browsing context</a>. |
There was a problem hiding this comment.
This should explain why the auxiliary navigating the non-auxiliary is not a problem.
There was a problem hiding this comment.
Well, hrm. I guess that actually is a problem without process isolation. attacker.site could open attacker.site in a new window, the latter could navigate the former to victim.site, and sadness would ensue. Perhaps this should instead ask whether we're navigating within a unit of related browsing contexts? Or whatever the new hotness is? "User agent cluster"?
There was a problem hiding this comment.
Without process isolation on the agent cluster level, right.
I think the navigation checks only make sense when the flag is set on a document. And that flag only makes sense if COOP is also set. (COOP guaranteeing process isolation on the browsing context group level.)
There was a problem hiding this comment.
fetch.bs
Outdated
|
|
||
| <li> | ||
| <p>If the following are true | ||
| <p>If <var>policy</var> is null, and <a>request</a>'s <a for=request>client</a>'s |
There was a problem hiding this comment.
Is this what we want? I kinda feel like an erroneous policy should fail closed when this TBD boolean is set.
There was a problem hiding this comment.
I want to be able to support new values for this header in the future (for example, a list of origins a la #760). I'm happy to tighten this up, but I'd like to figure out how to do so in a forward-compatible way.
There was a problem hiding this comment.
I guess the question then is what the migration strategy has to be. In equivalent cases we've failed for potentially new syntax and new servers will have to update (e.g., all the recentish and proposed CORS changes).
A straw-proposal to flesh out the discussion in whatwg/html#4175 (comment).