https://www.w3.org/Bugs/Public/show_bug.cgi?id=27196
Bug ID: 27196
Summary: Blob URL origin
Product: WebAppsWG
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P2
On Jun 30, 2014, at 7:13 PM, Glenn Maynard gl...@zewt.org wrote:
Why would the identifier not just be the blob URL itself?
Done.
Also, both Chrome and Firefox treat the entire URL as case-sensitive, eg.
Blob:... won't revoke the URL, or uppercasing the hostname portion in
Chrome.
On Tue, Jul 1, 2014 at 5:18 PM, Arun Ranganathan a...@mozilla.com wrote:
While I think mediastream URLs may have died on the vine, using the same
store for filesystem URLs would be good.
Yeah maybe. I thought those worked differently in that they're not
really tied to objects, but rather actual
On Tue, Jul 1, 2014 at 1:13 AM, Glenn Maynard gl...@zewt.org wrote:
Why would the identifier not just be the blob URL itself? The spec
currently makes the identifier just the scheme data, which seems much more
complex than it needs to be. revokeObjectURL should simply be Remove the
entry
On Jun 30, 2014, at 7:13 PM, Glenn Maynard gl...@zewt.org wrote:
Why would the identifier not just be the blob URL itself? The spec currently
makes the identifier just the scheme data, which seems much more complex than
it needs to be. revokeObjectURL should simply be Remove the entry from
On Jul 1, 2014, at 2:32 AM, Anne van Kesteren ann...@annevk.nl wrote:
That works for me. That way we can make this a more generic store if
god forbid we get more of these schemes.
While I think mediastream URLs may have died on the vine, using the same store
for filesystem URLs would be
On Jun 28, 2014, at 4:42 AM, Anne van Kesteren ann...@annevk.nl wrote:
I now defined the origin for blob URLs:
http://url.spec.whatwg.org/#concept-url-origin Sorry for the delay.
Still need to work out the correct Fetch integration.
Thanks :)
Removed origin extraction from FIle API, but
On Mon, Jun 30, 2014 at 8:45 PM, Arun Ranganathan a...@mozilla.com wrote:
Removed origin extraction from FIle API, but added identifier extraction
(based on the same model — that is, running the basic URL parser). This makes
adding entires to the Blob URL Store clearer.
I don't really
On Jun 30, 2014, at 4:20 PM, Anne van Kesteren ann...@annevk.nl wrote:
I don't really understand this. Entries should be added when a blob
URL is created.
They are! That is, at the time the method URL.createObjectURL(blob) is called
on blob, that method adds an entry to the Blob URL Store:
On Mon, Jun 30, 2014 at 10:48 PM, Arun Ranganathan a...@mozilla.com wrote:
They are! That is, at the time the method URL.createObjectURL(blob) is
called on blob, that method adds an entry to the Blob URL Store:
http://dev.w3.org/2006/webapi/FileAPI/#add-an-entry
I’ve only defined identifier
On Jun 30, 2014, at 4:57 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Mon, Jun 30, 2014 at 10:48 PM, Arun Ranganathan a...@mozilla.com wrote:
They are! That is, at the time the method URL.createObjectURL(blob) is
called on blob, that method adds an entry to the Blob URL Store:
On Mon, Jun 30, 2014 at 3:57 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Mon, Jun 30, 2014 at 10:48 PM, Arun Ranganathan a...@mozilla.com
wrote:
They are! That is, at the time the method URL.createObjectURL(blob) is
called on blob, that method adds an entry to the Blob URL Store:
I now defined the origin for blob URLs:
http://url.spec.whatwg.org/#concept-url-origin Sorry for the delay.
Still need to work out the correct Fetch integration.
--
http://annevankesteren.nl/
On Jun 10, 2014, at 2:57 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Tue, Jun 10, 2014 at 12:16 AM, Arun Ranganathan a...@mozilla.com wrote:
Right now, the Blob URL Store is defined in terms of units of similar-origin
browsing contexts; each unit is required to have a Blob URL Store. As
On Tue, Jun 10, 2014 at 12:16 AM, Arun Ranganathan a...@mozilla.com wrote:
Right now, the Blob URL Store is defined in terms of units of similar-origin
browsing contexts; each unit is required to have a Blob URL Store. As you
point out, that allows all origins within document.domain access to
On Thu, May 29, 2014 at 11:42 AM, Anne van Kesteren ann...@annevk.nl wrote:
However, I wonder if this at a standards level should come into play
in the URL parser. After all that creates a structured clone of the
blob in question. The lookup for the blob ID should probably fail at
that point
On Jun 9, 2014, at 3:23 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, May 29, 2014 at 11:42 AM, Anne van Kesteren ann...@annevk.nl wrote:
However, I wonder if this at a standards level should come into play
in the URL parser. After all that creates a structured clone of the
blob in
The 2 June 2014 Editor’s Draft of the File API solves some bugs and technical
issues with Blob URLs. Review is encouraged, with a view towards a LCWD
publication:
http://dev.w3.org/2006/webapi/FileAPI/
In particular:
1. It nails down syntax differences between user agents on Blob URLs.
2. It
On Fri, May 30, 2014 at 2:07 AM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, May 29, 2014 at 9:21 AM, Anne van Kesteren ann...@annevk.nl wrote:
Given that workers execute script in a fairly contained way, it might be
okay?
Worker scripts aren't going to be very contained as we add more
On Thu, May 22, 2014 at 1:29 AM, Anne van Kesteren ann...@annevk.nl wrote:
For blob URLs (and prolly filesystem and indexeddb) we put the origin
in the URL and define a way to extract it again so new
URL(blob).origin does the right thing.
Yup.
For fetching blob URLs (and prolly filesystem
On Thu, May 22, 2014 at 1:29 AM, Anne van Kesteren ann...@annevk.nl wrote:
How do we deal with data URLs? Obviously you can always get a resource
out of them. But when should the response of fetching one be tainted
and when should it not be? And there's a somewhat similar question for
about
On Thu, May 29, 2014 at 9:06 AM, Jonas Sicking jo...@sicking.cc wrote:
My proposal is something like this:
Thanks!
* Add a new flag to the fetch algorithm allow inheriting origin
same-origin data URL flag? Ideally we don't do another data URL mistake.
* The default for this new flag is
On Thu, May 29, 2014 at 9:21 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, May 29, 2014 at 9:06 AM, Jonas Sicking jo...@sicking.cc wrote:
* The default for this new flag is false
* If the flag is set to false, the origin of the URL is a unique identifier.
* When the origin is a unique
On May 22, 2014, at 4:29 AM, Anne van Kesteren ann...@annevk.nl wrote:
Thanks, I'm convinced.
So now I'd like to know what policy we want so we can carefully define it.
The lastest editor’s draft of the File API specifies what we discussed in this
email thread as syntax for Blob URLs:
On Thu, May 22, 2014 at 1:45 AM, Jonas Sicking jo...@sicking.cc wrote:
The fact that we allow passing blobs around is no different from the
fact that we allow passing an ArrayBuffer or a string around. Once a
page knows that it has the blob/arraybuffer/string the only way to
have it XSS you is
On Tue, May 20, 2014 at 9:24 PM, Jonas Sicking jo...@sicking.cc wrote:
I think you are confusing issues. Or at least talking about two
separate issues at once in a way that I'm not sure what you are
talking about. The issue of is there an XSS issue with treated blob:
like we treat data: is a
Hmm. One factor that might change my mind on this: If I pass a blob URL,
revoking the URL appropriately becomes hard. Even if it gets implemented,
auto-revoke can't help with this. That brings back all of the problems
with non-auto-revoking blob URLs, and adds a new layer of complexity, since
I
On Wed, May 21, 2014 at 3:59 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Tue, May 20, 2014 at 9:24 PM, Jonas Sicking jo...@sicking.cc wrote:
I think you are confusing issues. Or at least talking about two
separate issues at once in a way that I'm not sure what you are
talking about. The
On Mon, May 19, 2014 at 9:57 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, May 19, 2014 at 2:00 AM, Anne van Kesteren ann...@annevk.nl wrote:
Again fair, but do we consider that something we want to fix or do we
want to enshrine this?
Given that there's no way to set CORS headers on these
On Tue, May 20, 2014 at 1:28 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Mon, May 19, 2014 at 9:57 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, May 19, 2014 at 2:00 AM, Anne van Kesteren ann...@annevk.nl wrote:
Again fair, but do we consider that something we want to fix or do we
On Tue, May 20, 2014 at 2:24 PM, Jonas Sicking jo...@sicking.cc wrote:
Yes, we could demand that that implementations generate unguessable
UUIDs. And then define that a page from http://a.com can use img
src=blob:http://b.com/uuid;, but if it then used that element to
drawImage into a canvas,
On Sun, May 18, 2014 at 6:38 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Sat, May 17, 2014 at 12:22 AM, Jonas Sicking jo...@sicking.cc wrote:
And I agree with them. The fact that iframes end up same-origin
makes it easier to XSS a website by tricking it to load a URL of the
attackers
On Mon, May 19, 2014 at 2:33 AM, Frederik Braun fbr...@mozilla.com wrote:
On 15.05.2014 22:46, Glenn Maynard wrote:
On Thu, May 15, 2014 at 12:07 PM, Jonas Sicking jo...@sicking.cc
mailto:jo...@sicking.cc wrote:
On Thu, May 15, 2014 at 6:52 AM, Anne van Kesteren ann...@annevk.nl
It was pointed out to me that I should have read the rest of the thread ...
*looks sheepish*
- Kyle
On Mon, May 19, 2014 at 9:51 AM, Kyle Huey m...@kylehuey.com wrote:
On Mon, May 19, 2014 at 2:33 AM, Frederik Braun fbr...@mozilla.com wrote:
On 15.05.2014 22:46, Glenn Maynard wrote:
On Thu,
On May 19, 2014, at 5:33 AM, Frederik Braun fbr...@mozilla.com wrote:
On 15.05.2014 22:46, Glenn Maynard wrote:
On Thu, May 15, 2014 at 12:07 PM, Jonas Sicking jo...@sicking.cc
mailto:jo...@sicking.cc wrote:
On Thu, May 15, 2014 at 6:52 AM, Anne van Kesteren ann...@annevk.nl
On Mon, May 19, 2014 at 2:00 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Mon, May 19, 2014 at 10:30 AM, Jonas Sicking jo...@sicking.cc wrote:
In at least Chrome and Firefox, blob: acts like filesystem: and can't
be loaded cross-origin. Even in cases when we normally permit loading
of
On Mon, May 19, 2014 at 3:30 AM, Jonas Sicking jo...@sicking.cc wrote:
In at least Chrome and Firefox, blob: acts like filesystem: and can't
be loaded cross-origin. Even in cases when we normally permit loading
of cross-origin resources like in img and script.
This has been to prevent
On Sat, May 17, 2014 at 12:22 AM, Jonas Sicking jo...@sicking.cc wrote:
And I agree with them. The fact that iframes end up same-origin
makes it easier to XSS a website by tricking it to load a URL of the
attackers choice in an iframe. Or open a worker using a URL of the
attackers choice.
I
On Thu, May 15, 2014 at 8:17 PM, Jonas Sicking jo...@sicking.cc wrote:
I did. It's not very attractive to use the model of something that so
far we haven't been able to make work consistently across UAs, and
which isn't looking like we will be able to get consistently working
across UAs for a
On 5/16/14, 10:11 AM, Anne van Kesteren wrote:
What exactly is wrong with the data URL model that we have today
The fact that some UAs don't want to implement it?
and how do we plan on fixing it?
We don't have a plan yet.
But I guess this is a scenario you explicitly want to outlaw,
even
On Fri, May 16, 2014 at 4:31 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 5/16/14, 10:11 AM, Anne van Kesteren wrote:
What exactly is wrong with the data URL model that we have today
The fact that some UAs don't want to implement it?
Do we know why?
But I guess this is a scenario you
On 5/16/14, 10:39 AM, Anne van Kesteren wrote:
The fact that some UAs don't want to implement it?
Do we know why?
They think it's a security problem.
-Boris
On Fri, May 16, 2014 at 5:04 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 5/16/14, 10:39 AM, Anne van Kesteren wrote:
The fact that some UAs don't want to implement it?
Do we know why?
They think it's a security problem.
Not tainting canvas? Same-origin iframe? Doesn't matter?
--
On Fri, May 16, 2014 at 9:11 AM, Anne van Kesteren ann...@annevk.nl wrote:
I think the sad thing is that if you couple origins with blob URLs you
can no longer hand a blob URL to an iframe-based widget and let them
play with it. E.g. draw, modify, and hand a URL back for the modified
image.
On 5/16/14, 11:08 AM, Anne van Kesteren wrote:
Not tainting canvas? Same-origin iframe? Doesn't matter?
The same-origin iframe bit. I think everyone is on board with not
tainting canvas for data: things.
-Boris
On Thu, May 15, 2014 at 6:52 AM, Anne van Kesteren ann...@annevk.nl wrote:
I was thinking about the latter and that would not work if the URL was
revoked. Unless we store origin at parse time.
Good point. Without using the explicit syntax we couldn't return a
consistent result for the origin.
On Thu, May 15, 2014 at 12:07 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, May 15, 2014 at 6:52 AM, Anne van Kesteren ann...@annevk.nl
wrote:
I was thinking about the latter and that would not work if the URL was
revoked. Unless we store origin at parse time.
Good point. Without
On 12.05.2014 18:41, Jonas Sicking wrote:
(new URL(url)).origin should work, no?
It does not work for blob URIs in Firefox.
On 5/13/14, 1:20 AM, Frederik Braun wrote:
On 12.05.2014 18:41, Jonas Sicking wrote:
(new URL(url)).origin should work, no?
It does not work for blob URIs in Firefox.
It can't work, given how URL.origin is currently defined... It's
possible that definition should change, though.
-Boris
On Mon, May 12, 2014 at 6:51 PM, Jonas Sicking jo...@sicking.cc wrote:
I agree with this. But Adam's assessment of how long that will take to get
specced and implemented was in the order of year, not month. I share that
assessment.
I am also not at all convinced that I'd want blob: to behave
On Tue, May 13, 2014 at 10:33 AM, Boris Zbarsky bzbar...@mit.edu wrote:
It can't work, given how URL.origin is currently defined... It's possible
that definition should change, though.
We don't want new URL() to take ownership of the Blob object, so
making new URL() reflect the origin of
On Tue, May 13, 2014 at 6:00 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Tue, May 13, 2014 at 10:33 AM, Boris Zbarsky bzbar...@mit.edu wrote:
It can't work, given how URL.origin is currently defined... It's possible
that definition should change, though.
We don't want new URL() to take
On May 12, 2014, at 8:28 AM, Anne Van Kesteren ann...@annevk.nl wrote:
It still seems a bit sad though to tie these URLs to origins in this
fashion. Jonas is correct that there are inconsistencies in how data
URLs and origins behave across browsers, but it seems like we should
sort those out
On Tue, May 13, 2014 at 11:19 AM, Arun Ranganathan a...@mozilla.com wrote:
And really, all user agents seem to agree that the origin is that of the
settings object today. That model seems to work. The remaining question is
the pro and con of denoting this in the URL's syntax. abarth's advice is
On 09.05.2014 23:29, Arun Ranganathan wrote:
..
So this is problematic: we don’t have a common syntax on the web, and
even implementations which share code don’t do it exactly the same. Of
course, blob: URLs aren’t supposed to be human readable, or really
viewed by the developer. But not
On 5/12/14, 5:28 AM, Anne van Kesteren wrote:
so blob:https://origin:42/uuid would be fine.
I'd really rather we didn't make web pages parse these strings to get
the origin. A static method on Blob that takes a valid blob: URI and
returns its origin seems like it should be pretty easy for
On Mon, May 12, 2014 at 4:31 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 5/12/14, 5:28 AM, Anne van Kesteren wrote:
so blob:https://origin:42/uuid would be fine.
I'd really rather we didn't make web pages parse these strings to get the
origin. A static method on Blob that takes a valid
On 5/12/14, 7:46 AM, Anne van Kesteren wrote:
I thought the idea was to associate the origin of
URL.createObjectURL() with the Blob object (which might be different
from the Blob object's origin).
Er, right, these URLs come from URL.createObjectURL. So we'd want a
URL.getObjectURLOrigin() or
On May 12, 2014, at 10:31 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 5/12/14, 5:28 AM, Anne van Kesteren wrote:
so blob:https://origin:42/uuid would be fine.
I'd really rather we didn't make web pages parse these strings to get the
origin. A static method on Blob that takes a valid
On May 12, 2014, at 6:26 AM, Julian Reschke julian.resc...@gmx.de wrote:
Could you please clarify what spec you are referring to, and in which way
it's not implemented correctly?
Well, I think http://tools.ietf.org/html/rfc6454#section-4 is is supposed to be
normative for data: URL origin.
On May 12, 2014 7:33 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 5/12/14, 5:28 AM, Anne van Kesteren wrote:
so blob:https://origin:42/uuid would be fine.
I'd really rather we didn't make web pages parse these strings to get the
origin. A static method on Blob that takes a valid blob: URI
On May 12, 2014 8:57 AM, Arun Ranganathan a...@mozilla.com wrote:
On May 12, 2014, at 10:31 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 5/12/14, 5:28 AM, Anne van Kesteren wrote:
so blob:https://origin:42/uuid would be fine.
I'd really rather we didn't make web pages parse these strings
On Mon, May 12, 2014 at 11:41 AM, Jonas Sicking jo...@sicking.cc wrote:
I'd really rather we didn't make web pages parse these strings to get the
origin. A static method on Blob that takes a valid blob: URI and returns
its origin seems like it should be pretty easy for UAs to implement,
63 matches
Mail list logo
