Re: Data uris, was: Re: Enable compression of a blob to .zip file

On Fri, Dec 2, 2011 at 6:06 PM, Charles Pritchard <chuck@jumis.com> wrote:
> 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

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("<script>function 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 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.

Thanks. I appreciate the clarifications.

/ Jonas

Received on Sunday, 4 December 2011 01:52:50 UTC