W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2014

Re: Blob URL Origin

From: Glenn Maynard <glenn@zewt.org>
Date: Tue, 20 May 2014 17:43:16 -0500
Message-ID: <CABirCh_d4S5sgZYgXzAGwuT++OjD9j8gTgLqbPe0H504A1D6Jw@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Anne van Kesteren <annevk@annevk.nl>, Adam Barth <w3c@adambarth.com>, Joel Weinberger <jww@google.com>, Boris Zbarsky <bzbarsky@mit.edu>, WebApps WG <public-webapps@w3.org>
On Tue, May 20, 2014 at 2:24 PM, Jonas Sicking <jonas@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>, that the canvas would get tainted.
> But there appears to be very little utility of doing this. Rather than
> spending time implementing an unguessable UUID generator, and then
> worrying that someone would still accidentally pass a blob: URL where
> they shouldn't, I'd rather implement a way to generate a blob: URL
> which is explicitly usable cross-origin. But in <img> and in XHR. I.e.
> a Blob URL which responds with CORS headers.

It'd be a lot better for blob URLs to act like other resources: either full
access (same origin or CORS cross-origin) or limited access cross-origin
(usable but taints canvas, can't be read with XHR, etc.) than to block them
entirely cross-origin.

Generating unguessable tokens (including version 4 UUIDs) is so easy to do
that it doesn't make sense to limit the API based on this.

Glenn Maynard
Received on Tuesday, 20 May 2014 22:43:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:24 UTC