On Sat, Mar 30, 2013 at 1:42 AM, Jonas Sicking wrote:
> The reason that data: is relevant there is that blob: is proposed to behave
> the same as data:.
So the way a CORS fetch works in HTML is that it special cases data
URLs and about:blank to be in the same category as same-origin URLs.
XMLHttp
On Mar 29, 2013 4:09 PM, "Glenn Maynard" wrote:
>
> On Fri, Mar 29, 2013 at 10:17 AM, Jonas Sicking wrote:
>>
>> What I'm saying if that different browsers behave differently here.
>>
>> Requiring the crossorigin attribute might be your opinion on how to
solve it, but its not matching how any bro
On Fri, Mar 29, 2013 at 10:17 AM, Jonas Sicking wrote:
> What I'm saying if that different browsers behave differently here.
>
> Requiring the crossorigin attribute might be your opinion on how to solve
> it, but its not matching how any browsers treat data: URLs right now.
>
We're talking about
On Mar 28, 2013 7:36 AM, "Glenn Maynard" wrote:
>
> On Wed, Mar 27, 2013 at 1:35 PM, Jonas Sicking wrote:
>>
>> Same question applies if you create an and then
>> drawImage it into a canvas, does the canvas get tainted? Again, I
>> think different browsers do different things for data: URLs here
On Thu, Mar 28, 2013 at 7:22 PM, Arun Ranganathan wrote:
> The restriction was due to the (perhaps misguided?) safety assumption that
> it was prudent to restrict file references via this scheme to the origin
> invoking URL.createObjectURL. The initial proposal was scoped to origin,
> and dates t
On Mar 28, 2013, at 1:55 AM, Anne van Kesteren wrote:
> On Wed, Mar 27, 2013 at 8:16 PM, Arun Ranganathan wrote:
>> They're very different than data URLs. What's a good use case for making
>> them cross-origin, that isn't addressed by use of postMessage?
>
> Well, the question we started with
On Wed, Mar 27, 2013 at 1:35 PM, Jonas Sicking wrote:
> Same question applies if you create an and then
> drawImage it into a canvas, does the canvas get tainted? Again, I
> think different browsers do different things for data: URLs here.
>
You'd need to say to not taint, since it's still
cro
On Wed, Mar 27, 2013 at 8:16 PM, Arun Ranganathan wrote:
> They're very different than data URLs. What's a good use case for making
> them cross-origin, that isn't addressed by use of postMessage?
Well, the question we started with was why they're restricted to same
origin. That does not appear
On Wed, Mar 27, 2013 at 6:35 PM, Jonas Sicking wrote:
> The question is, what happens if you do:
>
>
> iframe.onload = function() {
> iframe.contentWindow.document; // throws or not?
> }
>
> What if the blob-url was created in another origin, does that make a
> difference?
>
> For data: URIs d
On Tue, Mar 26, 2013 at 5:30 PM, Jonas Sicking wrote:
> However we'd still need to nail down what the new behavior should be.
> Should it behave like data: URLs? The main advantage of those is that
> implementations still don't agree on how those should behave.
I meant to say "The main *problem*
On Mar 26, 2013, at 8:30 PM, Jonas Sicking wrote:
> On Tue, Mar 26, 2013 at 2:17 PM, Anne van Kesteren wrote:
>> Hi,
>>
>> Is there any particular reason why we restrict blob URLs to the same
>> origin as the script that created them? In effect they are pretty much
>> like capability URLs (conta
On Wed, Mar 27, 2013 at 2:41 AM, Anne van Kesteren wrote:
>> However we'd still need to nail down what the new behavior should be.
>> Should it behave like data: URLs? The main advantage of those is that
>> implementations still don't agree on how those should behave.
>
> I'm not sure what that me
On Wed, Mar 27, 2013 at 12:30 AM, Jonas Sicking wrote:
> I think the original concern was that implementations might not be
> able to reliably generate unguessable URLs. Potentially that's
> something that we could require though.
Yeah, think so.
> However we'd still need to nail down what the
On Tue, Mar 26, 2013 at 7:30 PM, Jonas Sicking wrote:
> I think the original concern was that implementations might not be
>
able to reliably generate unguessable URLs. Potentially that's
> something that we could require though.
>
Being able to generate a securely-random token isn't a concern--
On Tue, Mar 26, 2013 at 2:17 PM, Anne van Kesteren wrote:
> Hi,
>
> Is there any particular reason why we restrict blob URLs to the same
> origin as the script that created them? In effect they are pretty much
> like capability URLs (containing an unguessable token). So if someone
> decides to sha
Hi,
Is there any particular reason why we restrict blob URLs to the same
origin as the script that created them? In effect they are pretty much
like capability URLs (containing an unguessable token). So if someone
decides to share one, that should be okay I think. This would be
useful in the conte
16 matches
Mail list logo
