On Sat, Mar 30, 2013 at 1:42 AM, Jonas Sicking jo...@sicking.cc 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
On Mar 28, 2013 7:36 AM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Mar 27, 2013 at 1:35 PM, Jonas Sicking jo...@sicking.cc wrote:
Same question applies if you create an img src=blob:... and then
drawImage it into a canvas, does the canvas get tainted? Again, I
think different browsers do
On Fri, Mar 29, 2013 at 10:17 AM, Jonas Sicking jo...@sicking.cc 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
On Mar 29, 2013 4:09 PM, Glenn Maynard gl...@zewt.org wrote:
On Fri, Mar 29, 2013 at 10:17 AM, Jonas Sicking jo...@sicking.cc 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
On Wed, Mar 27, 2013 at 1:35 PM, Jonas Sicking jo...@sicking.cc wrote:
Same question applies if you create an img src=blob:... 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 img
On Mar 28, 2013, at 1:55 AM, Anne van Kesteren wrote:
On Wed, Mar 27, 2013 at 8:16 PM, Arun Ranganathan a...@mozilla.com 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
On Thu, Mar 28, 2013 at 7:22 PM, Arun Ranganathan a...@mozilla.com 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,
On Wed, Mar 27, 2013 at 12:30 AM, Jonas Sicking jo...@sicking.cc 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
On Wed, Mar 27, 2013 at 2:41 AM, Anne van Kesteren ann...@annevk.nl 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
On Mar 26, 2013, at 8:30 PM, Jonas Sicking wrote:
On Tue, Mar 26, 2013 at 2:17 PM, Anne van Kesteren ann...@annevk.nl 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
On Wed, Mar 27, 2013 at 6:35 PM, Jonas Sicking jo...@sicking.cc wrote:
The question is, what happens if you do:
iframe src=blob:... id=iframe
iframe.onload = function() {
iframe.contentWindow.document; // throws or not?
}
What if the blob-url was created in another origin, does that make
On Wed, Mar 27, 2013 at 8:16 PM, Arun Ranganathan a...@mozilla.com 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
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
On Tue, Mar 26, 2013 at 2:17 PM, Anne van Kesteren ann...@annevk.nl 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
On Tue, Mar 26, 2013 at 7:30 PM, Jonas Sicking jo...@sicking.cc 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
15 matches
Mail list logo
