> a browser that has OCSP or CRL does not need an > update
As long as you're wiling to accept that a DoS of DigiNotar's OCSP server will mean certs remain valid, sure.
Now browsers could treat failure to connect to the OCSP server as fatal, but it turns out lots of CAs run very flaky OCSP server, so if this were done SSL connection failures would be very common. It'd be nice to get to a state where that's not the case, but it hasn't happened yet.
CRLs, of course, have the obvious issue where if you DoS the server the CRL comes from the browser just has no way to know when things are added to the CRL.
> But Mozilla is not distrusting the certificates based > on revocation
Oh, it's distrusting them based on revocation too. But the fact is, revocation is broken in the face of a MITM who can control whether packets reach the OCSP and CRL servers. So an additional explicit check is being added to the software too. Of course if the MITM is blocking browser update downloads as well the users still lose... but at that point maybe they might at least _know_ they have lost, because they realize the browser update is being blocked. Maybe.
> Something should be done that enables control of > this kind of mishaps without having to update the > software.
The only way to do that with the current PKI setup is to have something like OCSP for all certificates, with a hard-fail on failure to connect to the OCSP server. Which is somewhat difficult given the current state of internet infrastructure.
The whole point of this last update to the story is that the Dutch government no longer trusts the DigiNotar intermediate and is revoking it. Browsers are also shipping updates to revoke the DigiNotar intermediate.
So in fact, the Dutch Government website certs are now invalid or will become so very soon in browsers.
Cross-signed certificates exist right now. It's completely standard practice in many cases. In particular when a new CA starts, it often cross-signs all its stuff with existing CAs for a bit so that its customers have working certs even when dealing with clients who have never heard of the new CA.
Yes, this is why browsers are also shipping updates with certs explicitly distrusted.... and why the fact that DigiNotar did not tell browsers about the problem a month and a half ago when it happened is such a huge issue.
> Can someone explain why a.nl organization has the > power to produce.com certs?
To avoid having a monopoly in the CA space?
But yes, having some limits on what CAs are trusted to issue certs of which sites what is a good idea, and I fully expect browsers will move in that direction. I'm certainly pushing for it.
There are at least 4 separate major codebases used for HTML rendering: WebKit, Presto, Trident, Gecko. I have no idea why you think browsers share their HTML rendering code.
In practice, all those codebases take a similar approach: they render HTML using CSS as the styling engine. Turns out it's pretty hard to do anything else while claiming to implement CSS.
dbaron tried to mark it invalid once, but was convince to reopen it.
As for me, I'm not going to touch it with a 10-foot pole. Letting it hang in limbo is a lot less painful for all concerned than dealing with the people who start sending you death threats when you wontfix a pet bug of theirs (and yes, there are lots of those out there).
I don't know about "beyond evil". I agree it seems globally suboptimal, but I don't know the details of the family's financial circumstances, etc.
But my point was that maybe he would have been unhappy with the way the copyright is being used, but maybe he wouldn't be. It does seem like the family has mostly been suing in cases where someoen is in fact making money off the speech.
This test exercises a situation that's very rare on the web (where by "rare" I mean that it's only been encountered in this test to my knowledge): thousands of absolutely positioned elements that are all being moved around using CSS transforms, with each one only being moved once by going from no transform to a translate transform. That's just not something anyone other than this test does. Most people who want to move an absolutely positioned element just change its.top and.left, but this test sort of went out of its way to do things the weird way.
Fixing these has not been a terribly high priority, since it would mostly affect this one synthetic benchmark (I say "mostly", because bug 670311 could have benefits elsewhere too).
I just pointed you to a way that you can ask it for that information and have it tell you. "What information" means "the exact data that is being sent in" (though it's presented in the form of labeled graphs, not JSON or whatever the submission format is).
> Or get on a periodic release schedule and stick to it.
That's exactly what's going on. The release schedule is "one release every 6 weeks". The lag time between 4 and 5 was a bit longer than that because that's when the schedule switch happened.
You're going to have to give up on that 90-day thing, because the releases are coming every 42 days....
Opera Mini is available for i*, which is not really a browser running on the device; it's just an image viewer, with the images generated on the Opera servers. Opera Mobile, which is an actual browser, is not available last I checked.
And yes, if you make a "new browser" by just creating a new UI around the shipped WebKit you can have it on iOS, of course. Whether you consider that a new browser is up to you.
What you're mostly seeing is that Mozilla is not as good at marketing the features they have that WebKit doesn't as Chrome is at marketing the features they have.
Which is not surprising, since Chrome spends a lot more money and effort on marketing than Mozilla does.
There is also the effect where Mozilla tends to value correctness of implementation over breadth of features when it has to choose between the two, whereas WebKit doesn't necessarily prioritize in the same way.
Sure. Vimeo only supports H.264 for its "HTML5" videos. Pick any video there (e.g. http://vimeo.com/5419749 ) then click on the "Switch to HTML5 player" link below the video description (doesn't get shown in Firefox, but does get shown in Chrome). That gives you a element that points to an H.264 video and plays fine in my Chrome on the dev channel.
requestAnimationFrame wasn't lifted from Chrome. App tabs were not lifted from Chrome. Mozilla's audio API wasn't lifted from Chrome (and in fact, once Chrome saw it they scrambled to create their own, incompatible, API). The url bar behavior in Firefox wasn't lifted from Chrome and is, in my opinion, vastly better than Chrome's.
That's just the new features I've encountered recently. Or did you mean by "features" something other than features?
Firefox extensions can do a lot more than Chrome extensions can. That's both a plus (more powerful extensions) and a minus (harder to not break extensions when something changes somewhere in the browser).
Bing would certainly love that. Users may or may not; I suspect that Mozilla wouldn't change the search engine default for that reason. But would not having the Google contract reduce the bar for that switch? Could be. I don't know, and I bet neither does Google nor Mozilla so far. So then the question is how much mitigating that risk is worth to Google.
Slashdot Mirror
> a browser that has OCSP or CRL does not need an
> update
As long as you're wiling to accept that a DoS of DigiNotar's OCSP server will mean certs remain valid, sure.
Now browsers could treat failure to connect to the OCSP server as fatal, but it turns out lots of CAs run very flaky OCSP server, so if this were done SSL connection failures would be very common. It'd be nice to get to a state where that's not the case, but it hasn't happened yet.
CRLs, of course, have the obvious issue where if you DoS the server the CRL comes from the browser just has no way to know when things are added to the CRL.
> But Mozilla is not distrusting the certificates based
> on revocation
Oh, it's distrusting them based on revocation too. But the fact is, revocation is broken in the face of a MITM who can control whether packets reach the OCSP and CRL servers. So an additional explicit check is being added to the software too. Of course if the MITM is blocking browser update downloads as well the users still lose... but at that point maybe they might at least _know_ they have lost, because they realize the browser update is being blocked. Maybe.
> Something should be done that enables control of
> this kind of mishaps without having to update the
> software.
The only way to do that with the current PKI setup is to have something like OCSP for all certificates, with a hard-fail on failure to connect to the OCSP server. Which is somewhat difficult given the current state of internet infrastructure.
What you say is _mostly_ correct.
The whole point of this last update to the story is that the Dutch government no longer trusts the DigiNotar intermediate and is revoking it. Browsers are also shipping updates to revoke the DigiNotar intermediate.
So in fact, the Dutch Government website certs are now invalid or will become so very soon in browsers.
Cross-signed certificates exist right now. It's completely standard practice in many cases. In particular when a new CA starts, it often cross-signs all its stuff with existing CAs for a bit so that its customers have working certs even when dealing with clients who have never heard of the new CA.
Yes, this is why browsers are also shipping updates with certs explicitly distrusted.... and why the fact that DigiNotar did not tell browsers about the problem a month and a half ago when it happened is such a huge issue.
> The same bug to all engines makes me think about
> the same approach and engineering.
Yes. That approach is known as "Implement HTML rendering via a CSS renderer".
A CSS renderer can't render this particular aspect of HTML; there is no way to express it in the CSS model.
You're assuming divergent evolution, but what you're actually seeing is convergent evolution.
> Can someone explain why a .nl organization has the .com certs?
> power to produce
To avoid having a monopoly in the CA space?
But yes, having some limits on what CAs are trusted to issue certs of which sites what is a good idea, and I fully expect browsers will move in that direction. I'm certainly pushing for it.
There are at least 4 separate major codebases used for HTML rendering: WebKit, Presto, Trident, Gecko. I have no idea why you think browsers share their HTML rendering code.
In practice, all those codebases take a similar approach: they render HTML using CSS as the styling engine. Turns out it's pretty hard to do anything else while claiming to implement CSS.
dbaron tried to mark it invalid once, but was convince to reopen it.
As for me, I'm not going to touch it with a 10-foot pole. Letting it hang in limbo is a lot less painful for all concerned than dealing with the people who start sending you death threats when you wontfix a pet bug of theirs (and yes, there are lots of those out there).
> he'd allow it to be viewed for free on a site like
> YouTube?
Or in other words to allow Google to profit off his speech?
Maybe he would. Maybe he wouldn't. Hard to say!
I don't know about "beyond evil". I agree it seems globally suboptimal, but I don't know the details of the family's financial circumstances, etc.
But my point was that maybe he would have been unhappy with the way the copyright is being used, but maybe he wouldn't be. It does seem like the family has mostly been suing in cases where someoen is in fact making money off the speech.
Would he be rolling in his grave? He himself filed suit when the recordings of the speech were being sold...
The problem with that bug is that the HTML 4 requirement in question is not really consistent with the CSS layout model.
So you can have that HTML feature or you can have CSS applying to your HTML, but not both. Your pick. Most people seem to have picked CSS.
13k unconfirmed bug reports.
Almost certainly fewer than 13k bugs in those.
This test exercises a situation that's very rare on the web (where by "rare" I mean that it's only been encountered in this test to my knowledge): thousands of absolutely positioned elements that are all being moved around using CSS transforms, with each one only being moved once by going from no transform to a translate transform. That's just not something anyone other than this test does. Most people who want to move an absolutely positioned element just change its .top and .left, but this test sort of went out of its way to do things the weird way.
The net result is that this test ends up hitting a rare-case O(N^2) codepath in Gecko. See https://bugzilla.mozilla.org/show_bug.cgi?id=641340 and https://bugzilla.mozilla.org/show_bug.cgi?id=641341 and https://bugzilla.mozilla.org/show_bug.cgi?id=670311 for the bugs tracking this on Mozilla's end.
Fixing these has not been a terribly high priority, since it would mostly affect this one synthetic benchmark (I say "mostly", because bug 670311 could have benefits elsewhere too).
I just pointed you to a way that you can ask it for that information and have it tell you. "What information" means "the exact data that is being sent in" (though it's presented in the form of labeled graphs, not JSON or whatever the submission format is).
The telemetry information is opt-in. So nothing is sent unless you _explicitly_ tell Firefox to send it.
If you want to see exactly what information is being gathered, https://addons.mozilla.org/en-US/firefox/addon/abouttelemetry/ will tell you.
> Or get on a periodic release schedule and stick to it.
That's exactly what's going on. The release schedule is "one release every 6 weeks". The lag time between 4 and 5 was a bit longer than that because that's when the schedule switch happened.
You're going to have to give up on that 90-day thing, because the releases are coming every 42 days....
Opera Mini is available for i*, which is not really a browser running on the device; it's just an image viewer, with the images generated on the Opera servers. Opera Mobile, which is an actual browser, is not available last I checked.
And yes, if you make a "new browser" by just creating a new UI around the shipped WebKit you can have it on iOS, of course. Whether you consider that a new browser is up to you.
What you're mostly seeing is that Mozilla is not as good at marketing the features they have that WebKit doesn't as Chrome is at marketing the features they have.
Which is not surprising, since Chrome spends a lot more money and effort on marketing than Mozilla does.
There is also the effect where Mozilla tends to value correctness of implementation over breadth of features when it has to choose between the two, whereas WebKit doesn't necessarily prioritize in the same way.
> So, Apple locks out downloading/running any other
> web browser?
On iOS (which is what the story is explicitly talking about when it says "Apple deveice") that is _exactly_ what Apple does.
Sure. Vimeo only supports H.264 for its "HTML5" videos. Pick any video there (e.g. http://vimeo.com/5419749 ) then click on the "Switch to HTML5 player" link below the video description (doesn't get shown in Firefox, but does get shown in Chrome). That gives you a element that points to an H.264 video and plays fine in my Chrome on the dev channel.
> It's wide open for any browser developer to play with
No, it's not, because it uses WebKit-specific prefixing. Other browsers implementing the same technology would use different prefixes, of course.
Really?
requestAnimationFrame wasn't lifted from Chrome. App tabs were not lifted from Chrome. Mozilla's audio API wasn't lifted from Chrome (and in fact, once Chrome saw it they scrambled to create their own, incompatible, API). The url bar behavior in Firefox wasn't lifted from Chrome and is, in my opinion, vastly better than Chrome's.
That's just the new features I've encountered recently. Or did you mean by "features" something other than features?
Firefox extensions can do a lot more than Chrome extensions can. That's both a plus (more powerful extensions) and a minus (harder to not break extensions when something changes somewhere in the browser).
Bing would certainly love that. Users may or may not; I suspect that Mozilla wouldn't change the search engine default for that reason. But would not having the Google contract reduce the bar for that switch? Could be. I don't know, and I bet neither does Google nor Mozilla so far. So then the question is how much mitigating that risk is worth to Google.