Re: [whatwg] [Web-storage] subdomains / cooperation and limits
On Sep 17, 2012 8:22 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 17 Sep 2012, Brian Kardell wrote: Ian, you hit the nail on the head with the text section that raised the issue but I still am not entirely sure that I understand... Doesn't this imply that in a case like *.wordpress.com would have a (suggested) limit of 5mb combined for all of its tons and tons of subdomains (at least without additional/constant prompting)? It wouldn't be constant prompting, but yes, the spec does suggest that if you visit a dozen WordPress-hosted blogs and they all try to load a bunch of content onto your machine, you should probably have to give consent or at least be aware of what's going on. I think I may be starting to fill in my mental gap here, thanks for your patience. I think you are saying that each subdomain does get a seperate area, but the spec encourages prompt or at least informative communication to the user to prevent at least obvious misuse and runaway scenarios. Specifically what degree to which they do that are left up to implementations...is that correct? There are a whole lot of what I would call common examples like where it seems (to me anyway) unintuitive given the regularity with which this kind of case would happen to think that that is what is actually proposed. What's the alternative? Allowing any site to overload your machine with infinite amounts of content isn't really a viable solution. Blindly, sure, that could be a problem. If a user can grant permission for more to a particular domain explicitly, that is mostly mitigated I think. If I understand, that is the idea with the subdomains limitations. I will have to do some more searching to find the conversations I might have missed as I expect this was all discussed a while back and in following so many lists I am just missing a few key points. I can understand blocking access to that data pretty easily, but with postMessage, being in the same top-level domain doesn't even matter so it seems that one could just as easily subvert the limit that way. The difference is that getting a new domain costs money, whereas getting a subdomain does not. So the cost of attacking someone with subdomains is much lower than with domains. I think it isn't really implemented that way anywhere though, is it? That is, do browsers really share the limit across subdomains like that... If they do not, they are likely vulnerable to this kind of griefing. It would be great if some ms, moz, opera and webkit variant folks could chime in with any helpful implementaion details so we could understand the emerging rationales about how this is being managed effectively, it might even flesh out additional notes that could be added to the doc. In the very least it would be in the archives for future searches. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [Web-storage] subdomains / cooperation and limits
On Tue, 18 Sep 2012, Brian Kardell wrote: I think you are saying that each subdomain does get a seperate area, but the spec encourages prompt or at least informative communication to the user to prevent at least obvious misuse and runaway scenarios. Specifically what degree to which they do that are left up to implementations...is that correct? Yeah, all of this is basically left up to UAs (notice how everything in the Disk Space section says should, not must). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Navigation and history traversal issues
On Tue, 12 Jun 2012, James Graham wrote:
In particular, what stops such navigations from re-triggering the unload
handler, and thus starting yet another navigation?
I've updated the spec to have guards in place for 'pagehide' and 'unload'.
(Not yet 'beforeunload'. Should we do that too?)
It looks like the spec tries to make a distinction between navigations
that are cross-origin and those that are not (step 4 in the navigating
across documents algorithm); I'm not sure why this inconsistency is
desirable rather than using the cross-origin approach always.
Based on some tests ([1]-[5]), it seems that WebKit seems to cancel the
navigation in the unload handler always, Opera seems to always carry out
the navigation in the unload handler, and Gecko seems to follow WebKit
in the cross-origin case and Opera in the same-origin case. In all cases
the unload handler is only called once.
[1] http://hoppipolla.co.uk/tests/navigation/003.html
[2] http://hoppipolla.co.uk/tests/navigation/004.html
[3] http://hoppipolla.co.uk/tests/navigation/005.html
[4] http://hoppipolla.co.uk/tests/navigation/006.html
[5] http://hoppipolla.co.uk/tests/navigation/007.html
On Tue, 12 Jun 2012, Boris Zbarsky wrote:
For what it's worth, we initially tried to do what you say WebKit does
but ran into web compat issues. See
https://bugzilla.mozilla.org/show_bug.cgi?id=371360 for the original bug
where we blocked all navigation during unload and
https://bugzilla.mozilla.org/show_bug.cgi?id=409888 for the bug where we
changed to the current behavior. I believe the spec says what it says
based on our implementation experience here...
Yeah, the spec's behaviour is intentional here. The error in the spec was
just that it still fired unload again. I've fixed that.
On Wed, 13 Jun 2012, James Graham wrote:
That seems to be true. On the other hand it appears that gecko will
still respect navigation from unload even if the unload was triggered by
explicit user interaction (e.g. by editing the address bar), as long as
all the origins match, so you can end up at a different page to the one
you expected. That is very surprising behaviour (although I see that you
can argue that it is possible in other ways).
When it's same origin, you really have no way to know what's going on. The
page could trivially pushState() a continuously changing URL, for example,
and could serve random files from the server for any URL.
On Thu, 14 Jun 2012, James Graham wrote:
On 06/13/2012 11:18 PM, Ian Hickson wrote:
On Fri, 20 Apr 2012, Henri Sivonen wrote:
* Should window.stop() really not abort the parser like the spec
seems to suggest?
Looks like Opera is alone with the non-aborting behavior. The spec
is wrong.
Can you elaborate on this? How can you tell?
I presume the TC is something like
!doctype html
Before stop
script
window.stop()
/script
After stop
Only Opera displays after stop here. We are planning to change this
behaviour, so that window.stop is much more like the abort the
document (I haven't yet closely studied how this interacts with the
readystate and other things that Henri has been looking at).
The spec now clearly requires the parser-stopping behaviour.
See also this bug where I'm tracking an issue with the word cancel:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16801
On Fri, 15 Jun 2012, James Graham wrote:
FWIW I think the conceptually simplest solution here is for aborting the
document to go through The End, so that defer scripts are run,
DOMContentLoaded and load events fire, and the readyState changes in the
normal way. This isn't quite like the behaviour of Gecko or WebKit
today, but is spec-wise easy to understand, and hopefully no one is
relying too much on specific behaviour of window.stop().
Aborting a document happens for many reasons other than stop(). For
example, document.open(), navigation, the user hitting STOP, going
back() in history, etc. In particular, The End can block on network, so
we definitely don't want to require that UAs do that when you close a tab,
for example.
On Wed, 15 Aug 2012, Glenn Maynard wrote:
Should this alert on initial load?
!doctype htmlbody onpopstate=alert('xxx')
[1] says After creating the Document object, but before any script
execution, certainly before the parser stops, the user agent must update
the session history with the new page. That invokes [2] update the
session history with the new page, which invokes [3] Traverse the
history to the new entry, which fires popstate in step 14.
However, After creating the Document object, but before any script
execution seems like it could happen before or after the body element
has been parsed, so the alert may or may not happen.
Yeah, this is an oversight as specced. Fixed.
On Sun, 16 Sep 2012, Justin Lebar wrote:
Suppose an attack page evil.html controls a separate frame F (e.g.
Re: [whatwg] Navigation and history traversal issues
This is all great; thanks for the quick turnaround!
I've also made back()/forward()/go() not work during the document's unload
handler, since that could be used for griefing. I'm tempted to disable it
entirely for all docs a la alert(), but I've no idea if that's Web-
compatible and I suspect not.
I don't know what you mean by the last sentence here. In my tests, IE
and Opera do not support cross-origin back/forward/go, if that's what
you mean. I don't see any good reason for us to support that in
Firefox, either, if we could get away with removing it.
-Justin
On Tue, Sep 18, 2012 at 8:18 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 12 Jun 2012, James Graham wrote:
In particular, what stops such navigations from re-triggering the unload
handler, and thus starting yet another navigation?
I've updated the spec to have guards in place for 'pagehide' and 'unload'.
(Not yet 'beforeunload'. Should we do that too?)
It looks like the spec tries to make a distinction between navigations
that are cross-origin and those that are not (step 4 in the navigating
across documents algorithm); I'm not sure why this inconsistency is
desirable rather than using the cross-origin approach always.
Based on some tests ([1]-[5]), it seems that WebKit seems to cancel the
navigation in the unload handler always, Opera seems to always carry out
the navigation in the unload handler, and Gecko seems to follow WebKit
in the cross-origin case and Opera in the same-origin case. In all cases
the unload handler is only called once.
[1] http://hoppipolla.co.uk/tests/navigation/003.html
[2] http://hoppipolla.co.uk/tests/navigation/004.html
[3] http://hoppipolla.co.uk/tests/navigation/005.html
[4] http://hoppipolla.co.uk/tests/navigation/006.html
[5] http://hoppipolla.co.uk/tests/navigation/007.html
On Tue, 12 Jun 2012, Boris Zbarsky wrote:
For what it's worth, we initially tried to do what you say WebKit does
but ran into web compat issues. See
https://bugzilla.mozilla.org/show_bug.cgi?id=371360 for the original bug
where we blocked all navigation during unload and
https://bugzilla.mozilla.org/show_bug.cgi?id=409888 for the bug where we
changed to the current behavior. I believe the spec says what it says
based on our implementation experience here...
Yeah, the spec's behaviour is intentional here. The error in the spec was
just that it still fired unload again. I've fixed that.
On Wed, 13 Jun 2012, James Graham wrote:
That seems to be true. On the other hand it appears that gecko will
still respect navigation from unload even if the unload was triggered by
explicit user interaction (e.g. by editing the address bar), as long as
all the origins match, so you can end up at a different page to the one
you expected. That is very surprising behaviour (although I see that you
can argue that it is possible in other ways).
When it's same origin, you really have no way to know what's going on. The
page could trivially pushState() a continuously changing URL, for example,
and could serve random files from the server for any URL.
On Thu, 14 Jun 2012, James Graham wrote:
On 06/13/2012 11:18 PM, Ian Hickson wrote:
On Fri, 20 Apr 2012, Henri Sivonen wrote:
* Should window.stop() really not abort the parser like the spec
seems to suggest?
Looks like Opera is alone with the non-aborting behavior. The spec
is wrong.
Can you elaborate on this? How can you tell?
I presume the TC is something like
!doctype html
Before stop
script
window.stop()
/script
After stop
Only Opera displays after stop here. We are planning to change this
behaviour, so that window.stop is much more like the abort the
document (I haven't yet closely studied how this interacts with the
readystate and other things that Henri has been looking at).
The spec now clearly requires the parser-stopping behaviour.
See also this bug where I'm tracking an issue with the word cancel:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16801
On Fri, 15 Jun 2012, James Graham wrote:
FWIW I think the conceptually simplest solution here is for aborting the
document to go through The End, so that defer scripts are run,
DOMContentLoaded and load events fire, and the readyState changes in the
normal way. This isn't quite like the behaviour of Gecko or WebKit
today, but is spec-wise easy to understand, and hopefully no one is
relying too much on specific behaviour of window.stop().
Aborting a document happens for many reasons other than stop(). For
example, document.open(), navigation, the user hitting STOP, going
back() in history, etc. In particular, The End can block on network, so
we definitely don't want to require that UAs do that when you close a tab,
for example.
On Wed, 15 Aug 2012, Glenn Maynard wrote:
Should this alert on initial load?
!doctype htmlbody onpopstate=alert('xxx')
[1] says After creating the Document object, but before any script
execution,
Re: [whatwg] Navigation and history traversal issues
On Tue, 18 Sep 2012, Justin Lebar wrote: This is all great; thanks for the quick turnaround! I've also made back()/forward()/go() not work during the document's unload handler, since that could be used for griefing. I'm tempted to disable it entirely for all docs a la alert(), but I've no idea if that's Web- compatible and I suspect not. I don't know what you mean by the last sentence here. In my tests, IE and Opera do not support cross-origin back/forward/go, if that's what you mean. I don't see any good reason for us to support that in Firefox, either, if we could get away with removing it. I meant blocking all scripted back/forward session history traversal while any page is running the unload algorithms. As far as cross-origin back/forward, there are 404 pages on the Web that have javascript:history.back() links; these would break for cross-origin links if we blocked cross-origin history traversal. I don't really see much point. What's the security risk? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Navigation and history traversal issues
I've also made back()/forward()/go() not work during the document's unload handler, since that could be used for griefing. I'm tempted to disable it entirely for all docs a la alert(), but I've no idea if that's Web- compatible and I suspect not. I don't know what you mean by the last sentence here. In my tests, IE and Opera do not support cross-origin back/forward/go, if that's what you mean. I don't see any good reason for us to support that in Firefox, either, if we could get away with removing it. I meant blocking all scripted back/forward session history traversal while any page is running the unload algorithms. Ah, I see. I don't have any idea if that's a good idea or not, so, okay. :) As far as cross-origin back/forward, there are 404 pages on the Web that have javascript:history.back() links; these would break for cross-origin links if we blocked cross-origin history traversal. I don't really see much point. What's the security risk? The issue isn't a history.back() which crosses origins -- that seems fine -- but rather calling history.back() on a cross-origin window. (Sorry that wasn't clear.) It's not clear that this poses a security risk (otherwise, I'm sure we'd have removed it by now), aside from making it easier to tickle Firefox into buggy states like this bug [1]. But it's also not clear to me what benefit there is to being able to call back() on an arbitrary window. I guess I can navigate a window, so I might as well be able to make it go back? But those aren't quite the same thing. -Justin [1] https://bugzilla.mozilla.org/show_bug.cgi?id=737307
Re: [whatwg] Navigation and history traversal issues
On Tue, 18 Sep 2012, Justin Lebar wrote: The issue isn't a history.back() which crosses origins -- that seems fine -- but rather calling history.back() on a cross-origin window. (Sorry that wasn't clear.) Aah, ok. The spec already says that's not allowed. You can't get to the History object of a cross-origin Window: http://www.whatwg.org/specs/web-apps/current-work/#security-window (I forget what the story is if you get a History object from a same-origin Window, then have the browsing context navigated, then use the History object you kept around... I expect it is supposed to work much as if you were to call it on the new, cross-origin, History object, though.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
