Re: [whatwg] EventSource and data URLs
On Mon, 27 Apr 2015, Anne van Kesteren wrote: Currently Chrome supports data URLs inside EventSource whereas in Firefox EventSource is restricted to http/https URLs: https://bugzilla.mozilla.org/show_bug.cgi?id=1156137 What's the convergence we want here? It's definitely intentional that EventSource not introduce any new exceptions to the networking layer. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] EventSource and data URLs
On Mon, Apr 27, 2015 at 7:00 AM, Anne van Kesteren ann...@annevk.nl wrote: Currently Chrome supports data URLs inside EventSource whereas in Firefox EventSource is restricted to http/https URLs: https://bugzilla.mozilla.org/show_bug.cgi?id=1156137 What's the convergence we want here? It's rather frustrating when data: urls don't work in various places; they're an invaluable debugging tool, at minimum. They should generally be treated as the same security level as the page, no? ~TJ
Re: [whatwg] EventSource and data URLs
On 4/27/15 10:00 AM, Anne van Kesteren wrote: Currently Chrome supports data URLs inside EventSource whereas in Firefox EventSource is restricted to http/https URLs: https://bugzilla.mozilla.org/show_bug.cgi?id=1156137 What's the convergence we want here? Note that per current spec, EventSource is supposed to support whatever fetch supports. I haven't tested whether Chrome in fact does that (e.g. whether it supports EventSource over FTP or blob: or whatnot). -Boris
Re: [whatwg] EventSource and data URLs
On Mon, Apr 27, 2015 at 3:58 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Apr 27, 2015 at 2:20 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Apr 27, 2015 at 7:00 AM, Anne van Kesteren ann...@annevk.nl wrote: Currently Chrome supports data URLs inside EventSource whereas in Firefox EventSource is restricted to http/https URLs: https://bugzilla.mozilla.org/show_bug.cgi?id=1156137 What's the convergence we want here? It's rather frustrating when data: urls don't work in various places; they're an invaluable debugging tool, at minimum. They should generally be treated as the same security level as the page, no? There's definitely exceptions to this. For example chrome doesn't run a iframe src=data:... with the same origin as its parent. For IMHO good reasons since it's a potential XSS vector if a website accepts URLs from third parties and render them inside a child iframe. The same problem exists with accepting data: URLs in new Worker(...). So no, I don't think it should be treated as the same security level as the page. For data-loading APIs, rather than script-running APIs, I see less of such risk though. Yeah, I can see the potential risks for script-running APIs, but this is definitely a data-loading API. ^_^ ~TJ
Re: [whatwg] EventSource and data URLs
On Mon, Apr 27, 2015 at 7:37 PM, duanyao duan...@ustc.edu wrote: In iframe, srcdoc attribute seems as secure (insecure) as data: URL in src, so should it be removed from the spec? The difference there, and in the other examples that you mention, is that you know that you are loading content in your own domain. The problem with data: URLs is that the same API sometimes does a network load, and sometimes parses content and runs in your security origin. I'm happy to have a way to opt-in to enable loading data: in iframes and Workers. But I strongly prefer an explicit opt-in. Note that the chrome team apparently currently feels that data: in iframe is so unsafe that they always load it in a sandbox. And never allow data: in Workers. There's no way to even opt in to having it behave any other way. / Jonas
Re: [whatwg] EventSource and data URLs
在 2015年04月27日 22:58, Jonas Sicking 写道: On Mon, Apr 27, 2015 at 2:20 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Apr 27, 2015 at 7:00 AM, Anne van Kesteren ann...@annevk.nl wrote: Currently Chrome supports data URLs inside EventSource whereas in Firefox EventSource is restricted to http/https URLs: https://bugzilla.mozilla.org/show_bug.cgi?id=1156137 What's the convergence we want here? It's rather frustrating when data: urls don't work in various places; they're an invaluable debugging tool, at minimum. They should generally be treated as the same security level as the page, no? There's definitely exceptions to this. For example chrome doesn't run a iframe src=data:... with the same origin as its parent. For IMHO good reasons since it's a potential XSS vector if a website accepts URLs from third parties and render them inside a child iframe. The same problem exists with accepting data: URLs in new Worker(...). I think this is unfortunate. In iframe, srcdoc attribute seems as secure (insecure) as data: URL in src, so should it be removed from the spec? Restriction of data: URL to iframe.src can also be workarounded by creating an iframe with src=about:blank, and then manipulate its DOM as your wish. On Web Worker, according to current spec (http://dev.w3.org/html5/workers/#dedicated-workers-and-the-worker-interface ), data: URL and same-origin blob: URL are allowed as worker URL: Firefox accepts data: URL as worker URL, and I remeber that older versions of Chrome also did. So should the Worker spec be changed to disallow data:/blob: URL? This change would make it hard or impossible to ship a web app/library that uses workers in one file. Regards, Duan Yao
Re: [whatwg] EventSource and data URLs
在 2015年04月28日 02:42, Jonas Sicking 写道: On Mon, Apr 27, 2015 at 7:37 PM, duanyao duan...@ustc.edu wrote: In iframe, srcdoc attribute seems as secure (insecure) as data: URL in src, so should it be removed from the spec? The difference there, and in the other examples that you mention, is that you know that you are loading content in your own domain. The problem with data: URLs is that the same API sometimes does a network load, and sometimes parses content and runs in your security origin. I understand now, thanks. However, normal URLs from third parties to be rendered inside iframes are not necessarily from different origins (e.g. blog or forum sites), so the attack is still possible unless those sites explictly sandbox all iframes, or disallow iframes at all. I'm happy to have a way to opt-in to enable loading data: in iframes and Workers. But I strongly prefer an explicit opt-in. Note that the chrome team apparently currently feels that data: in iframe is so unsafe that they always load it in a sandbox. And never allow data: in Workers. There's no way to even opt in to having it behave any other way. How about blob: URL in Workers? Current chrome seems allowing it. I think it is less likely for Workers to run third party URLs as iframes -- after all, worker URLs must have same origin in the first place. / Jonas
Re: [whatwg] EventSource and data URLs
On Mon, Apr 27, 2015 at 2:20 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Apr 27, 2015 at 7:00 AM, Anne van Kesteren ann...@annevk.nl wrote: Currently Chrome supports data URLs inside EventSource whereas in Firefox EventSource is restricted to http/https URLs: https://bugzilla.mozilla.org/show_bug.cgi?id=1156137 What's the convergence we want here? It's rather frustrating when data: urls don't work in various places; they're an invaluable debugging tool, at minimum. They should generally be treated as the same security level as the page, no? There's definitely exceptions to this. For example chrome doesn't run a iframe src=data:... with the same origin as its parent. For IMHO good reasons since it's a potential XSS vector if a website accepts URLs from third parties and render them inside a child iframe. The same problem exists with accepting data: URLs in new Worker(...). So no, I don't think it should be treated as the same security level as the page. For data-loading APIs, rather than script-running APIs, I see less of such risk though. / Jonas
