- From: <bugzilla@jessica.w3.org>
- Date: Thu, 20 Mar 2014 21:53:28 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24998 --- Comment #12 from Arun <arun@mozilla.com> --- (In reply to Anne from comment #11) > The implementation is going to look at that string and wanting to know the > origin of it... How else is it going to do origin-comparison? The same way it does origin comparisons based on the incumbent settings object? That is, the same way scripts are origin-restricted. > > > Yes, my proposal is to do like data URLs, but that does mean blob URLs work > across origins (which I think might be desirable, but others might disagree). This thread isn't resolved properly, and I can't change the origin policy till that happens: Start here: http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0442.html Specifically, I want to understand: "This is because we have been bit several times by having code from security context A (in our case code from chrome://) receive a URL from code from security context B. A would then load that URL. This way B can trick A into creating content that B controls, but that runs with As privileges. I'd love it if the web also had such an opt-in flag, but I don't know how possible that is to create." Which is found: http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0682.html A conservative way to thwart this is to make the URL from B not loadable in A. This isn't about the guessability of the URL either. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Thursday, 20 March 2014 21:53:30 UTC