- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 10 Apr 2012 00:24:52 +0000 (UTC)
On Mon, 9 Apr 2012, Tyler Close wrote: > On Mon, Apr 9, 2012 at 4:48 PM, Ian Hickson <ian at hixie.ch> wrote: > > On Mon, 9 Apr 2012, Tyler Close wrote: > >> > >> The RPH handler doesn't need to know which is the legit site. The RPH > >> handler just needs to know that it's getting the RPH data from the > >> site that the user was interacting with, not some other unseen site > >> running in the browser. > > > > Nothing we have discussed so far would provide such a guarantee. > > Yes, what I am proposing provides that guarantee. When an iframe is > initially navigated to a mailto URL, the browser starts its RPH dispatch > logic. In Firefox, this means a Picker dialog is shown and the user > selects an RPH handler. The browser then navigates the iframe to the RPH > handler URL and, under my proposal, would populate a DOM field > containing the mailto URL. Nothing in the spec guarantees that a picker dialog is shown. Indeed, the specification is specifically designed to allow sites to be marked as default handlers, and in typical operation that would likely be the preferred behaviour for users. (Users don't typically want to pick a new PDF viewer or e-mail client every time they click on a PDF or mailto: link.) > Alternatively, the browser could refuse to do repeated RPH navigation of > the same iframe. That would break a use case such as a site with an index of PDFs opening in an irame, if the PDF viewer was a handler rather than a plugin. > >> The vulnerability is that window.location can be overwritten by other > >> code running in the browser. > > > > Then we should fix _that_. > > I was under the impression that the descendant policy on frame > navigation was baked into the Web at this point and could not be > changed. As far as I can tell, at least some browsers prevent anything but the fragment identifier being changed in certain cross-origin cases. I haven't studied this in depth recently, but I strongly suspect that the rules currently in the spec regarding access to Location object members (which block the access you are describing for scripted navigations as well as window.open() and target="" navigations) do not need to be relaxed beyond merely allowing changes to fragment identifiers. As I mentioned, the implications if we do not limit them beyond this are far more dramatic than a site making a handler use a different URL. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 9 April 2012 17:24:52 UTC