Browser-Wars History: MD5-Hashed Posts Declassified

#1

Post by sankha93 » Sun, Jan 07, 2018, 6:05 AM UTC

Browser-Wars History: MD5-Hashed Posts Declassified
robert.ocallahan.org

Re: Browser-Wars History: MD5-Hashed Posts Declassified

#2

Post by zaro » Sun, Jan 07, 2018, 8:01 AM UTC

> 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 :)

Re: Browser-Wars History: MD5-Hashed Posts Declassified

#3

Post by roca » Sun, Jan 07, 2018, 8:22 AM UTC

zaro wrote: post #2

> 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 :)

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.

Re: Browser-Wars History: MD5-Hashed Posts Declassified

#4

Post by Leszek » Sun, Jan 07, 2018, 8:28 AM UTC

roca wrote: post #3

zaro wrote: post #2

> 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 :)

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.

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.

Re: Browser-Wars History: MD5-Hashed Posts Declassified

#5

Post by peterwwillis » Sun, Jan 07, 2018, 8:50 AM UTC

Leszek wrote: post #4

roca wrote: post #3

Earlier quoted context omitted.

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.

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.

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.

Re: Browser-Wars History: MD5-Hashed Posts Declassified

#6

Post by roca » Sun, Jan 07, 2018, 9:11 AM UTC

Leszek wrote: post #4

roca wrote: post #3

Earlier quoted context omitted.

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.

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.

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.

Re: Browser-Wars History: MD5-Hashed Posts Declassified

#7

Post by foxhill » Sun, Jan 07, 2018, 9:36 AM UTC

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.

Re: Browser-Wars History: MD5-Hashed Posts Declassified

#8

Post by vbezhenar » Sun, Jan 07, 2018, 9:45 AM UTC

roca wrote: post #3

zaro wrote: post #2

> 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 :)

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.

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.

Re: Browser-Wars History: MD5-Hashed Posts Declassified

#9

Post by nly » Sun, Jan 07, 2018, 10:22 AM UTC

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

Re: Browser-Wars History: MD5-Hashed Posts Declassified

#10

Post by frik » Sun, Jan 07, 2018, 10:27 AM UTC

  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.