Hacker News Reader

Comment by quotemstr | Hacker News Reader

The ossification phenomenon happens to all sorts of APIs. Consider stat(2): all hell would break loose if we introduced another file type for st_mode. I'm a fan of keeping things "well oiled" by exercising extension points that are supposed to keep working.

That said, I wish we would be more willing to force these rusted joints to open, breakage be damned. Breaking 3% of the web sounds like a lot, but it's not that much, especially considering that anyone broken will very quickly upgrade.

By using elaborate workarounds described in the article, we recognize and reward the worst technical practices. The author may not want to cast blame, but I do.

View on HN

Web breakage is a Prisoner's Dilemma. Unless all major vendors agree to break the same thing at the same time, the one that "defects" to being compatible with garbage will seem more reliable to users. Remember, most users don't know what TLS is, but they care whether the page they wanted to see opens "fine" or shows scary errors.

We've been there with CSS box model, DOM levels, (X)HTML(5), and CSS prefixes. There have been some cases of cooperation, e.g. SHA-1 certs and kicking of bad CAs, but most of the time browser vendors only "break" things gradually and only when it affects < 0.1%.

Considering Chrome's market share, it's enough for Chrome to break something to force server-side action. Distrusting Symantec certificates is a prime example, I think. The breakage rate for distrusting all Symantec certificates is significantly higher than 0.1%, but there is just one vendor that needs to fix things.

Middleboxes are considerably more problematic, since you've got a lot of manufacturers out there, some of them might actually be out of business. Pushing firmware upgrades to all of those middleboxes would also be a nightmare. And the icing on the cake is actually finding the malfunctioning middleboxes, since they can be anywhere between the end user and the web server.

> The breakage rate for distrusting all Symantec certificates is significantly higher than 0.1%, but there is just one vendor that needs to fix things.

No. Every website that uses a Symantec cert (that was issued before 2017-12-01) needs to renew their cert early to move to their new root.

> We've been there with CSS box model, DOM levels, (X)HTML(5), and CSS prefixes.

Other examples:

Content-Type. There were a few years where many sites were misconfigured to serve virtually every non-HTML file as text/plain. IE, deviating from the HTTP spec, always used its own algorithm to detect the actual file type and thus "worked", whereas Netscape (and later Mozilla) respected the header and would display "garbage".

Windows-1252 mojibake. Various Windows-based authoring tools simply used the native Windows code page 1252 to encode their text in HTML files, which were then claimed to be encoded as ASCII or ISO 8859-1. This led to documents that mostly looked correct but would have garbage sprinkled around due to added punctuation in Windows-1252 (primarily the distinct open/close quotes and em-dashes, if memory serves). IE of course handled these "correctly", i.e. interpreted ASCII or ISO 8859-1 to mean Windows-1252. I think this behavior is now specified by HTML5 under certain conditions.

> IE of course handled these "correctly", i.e. interpreted ASCII or ISO 8859-1 to mean Windows-1252. I think this behavior is now specified by HTML5 under certain conditions.

You can leave out "under certain conditions", whatwg just plain specifies the "iso-8859-1" label identifies the windows-1252 encoding [1]

[1] https://encoding.spec.whatwg.org/#names-and-labels

The numbers shown were more than 3%

I'm okay with this if and only if browser vendors make old releases available for download, or better yet open-source their old releases. That way we can be more confident, when archiving pages that no longer render correctly, someone will be able to actually view them.

Firefox is open source as is large portions of chrome and the engine in safari...

So mostly you're talking about IE/Edge...

Old Firefox releases (binary and source) are very much available for download, though whether you can run them on modern operating systems somewhat varies. And you almost certainly can't compile some of them with a modern compiler, though a compiler from the era of the release should work...

Anyway, https://ftp.mozilla.org/pub/firefox/releases/ has links to all the Firefox release binaries and corresponding source snapshots starting with version 0.8. It includes a number of the betas as well (so for example has the Firefox 58 beta builds already).

>And you almost certainly can't compile some of them with a modern compiler,

I wonder how long and difficult it must be to get all the required dependencies to compile a modern web browser...

[two hours of obscure error messages later]

"You have v2.3030392.302 of dependency 113, you need to compile v2.3030392.300 in 32-bit first, then build the 64-bit version of v2.3030392.301 then ..."

You get all the compiler errors fixed and then it's on to round two... linker errors.

Maybe old browser versions should be archived as container images with all the necessary shared libraries. Then the only interface that might break them is the kernel interface, and we know Linus' stance on breaking userspace.

I've created dev environment VM's with classic operating systems (XP, etc) because my job involves updating lots of really old code (most clients only update when they have to, every 5-10 years).

I could definitely see someone doing that with Firefox. They may already exist. I've just, from experience, had so much trouble with compiling large codebases.

On the bright side, the larger a codebase, often, the more popular. And the more popular, the more likely people will have EXACT dependencies listed.

For the current version, it's not too bad if you're on a "popular enough" OS. For example, Firefox has a bootstrap.py script for Linux which will install the right packages on either Ubuntu or Fedora Core. See https://developer.mozilla.org/en-US/docs/Mozilla/Developer_g...

https://developer.mozilla.org/en-US/docs/Mozilla/Developer_g... lists the actual set of libraries and whatnot needed; converting those to the relevant package names for the Linux distro of your choice is tedious, but not too hard.

For an old version, things could be more complicated, depending...

Reply on news.ycombinator.com