Spinning out from bug 394483 comment 1: Generally, we need to make sure that the behavior for URIs handled by web-based protocols in various HTML attributes is defined, sane, and safe. In particular, we need to find out what happens with <object>, <embed>, <iframe>, and <img> and perhaps other similar situations.

The high-level question we need to answer is "should we allow web-based protocol handlers in the various block elements?". Con: * There's no URL bar associated with these elements, so the user doesn't necessarily understand where the content is coming from and whom they should or shouldn't be trusting in order to login to those apps. Pro: * People are already susceptible to exactly this sort of confusion with flash, java, etc. Making web-based protocol handlers less capable will just cause implementors to use those technologies instead. Con: * We avoid expanding the attack surface larger than it already is. Thoughts?

Con: * It would make the behavior of <iframe src="xxx:..."> differ depending on whether you use a local application or a web-based handler. For both the "hidden iframe to launch your irc client" case and the "visible iframe to let you compose an email message" case, this would be bad.

See also bug 400886.

Er, I meant bug 402736.

What is left to do here?

Rob: decide on what policy we want, possibly in concert with what we decide in bug 402736; write tests of that policy, and fix anything that fails those tests.

With a few exceptions, I'm mostly focused on MailCo-related hacking now. Reassigning a bunch of bugs to default component owners. I'm happy to help with brainstorming/advice as needed, however. Search for the string MAILMONKEY to delete any bugmail generated by this change.

(In reply to comment #1) > The high-level question we need to answer is "should we allow web-based > protocol handlers in the various block elements?". Do we currently allow this?

> Do we currently allow this? We allow it for <frame> and <iframe>. Probably not for <object>; not sure about <embed>.

As far as I know, there is currently no high-level knowledge by any of the container code about the fact that there are different kinds of protocol handlers (web-based and local). So any place where an external protocol handler is allowed, it will attempt to use whatever it finds. This may fail in some cases for web-based handlers where it would succeed for local handlers.

Oh, we just do these via the external protocol handler? What do these do as an img src, exactly?

Mostly, it comes through the ext handler. There a few instances that go through the service though (iirc, these include typing a link into the URL bar, and the mailto: link that is generated by "Send Link To" commands). I'm not sure what <img src> does; finding that and other such things was specifically why I filed this bug.

Ping - whats the status on this?

This is a set of testcases to exercise what happens when protocol handlers are invoked from different contexts. 0: <a href="mailto:blah> 1: <object> 2: <embed> 3: <iframe> 4: <img> 5: <script> 6: <link rel="stylesheet"> 7: XHR

I ran the attached testcases with 3 different actions configured for the mailto protocol... "Always Ask Me", Thunderbird (w/o prompting), Yahoo (w/o prompting). In the last case, I also ran with Wireshark to ensure I saw if any network activity was triggered. For tests 1,2,4,5,6,7: nothing happens, the loads are ignored. (No prompt is show, Thunderbird is not invoked, Yahoo is not loaded). Test 3 (<iframe>) works, correctly as bz noted in comment 9... "Always Ask Me" prompts, Thunderbird opens, or Yahoo loads. The only interesting bit is that Yahoo seems to detect that it was loaded in an iframe, and causes the the top-level window to change location to www.yahoo.com. [This seems to be the standard thing some sites to do prevent people from usage through some other site's frames.] Test 0 (<a href="mail:...">) also works as expected. So, I think this bug is resolved. I don't think any of the tests where the handler is *not* invoked should be made to work (questionable usage, avoids any lurking security issues with doing to). I'd probably prefer that the <iframe> case not actually work, out of paranoia, but I can't think of why it would be a problem. A site could just load <iframe src="http://yahoo.com/inbox"> explicitly to the same effect.