Re: Blob URL Origin
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 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. You did say this, but this does not explain the actual problem. What exactly is wrong with the data URL model that we have today and how do we plan on fixing it? 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. The origin you get out of a URL is not the origin assigned to a resource, necessarily. At the moment Fetch (and HTML before it) defines that fetching a data URL is the same as fetching a same-origin resource and gives you something back that is not tainted. This is the same for blob URLs, they won't get tainted either. Or about:blank. 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:. 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. But I guess this is a scenario you explicitly want to outlaw, even though you could do the equivalent by passing a Blob object directly and that would always work. -- http://annevankesteren.nl/
Re: Blob URL Origin
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 though you could do the equivalent by passing a Blob object directly and that would always work. Where by directly you mean postMessage, right? -Boris
Re: Blob URL Origin
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 explicitly want to outlaw, even though you could do the equivalent by passing a Blob object directly and that would always work. Where by directly you mean postMessage, right? Yes. -- http://annevankesteren.nl/
Re: Blob URL Origin
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
Re: Blob URL Origin
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? -- http://annevankesteren.nl/
Re: Blob URL Origin
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. But I guess this is a scenario you explicitly want to outlaw, even though you could do the equivalent by passing a Blob object directly and that would always work. As I recall, when I asked why blob URLs were same-origin only, the answer was that it was uncertain whether all platforms had a good enough PRNG to allow generating securely-unguessable tokens for blob URLs in order to make sure sites can't guess blob URLs for other sites. I don't think that's an issue (if you don't have an entropy source to implement a secure PRNG, you don't even have basic crypto). I think that the same-origin restriction for blob URLs should be removed. -- Glenn Maynard
Re: Blob URL Origin
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
[last call feedback] Last Call of Web Crypto API; deadline May 20
On Tue, Mar 25, 2014 at 12:31 PM, Arthur Barstow art.bars...@nokia.com wrote: WebApps was asked to review the Last Call Working Draft of the Web Crypto API: http://www.w3.org/TR/2014/WD-WebCryptoAPI-20140325/ Individual WG members are encouraged to provide individual feedback. I don't really have the crypto chops to do anything more than a superficial review here, so just a couple of pieces of feedback: Should Key be a dictionary rather than an interface? Same question for KeyAlgorithm and anything that derives from it. It looks like these interfaces just provides a bunch of properties. Unless it also stores internal data (?) it looks like this would be better done as a dictionary. The fact that KeyAlgorithm is a [NoInterfaceObject] further indicates this. / Jonas
Re: [last call feedback] Last Call of Web Crypto API; deadline May 20
On May 16, 2014 7:20 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Mar 25, 2014 at 12:31 PM, Arthur Barstow art.bars...@nokia.com wrote: WebApps was asked to review the Last Call Working Draft of the Web Crypto API: http://www.w3.org/TR/2014/WD-WebCryptoAPI-20140325/ Individual WG members are encouraged to provide individual feedback. I don't really have the crypto chops to do anything more than a superficial review here, so just a couple of pieces of feedback: Should Key be a dictionary rather than an interface? No. There is a hidden opaque handle for the cryptosystem that is represented by the Key object, that is a Platform object that can't be polyfilled. The TAG review on github digs into this much deeper. Same question for KeyAlgorithm and anything that derives from it. It looks like these interfaces just provides a bunch of properties. Unless it also stores internal data (?) it looks like this would be better done as a dictionary. This was raised during TAG and is being corrected. It will be an object type, converted from Dictionaries of the same (existing) types. The dictionaries serve as spec shorthand. The fact that KeyAlgorithm is a [NoInterfaceObject] further indicates this. / Jonas
