On 12/2/11 5:41 PM, Jonas Sicking wrote:
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 Pritchard<ch...@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
