For what it's worth tracemonkey is about the same speed as unoptimized C on integer math at this point. The difference is register allocation (which tracemonkey doesn't do yet).
Moving to more complicated examples, things get more interesting. Since the jit has full runtime information, it can do optimizations that a AOT compiler cannot do. At the same time, the lack of a type system does hurt, as you point out. At the moment, tracemonkey handles this by doing type inference and then if it turns out to be wrong (e.g. the type changes) bailing out and falling back on the interpreter. Turns out, types don't change much.
The real issue for a real-world Javascript program is that most of them touch the DOM too, not just execute JS. And right now tracemonkey doesn't speed that up at all. In fact, it can't jit parts of the code that touch the DOM. Eventually the hope is to add that ability.
> We can't guarantee you are sending the credit card information to who you think you are.
That's false, though. There are situations where we can certainly guarantee it at the level at which it's guaranteed in a brick-and-mortar store. Self-signed certificates just aren't such a situation.
I admit that it's nice to have the view that people shouldn't be using the Internet for anything money-related, and if they do they're just ignorant morons. It's simple and consistent. It's not very useful, though, unlike the view that it would be good to make it usable for money-related things, and that if the Internet needs to change to support that then it should.
> I think simply not displaying the padlock would be a better option
It was considered, actually. Interestingly, people seemed even more vocally opposed to that than to the current setup.
> Nonsense, you can go out an get a cert that is poorly or not at all verified today > for about $15.
Not verified that you actually have to do with the domain the cert is being issued for? Which CA, pray tell me? Sounds like some CAs need to be removed from the default CA list.
> Self-signed certs do provide an encrypted connection, so they > should provide an encryption indicator.
Only if the user cares about encryption but not whether they're talking to who they think they're talking to. Can't think of such situations offhand, to be honest.
> When you visit an unencrypted page in firefox for the first time, > it brings up a notification telling you as much.
Uh.. not last I checked, no. That would be most pages users visit, and I can assure you that Firefox does NOT bring up notifications every time you hit a site you haven't been to before.
> Whether the encryption used is strong and secure is a technical matter > that joe blow is not capable of determining.
We agree on something!
> The website's identity not being verified is not a technical matter at all
Sure it is. Try talking to an actual Joe Blow sometime... I think you underestimate how much technical knowledge and understanding of the CA/certificate/SSL setup goes into even asking the question, "Is this website's identity verified?"
Just curious... which side of the wide gap do you think the two things lie on?
> we know that the bar is low enough with authenticated certs that they don't provide trust > either
They provide trust that the entity you are talking to is the legal owner of the domain name listed in the cert. Any CA that doesn't guarantee that shouldn't be in the default CA lists of browsers (and Mozilla in particular requires that from the CAs it includes).
That's simply false as far as UI goes. Heck, IE had 90+% market share, yet other browsers didn't exactly blindly copy IE's UI decisions.
If your issue is that other UAs might tighten up their security without adding free CAs, that's a concern for sure, but there's nothing Firefox can do to bring it about or prevent it.
We're specifically talking about Firefox in this whole article, so the only recognition that would matter is whether Firefox recognizes it. In other browsers you'll certainly be no worse off than a self-signed cert.
As far as I can tell, it's never asked to be included (e.g. it's not present on the "pending review" list of CAs on mozilla.org). Being included does involve some time investment on the part of the CA, since the browser maker wants to verify that the CA does in fact perform domain verification, etc. So maybe they just haven't gotten around to finding the time to do this.
> First, some authority that signs for free for anyone that can demonstrate DNS-control > should get their key included
This is already the case.
> Second, we need two security-icons rather than one. One for encrypted or not. One for > identified or not.
There start to be serious issues with user confusion here. It's taken about a decade to sort of get people looking at the lock icon. Sometimes.
Dealing with security UI for people who don't know much about security is really hard. Of course the same is true if you replace "security" with just about anything else...
> But a self-signed cert is better than no cert so there certainly shouldn't be more > stringent notifications than there are for completely unencrypted pages.
This would be fine if self-signed certs also didn't show any encryption indicators. But people want to see those for some reason... Then you have to make it clear that they're not quite the same as the encrypted pages one is used to.
They're free to ask to be included (which includes an audit that verifies that they in fact verify domain ownership). The process does take a little bit of time on everyone's part, of course.
For someone who understands the issues, "encrypted + trusted > encrypted > nothing".
For someone who just looks for the lock icon, treating "encrypted" like "encrypted + trusted" makes it a phish magnet. So you certainly can't do that. Your options are either to not show the lock icon or to make it clear that something is up in this special case.
Put another way, for most users, given their trust and threat models, unencrypted connections _are_ safer, since they don't trust them. Or they do, but then they're just screwed no matter what.
> by demonstrating their (hijacked) control of the domain
Hijacking a connection just means replying to the user's request. No control of the domain required. And CAs that don't verify domain control properly don't end up in UA trusted CA lists.
> and requiring website owners to always sign up and be approved before they can use the > HTTPS protocal on a public website
No one is requiring anything of the sort. Do read Johnathan's blog post linked above.
While fair enough, that also means that if there's a bug that affects your site it might not get reported and fixed... I see no reason to spend hours making your site work in the browser, but if you're willing to take a few minutes to test with the beta and report issues you run into, that would be much appreciated.
I agree that there's not much point doing that in an alpha unless you kind of like playing with shiny new stuff.
For what it's worth, on Mac and Linux installing two different Firefox versions side by side is easy. On Windows, you can do it if you install in a different directory from the installer, I think. I haven't checked recently.
The difference is the speed. The idea is that toolkits like jquery can use querySelectorAll under to hood to speed up their query implementations.
Just to put this in perspective, here are the numbers for three toolkits and the native implementations in a build more or less equivalent to the alpha on http://webkit.org/perf/slickspeed/ :
All times in milliseconds. The more complex the query, the bigger the lead querySelectorAll has, generally speaking. For example, for the "div div div" selector, it's about 36 times faster than the fastest of the toolkits, and about 200 times faster than the slowest one.
> I don't need to read checkin logs to see that Squirelfish is fast
Indeed. But that's changing the subject from the original topic here (which is the effect of the browsers on each other over the last several months of development). That effect was that both were pushing each other to become faster. Squirrelfish is just the latest entry in this continuing competition, not the end of it, nor the beginning.;)
I suggest taking a look at the commit history of both Gecko and Webkit in the last year or so where JS perf is concerned.
You'll find that they've basically been pushing each other, in almost perfect alternation: one checks in a patch that makes it faster, the other responds with changes that make it faster, etc.
How much data is transferred per month if one is doing active development using a distributed version control system like Mercurial on a 4 GB repository? I'm pretty sure that one can easily be pushing around a lot more than 5 gigs a month in such a setup (probably even just uploading, depending on exact collaboartion patterns).;)
But even ignoring that sort of thing, which doesn't apply to most people anyway, if you really want to do reasonable streaming video, a single layer DVD (not HD, regular DVD) holds 4.7GB of data. So if you watch 2 movies a week (and plenty of people do), that should easily add up to 2 * 4 * 3 = 24 GB per month. All download, of course. It would be interesting to see what a reasonable download bandwidth would be for a few HD movies a week, and what the corresponding upload bandwidth needs to be to send all the ACKs.
I think it's a safe bet that HD streaming video can happen in the next 10 years if the bandwidth consumers have allows it.
Slashdot Mirror
For what it's worth tracemonkey is about the same speed as unoptimized C on integer math at this point. The difference is register allocation (which tracemonkey doesn't do yet).
Moving to more complicated examples, things get more interesting. Since the jit has full runtime information, it can do optimizations that a AOT compiler cannot do. At the same time, the lack of a type system does hurt, as you point out. At the moment, tracemonkey handles this by doing type inference and then if it turns out to be wrong (e.g. the type changes) bailing out and falling back on the interpreter. Turns out, types don't change much.
The real issue for a real-world Javascript program is that most of them touch the DOM too, not just execute JS. And right now tracemonkey doesn't speed that up at all. In fact, it can't jit parts of the code that touch the DOM. Eventually the hope is to add that ability.
> We can't guarantee you are sending the credit card information to who you think you are.
That's false, though. There are situations where we can certainly guarantee it at the level at which it's guaranteed in a brick-and-mortar store. Self-signed certificates just aren't such a situation.
I admit that it's nice to have the view that people shouldn't be using the Internet for anything money-related, and if they do they're just ignorant morons. It's simple and consistent. It's not very useful, though, unlike the view that it would be good to make it usable for money-related things, and that if the Internet needs to change to support that then it should.
> I think simply not displaying the padlock would be a better option
It was considered, actually. Interestingly, people seemed even more vocally opposed to that than to the current setup.
> Nonsense, you can go out an get a cert that is poorly or not at all verified today
> for about $15.
Not verified that you actually have to do with the domain the cert is being issued for? Which CA, pray tell me? Sounds like some CAs need to be removed from the default CA list.
> Self-signed certs do provide an encrypted connection, so they
> should provide an encryption indicator.
Only if the user cares about encryption but not whether they're talking to who they think they're talking to. Can't think of such situations offhand, to be honest.
> When you visit an unencrypted page in firefox for the first time,
> it brings up a notification telling you as much.
Uh.. not last I checked, no. That would be most pages users visit, and I can assure you that Firefox does NOT bring up notifications every time you hit a site you haven't been to before.
> Whether the encryption used is strong and secure is a technical matter
> that joe blow is not capable of determining.
We agree on something!
> The website's identity not being verified is not a technical matter at all
Sure it is. Try talking to an actual Joe Blow sometime... I think you underestimate how much technical knowledge and understanding of the CA/certificate/SSL setup goes into even asking the question, "Is this website's identity verified?"
Just curious... which side of the wide gap do you think the two things lie on?
> we know that the bar is low enough with authenticated certs that they don't provide trust
> either
They provide trust that the entity you are talking to is the legal owner of the domain name listed in the cert. Any CA that doesn't guarantee that shouldn't be in the default CA lists of browsers (and Mozilla in particular requires that from the CAs it includes).
That may be the case, but neither do they have any particular desire to copy Firefox UI.
That's simply false as far as UI goes. Heck, IE had 90+% market share, yet other browsers didn't exactly blindly copy IE's UI decisions.
If your issue is that other UAs might tighten up their security without adding free CAs, that's a concern for sure, but there's nothing Firefox can do to bring it about or prevent it.
We're specifically talking about Firefox in this whole article, so the only recognition that would matter is whether Firefox recognizes it. In other browsers you'll certainly be no worse off than a self-signed cert.
> rather than pay yearly fees to a 'certified' vendor
There are CAs that offer up certs for free.
> the big problem is that Firefox hasn't imported CACert root certificate in it's trusted
> database yet.
Of course CACert hasn't asked to be imported and hasn't provided the information that would be needed to import them...
As far as I can tell, it's never asked to be included (e.g. it's not present on the "pending review" list of CAs on mozilla.org). Being included does involve some time investment on the part of the CA, since the browser maker wants to verify that the CA does in fact perform domain verification, etc. So maybe they just haven't gotten around to finding the time to do this.
> So, it makes little sense to make self-signed https:/// look MORE scary that http:///
It makes all the sense in the world if users are conditioned to just look for the https:/// and assume everything is fine.
> First, some authority that signs for free for anyone that can demonstrate DNS-control
> should get their key included
This is already the case.
> Second, we need two security-icons rather than one. One for encrypted or not. One for
> identified or not.
There start to be serious issues with user confusion here. It's taken about a decade to sort of get people looking at the lock icon. Sometimes.
Dealing with security UI for people who don't know much about security is really hard. Of course the same is true if you replace "security" with just about anything else...
> But a self-signed cert is better than no cert so there certainly shouldn't be more
> stringent notifications than there are for completely unencrypted pages.
This would be fine if self-signed certs also didn't show any encryption indicators. But people want to see those for some reason... Then you have to make it clear that they're not quite the same as the encrypted pages one is used to.
> open and free ca like https://www.openca.org/
They're free to ask to be included (which includes an audit that verifies that they in fact verify domain ownership). The process does take a little bit of time on everyone's part, of course.
For someone who understands the issues, "encrypted + trusted > encrypted > nothing".
For someone who just looks for the lock icon, treating "encrypted" like "encrypted + trusted" makes it a phish magnet. So you certainly can't do that. Your options are either to not show the lock icon or to make it clear that something is up in this special case.
Put another way, for most users, given their trust and threat models, unencrypted connections _are_ safer, since they don't trust them. Or they do, but then they're just screwed no matter what.
> Snooping a connection is a hell of a lot easier and more common than hijacking one
I suggest you give http://blog.johnath.com/2008/08/05/ssl-question-corner/ a read. And heck, that's not even including wireless access point operators, who can hijack whatever connections they want.
> by demonstrating their (hijacked) control of the domain
Hijacking a connection just means replying to the user's request. No control of the domain required. And CAs that don't verify domain control properly don't end up in UA trusted CA lists.
> and requiring website owners to always sign up and be approved before they can use the
> HTTPS protocal on a public website
No one is requiring anything of the sort. Do read Johnathan's blog post linked above.
While fair enough, that also means that if there's a bug that affects your site it might not get reported and fixed... I see no reason to spend hours making your site work in the browser, but if you're willing to take a few minutes to test with the beta and report issues you run into, that would be much appreciated.
I agree that there's not much point doing that in an alpha unless you kind of like playing with shiny new stuff.
For what it's worth, on Mac and Linux installing two different Firefox versions side by side is easy. On Windows, you can do it if you install in a different directory from the installer, I think. I haven't checked recently.
The difference is the speed. The idea is that toolkits like jquery can use querySelectorAll under to hood to speed up their query implementations.
Just to put this in perspective, here are the numbers for three toolkits and the native implementations in a build more or less equivalent to the alpha on http://webkit.org/perf/slickspeed/ :
prototype 1.6.0.2: 16310
jQuery 1.2.3: 36201
ext 2.0: 23310
querySelectorAll: 716
All times in milliseconds. The more complex the query, the bigger the lead querySelectorAll has, generally speaking. For example, for the "div div div" selector, it's about 36 times faster than the fastest of the toolkits, and about 200 times faster than the slowest one.
Have you filed a bug?
There's a good chance that's a bug in either Firefox, cairo, or your X server. Hard to say which without a testcase, though.
Um... -moz-box-shadow support is in this alpha, for what it's worth.
> I don't need to read checkin logs to see that Squirelfish is fast
Indeed. But that's changing the subject from the original topic here (which is the effect of the browsers on each other over the last several months of development). That effect was that both were pushing each other to become faster. Squirrelfish is just the latest entry in this continuing competition, not the end of it, nor the beginning. ;)
I suggest taking a look at the commit history of both Gecko and Webkit in the last year or so where JS perf is concerned.
You'll find that they've basically been pushing each other, in almost perfect alternation: one checks in a patch that makes it faster, the other responds with changes that make it faster, etc.
Seriously, go read the checkin logs.
How much data is transferred per month if one is doing active development using a distributed version control system like Mercurial on a 4 GB repository? I'm pretty sure that one can easily be pushing around a lot more than 5 gigs a month in such a setup (probably even just uploading, depending on exact collaboartion patterns). ;)
But even ignoring that sort of thing, which doesn't apply to most people anyway, if you really want to do reasonable streaming video, a single layer DVD (not HD, regular DVD) holds 4.7GB of data. So if you watch 2 movies a week (and plenty of people do), that should easily add up to 2 * 4 * 3 = 24 GB per month. All download, of course. It would be interesting to see what a reasonable download bandwidth would be for a few HD movies a week, and what the corresponding upload bandwidth needs to be to send all the ACKs.
I think it's a safe bet that HD streaming video can happen in the next 10 years if the bandwidth consumers have allows it.
The record was for the number of manually initiated downloads.