Wouldn't it make more sense just to fix the URL bar to make data URIs look different? You could even go to the extreme of making it just show "data:…" and requiring you to put focus on it to find out the full URI.
No kidding... this is a problem they created by hiding/obfuscating the URL scheme. If the majority of URLs you visit start with http:// or https://, then data: stands out like the proverbial sore thumb.
That requires that you know what you're doing, though. Non-technical people are probably more inclined to think along the lines of "huh, odd, but everything looks fine, so it's probably my fault it looks like that"
Oh, I honestly would've missed this, because so few sites I browse are in cleartext anymore. They may as well just display a giant "INSECURE" banner, instead of http://, though.
Though it's still disabled by default (currently the insecure connection icon is only shown if a password field is present on a http page / the form action url is http).
I'm glad they aren't blocking explicit entries. This morning I discovered I could quickly send snippets of text to my phone by writing it as a data uri and sending the tab via Fx sync.
Alternatively for Android, you could enable KDE Connect[1] and copy the text to the clipboard (which will then be copied to the Android clipboard, and vice-versa). Or easily put it in a file and transfer it over to your device.
I used to do exactly the same, but using a Firefox extension [0]. Since it is not compatible with quantum, I am writing my own, but it's still a prototype for now.
It is you can embed any binary in a b64 string in the html page and then download it from within the browser.
Since the download happens locally it also will not be logged in your perimeter monitoring and most security appliances do not inspect inline HTML especially from “trusted” domains due to performance limitation.
I’ve used this trick to bypass DLP, local policies and various content filtering appliances multiple times.
Depending on how exactly this block works, it may break an important functionality of our application :/
We generate SVG graphs in the browser, and have a button with a data:image/svg+xml URL to allow users to download these graphs, for example to include in a publication.
And that "I presume" instead of "I am quite certain" is precisely why I said I was worried about exactly how this block works. I will need to try with the beta, I suppose.
Yeah, the form on http://sprunge.us/ is blocked for me in Firefox 58.0b7, which is kind of annoying because I used it regularly. If this is a phishing problem, couldn't it be fixed by changing UI rather than breaking functionality?
Hopefully data:image/ still works for favicons. Embedding a highly compressible ~450 byte string in HTML is faster than issuing a new request, under most instances.
It does, not sure why you would think it doesn't? I do know chrome gets annoying about them, always requesting a sites favicon even when it doesn't have one listed in the document.
I haven’t seen them in the UI while I remember them being shown quite prominently. I wouldn’t really expect them to be used only for sites added to favorites because that’s a privacy issue.
Does anyone have a (non-malicious) example of this sort of "attack"? I don't quite get it; some people are mentioning Javascript, but the description sounds more like a phishing, e.g. `data:text/html;base64,MyBank.com/account/xxxxx`
Presumably such leading junk is hidden in the rendered page, making the user think they're on MyBank.com?
>Presumably such leading junk is hidden in the rendered page, making the user think they're on MyBank.com?
it's even simpler than that, they add a bunch of spaces after the "fake" url to pad out the actual payload so it doesn't show in the urlbar. any issues with the page content can be fixed with document.write or whatever.
I know of a website that decrypts all its content clientside and uses this (i think) as a mechanism for a user to download his own attachments.
The Idea is that the whole website could be a static file somewhere and the webserver is only a key value store that has no idea what it is saving. Doesn't work that way currently because file:/// doesn't allow ajax calls to somewhere else but that's a solveable problem.
Generally, every download that gets generated clientside by the JS is hit by this
Only some bookmarklets that go to a data URL on top level are affected. They should be easy to modify to open them inside an iframe or to replace the existing document instead.
