Do you really think that if Google, Microsoft, Apple, and Mozilla all shipped browsers supporting H.264, Google would have decided to remove H.264 support from Chrome after open-sourcing VP8? H.264 would have been the end of the story, and we all would be paying the price.
What is it that makes it so much better than the competition now like it did in the old days?
That's a great question. The marketing people like to say that "Firefox reports to no one but you." It's cheesy, but in practical terms, it means:
We don't send every keystroke you type into the location bar to Google.
When you use Firefox's bookmark / password sync, your data is encrypted so that even Mozilla can't access it. (No, not like Dropbox's "we promise not to look at it" -- the protocol is public, if you want to check its security.)
We don't compromise on our principals. For instance, you'll recall that we were the lone browser which didn't implement H.264, back before WebM. If we'd capitulated, WebM never would have happened, and there'd be no high-quality and free (as in speech or beer, in this case) video codec for the web.
That said, Chrome is a really good browser, and I'll be the first to say that we have plenty of catching up to do, in a number of areas. But there's a difference between being fast and being "stripped-down" -- both Chrome and Firefox support a quickly-growing number of web features, like web workers, WebM, and WebGL.
It's time for someone to make a browser that does nothing but render HTML.
You wouldn't have been able to share this insight on Slashdot in such a browser, you know...
Seriously, I'm looking forward to the day when someone posts a story on Slashdot about a Mozilla project, and everyone doesn't instantly complain that we're doing X or Y instead of making teh awesomest stripped-down browser, which does nothing but send http requests and display unrendered HTML.
In the meantime, Firefox 1.0 is still available for download. I encourage you to try it out if you're dissatisfied with the direction we've taken recently.
To implement this thing correctly is would require that JS have direct access to the file system, which as I understand it, aint fucking supposed to happen
The entire notion of the browser needs to be forked out to an application shell with hard as nails security and a presentation shell and never the twain shall meet.
It will be slower the native x86/ARM code by far, and won't integrate well with the desktop environment.
Does your PDF reader integrate well with the browser environment?
One of the major benefits of rendering PDFs in the browser, aside from the fact that users don't have to download, trust, and run a separate PDF viewer, is that you reduce the security vulnerability surface area. PDFs (well, Adobe Reader) is a major vector for attacks, but that goes away when you sandbox it in the browser.
I think you might also be surprised how fast one can make something like this in JS. Most of the expensive paths, like drawing to the screen, are exported to C++ code.
At the very least, if Mozilla is unable or unwilling to provide security updates for a reasonable length of time then you should avoid placing obstacles in the way of others who want to take on that role (as was done to Debian when they were required to rebrand Firefox as Iceweasel).
What obstacles is Mozilla is placing in the way of a group of people who want to provide LTS versions of Firefox? We've even discussed the possibility of opening up our automated testing infrastructure to such a (hypothetical, at this point) group.
Yes, you might not get to call your LTS of Firefox "Firefox". But it won't be Firefox, it'll be your personal LTS build.
As a Firefox developer, I think there's a story here that's not being told.
Mozilla had the HTML5 history API ready in February 2010, but it wasn't released until a year later, with Firefox 4.
In contrast, Mozilla had CSS animations ready eighteen weeks ago. It was released as part of Firefox 5. This is the power of rapid releases: It means that improvements to the browser and the web platform get into users' hands much more quickly than the would otherwise.
Maybe you don't really care about adding new features to the web platform. You'd be happy just using Lynx. Who cares about all these new features, anyway? You don't want your browser to be able to play webm videos or show 3D graphics. That's just bloat.
And anyway, why should Mozilla be focusing on these features? Half of them get disabled (like Websockets), and the other ones you can't use because IE doesn't support them. And even if IE10 supports them when it's released who knows when, half the web will still be on previous versions of IE.
If you feel that way, it sounds like IE8 is the perfect browser for you. Please give that a try. In the meantime, we're not going to let you hold the web back from what it can be.
It's precisely this kind of pressure, both in terms of new features and improved performance -- rapid release doesn't mean we're focusing only on the former -- that caused Microsoft to take browsers seriously again and release IE9. This was a Big Deal, because now all major browser vendors ship a version which supports things like canvas and mathml. You might even be able to *use* these things on your website sometime in the next century, too; it's just IE6 through 8 that are holding us back.
On the flip side, if you care about Google not winning this set of browser wars, if you care about having a fast browser that isn't made by a data-mining company, you care about Mozilla keeping pace with Google's release cycle. It's hard enough to release a version of Firefox every six weeks which is as good as Chrome today. It's impossible to release a version of Firefox now that will be as good as Chrome is in a year.
If you don't care about any of this stuff, by all means, pick a version of IE and get your security updates for 10 years. Microsoft has the resources and the will to do that kind of thing. Mozilla doesn't.
Hash with a small-ish random salt (say 10 bits) and then forget the salt. Then decrypting requires trying all possible salts until you get a hash match.
If you need to ask this question, you shouldn't be developing a crypto tool. Seriously, don't.
There are a million ways to get something like this wrong. Doing it right requires deep domain knowledge, which it seems you don't have.
(To answer the question, the definition of a secure encryption function E(k, m) is that, when k is random, E(k, m) is indistinguishable from random. If you believe that AES CBC mode is secure, then you believe that an attacker can't distinguish AES-encrypted text from random text.)
Slashdot Mirror
I haven't read up too closely on this, but I think traffic going through Firefox itself is not vulnerable. See http://blog.mozilla.com/security/2011/09/27/attack-against-tls-protected-communications/.
We released 3.6.21 yesterday to remove the Diginotar root cert.
http://blog.mozilla.com/security/2011/08/29/fraudulent-google-com-certificate/
The only thing which seems to happen more often than Firefox releases are posts on Slashdot complaining about them. :)
Yes, many of us do read Slashdot. But believe it or not, we don't base all our decisions on what we see here.
Do you really think that if Google, Microsoft, Apple, and Mozilla all shipped browsers supporting H.264, Google would have decided to remove H.264 support from Chrome after open-sourcing VP8? H.264 would have been the end of the story, and we all would be paying the price.
I think what you'd want to do is start with modern Firefox and strip out things you don't like from the UI. That should be much easier.
That's a great question. The marketing people like to say that "Firefox reports to no one but you." It's cheesy, but in practical terms, it means:
That said, Chrome is a really good browser, and I'll be the first to say that we have plenty of catching up to do, in a number of areas. But there's a difference between being fast and being "stripped-down" -- both Chrome and Firefox support a quickly-growing number of web features, like web workers, WebM, and WebGL.
You wouldn't have been able to share this insight on Slashdot in such a browser, you know...
Seriously, I'm looking forward to the day when someone posts a story on Slashdot about a Mozilla project, and everyone doesn't instantly complain that we're doing X or Y instead of making teh awesomest stripped-down browser, which does nothing but send http requests and display unrendered HTML.
In the meantime, Firefox 1.0 is still available for download. I encourage you to try it out if you're dissatisfied with the direction we've taken recently.
To implement this thing correctly is would require that JS have direct access to the file system, which as I understand it, aint fucking supposed to happen
Too late.
The entire notion of the browser needs to be forked out to an application shell with hard as nails security and a presentation shell and never the twain shall meet.
What a novel idea!
Does your PDF reader integrate well with the browser environment?
One of the major benefits of rendering PDFs in the browser, aside from the fact that users don't have to download, trust, and run a separate PDF viewer, is that you reduce the security vulnerability surface area. PDFs (well, Adobe Reader) is a major vector for attacks, but that goes away when you sandbox it in the browser.
I think you might also be surprised how fast one can make something like this in JS. Most of the expensive paths, like drawing to the screen, are exported to C++ code.
Shaver just published a blog post on this.
(Disclaimer: I work for Mozilla.)
Asa is one guy with strong opinions. He doesn't speak for all of us.
Here's a senior developer disagreeing with Asa, for instance. We're still figuring this out at Mozilla. Asa's is not the red dino's final word.
What obstacles is Mozilla is placing in the way of a group of people who want to provide LTS versions of Firefox? We've even discussed the possibility of opening up our automated testing infrastructure to such a (hypothetical, at this point) group.
Yes, you might not get to call your LTS of Firefox "Firefox". But it won't be Firefox, it'll be your personal LTS build.
As a Firefox developer, I think there's a story here that's not being told.
Mozilla had the HTML5 history API ready in February 2010, but it wasn't released until a year later, with Firefox 4.
In contrast, Mozilla had CSS animations ready eighteen weeks ago. It was released as part of Firefox 5. This is the power of rapid releases: It means that improvements to the browser and the web platform get into users' hands much more quickly than the would otherwise.
Maybe you don't really care about adding new features to the web platform. You'd be happy just using Lynx. Who cares about all these new features, anyway? You don't want your browser to be able to play webm videos or show 3D graphics. That's just bloat.
And anyway, why should Mozilla be focusing on these features? Half of them get disabled (like Websockets), and the other ones you can't use because IE doesn't support them. And even if IE10 supports them when it's released who knows when, half the web will still be on previous versions of IE.
If you feel that way, it sounds like IE8 is the perfect browser for you. Please give that a try. In the meantime, we're not going to let you hold the web back from what it can be.
It's precisely this kind of pressure, both in terms of new features and improved performance -- rapid release doesn't mean we're focusing only on the former -- that caused Microsoft to take browsers seriously again and release IE9. This was a Big Deal, because now all major browser vendors ship a version which supports things like canvas and mathml. You might even be able to *use* these things on your website sometime in the next century, too; it's just IE6 through 8 that are holding us back.
On the flip side, if you care about Google not winning this set of browser wars, if you care about having a fast browser that isn't made by a data-mining company, you care about Mozilla keeping pace with Google's release cycle. It's hard enough to release a version of Firefox every six weeks which is as good as Chrome today. It's impossible to release a version of Firefox now that will be as good as Chrome is in a year.
If you don't care about any of this stuff, by all means, pick a version of IE and get your security updates for 10 years. Microsoft has the resources and the will to do that kind of thing. Mozilla doesn't.
Please let new tabs open alongside the current tab! With a bunch of tabs, it makes navigation between the parent and child tab so much easier.
Try it. It does this!
You don't want a salt -- you want a pepper!
Hash with a small-ish random salt (say 10 bits) and then forget the salt. Then decrypting requires trying all possible salts until you get a hash match.
If you need to ask this question, you shouldn't be developing a crypto tool. Seriously, don't.
There are a million ways to get something like this wrong. Doing it right requires deep domain knowledge, which it seems you don't have.
(To answer the question, the definition of a secure encryption function E(k, m) is that, when k is random, E(k, m) is indistinguishable from random. If you believe that AES CBC mode is secure, then you believe that an attacker can't distinguish AES-encrypted text from random text.)