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 Pritchard<chuck@jumis.com>  wrote:
>> On 12/2/11 4:52 PM, Jonas Sicking wrote:
>>> On Fri, Dec 2, 2011 at 4:38 PM, Charles Pritchard<chuck@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

>> 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, 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".

Have it as you will. Vendors are holding out for higher principles.
Those intentions have consequences, for the greater good, so to speak.



>> 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.

I'm responding to your questions. You've continued to ask for specifics 
in this thread.

There are active bug reports specifically about the copying and pasting 
of data uris, and they're not reports that I posted.
I don't quite understand what fear it is I'm driving up here... I'm 
reporting on existing experiences and practices of UAs.

I do understand that you found my comment that "vendors are moving away 
from data uris" to be FUD-full.
I did not mean to imply that vendors are retiring data uris.

>>> 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 anonymous / non-scoped origins.
>> Otherwise known as "null".
> Again, not adding support for data uris at the speed you want is not
> the same as moving away from data uris.
>
>> Within Webkit, it seems that blob url will not be supported in the null
>> scope.
> What data do you have for "will not be supported" rather than "is
> currently not supported"?

Chromium has gone back and forth about enabling blob: from file:///, and 
other null scopes. Initially, they round up as  blob:null:....; at some 
point, Windows-only enabled blob. It was subsequently disabled.

I do want to have a productive and active discussion about the various 
origin scopes that are out there and how to enter into and what to 
expect from a null origin. I don't know that this is the time or place 
for that discussion.

There are about two null origin scopes in Webkit. And I apologize as I'm 
sure I'm using the wrong terminology.

In one scope, best seen with file:///, the author may access 
localStorage. In another scope, easier to see with hosted apps in Mobile 
Safari, but also available through some redirect techniques on the 
desktop, accessing localStorage results in a DOM security error. In both 
cases, authors can not create object urls.


I don't mean to suggest that in X years, security scopes will still be 
the same, or that new apis won't be written. I didn't mean to suggest 
absolutes. I tried to hedge my terms by using phrases like "moving away" 
and "seems that".

I've spent a lot of time working with data:, blob:, file:, filesystem: 
and svgz files, and I thought it'd make sense to report on obstacles. 
I've tried to answer all questions you've asked me.

-Charles

Received on Saturday, 3 December 2011 02:06:37 UTC