Hacker News Reader

Comment by andrewcooke | Hacker News Reader

is it actually sending 2M characters over the wire (ie uncompressed)? you could imagine seeing something like this via a glitch in compression (2 million of anything, run length encoded, doesn't take much space).

(i guess it's also possible that this really is 2M nulls at a lower level and compression just happens to save you from an embarrassing waste of bandwidth).

it's not clear to me what the URL is to check myself.

View on HN

I was thinking the same thing. Is the content gzip'd on the server? This could be a nice (i.e. evil) way to send a very small response to the browser that would pretty much kill it.

a slightly more evil version would be to perhaps do:

  var x="...2 billion of the same character...";

This should compress very well to gzip, but will likely to exhaust the browser's memory (??)

Indeed, there was a 'crash your browser' webpage a few months ago which used this technique I think. Unfortunatly I can't find it currently.

Oh, I do remember seeing that. Ahh, just fou

This is very similar to the ping of death that requests a undeliverably big ping response.

Ping of death was +++ath0 which causes a dialup modem to hang up.

I have no idea why most modems did this. But by god it was a lot of fun on IRC when I was 14 or so. I still remember the hex string for +++ath0 you'd need to pass into 'ping -p', haha..

The "proper" Hayes AT drop-back-to-command-mode sequence was +++ followed by a long pause (1 second or so). Any characters sent during that pause time would invalidate the attempt to switch to command mode. So theoretically this shouldn't happen. However, lots of cheaper modems seemed to not check for the pause, so sending +++ATH0 would make them switch to command mode and immediately process a Hangup command ... not pretty :-).

Specfically, that pause was the part of the Hayes AT command-set that was patented. Therefore lots of manufacturers who didn't want to licence the patent but wanted to have 'Hayes AT compatible' on the box just didn't bother implementing the timeout-cancellation bit.

Wow, I didn't know that, it explains a lot.

You are describing a zip/decompression bomb. Most zip and compression libs protect against them.

http://en.wikipedia.org/wiki/Zip_bomb

Interesting, but the wikipedia article mentions that antivirus libraries protect against those. Couldn't find much on wikipedia or otherwise talking about browsers or zip libraries that have built-in protection for this...

The easier version would be to just run a crashing script

    var i = 1, a = []; while(a[i++] = "a" + a);

The author's choice of title somewhat implies malfeasance on Microsoft's part. In general, the article seems intended to spread FUD regarding Skydrive.

I would point out that if Opera is just now debugging their interaction with Skydrive, it is indicative of how few people use it. While I appreciate the motivations behind it and its rich feature set, I gave up on Opera for Firefox after a year. In part this was the fatigue of experiencing broken websites, in part because of low quality plugins comparable to noscript.

Opera would be great if it handled nonstandard html gracefully for me instead of telling me about its high horse and the shoddiness of the websites I use.

Where's the FUD? The tone of the article is fairly strictly factual. The only deviation from facts is where he says that it's bizarre to encounter this, which is an opinion, but still completely reasonable. IMO it is bizarre.

The meaning of "FUD" slowly morphed to "saying bad things about software I like" a few years back.

> I gave up on Opera for Firefox after a year

And went to use what? IE? Or did you try Opera/FF just recently when Chrome became usable?

Chrome's been usable for something like 4 years now.

Not really. It wasn't really usable after the release (which was 4 years ago). Constantly crashing, featureless (which it still is, but now you have extensions). I tried it several times in the course of the first year after release and it was really (really) bad. But even if it was 3 years, it's still a short time for a browser to be around.

But as leddt pointed out, I misunderstood the comment I replied to.

> featureless (which it still is)

It can render web pages.

So can wkhtmltopdf, but I wouldn't use it as a browser.

That's not an exhaustive list of features. It can also execute javascript, which seems to be lacking in wkhtmltopdf. That's a must-have for me.

Obviously. And "feature" might not be the best term as I meant something like "can't configure it or do anything else than render a web page really".

I think he meant he gave up on Opera and went to use Firefox.

Right, I somehow misread it and understood he gave up on both. Thanks for pointing that out.

Skydrive's main page worked fine in Opera last week, I assume an update caused this. I've made many stupid mistakes myself (sometimes very public ones - http://my.opera.com/hallvors/blog/2012/08/04/bumpy-road-to-o... ), so I have no intention of implying malfeasance or spreading FUD about Skydrive. It is however a surprising and amusing error, hopefully soon fixed.

> Opera would be great if it handled nonstandard html gracefully for me

We put a huge amount of effort into handling "nonstandard" html, including fixing the standards so that they represent the reality of what browsers have to handle.

In this case our failure is clearly a bug that we should fix. I don't think anyone disputes that.

In general, site-compatibility is a hard problem. People often depend – intentionally or not – on the specific behaviour of particular browsers. When this causes sites to break in Opera we try to analyse the breakage and adopt some strategy to fix it. Hallvord is one of the people responsible for this and, if you read his blog you'll see that it's not a trivial undertaking; pinpointing an error in tens of thousands of lines of closure-compiled, minified JS makes for an interesting challenge, for example.

If we find the problem's a bug in Opera we obviously try to fix that bug. If it is the site doing something broken we typically try to contact the site owner to get it fixed. In either case we may also try using our browser.js system to make a short-term "sitepatch"; a hack using a combination of UA string manipulation, javascript and CSS that changes the behaviour for a specific site and which can be rapidly deployed. In this instance sitepatching likely isn't reasonable, so we will have to work to find the solution that will unbreak the site as quickly as practical.

I gave up on Opera because it was unusable on a small site that I use regularly. The site's owner licenses vBulletin and hires some local web guy to customize it (local being rural Pennsylvania).

I was the only person using Opera on the site. It wouldn't be a surprise if I was the only Opera user the web guy encountered all year.

IE, Firefox, Chrome all worked properly. Using Opera was turning me into a whiner as far as the site's owner was concerned. And he was justified, using Opera was just a luxury that was creating a PITA for him...on a site he was providing gratis.

I suspect his site was broken in terms of standards. But from my standpoint, it was Opera that was broken.

Don't misunderstand me, I chose Opera originally because I admired the project's goals. I still admire the feature set Opera provides. For me, it's tradeoffs became increasingly impractical. I want my browser to deal with the problem of broken sites in real time, not contact the site's owner for a long term solution.

To be clear, we aren't running some idealistic enterprise where we value standards compliance over real world usefulness. Indeed Opera has historically been more willing to implement IE quirks than other browsers, a policy that has recently come to cause problems because some sites punt us down an legacy-IE-only codepath that we don't work with, rather than a standards codepath that would work fine.

Our sitepatching is specifically designed to solve problems in real time rather than needing the site owner to make any changes, or for the user to upgrade their Opera.

Did you report a bug on Opera for the site that you were having difficulty with? Often half the battle is knowing that there is a problem, and having good steps to reproduce. With those things we likely could investigate whether we have a bug that needs to be fixed or whether the site is treating us differently to Gecko/WebKit for some reason, and come up with a solution.

>Opera would be great if it handled nonstandard html gracefully for me instead of telling me about its high horse and the shoddiness of the websites I use. //

I find it hard to see how you think this is Opera's fault. MS send their browser different, non-standards compliant, content that includes 2M of null characters. Yes Opera can modify to correct their handling of MS's disastrous abuse of the web but you can't exactly blame Opera.

>if Opera is just now debugging their interaction with Skydrive //

I'm sure MS won't amend it in any non-standards compliant way without notifying the other major browser makers and giving them a suitable implementation period; they'll surely keep all interactions well documented too. /s

Just to save anyone else bothering to check, 2M of nulls gzips to almost exactly 2k. Easy to imagine with compression how you could miss that, although it is still a bit embarrassing.

I think most HTTP these days uses transparent compression, but I can't find a source for that just now.

Exactly what I was thinking. My best guess is that their data is triggering a latent bug in their gzip compressor which causes it to output something that decompresses to 2MB of zeroes.

Reply on news.ycombinator.com