Re: Data uris, was: Re: Enable compression of a blob to .zip file
On Fri, Dec 2, 2011 at 6:06 PM, Charles Pritchard ch...@jumis.com wrote:
On 12/2/11 5:41 PM, Jonas Sicking wrote:
On Fri, Dec 2, 2011 at 5:05 PM, Charles Pritchardch...@jumis.com wrote:
On 12/2/11 4:52 PM, Jonas Sicking wrote:
On Fri, Dec 2, 2011 at 4:38 PM, Charles Pritchardch...@jumis.com
wrote:
As far as I can tell, vendors are trying to move away from data uris
and
toward blob uris.
Just to clear something up. I have not heard anything about vendors
trying to move away from data uris.
I didn't mean it in the sense of retiring the protocol. The URL, such
as
createObjectUrl and blob specs get around a lot of the issues present in
data uris. The simple action of copying and pasting a data uri from the
user-side is becoming more difficult.
So what specifically do you mean by trying to move away from data uris?
move away generally involves taking an action. You seem to be using
some alternative meaning?
I'll try to be more precise in the future. I do appreciate your constructive
criticism.
Specifically, vendors are disabling data uri access from the url bar and
replying with WONTFIX statuses to bug reports related to issues with long
data uris
Yes, that is the one area where I've heard of anyone moving away
from data. Though it's not specific to data, but also to javascript.
And possibly also blob in the future if needed. See below.
There have been no steps to expand or otherwise support base64 encoding,
nor
data uris, from a higher level.
What do you mean by this? base64 encoding has been supported in
datauris as long as data uris have been supported, and base64 encoding
in general has been supported far longer than that.
There are no binary base64 encoding methods available to the scripting
environment, there are no new types [btoa and atob already existing methods]
relating to base64 strings. There are no optimizations nor new helper
methods.
Why doesn't btoa and atob count just because they exist? If we exclude
all functions that exist then of course there is no support. For
anything!
Are you perhaps specifically pointing out that there are not built-in
methods that converts between ArrayBuffers and base64 encoded strings?
recently, Chrome started limiting paste into
address bar length, Firefox limited paste into address bar altogether.
This is due to a recent rise of social engineering attacks which
tricked users into pasting unknown contents into the URL bar. It might
apply to to blob uris as much as data uris. Though given that blob
uris still require script to be created, it isn't currently a problem.
But this might change in the future.
Yes, that's exactly what Firefox reports, now. I wouldn't call this a
bug.
It's also an intentional limitation.
What motivations are there for Firefox to block user-copying of blob
urls?
If/when we get to a point when blob-uris can be used to launch social
engineering attacks I don't see why we wouldn't block it. This could
for example happen if websites start running untrusted code in the
context of their origin, for example using technologies like Caja.
Are there means in Mozilla for running untrusted code outside of the context
of their origin?
I don't understand the question.
Thanks for providing the example, I understand that something in Caja might
create a blob url which would contain a same origin script untrusted by the
publisher, and that script would effectively break through the Caja
sandbox. I believe Caja is supposed to prohibit scripts from accessing APIs,
such as createObjectUrl. Regardless, I appreciate you coming up with an
example, and I'll continue to consider what social engineering attacks may
be present.
I'd like to allow users to easily click and drag and copy and paste URIs. I
hope we can still have that with blob:, but I understand that may not be
sustainable.
I don't believe Caja completely blocks access to any API. Instead it
offers a policy framework such that you can choose what APIs that you
want to expose.
The risk appears if a site like facebook were to allow javascript to
execute on their site while also wanting to allow such script to
access the File API. In such a scenario the page could do something
like:
var str = createObjectURL(new Blob(scriptfunction sendToServer(s)
{...} sendToServer(document.cookie)/script));
displayOnScreen(copy the following text to your url bar for free
smiley icons + str);
Of course, no websites do this today. But if it happens in the future
we might need to re-evaluate our policy for typing/pasting blob: urls
in the url-bar. Just like we did with data: and javascript:
At least at mozilla we have in fact been moving in the opposite
direction. Workers recently started supporting data uris and the new
architecture for uri loading specifically tries to make data uris more
consistently working.
There are some interesting semantics with blob and data uris in relation
to
file:/// and essentially
Re: Data uris, was: Re: Enable compression of a blob to .zip file
On 12/3/11 5:51 PM, Jonas Sicking wrote: On Fri, Dec 2, 2011 at 6:06 PM, Charles Pritchardch...@jumis.com wrote: On 12/2/11 5:41 PM, Jonas Sicking wrote: On Fri, Dec 2, 2011 at 5:05 PM, Charles Pritchardch...@jumis.comwrote: There have been no steps to expand or otherwise support base64 encoding, nor data uris, from a higher level. What do you mean by this? base64 encoding has been supported in datauris as long as data uris have been supported, and base64 encoding in general has been supported far longer than that. There are no binary base64 encoding methods available to the scripting environment, there are no new types [btoa and atob already existing methods] relating to base64 strings. There are no optimizations nor new helper methods. Why doesn't btoa and atob count just because they exist? If we exclude all functions that exist then of course there is no support. For anything! They don't count because they hurt my feelings every time I use them with binary data. And they're not new. Are you perhaps specifically pointing out that there are not built-in methods that converts between ArrayBuffers and base64 encoded strings? The methods convert DOMString. They fall apart across implementations when binary data is used from String. I was wrong in claiming there were no new types relating to base64 strings. FileReader.readAsDataURL does offer improved data: uri support for encoding binary data. recently, Chrome started limiting paste into address bar length, Firefox limited paste into address bar altogether. This is due to a recent rise of social engineering attacks which tricked users into pasting unknown contents into the URL bar. It might apply to to blob uris as much as data uris. Though given that blob uris still require script to be created, it isn't currently a problem. But this might change in the future. Yes, that's exactly what Firefox reports, now. I wouldn't call this a bug. It's also an intentional limitation. What motivations are there for Firefox to block user-copying of blob urls? If/when we get to a point when blob-uris can be used to launch social engineering attacks I don't see why we wouldn't block it. This could for example happen if websites start running untrusted code in the context of their origin, for example using technologies like Caja. Are there means in Mozilla for running untrusted code outside of the context of their origin? I don't understand the question. Sorry I asked it without more information, and more study. iframe sandbox was specifically created to run outside of the current origin and it has broad support. So, my question is dated, moot. Mozilla already supports the it. Background: The following nastiness is currently tolerated by Webkit and Mozilla, it appears: iframe.src = data:text/html,meta http-equiv='refresh' content=\0;URL='data:text/html,object /objectscriptalert(31337);/script'\; That breaks out of the current origin and goes into what amounts to a null origin. localStorage will throw an error in Webkit, but is tolerated in Mozilla (though I doubt it does much). iframe sandbox allows authors to run untrusted code outside of the current origin, in a safe manner. iframe sandbox=allow-scripts Microsoft does not allow data uris to be used as the source of an iframe. Microsoft is supporting iframe sandbox http://msdn.microsoft.com/en-us/library/hh673561.aspx I suspect vendors may retire data uris for iframe, in time. Vendors may suspect that users will retire IE, in time. But that's a different topic. As an aside, there's a good example here of using Blob urls for web workers, instead of data uris: http://www.html5rocks.com/en/tutorials/workers/basics/ Afaik, Microsoft has not yet chimed in about Blob urls and iframe. Thanks for providing the example, I understand that something in Caja might create a blob url which would contain a same origin script untrusted by the publisher, and that script would effectively break through the Caja sandbox. I believe Caja is supposed to prohibit scripts from accessing APIs, such as createObjectUrl. Regardless, I appreciate you coming up with an example, and I'll continue to consider what social engineering attacks may be present. I'd like to allow users to easily click and drag and copy and paste URIs. I hope we can still have that with blob:, but I understand that may not be sustainable. I don't believe Caja completely blocks access to any API. Instead it offers a policy framework such that you can choose what APIs that you want to expose. The risk appears if a site like facebook were to allow javascript to execute on their site while also wanting to allow such script to access the File API. In such a scenario the page could do something like: Wouldn't they simply limit access to the URL object, so that URL.createObjectURL can not be run? Or would they keep access on, so authors can use it? As I've noted, in Webkit, it seems that blob: urls can not
Re: Data uris, was: Re: Enable compression of a blob to .zip file
On Fri, Dec 2, 2011 at 5:05 PM, Charles Pritchard ch...@jumis.com wrote: On 12/2/11 4:52 PM, Jonas Sicking wrote: On Fri, Dec 2, 2011 at 4:38 PM, Charles Pritchardch...@jumis.com wrote: On 12/2/11 5:22 AM, Julian Reschke wrote: On 2011-11-30 19:42, Charles Pritchard wrote: On 11/30/2011 8:04 AM, Julian Reschke wrote: On 2011-11-30 16:50, Charles Pritchard wrote: Nope. If you need gzipped SVG in data URIs, the right thing to do is to either extend data URIs to support that, or to mint a separate media type. Why? Seems like a lot of complexity for blob, data and file for something that could otherwise be handled by minimal code. It would mean that the semantics of a data URI depends on who's processing it. It would probably also cause lots of confusion about what types is applies to. It's already the case that data URIs depend on UA quirks. There's no reason to add more quirks. Instead we should try to remove the quirks. This in no way changes the scheme of data URIs. Data uri quirks are mainly about string length. As far as I can tell, vendors are trying to move away from data uris and toward blob uris. Just to clear something up. I have not heard anything about vendors trying to move away from data uris. I didn't mean it in the sense of retiring the protocol. The URL, such as createObjectUrl and blob specs get around a lot of the issues present in data uris. The simple action of copying and pasting a data uri from the user-side is becoming more difficult. So what specifically do you mean by trying to move away from data uris? move away generally involves taking an action. You seem to be using some alternative meaning? There have been no steps to expand or otherwise support base64 encoding, nor data uris, from a higher level. What do you mean by this? base64 encoding has been supported in datauris as long as data uris have been supported, and base64 encoding in general has been supported far longer than that. IE has string length issues; Bugs are in general not a sign of moving away from a technology. It's rather a sign that there isn't a comprehensive test suite that the vendor is using. And last I checked IEs length issues were a generic uri limitation. Nothing data-uri specific. It's an intentional limitation, and though it's certainly not data-uri specific (neither are the string length limitations of webkit), they are absolutely and primarily an issue in the use of data uris. I don't think it's fair to call it a bug. Indeed, but in the context you were using this it sounded like you were saying that this was an active step taken by IE. The limitation has always been there. recently, Chrome started limiting paste into address bar length, Firefox limited paste into address bar altogether. This is due to a recent rise of social engineering attacks which tricked users into pasting unknown contents into the URL bar. It might apply to to blob uris as much as data uris. Though given that blob uris still require script to be created, it isn't currently a problem. But this might change in the future. Yes, that's exactly what Firefox reports, now. I wouldn't call this a bug. It's also an intentional limitation. What motivations are there for Firefox to block user-copying of blob urls? If/when we get to a point when blob-uris can be used to launch social engineering attacks I don't see why we wouldn't block it. This could for example happen if websites start running untrusted code in the context of their origin, for example using technologies like Caja. Webkit can not cope with data uris in any copy/paste text field (input type=text / textarea) if they are more than ~20k and have no spaces. Again, just seems like a bug. Not a intended decision to move away from data uris. And a third browser, out of the top three, where data uris are less-operable. It's also intentional, for memory management in widgets. All three of these cases are intentional. I wrote them out to support my statement that vendors are moving away from data uris, opposed to trying to support them in additional manners. failing to move towards data uris at the speed you like is not the same as moving away from data uris. Additionally having limitations on string lengths in various situations is not the same as intentionally limiting data uris. I'm sure everybody is hoping for blob urls and dataTransfer to continue to gain more features. Also, is webkit really parsing uri contents of text fields?? That seems like a big waste. Is this not just a limitation in number of characters pasted? It's just a limitation of characters copied (not pasted). Holy crap man, why on earth would you express this as a limitation in pasting data uris then?? You are bordering on FUD here. Please stop. At least at mozilla we have in fact been moving in the opposite direction. Workers recently started supporting data uris and the new architecture for uri
Re: Data uris, was: Re: Enable compression of a blob to .zip file
On 12/2/11 5:41 PM, Jonas Sicking wrote: On Fri, Dec 2, 2011 at 5:05 PM, Charles Pritchardch...@jumis.com wrote: On 12/2/11 4:52 PM, Jonas Sicking wrote: On Fri, Dec 2, 2011 at 4:38 PM, Charles Pritchardch...@jumis.comwrote: As far as I can tell, vendors are trying to move away from data uris and toward blob uris. Just to clear something up. I have not heard anything about vendors trying to move away from data uris. I didn't mean it in the sense of retiring the protocol. The URL, such as createObjectUrl and blob specs get around a lot of the issues present in data uris. The simple action of copying and pasting a data uri from the user-side is becoming more difficult. So what specifically do you mean by trying to move away from data uris? move away generally involves taking an action. You seem to be using some alternative meaning? I'll try to be more precise in the future. I do appreciate your constructive criticism. Specifically, vendors are disabling data uri access from the url bar and replying with WONTFIX statuses to bug reports related to issues with long data uris There have been no steps to expand or otherwise support base64 encoding, nor data uris, from a higher level. What do you mean by this? base64 encoding has been supported in datauris as long as data uris have been supported, and base64 encoding in general has been supported far longer than that. There are no binary base64 encoding methods available to the scripting environment, there are no new types [btoa and atob already existing methods] relating to base64 strings. There are no optimizations nor new helper methods. That said, I know that Chrome displaying data:, truncated in the URL helps with performance and Webkit recently fixed a multi-year memory leak with referencing data uris in images. IE has string length issues; Bugs are in general not a sign of moving away from a technology. It's rather a sign that there isn't a comprehensive test suite that the vendor is using. And last I checked IEs length issues were a generic uri limitation. Nothing data-uri specific. It's an intentional limitation, and though it's certainly not data-uri specific (neither are the string length limitations of webkit), they are absolutely and primarily an issue in the use of data uris. I don't think it's fair to call it a bug. Indeed, but in the context you were using this it sounded like you were saying that this was an active step taken by IE. The limitation has always been there. Inaction has some meaning when reasons for action are pointed out and dismissed (as in, WONTFIX). I'm aware of the buffer size limitation in URL handlers in Windows. This sub-thread continues my assertion that data uris are already quite quirky with existing browsers. I don't think that data uri is responsible for the issues with SVGZ support in UAs. recently, Chrome started limiting paste into address bar length, Firefox limited paste into address bar altogether. This is due to a recent rise of social engineering attacks which tricked users into pasting unknown contents into the URL bar. It might apply to to blob uris as much as data uris. Though given that blob uris still require script to be created, it isn't currently a problem. But this might change in the future. Yes, that's exactly what Firefox reports, now. I wouldn't call this a bug. It's also an intentional limitation. What motivations are there for Firefox to block user-copying of blob urls? If/when we get to a point when blob-uris can be used to launch social engineering attacks I don't see why we wouldn't block it. This could for example happen if websites start running untrusted code in the context of their origin, for example using technologies like Caja. Are there means in Mozilla for running untrusted code outside of the context of their origin? Thanks for providing the example, I understand that something in Caja might create a blob url which would contain a same origin script untrusted by the publisher, and that script would effectively break through the Caja sandbox. I believe Caja is supposed to prohibit scripts from accessing APIs, such as createObjectUrl. Regardless, I appreciate you coming up with an example, and I'll continue to consider what social engineering attacks may be present. I'd like to allow users to easily click and drag and copy and paste URIs. I hope we can still have that with blob:, but I understand that may not be sustainable. Webkit can not cope with data uris in any copy/paste text field (input type=text / textarea) if they are more than ~20k and have no spaces. Again, just seems like a bug. Not a intended decision to move away from data uris. And a third browser, out of the top three, where data uris are less-operable. It's also intentional, for memory management in widgets. All three of these cases are intentional. I wrote them out to support my statement that vendors are moving away from data uris,
