- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 15 May 2014 11:17:32 -0700
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: Arun Ranganathan <arun@mozilla.com>, Web Applications Working Group WG <public-webapps@w3.org>, Adam Barth <w3c@adambarth.com>
On Thu, May 15, 2014 at 7:05 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Tue, May 13, 2014 at 8:19 PM, Arun Ranganathan <arun@mozilla.com> wrote:
>> Also, if it's "sad" because it doesn't match data: URL's way of reckoning
>> origin, that doesn't seem sad to me.
>
> Why not? So far nobody really elaborated on that in this thread.
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 long time to come. Not only does that mean that we'll
keep blob: in the same limbo, it also means that we don't know if
after that limbo we'll get something that is particularly great.
Another argument that I'm not sure if I've raised yet is that so far I
don't see any good solutions for data:. The rfc seems to currently
call for all data: URLs to be given a unique origin. That means that
you can't do new Worker("data:..."), which seems bad. And for blob:
it'd be particularly sad if we couldn't do new Image("blob:") and then
using that image in WebGL or in canvas2d without the canvas getting
tainted.
We could make exceptions to some of these things (in fact, for workers
we might be forced to at this point), but that's also messy.
The best solution that I've been able to think of so far was what I
proposed in another thread of requiring explicit opt-in. However that
requires messy and unusual syntax everywhere where URLs are used and
where we might want to treat data: as same-origin. So also not
something I'd be sad not to have to do for blob:.
/ Jonas
Received on Thursday, 15 May 2014 18:18:29 UTC