On Wed, 9 Jul 2014, Jonas Sicking wrote:
>
> But javascript: is sort of screwed no matter what. A javascript URL
> inheritely will run javascript, and it always does so in the origin of
> whoever set the url. So pages will have to look for javascript: anytime
> they are handling URLs.
>
> But
On Thu, Jul 3, 2014 at 10:00 AM, Anne van Kesteren wrote:
> On Tue, Jun 3, 2014 at 12:21 AM, Jonas Sicking wrote:
>> srcdoc is like eval(). Yes, it's definitely a tool that enables you to
>> run 3rd party code in your own context and with your own principal.
>> However whenever you use the featur
On Tue, Jun 3, 2014 at 12:21 AM, Jonas Sicking wrote:
> srcdoc is like eval(). Yes, it's definitely a tool that enables you to
> run 3rd party code in your own context and with your own principal.
> However whenever you use the feature you (should) know that it's
> running code in your own context
On Mon, Jun 2, 2014 at 6:03 AM, Boris Zbarsky wrote:
> On 6/2/14, 9:00 AM, Anne van Kesteren wrote:
>>
>> You're not persuaded by the attack scenario?
>
> Correct. I mean, the same scenario applies to srcdoc, document.write() into
> an iframe, etc. Why are data urls special?
srcdoc is like eval
On Mon, 2 Jun 2014, Anne van Kesteren wrote:
>
> At the moment data URLs inherit the origin of the context that fetches
> them.
To be precise, the origin of data: URLs themselves is the unique origin.
It's the origin of resources that come from data: URLs that's different.
--
Ian Hickson
On 6/2/14, 10:15 AM, Anne van Kesteren wrote:
The attack is the URL. A developer has to specifically consider data
URLs and realize their implications.
Note that this is already true for javascript: URLs in @src values (but
not in location sets and the like, I agree).
-Boris
On Mon, Jun 2, 2014 at 3:03 PM, Boris Zbarsky wrote:
> On 6/2/14, 9:00 AM, Anne van Kesteren wrote:
>> You're not persuaded by the attack scenario?
>
> Correct. I mean, the same scenario applies to srcdoc, document.write() into
> an iframe, etc. Why are data urls special?
The attack is the URL.
On 6/2/14, 9:00 AM, Anne van Kesteren wrote:
You're not persuaded by the attack scenario?
Correct. I mean, the same scenario applies to srcdoc, document.write()
into an iframe, etc. Why are data urls special?
Provided we agree that it is always unset after any redirect, yes.
We agree on
On Mon, Jun 2, 2014 at 2:48 PM, Boris Zbarsky wrote:
> On 6/2/14, 5:19 AM, Anne van Kesteren wrote:
>> This is not the case in Chrome and we'd like this to be no
>> longer the case in Gecko.
>
> Note that it's not clear to me what "we" means in this case. For example,
> I'm unconvinced we want to
On 6/2/14, 5:19 AM, Anne van Kesteren wrote:
This is not the case in Chrome and we'd like this to be no
longer the case in Gecko.
Note that it's not clear to me what "we" means in this case. For
example, I'm unconvinced we want to change Gecko behavior here.
And then it would only be set f
On Mon, Jun 2, 2014 at 11:19 AM, Anne van Kesteren wrote:
> Workers might be harder as there might be content relying on workers
> working with data URLs. That needs to be investigated.
Per http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3046
(thanks Simon) workers throw in Chrome wh
At the moment data URLs inherit the origin of the context that fetches
them. This is not the case in Chrome and we'd like this to be no
longer the case in Gecko.
https://bugzilla.mozilla.org/show_bug.cgi?id=1018872 is tracking this.
The reasoning is that data URLs require being careful with a URL
12 matches
Mail list logo
