10 ms·

Browser-Wars History: MD5-Hashed Posts Declassified

163 points by sankha93 9y ago

zaro 9y ago
> the more code engines share, the more de facto standardization of bugs we would see, so having genuinely separate implementations is very important. Well it's not like there aren't any bugs in the specs. And whether there are bugs in the code or the specification, it's the same process for fixing them : politics :)
- roca 9y ago
  Web developers code to Web browsers, so bugs in Web browsers lead to sites depending on those bugs, making those bugs unfixable unless you have developers testing in multiple browsers. Spec bugs don't become unfixable that way.
  - Leszek 9y ago
    Though spec bugs go the opposite way: if you discover an issue in the spec, then it is very difficult to change it because someone somewhere may have been - at the time correctly - relying on that behaviour.
    - peterwwillis 9y ago
      Or, you could just be Google, and change your browser to work the way you want, and ignore all the pages breaking by insisting that the change is "within spec", giving a big middle finger to anyone that complains.
    - roca 9y ago
      Web developers can only rely on a spec bug if the browsers they test with actually implement that bug. So it still comes down to what browsers implement, not what the spec says.
  - vbezhenar 9y ago
    It doesn't have to be this way. Apple doesn't have fear of breaking old apps sometimes, for example, and they are successful. I think that absurd backwards compatibility should be considered harmful and some breakage should be normal. It's always possible to install old browser into virtual machine, if content is so precious.
    - tolien 9y ago
      Apple doesn’t have the competitive pressure that I can take my broken iOS app and run it somewhere else as-is, or tell my customers to do that. “It works in Chrome” (and previously IE) is a real issue and the browser that broke compatibility like that would have to be supported (potentially through the coercive power of its own market share - see the initial “any open source browser versus IE is a good thing” switching to “we need multiple browser engines, even if they’re all open source”) by the others or face irrelevance.
- jgraham 9y ago
  There has been a lot of progress recently on the web-platform-tests project [1]. This is a cross-vendor effort to improve interoperability on the web platform through testing. Historically the process for building web-platform features has been to write a spec and then assume that implementations of the spec would reach compatibility in an ad-hoc manner by patching until sites worked. The big innovation of the last decade — still controversial to some — was the idea that it's OK to adjust the specs themselves when implementations have converged on some other behaviour or when the spec is otherwise wrong. The goal for the future is to use the same engineering discipline that you would use for developing software to developing the platform itself. In particular the objective is: * Every change to a spec that influences browser behaviour must be accompanied by a corresponding test case. * Every change to a browser that affects a cross-platform feature that isn't already adequetely tested must be accompanied by cross-browser test cases. * The results of those tests must be visible to browser vendors in a way that makes it easy to identify the higest value bugfixes (e.g. cases where N-1 browsers agree and one is different, or cases where a spec change makes previously correct behaviour — which may not have shipped yet, but just be enabled on nightly builds or behing a flag — wrong). Apart from the work of actually writing the test, achieving those goals involves a lot of infrastrucutre work to ensure that the cross-browser tests are well integrated into the development cycle of each browser and are able to cover as many scenarios as possible (testing often involves manipulating the browser in a way that is not exposed to normal web content). Despite the large scope of the project, I think it's agreed that modernising the way the platform is developed, and prioritising interoperability at all stages of spec and browser development is essential to avoiding existential threats to the open web in the long term. Certainly Mozilla put a lot of resources into post-hoc fixes for site-compatibility issues, and whilst there will probably always be some bugs that slip through, it will be much more efficient to catch those problems up-front before they ship to end users. I sadly don't have data to backc this up, but I'm pretty sure we're already seeing the effects of this effort, with recent, complex, features shipping with fewer cross-browser issues that we would have predicted five years ago. [1] http://web-platform-tests.org/ http://web-platform-tests.org/
  - zaro 9y ago
    Very nice. I haven't heard of these tests before.
foxhill 9y ago
2007-jan-21 hash: ec06b3461cf0eaf3d3e4d7a2e429bddb but then $ curl -s https://raw.githubusercontent.com/rocallahan/blog-archive/master/hashed-blog1.txt | md5 9ba0c5cba20cff553500f034f58d5bb7 hmm. that said, the others check out, so i'm sure it's harmless.
- feb 9y ago
  Someone said the same thing in the comments. In a reply, the author does not know why the MD5 fails but confirms that the post is correct: I wondered if anyone would check :-). I'm not sure what the problem is with the first post. It's been a long time. You'll have to take my word for it that the first post is the right text :-).
  - puzzle 9y ago
    Different encodings for line endings?
    - rzzzt 9y ago
      hashed-blog1.txt contains HTML markup for paragraphs, while all others are in plain text.
      - raverbashing 9y ago
        Taking them out has not resulted in the correct hash, or maybe I forgot something Neither adding a \n to the last line makes it match
        rzzzt 9y ago
        I also tried it with some line endings :) There might be some other slight changes in formatting which is still missing.
nly 9y ago
Opera made the bet he proposed and lead themselves down a path to irrelevance.
- tolien 9y ago
  Opera also lost most of their distinctiveness (i.e. features) along the way, laid off the bulk of their developers and sold out to a consortium including Qihoo360 (who, as well as the usual FUD—well-founded or not—about Chinese companies, were simultaneously found to be really bad at being a competent Certificate Authority). There’s plenty of scope for Mozilla to have used WebKit and not done the subsequent parts - Brave’s perhaps as good an example of that as any. Saying that, roc proposes porting XUL and XPCOM which are largely dead these days (the former by virtue of Firefox switching to WebExtensions). With browser.html for Servo being a thing, building Firefox’s UI in a way that it would work in WebKit is more possible than ever.
- jasode 9y ago
  As one of the few who paid for a web browser (paid $29 for Opera 7 in 2003), it looked to me like Opera really had no choice. There was a post from an Opera insider that I can't find but it was basically this: the web's complexity was evolving faster than the Opera team could maintain their proprietary Presto rendering engine. Switching away from Presto and building on WebKit was a basic matter of survival. Yes, they still became irrelevant but they would have also stayed irrelevant with their Presto engine. I agree with their assessment because around 2009, I started encountering more and more web pages that broke Opera. The Opera forums had more and more complaints from users reporting broken web pages. The Presto engine was becoming a liability. It was a vicious feedback loop because web authors wouldn't bother to test their sites with Opera ... which led to more user frustrations. I had to switch to Chrome to get a usable web surfing experience back. I originally paid for Opera because it had the fastest rendering engine which was very helpful for slow dialup connections. As Presto started falling further behind, that speed advantage was negated. Opera did try to some interesting features such as "Unite" which -- if you squint a certain way -- was a form of p2p decentralization. Yes, it's interesting to have a built-in web server in the browser but not enough people cared about it. The author's predictions for Firefox's Gecko engine meeting the same irrelevant fate as Presto didn't happen because unlike Opera, Mozilla from 2004-2014 got massive funding from Google. Mozilla could afford to keep programmers enhancing the Gecko engine. Opera couldn't do the same with Presto.
frik 9y ago
Jan 21th 2007 [...] Furthermore, there's a wider community relying on Gecko --- embedders, XUL developers, extension authors, Web authors, and their users, who would not be well served if Gecko suddenly nose-dives. [...] They changed their opinion 10 years later.
adius 9y ago
Cool idea to just post the hashes for the future. I think I might do it too on my blog :-)
- dr_win 9y ago
  Use blockchain :-)
- lovemenot 9y ago
  Maybe use SHA256 rather than MD5. A few years hence ease of producing MD5 collisions might render moot anything that you had to say.
  - torstenvl 9y ago
    I don't think that's necessary. This isn't really a cryptographic use of the hash. Between the legitimate text of the blog entry and whatever arbitrary (likely nonsensical) string produces an MD5 collision, it's going to be pretty obvious which is which.
    - tonyztan 9y ago
      Isn't it feasible to construct two sets of legible texts with the same MD5 hash now?
      - jaaames 9y ago
        Sort of, in PDF form, by inserting invisible images/data crafted to create the collision. I haven't seen a collision demonstration with plain text that could be a practical attack.
      - tialaramex 9y ago
        Legible, maybe, but I don't think you'll be able to collide the hash with natural language, so you will need an excuse as to why the revealed text has weird nonsense in it that is actually there to collide the hash. You can also "see" this, once you suspect it's going on, if you're a cryptanalyst and have the tools to see inside the hash, you can see basically such collisions involving getting the internal state into an awkward place, and then forcing it from there where they want to go, that could happen by accident, but only by truly astronomical bad luck, so it's a pretty good smoking gun. MD5 is a bad idea for situations where a machine will be verifying, because machines aren't good at saying "that's odd...", enhancing them to do so is _way_ more effort than just using SHA-256 instead. But for something like this where a human will be examining things by hand, it's fine. For SHA-1 (which we knew at the time would be broken shortly, and then in practice it was less than a year before Google and some academics announced their full collision) we reviewed special "Exception" SHA-1 SSL issuances by hand on m.d.s.policy after the official deadline for SHA-1 issuance and I asked for one application to be explained or rejected on the basis that the requested certificate had bizarre short gibberish values for "Organizational Unit". The applicant provided an explanation (which was maybe plausible but not up to the standard of transparency needed in the circumstances) but agreed to accept certificates missing the OU value altogether instead. That's the sort of thing you'd catch if a human examines what was hashed rather than a machine. I had no reason to believe that applicant was trying anything sinister, but the point of the manual examinations was to ensure everybody can see there were no shenanigans going on (and to make it a complete pain -- if the process was easy it would have become routine and defeated the purpose of prohibiting new SHA-1 issuance, being annoying was a feature).
jwilk 9y ago
I expected an article about 1990s browser wars. 2007-2008 is not ancient in my book.
- dang 9y ago
  Ok, we'll take 'ancient' out of the title above.
- yjftsjthsd-h 9y ago
  It doesn't feel that way, but a decade(!) is a long time in our field.
  - loopbit 9y ago
    Still, as someone who lived the browser wars of the 90's, "ancient" is not an adjective I'd use for something that happened only a decade ago. Or put in a different way, if the browser changes in 2007 are "ancient", how would you describe the ones that happened 10 years before that? Prehistoric? Jurassic?
    - bzbarsky 9y ago
      Antediluvian, in the almost literal sense of happening in a totally different world.
- rainbowmverse 9y ago
  10 years is a long time. This was back when I still heard people seriously asking if the internet would last. It was even plausible! Google was only a few years out from its IPO. Few people thought the internet could help elect a president (and I don't mean the current guy). A lot changed in the last ten years. It may not seem like it because most of those changes were refinements on things we already had at the time. We've just been in a long period of revisions. New programming tools, new social networks, new [insert thing we've had since the '90s]. The late '90s and first half of the '00s were full of radical changes, so it seems less significant in context. We're probably on the brink of another radical upheaval like the '90s. There's lots of money flowing around, lots of amazing and well-refined tools, and all the low hanging fruit is more or less captured. No one's getting rich on "x as a service" anymore. People will have to really change something to capture the next huge payday, and the first few will set off a cascade of changed expectations.
devit 9y ago
I wonder whether this scenario is now going to play out in the opposite way, with Google ditching Blink for Servo once Mozilla finishes morphing Gecko into Servo with the Firefox Quantum project. Who would win then? Google's money and marketing power, or Mozilla's independence, trustworthiness and being the renderer's creator?
- fabrice_d 9y ago
  Not sure why this is down voted. I would not be surprised if Google was working on a next-gen browser engine along the same lines as Servo, or even a Servo fork. After all, there is a Rust toolchain for Fuschia...
  - guelo 9y ago
    Google probably couldn't stomach mozilla's open source license which makes it difficult to distribute with proprietary code.
    - asadotzler 9y ago
      Mozilla's open source license was created 20 years ago precisely to make it easier to distribute proprietary bits with open bits. I'm not kidding, that was a primary goal.
toyg 9y ago
At the time this internal skepticism about the future of Gecko was very palpable from outside. Which is why it was infuriating to see Mozilla jumping on every bandwagon they could, eventually ending up with the OS silliness: it really felt like they were trying to run from their own browser and from their own tech, like they were ashamed of not being cool. Thank god they eventually “saw the light” and they’re now back on track.
- fabrice_d 9y ago
  FxOS started in 2011, not 2008. But yeah, that's the usual scapegoat to explain any of Mozilla's issues from the last 5 (or 10?) years. You also totally misunderstand the goal pursued with FxOS, which had nothing to do with "run from their own browser and tech". If anything, the current work to remove XUL and xpcom puts Firefox closer to how FxOS was built, not further away. At the time some employees even build a new desktop browser around the same tech (not the failed Tofino experiment), that was outperforming Firefox because it had a lot of the "new hotness" like e10s and web extensions. Guess what, the desktop team ignored it, only to do the same thing later. Mozilla is not back on track at all, they are still playing catch up on the desktop market which is not growing much and totally irrelevant on mobile. But they have enough money to last years, in a weird way of "to rich to fail".
  - toyg 9y ago
    Please read my comment, before trying to read my mind. I'm telling you what it looked like from the outside. Nobody ever cared for the internal politics of Mozilla; what we saw was a wobbly org that looked anxious to build anything that wasn't their own browser. I didn't say the OS was responsible, nobody cares if FxOS ended up making choices that the browser should have made or whatnot. The problem was not FxOS; FxOS was a symptom of an institution that had lost its way before the OS was even in the picture. > they are still playing catch up on the desktop market It's not the sort of wave you turn in a month. 57 is a big release, give it time. It had a massive surge of good press, which is a good sign. If they can come up with developer tools that can beat Chrome at something, they will see numbers go up. > totally irrelevant on mobile. They are making inroads on Android, which is the only market they will ever play into. iOS will only be cracked open by legal coercion. Anything else is wishful thinking. > But they have enough money to last years Mozilla is not just a company, it's basically a public institution. Their role is to champion a view of the web as an open utility, not to be the most popular widget maker. They don't need bazillions of money to do that.
twic 9y ago
>* There is a huge overhang of security-critical bugs; we have to choose between addressing that and making forward progress. We are putting code-cleanup projects on the back burner for the same reason.* Have they considered rewriting it in R... oh, hang on.
- carussell 9y ago
  When posting dumb comments like this, please consider doing it somewhere else. (Or better, maybe: not at all.)
JepZ 9y ago
Somehow, everybody pretends as if Webkit is some proprietary, closed source rendering engine, but after all, it is the great success of the KDE/Konqueror rendering engine, being adopted by some huge corporations (Apple, Google). [1] While I appreciate that we still have the independent Firefox and its brand new Quantum engine, sometimes I feel like the Konqueror/KHTML team does not receive the appropriate tribute for laying the foundation for the dominant KHTML/Webkit/Blink engine. [1] https://en.wikipedia.org/wiki/WebKit#Origins https://en.wikipedia.org/wiki/WebKit#Origins
- tambourine_man 9y ago
  While I largely agree, a ton of work was done by Apple before Webkit was usable. Most sites would show subtle rendering glitches and it took a while before it matured.
  - lbenes 9y ago
    Not sure why you had issues. In my experience under KDE it was rock solid. It was my primary browser from around 2002 until ~2009. I often tried other browsers and Konqueror led the pack in terms of web conformance and performance.
  - Fnoord 9y ago
    The way I remember it is that KHTML and Mozilla worked perfectly fine if websites followed the real standards instead of MSIE's defacto standard. Which, back in the early '00s, was often not the case.
gcb0 9y ago
it only have optimistic views of google promoting webkit. completely ignores the fact that google effectively took over the project, killing old features it didn't like and preventing any new contribution from making it to main line unless they fit their plan.

163 points by sankha93 9y ago

zaro 9y ago

> the more code engines share, the more de facto standardization of bugs we would see, so having genuinely separate implementations is very important. Well it's not like there aren't any bugs in the specs. And whether there are bugs in the code or the specification, it's the same process for fixing them : politics :)

roca 9y ago
Web developers code to Web browsers, so bugs in Web browsers lead to sites depending on those bugs, making those bugs unfixable unless you have developers testing in multiple browsers. Spec bugs don't become unfixable that way.
- Leszek 9y ago
  Though spec bugs go the opposite way: if you discover an issue in the spec, then it is very difficult to change it because someone somewhere may have been - at the time correctly - relying on that behaviour.
  - peterwwillis 9y ago
    Or, you could just be Google, and change your browser to work the way you want, and ignore all the pages breaking by insisting that the change is "within spec", giving a big middle finger to anyone that complains.
  - roca 9y ago
    Web developers can only rely on a spec bug if the browsers they test with actually implement that bug. So it still comes down to what browsers implement, not what the spec says.
- vbezhenar 9y ago
  It doesn't have to be this way. Apple doesn't have fear of breaking old apps sometimes, for example, and they are successful. I think that absurd backwards compatibility should be considered harmful and some breakage should be normal. It's always possible to install old browser into virtual machine, if content is so precious.
  - tolien 9y ago
    Apple doesn’t have the competitive pressure that I can take my broken iOS app and run it somewhere else as-is, or tell my customers to do that. “It works in Chrome” (and previously IE) is a real issue and the browser that broke compatibility like that would have to be supported (potentially through the coercive power of its own market share - see the initial “any open source browser versus IE is a good thing” switching to “we need multiple browser engines, even if they’re all open source”) by the others or face irrelevance.
jgraham 9y ago
There has been a lot of progress recently on the web-platform-tests project [1]. This is a cross-vendor effort to improve interoperability on the web platform through testing. Historically the process for building web-platform features has been to write a spec and then assume that implementations of the spec would reach compatibility in an ad-hoc manner by patching until sites worked. The big innovation of the last decade — still controversial to some — was the idea that it's OK to adjust the specs themselves when implementations have converged on some other behaviour or when the spec is otherwise wrong. The goal for the future is to use the same engineering discipline that you would use for developing software to developing the platform itself. In particular the objective is: * Every change to a spec that influences browser behaviour must be accompanied by a corresponding test case. * Every change to a browser that affects a cross-platform feature that isn't already adequetely tested must be accompanied by cross-browser test cases. * The results of those tests must be visible to browser vendors in a way that makes it easy to identify the higest value bugfixes (e.g. cases where N-1 browsers agree and one is different, or cases where a spec change makes previously correct behaviour — which may not have shipped yet, but just be enabled on nightly builds or behing a flag — wrong). Apart from the work of actually writing the test, achieving those goals involves a lot of infrastrucutre work to ensure that the cross-browser tests are well integrated into the development cycle of each browser and are able to cover as many scenarios as possible (testing often involves manipulating the browser in a way that is not exposed to normal web content). Despite the large scope of the project, I think it's agreed that modernising the way the platform is developed, and prioritising interoperability at all stages of spec and browser development is essential to avoiding existential threats to the open web in the long term. Certainly Mozilla put a lot of resources into post-hoc fixes for site-compatibility issues, and whilst there will probably always be some bugs that slip through, it will be much more efficient to catch those problems up-front before they ship to end users. I sadly don't have data to backc this up, but I'm pretty sure we're already seeing the effects of this effort, with recent, complex, features shipping with fewer cross-browser issues that we would have predicted five years ago. [1] http://web-platform-tests.org/ http://web-platform-tests.org/
- zaro 9y ago
  Very nice. I haven't heard of these tests before.

foxhill 9y ago

2007-jan-21 hash: ec06b3461cf0eaf3d3e4d7a2e429bddb but then $ curl -s https://raw.githubusercontent.com/rocallahan/blog-archive/master/hashed-blog1.txt | md5 9ba0c5cba20cff553500f034f58d5bb7 hmm. that said, the others check out, so i'm sure it's harmless.

feb 9y ago
Someone said the same thing in the comments. In a reply, the author does not know why the MD5 fails but confirms that the post is correct: I wondered if anyone would check :-). I'm not sure what the problem is with the first post. It's been a long time. You'll have to take my word for it that the first post is the right text :-).
- puzzle 9y ago
  Different encodings for line endings?
  - rzzzt 9y ago
    hashed-blog1.txt contains HTML markup for paragraphs, while all others are in plain text.
    - raverbashing 9y ago
      Taking them out has not resulted in the correct hash, or maybe I forgot something Neither adding a \n to the last line makes it match
      - rzzzt 9y ago
        I also tried it with some line endings :) There might be some other slight changes in formatting which is still missing.

nly 9y ago

Opera made the bet he proposed and lead themselves down a path to irrelevance.

tolien 9y ago
Opera also lost most of their distinctiveness (i.e. features) along the way, laid off the bulk of their developers and sold out to a consortium including Qihoo360 (who, as well as the usual FUD—well-founded or not—about Chinese companies, were simultaneously found to be really bad at being a competent Certificate Authority). There’s plenty of scope for Mozilla to have used WebKit and not done the subsequent parts - Brave’s perhaps as good an example of that as any. Saying that, roc proposes porting XUL and XPCOM which are largely dead these days (the former by virtue of Firefox switching to WebExtensions). With browser.html for Servo being a thing, building Firefox’s UI in a way that it would work in WebKit is more possible than ever.
jasode 9y ago
As one of the few who paid for a web browser (paid $29 for Opera 7 in 2003), it looked to me like Opera really had no choice. There was a post from an Opera insider that I can't find but it was basically this: the web's complexity was evolving faster than the Opera team could maintain their proprietary Presto rendering engine. Switching away from Presto and building on WebKit was a basic matter of survival. Yes, they still became irrelevant but they would have also stayed irrelevant with their Presto engine. I agree with their assessment because around 2009, I started encountering more and more web pages that broke Opera. The Opera forums had more and more complaints from users reporting broken web pages. The Presto engine was becoming a liability. It was a vicious feedback loop because web authors wouldn't bother to test their sites with Opera ... which led to more user frustrations. I had to switch to Chrome to get a usable web surfing experience back. I originally paid for Opera because it had the fastest rendering engine which was very helpful for slow dialup connections. As Presto started falling further behind, that speed advantage was negated. Opera did try to some interesting features such as "Unite" which -- if you squint a certain way -- was a form of p2p decentralization. Yes, it's interesting to have a built-in web server in the browser but not enough people cared about it. The author's predictions for Firefox's Gecko engine meeting the same irrelevant fate as Presto didn't happen because unlike Opera, Mozilla from 2004-2014 got massive funding from Google. Mozilla could afford to keep programmers enhancing the Gecko engine. Opera couldn't do the same with Presto.

frik 9y ago

Jan 21th 2007 [...] Furthermore, there's a wider community relying on Gecko --- embedders, XUL developers, extension authors, Web authors, and their users, who would not be well served if Gecko suddenly nose-dives. [...] They changed their opinion 10 years later.

adius 9y ago

Cool idea to just post the hashes for the future. I think I might do it too on my blog :-)

dr_win 9y ago
Use blockchain :-)
lovemenot 9y ago
Maybe use SHA256 rather than MD5. A few years hence ease of producing MD5 collisions might render moot anything that you had to say.
- torstenvl 9y ago
  I don't think that's necessary. This isn't really a cryptographic use of the hash. Between the legitimate text of the blog entry and whatever arbitrary (likely nonsensical) string produces an MD5 collision, it's going to be pretty obvious which is which.
  - tonyztan 9y ago
    Isn't it feasible to construct two sets of legible texts with the same MD5 hash now?
    - jaaames 9y ago
      Sort of, in PDF form, by inserting invisible images/data crafted to create the collision. I haven't seen a collision demonstration with plain text that could be a practical attack.
    - tialaramex 9y ago
      Legible, maybe, but I don't think you'll be able to collide the hash with natural language, so you will need an excuse as to why the revealed text has weird nonsense in it that is actually there to collide the hash. You can also "see" this, once you suspect it's going on, if you're a cryptanalyst and have the tools to see inside the hash, you can see basically such collisions involving getting the internal state into an awkward place, and then forcing it from there where they want to go, that could happen by accident, but only by truly astronomical bad luck, so it's a pretty good smoking gun. MD5 is a bad idea for situations where a machine will be verifying, because machines aren't good at saying "that's odd...", enhancing them to do so is _way_ more effort than just using SHA-256 instead. But for something like this where a human will be examining things by hand, it's fine. For SHA-1 (which we knew at the time would be broken shortly, and then in practice it was less than a year before Google and some academics announced their full collision) we reviewed special "Exception" SHA-1 SSL issuances by hand on m.d.s.policy after the official deadline for SHA-1 issuance and I asked for one application to be explained or rejected on the basis that the requested certificate had bizarre short gibberish values for "Organizational Unit". The applicant provided an explanation (which was maybe plausible but not up to the standard of transparency needed in the circumstances) but agreed to accept certificates missing the OU value altogether instead. That's the sort of thing you'd catch if a human examines what was hashed rather than a machine. I had no reason to believe that applicant was trying anything sinister, but the point of the manual examinations was to ensure everybody can see there were no shenanigans going on (and to make it a complete pain -- if the process was easy it would have become routine and defeated the purpose of prohibiting new SHA-1 issuance, being annoying was a feature).

jwilk 9y ago

I expected an article about 1990s browser wars. 2007-2008 is not ancient in my book.

dang 9y ago
Ok, we'll take 'ancient' out of the title above.
yjftsjthsd-h 9y ago
It doesn't feel that way, but a decade(!) is a long time in our field.
- loopbit 9y ago
  Still, as someone who lived the browser wars of the 90's, "ancient" is not an adjective I'd use for something that happened only a decade ago. Or put in a different way, if the browser changes in 2007 are "ancient", how would you describe the ones that happened 10 years before that? Prehistoric? Jurassic?
  - bzbarsky 9y ago
    Antediluvian, in the almost literal sense of happening in a totally different world.
rainbowmverse 9y ago
10 years is a long time. This was back when I still heard people seriously asking if the internet would last. It was even plausible! Google was only a few years out from its IPO. Few people thought the internet could help elect a president (and I don't mean the current guy). A lot changed in the last ten years. It may not seem like it because most of those changes were refinements on things we already had at the time. We've just been in a long period of revisions. New programming tools, new social networks, new [insert thing we've had since the '90s]. The late '90s and first half of the '00s were full of radical changes, so it seems less significant in context. We're probably on the brink of another radical upheaval like the '90s. There's lots of money flowing around, lots of amazing and well-refined tools, and all the low hanging fruit is more or less captured. No one's getting rich on "x as a service" anymore. People will have to really change something to capture the next huge payday, and the first few will set off a cascade of changed expectations.

devit 9y ago

I wonder whether this scenario is now going to play out in the opposite way, with Google ditching Blink for Servo once Mozilla finishes morphing Gecko into Servo with the Firefox Quantum project. Who would win then? Google's money and marketing power, or Mozilla's independence, trustworthiness and being the renderer's creator?

fabrice_d 9y ago
Not sure why this is down voted. I would not be surprised if Google was working on a next-gen browser engine along the same lines as Servo, or even a Servo fork. After all, there is a Rust toolchain for Fuschia...
- guelo 9y ago
  Google probably couldn't stomach mozilla's open source license which makes it difficult to distribute with proprietary code.
  - asadotzler 9y ago
    Mozilla's open source license was created 20 years ago precisely to make it easier to distribute proprietary bits with open bits. I'm not kidding, that was a primary goal.

toyg 9y ago

At the time this internal skepticism about the future of Gecko was very palpable from outside. Which is why it was infuriating to see Mozilla jumping on every bandwagon they could, eventually ending up with the OS silliness: it really felt like they were trying to run from their own browser and from their own tech, like they were ashamed of not being cool. Thank god they eventually “saw the light” and they’re now back on track.

fabrice_d 9y ago
FxOS started in 2011, not 2008. But yeah, that's the usual scapegoat to explain any of Mozilla's issues from the last 5 (or 10?) years. You also totally misunderstand the goal pursued with FxOS, which had nothing to do with "run from their own browser and tech". If anything, the current work to remove XUL and xpcom puts Firefox closer to how FxOS was built, not further away. At the time some employees even build a new desktop browser around the same tech (not the failed Tofino experiment), that was outperforming Firefox because it had a lot of the "new hotness" like e10s and web extensions. Guess what, the desktop team ignored it, only to do the same thing later. Mozilla is not back on track at all, they are still playing catch up on the desktop market which is not growing much and totally irrelevant on mobile. But they have enough money to last years, in a weird way of "to rich to fail".
- toyg 9y ago
  Please read my comment, before trying to read my mind. I'm telling you what it looked like from the outside. Nobody ever cared for the internal politics of Mozilla; what we saw was a wobbly org that looked anxious to build anything that wasn't their own browser. I didn't say the OS was responsible, nobody cares if FxOS ended up making choices that the browser should have made or whatnot. The problem was not FxOS; FxOS was a symptom of an institution that had lost its way before the OS was even in the picture. > they are still playing catch up on the desktop market It's not the sort of wave you turn in a month. 57 is a big release, give it time. It had a massive surge of good press, which is a good sign. If they can come up with developer tools that can beat Chrome at something, they will see numbers go up. > totally irrelevant on mobile. They are making inroads on Android, which is the only market they will ever play into. iOS will only be cracked open by legal coercion. Anything else is wishful thinking. > But they have enough money to last years Mozilla is not just a company, it's basically a public institution. Their role is to champion a view of the web as an open utility, not to be the most popular widget maker. They don't need bazillions of money to do that.

twic 9y ago

>* There is a huge overhang of security-critical bugs; we have to choose between addressing that and making forward progress. We are putting code-cleanup projects on the back burner for the same reason.* Have they considered rewriting it in R... oh, hang on.

carussell 9y ago
When posting dumb comments like this, please consider doing it somewhere else. (Or better, maybe: not at all.)

JepZ 9y ago

Somehow, everybody pretends as if Webkit is some proprietary, closed source rendering engine, but after all, it is the great success of the KDE/Konqueror rendering engine, being adopted by some huge corporations (Apple, Google). [1] While I appreciate that we still have the independent Firefox and its brand new Quantum engine, sometimes I feel like the Konqueror/KHTML team does not receive the appropriate tribute for laying the foundation for the dominant KHTML/Webkit/Blink engine. [1] https://en.wikipedia.org/wiki/WebKit#Origins https://en.wikipedia.org/wiki/WebKit#Origins

tambourine_man 9y ago
While I largely agree, a ton of work was done by Apple before Webkit was usable. Most sites would show subtle rendering glitches and it took a while before it matured.
- lbenes 9y ago
  Not sure why you had issues. In my experience under KDE it was rock solid. It was my primary browser from around 2002 until ~2009. I often tried other browsers and Konqueror led the pack in terms of web conformance and performance.
- Fnoord 9y ago
  The way I remember it is that KHTML and Mozilla worked perfectly fine if websites followed the real standards instead of MSIE's defacto standard. Which, back in the early '00s, was often not the case.

gcb0 9y ago

it only have optimistic views of google promoting webkit. completely ignores the fact that google effectively took over the project, killing old features it didn't like and preventing any new contribution from making it to main line unless they fit their plan.