- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 6 Apr 2012 22:36:40 +0000 (UTC)
On Fri, 6 Apr 2012, Tyler Close wrote: > > > > Well if it's an iframe, the parent can't be anything but the original > > origin, as far as I can tell. > > What happens if the handler sends the postMessage to "*", then the > parent is navigated? Will the postMessage be delivered or not? A task queued on a Document is associated with that Document and can only be processed when that document is active. > > But in general, there's not expected to be any talking back. If you > > want something where the handler talks back to the page that provided > > the data, then you should use Web Intents. registerProtocolHandler() > > and registerContentHandler() are intended for things like mail clients > > (mailto:) or PDF viewers, which do not talk back. Indeed in the common > > use case, you just click the link and the entire browsing context gets > > replaced, so there's nothing to talk back _to_. > > I was prompted to write the original email by a Mozilla blog post that > suggested talking back. > > It also seems bad for web APIs to break under simple composition like > this; especially when there's an easy fix available. I think it's unsurprising that a feature would not be suitable for a task for which it was not designed. Turns out <canvas> is really bad at cross- document communication too. ;-) In the case of <iframe>, there's no problem since you can't post anything to a parent that isn't the parent that spawned you. In the case of window.open, it's true that the opener could have navigated by the time you try to communicate back. That's a general problem with window.open(), though; it's not specific to register*Handler(). The solution is to not use window.open(), which is in any case bad UI. > > For such an example, you can just use a fallback section in the > > appcache manifest. (Or a fragment identifier, indeed.) > > Right, the obvious thing to do is use the fragment identifier, but > that's got some security problems. With a small tweak we can make this > safe and easy. I don't understand the security problem. Could you give a concrete example of an attack scenario? > > Why would a mail client talk back to its opener? > > It might not, but some RPH handlers will. Why? What's the use case? > > I don't understand the attack scenario. Sure, a Web page can open > > another Web page with arbitrary arguments. Why does it matter here? > > Two reasons: > 1. An RPH dispatch is different from a direct load because it > communicates a user choice to the RPH handler. I explained above how a > handler might use this information. I don't see how this difference affects the security here. > 2. An RPH dispatch comes from the browser, so URL parameters can be > trusted; whereas they cannot be trusted in a load from another web page. I don't see how they can be viewed as "trusted". > With a small change, we can prevent a client page from faking an RPH > dispatch to a handler page. It's just a page load, not a "fake RPH dispatch". I don't understand the problem here. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 6 April 2012 15:36:40 UTC