Le 03/08/2013 03:03, Boris Zbarsky a écrit :
On 8/2/13 6:44 PM, David Bruant wrote:
And apparently @sandbox doesn't help here if there is allow-same-origin.
So here is an idea: make the document.domain setter throw inside an
iframe@sandbox, *regardless* of allow-same-origin. That solves the
mail.google.com VS calendar.google.com case.
How exactly does it solve it? How is @sandbox even relevant here?
(feeling this might be again an instance of me misunderstanding the
spec. sigh. sorry about that if that's the case)
I mistakenly wrote "VS" giving the impression that this is a security
oriented thread, but that's not what I meant. Sorry for the mislead.
I was following up on the iframe process isolation idea.
document.domain requires opt-on on both sides
Indeed and that's the reason what I describe works I believe.
Let's say we have pages from 2 domains "a.example.org" and
"b.example.org". One has an iframe to the other. iframe process
isolation is not possible, because at any point, both could set their
domains to "example.org" (or process isolation is possible, but the
deoptimization would have a violent cost)
"a.example.org" can sandbox the iframe to "b.example.org" and process
isolation becomes possible again, because the parent and iframe are
guaranteed to be of a different origin. However, this looses the origin
of the iframe which breaks localstorage, etc. This can be solved with
allow-same-origin, but process isolation is lost back because we're
pretty much back in the previous case.
What I'm suggesting is the following: poison the document.domain setter
in sandboxed iframes regardless of whether there is allow-same-origin.
This way, in the "a.example.org"/"b.example.org" case, the iframe can be
process isolated (because guaranteed to be of a different origin).
This also applies to "example.org" with a "b.example.org" iframe.
The only case this doesn't allow to optimize is "a.example.org" with an
iframe to "example.org", where "a.example.org" might set document.domain
to "example.org".
David
