- From: Bjoern Hoehrmann <derhoermi@gmx.net>
- Date: Mon, 17 Mar 2014 15:26:04 +0100
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: Ian Hickson <ian@hixie.ch>, Arun Ranganathan <arun@mozilla.com>, Jonas Sicking <jonas@sicking.cc>, Travis Leithead <travis.leithead@microsoft.com>, public-webapps <public-webapps@w3.org>
* Anne van Kesteren wrote: >On Fri, Mar 14, 2014 at 10:40 PM, Ian Hickson <ian@hixie.ch> wrote: >> On Fri, 14 Mar 2014, Arun Ranganathan wrote: >>> http://dev.w3.org/2006/webapi/FileAPI/#originOfBlobURL >> >> LGTM. Assuming that UAs implement this, that makes Workers automatically >> support blob: URLs, too. > >I don't think this is the way we should go about this. I don't >understand why a blob URL would have an origin. Simply fetching a blob >URL will work and the response won't be tainted and therefore it >should work. Trying to couple origins with strings seems like a bad >idea. The way RFC 6454 defines the concept, an origin is a string derived from a resource identifier and one would expect 'blob' identifiers to have a "globally unique identifier" as their origin, so having one is fine. But it seems as proposed here, it would not be possible to derive the origin based only on the 'blob' identifier, you rather need specific knowledge about individual identifiers so that `blob:A` and `blob:B` end up as two same-origin blobs. I think that is incompatible with the concept as it's defined in RFC 6454, but then again, given the other problems with that, https://mailarchive.ietf.org/arch/msg/websec/ln55YxWM-uRNdxRLu9-7YH9mN2k the idea that "URLs" have "origins" may be the actual problem and we may have to make some bigger conceptual changes to explain the rules. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Received on Monday, 17 March 2014 14:26:48 UTC