> when your threat model is somebody with the ability to intercept network traffic, but not > modify it
Unauthenticated implies that you have no assurance that the other end is who you mean to be talking to. Your threat model is assuming that DNS is not lying to you and that the IP address maps to the right entity; in that case you're actually assuming (out of band) authentication.
> And if an encrypted but unauthenticated and a non-encrypted connection are equally > insecure, then why does firefox complain about the former and not the latter?
Because the former shows security indicators that users have been trained to look for: "https" in the url bar and a lock icon. It's been argued that the browser should just not show those and treat these connections as unencrypted, but the counterargument is that in the case of a MITM against a site the user expects to be encrypted it's better to alert the user than downgrade to unencrypted.
> However, the status quo isn't exactly a bed of roses.
Oh, absolutely agreed.
> Granted, I can make some allowance for devices that don't have sufficient CPU to > perform AES
Given that there are hardware AES implementations, and that the cost is coming down, I'm not even sure that we should make those allowances a few years out. I agree that having everything encrypted by default would be quite nice.
> Mozilla and friends aren't going to do the SSH style thing
There's a small problem with doing that in the PKI world: PKI certs, unlike SSH keys, have expiration dates. It's pretty common to have certs that are only valid for a year, renewed yearly. The problem is that "renewal" is just the issuing of a different cert for the same entity.
It's as if the SSH key of every server changed every year. Users would just learn to click through the "something changed" warning and move right on with their stuff.
There are several fun things going into the performance difference there. The three main ones I know of are:
1) MSVC++ happens to generate faster (and smaller) code than g++ does. This is especially noticeable when turning on profile-guided optimization. That gave a 10% speedup across the board on Windows, and basically nothing on Linux. It seems that the g++ profile-guided optimizer could use a lot of work. 2) Certain parts of the OS that are of critical importance to web browser performance are faster on Windows at this point (Uniscribe vs Pango and whatever GDI vs X are the two main comparisons here). It doesn't help that moving to cairo means that a lot of operations are delegated to the X server, via RENDER. In theory this means that they can be executed efficiently on the graphics hardware, but in practice it means they use the same software codepaths that the browser could have used itself. In fact RENDER uses the same pixman library that cairo uses for its own software fallback, except recent cairo versions use a much newer and faster pixman. And while it's possible to ship a cutting-edge cairo with the browser and get the faster pixman for client-side use even if your system cairo is older and slower, I don't think you want your browser making changes to your Xorg install.;) 3) Some of the system APIs on Windows are a little easier to use efficiently than equivalent ones on Linux. Font selection on Linux, apparently, did get a good bit faster an memory efficient between Firefox 3 and the current Firefox 3.1 beta. But this took a good bit of analysis of exactly how fontconfig works and how to work around some of what it does.
> An "independent" life eh? Lets take it out of the woman and see how long it survives.
Actually, this is getting into very interesting territory.
The earliest premature baby who survived (and in fact is about 20 years old right now and doing fine) was born at less than 22 weeks gestation. He's not an isolated case. And premature babies born at 24 weeks (so over 3 months premature) nowadays have about 50% survival rates. I can assure you that this rate is significantly higher than it was 20 years ago.
So as time passes (and we're talking a "several decades" timeframe here) the age at which a fetus can be removed from a woman and have a good shot at surviving to adulthood will creep down.
The limiting point, of couse, is being able to go from an in vitro fertilization to adulthood (a "uterine replicator", let's call the setup). I'd suspect that's 50+ years off, at least (gut feeling; no data to back this up).
So at the point at which we have uterine replicators would you still be in favor of abortions? If yes, why? If not, why not?
At the point at which a 6-week-old fetus can be carefully removed from the uterus and have a 50+% survival chance, would you still be in favor of abortions after 6 weeks?
Note that I'm not talking about current law here; I'm talking about what the law should be at that point.
I should note that the poster you replied to actually laid out the quite serious ethical issues involved fairly clearly, and you proceeded to knee-jerk, call him names, claim that his worldview is "idiotic" (whereas it's simply much more nuanced and thoughtful than yours appears to be), and put in some thoughtless political jibes which not only stereotype poorly but also ignore what the poster actually said.
I'm willing to take the time to try and expand your worldview outside of the political platform of minority segments of certain political parties, but I'd appreciate a slightly higher level of discourse than what you've shown so far.
Really? A 3-year-old Core Duo (don't recall the clock speed, but in the 1.5-2 GHz range) is about 10x faster than a P3-733 on cpu-bound (small amount of memory accessed, no disk access) code. That's single-threaded code, so only using one core. 2-3x of that is the clock speed, the rest is the better architecture and process. 3-5x performance gain at the same clock speed is pretty good, in my book.
You're right that whole-system performance has not kept pace with that, but it never does.
While true, you do want to keep performance in mind when designing your _architecture_. If your program is algorithmically slow, or if it requires a virtual function call for any operation, then all profiling will show is time spent all over the map, because literally everything is slow.
1) There is no pledge to not support d-o-e. Please read my other comment in this thread. 2) I'm not saying we want to remove XSLT. Please do go read what I actually said, and what
it was a response to. I think you're overstating the XSLT case, but I certainly agree
that it's a very useful technology in many situations. 3) Patches for d-o-e support accepted, as I said in the other comment. But it's not a high
priority to spend time on compared to a number of other issues that have much broader
impact. If it's a high priority for someone, then they can take action on it, of course.
1) There are no locking primitives exposed to JavaScript. It is not possible to busy-wait
in JavaScript (the browser will put up the slow script dialog). So at no point can a
"deadlock" occur that causes you to have to kill your browser session. 2) One can already "deadlock" a web app in the sense of parts of it waiting on each
other. No threads needed for this; it can be done with timeouts on a single thread. 3) Web workers exposes a message-passing, shared-nothing, messages delivered via the
event loop concurrency model. There is no way to tell from the web page whether the
worker threads are implemented as separate OS-level threads, or separate user-level
threads, or OS-level processes, or simply via time-slicing on a single interpreter
thread. Of course some of these implementations do a better job of utilizing modern
multi-core processors than others do.
People _have_ spent a good bit of time thinking about how to expose this stuff to web javascript without unduly complicating the programming model.
Just to make it clear, we'd like to add support for disable-output-escaping. It's not like the bug is marked wontfix or invalid or anything. However it needs to be done in such a way that there is no performance impact for stylesheets that don't use it, it needs to be done in a way that doesn't cause security holes due to script executing during the reparse, and it's a low priority.
If someone really wants this and implements within the above constraints (and the usual code review rules), we'll take the patch. The source _is_ open last I checked.
> for values of "small minority" that are actually the "large majority"
Honestly, the bug volume doesn't support that claim.
> can you describe to me why firefox caved on innerHTML?
Sure. There was a very large fraction of websites using it, and it offered significant authoring benefits over the clumsy DOM API (ease of use, and more importantly vastly better performance).
Note that not all of those considerations apply to disable-output-escaping. In particular, it would degrade performance, and its actual usage on the web is minuscule. Heck, client-side XSLT usage in general is minuscule.
> what was that you were saying about significantly slowing down the process by inserting > extra steps?
Hey, if you're the one who wants extra steps to happen and you pay the performance cost... that's ok. If you want everyone else to pay performance costs for things you want and they don't, then some careful thinking about tradeoffs needs to happen.
> seriously, do you know what people do with fucking browsers? what kind of content is > transferred?
Yeah. I actually do. They browse HTML, and XSLT is not involved. To a first approximation, of course. We could remove our XSLT support tomorrow, and fewer pages would break than broke when we stopped allowing them to read the full filepath from a file input....
I'm saying that XSLT transforms a DOM into a DOM. To get the behavior you want you'd then have to serialize that DOM. The parsing afterwards is not that much of a problem, of course.
That said, the whole point is that it would significantly slow down the process by inserting extra steps for all XSLT users, to benefit the small minority who want disable-output-escaping. That hasn't seemed like a good tradeoff in the past, and still doesn't now.
I think you pretty much completely misunderstood the FAQ. Right now XSLT in Firefox transforms one DOM into another. There is no output happening, so no output escaping relevant.
What you want is to transform one DOM into another, then serialize the second DOM, without escaping things, then reparse it into a third DOM, different from the second DOM (because you put things like '' in your text nodes and asked for them to not be escaped).
That's a fine desire, but it adds a lot of complications and the use cases really just aren't that compelling.
Now in XSLT engines that have to create text anyway (e.g. IE, because the XML DOM and the browser DOM are completely different things implemented by different applications in that case, and are totally incompatible, so the output of the XML library _has_ to get serialized), there is no additional price to pay for supporting disable-output-escaping on top of their _existing_ serialization mechanism. So they do.
> no transmission of entered URLs/searches to third parties
For URLs this is the case by default. For searches, set browser.search.suggest.enabled to false (though effectively the default setting sends your partial search to the same search engine your final search will go to, iirc; whether you want that is up to you).
> no "auto-complete" with www. and.com/.net
I assume you still want your "http://" tossed in front? If so, set browser.fixup.alternate.enabled to false. You probably also want keyword.enabled set to false too. If you want to always type your protocol by hand, that will take more work; there's no pref for that. You can do it with an extension that replaces the URI fixup service, of course.
> and any of that bullshit that has become accepted nowadays?
If that's a non-rhetorical question, then it's hard to answer without more details.
It's really your call whether you want to use a browser that's not getting security updates, especially when a newer one _is_ available and supported (through your existing support contract, event!).
You might want to point out the security issues here to corporate IT (which is sounding like it's being boneheaded to me).
Distros were planning to ship Firefox 3 on their supported long-life products (e.g. RedHat on RHEL). They'll probably have to statically link with a newer GTK2 and so forth, but they're doing it.
If your complaint is that you're using a distro that doesn't do long-term support in a situation where you need long-term support.... then I'm not quite sure what to tell you.
I don't see a big difference in mathematical content between "if you start with this state, and perform these transformations you will have this other state" and "if you start with this state, and perform some transformations, then you will have this other state".
Those are descriptions of classical and quantum algorithms, basically.
Now the only question is how to translate the final state into "the answer". In the case of classical algorithms the translation is usually very simple. In the quantum case, the final state is a probability distribution, and "the answer" is the mean of the distribution.
That's if you're talking about the computer science aspect of the whole thing. If you're talking about actually building a computer, that's a different story, and you need to worry about your distribution's standard deviation, etc, but let's not mistake that for the theory part.
I should note that there is a long tradition of probabilistic algorithms in classical computer science, by the way.
I should also note that probability theory is generally considered "pure math".
Of course any quantum computing algorithm (including Shor's) has the same issue.
In practice, once the probability of the answer being incorrect is smaller than some threshold (e.g. the probability of the classical computer giving a wrong answer due to cosmic rays) it really doesn't matter that you're using a probabilistic algorithm.
Add-ons (extensions) have to come from a site that's trusted.
By default the only trusted site for that purpose is addons.mozilla.org. Any attempt to install an add-on from another site will show an infobar explaining that the site is asking to install software on your computer and asking whether you trust them to do this. If you say yes, and click the button _again_, you will be prompted (dialog, not infobar, with a timer so you can't click OK for at least 5 seconds after the dialog appears) whether to install the add-on.
That said, installing an add-on just means putting it in a particular place on disk. So if something else can write to your disk, it can install add-ons. Of course it could also overwrite the Firefox binary with a custom-compiled one that has a Trojan built in, so once something is writing to your disk you just lose.
Since the JS can also just change the form action to evil.com and submit the form, there's not much mileage here.
The file control sends the file but NOT the file path to the server. There are proposals to allow JS access to the file content of the selected file (but still not the path).
Basically, anything JS can send to the server might as well be available to the JS directly.
Note that part of the problem here is that as far as anyone can tell OS X 10.3.x is no longer supported by Apple in terms of security fixes.... so the unsecured browser might be the least of your problems.:(
Actually, in a lot of cases it's more than twice as much work (when the Fx 3 fix depends on a whole bunch of changes so that lots of stuff has to be backported or a more complicated fix has to be done on the Fx 2 branch).
Slashdot Mirror
> when your threat model is somebody with the ability to intercept network traffic, but not
> modify it
Unauthenticated implies that you have no assurance that the other end is who you mean to be talking to. Your threat model is assuming that DNS is not lying to you and that the IP address maps to the right entity; in that case you're actually assuming (out of band) authentication.
> And if an encrypted but unauthenticated and a non-encrypted connection are equally
> insecure, then why does firefox complain about the former and not the latter?
Because the former shows security indicators that users have been trained to look for: "https" in the url bar and a lock icon. It's been argued that the browser should just not show those and treat these connections as unencrypted, but the counterargument is that in the case of a MITM against a site the user expects to be encrypted it's better to alert the user than downgrade to unencrypted.
> However, the status quo isn't exactly a bed of roses.
Oh, absolutely agreed.
> Granted, I can make some allowance for devices that don't have sufficient CPU to
> perform AES
Given that there are hardware AES implementations, and that the cost is coming down, I'm not even sure that we should make those allowances a few years out. I agree that having everything encrypted by default would be quite nice.
How is "encryption if you don't know who you're talking to" better than "no encryption at all" for the typical web browser, exactly?
Heck, I can't think of any cases where I'd think it's more secure, even outside web browsing. Care to mention one?
> Mozilla and friends aren't going to do the SSH style thing
There's a small problem with doing that in the PKI world: PKI certs, unlike SSH keys, have expiration dates. It's pretty common to have certs that are only valid for a year, renewed yearly. The problem is that "renewal" is just the issuing of a different cert for the same entity.
It's as if the SSH key of every server changed every year. Users would just learn to click through the "something changed" warning and move right on with their stuff.
There are several fun things going into the performance difference there. The three main ones I know of are:
1) MSVC++ happens to generate faster (and smaller) code than g++ does. This is especially noticeable when turning on profile-guided optimization. That gave a 10% speedup across the board on Windows, and basically nothing on Linux. It seems that the g++ profile-guided optimizer could use a lot of work. ;)
2) Certain parts of the OS that are of critical importance to web browser performance are faster on Windows at this point (Uniscribe vs Pango and whatever GDI vs X are the two main comparisons here). It doesn't help that moving to cairo means that a lot of operations are delegated to the X server, via RENDER. In theory this means that they can be executed efficiently on the graphics hardware, but in practice it means they use the same software codepaths that the browser could have used itself. In fact RENDER uses the same pixman library that cairo uses for its own software fallback, except recent cairo versions use a much newer and faster pixman. And while it's possible to ship a cutting-edge cairo with the browser and get the faster pixman for client-side use even if your system cairo is older and slower, I don't think you want your browser making changes to your Xorg install.
3) Some of the system APIs on Windows are a little easier to use efficiently than equivalent ones on Linux. Font selection on Linux, apparently, did get a good bit faster an memory efficient between Firefox 3 and the current Firefox 3.1 beta. But this took a good bit of analysis of exactly how fontconfig works and how to work around some of what it does.
> An "independent" life eh? Lets take it out of the woman and see how long it survives.
Actually, this is getting into very interesting territory.
The earliest premature baby who survived (and in fact is about 20 years old right now and doing fine) was born at less than 22 weeks gestation. He's not an isolated case. And premature babies born at 24 weeks (so over 3 months premature) nowadays have about 50% survival rates. I can assure you that this rate is significantly higher than it was 20 years ago.
So as time passes (and we're talking a "several decades" timeframe here) the age at which a fetus can be removed from a woman and have a good shot at surviving to adulthood will creep down.
The limiting point, of couse, is being able to go from an in vitro fertilization to adulthood (a "uterine replicator", let's call the setup). I'd suspect that's 50+ years off, at least (gut feeling; no data to back this up).
So at the point at which we have uterine replicators would you still be in favor of abortions? If yes, why? If not, why not?
At the point at which a 6-week-old fetus can be carefully removed from the uterus and have a 50+% survival chance, would you still be in favor of abortions after 6 weeks?
Note that I'm not talking about current law here; I'm talking about what the law should be at that point.
I should note that the poster you replied to actually laid out the quite serious ethical issues involved fairly clearly, and you proceeded to knee-jerk, call him names, claim that his worldview is "idiotic" (whereas it's simply much more nuanced and thoughtful than yours appears to be), and put in some thoughtless political jibes which not only stereotype poorly but also ignore what the poster actually said.
I'm willing to take the time to try and expand your worldview outside of the political platform of minority segments of certain political parties, but I'd appreciate a slightly higher level of discourse than what you've shown so far.
Really? A 3-year-old Core Duo (don't recall the clock speed, but in the 1.5-2 GHz range) is about 10x faster than a P3-733 on cpu-bound (small amount of memory accessed, no disk access) code. That's single-threaded code, so only using one core. 2-3x of that is the clock speed, the rest is the better architecture and process. 3-5x performance gain at the same clock speed is pretty good, in my book.
You're right that whole-system performance has not kept pace with that, but it never does.
While true, you do want to keep performance in mind when designing your _architecture_. If your program is algorithmically slow, or if it requires a virtual function call for any operation, then all profiling will show is time spent all over the map, because literally everything is slow.
1) There is no pledge to not support d-o-e. Please read my other comment in this thread.
2) I'm not saying we want to remove XSLT. Please do go read what I actually said, and what
it was a response to. I think you're overstating the XSLT case, but I certainly agree
that it's a very useful technology in many situations.
3) Patches for d-o-e support accepted, as I said in the other comment. But it's not a high
priority to spend time on compared to a number of other issues that have much broader
impact. If it's a high priority for someone, then they can take action on it, of course.
Some things need to be cleared up here:
1) There are no locking primitives exposed to JavaScript. It is not possible to busy-wait
in JavaScript (the browser will put up the slow script dialog). So at no point can a
"deadlock" occur that causes you to have to kill your browser session.
2) One can already "deadlock" a web app in the sense of parts of it waiting on each
other. No threads needed for this; it can be done with timeouts on a single thread.
3) Web workers exposes a message-passing, shared-nothing, messages delivered via the
event loop concurrency model. There is no way to tell from the web page whether the
worker threads are implemented as separate OS-level threads, or separate user-level
threads, or OS-level processes, or simply via time-slicing on a single interpreter
thread. Of course some of these implementations do a better job of utilizing modern
multi-core processors than others do.
People _have_ spent a good bit of time thinking about how to expose this stuff to web javascript without unduly complicating the programming model.
I believe the private browsing mode does delete downloads from the download manager (though not from your disk, of course).
Just to make it clear, we'd like to add support for disable-output-escaping. It's not like the bug is marked wontfix or invalid or anything. However it needs to be done in such a way that there is no performance impact for stylesheets that don't use it, it needs to be done in a way that doesn't cause security holes due to script executing during the reparse, and it's a low priority.
If someone really wants this and implements within the above constraints (and the usual code review rules), we'll take the patch. The source _is_ open last I checked.
> for values of "small minority" that are actually the "large majority"
Honestly, the bug volume doesn't support that claim.
> can you describe to me why firefox caved on innerHTML?
Sure. There was a very large fraction of websites using it, and it offered significant authoring benefits over the clumsy DOM API (ease of use, and more importantly vastly better performance).
Note that not all of those considerations apply to disable-output-escaping. In particular, it would degrade performance, and its actual usage on the web is minuscule. Heck, client-side XSLT usage in general is minuscule.
> what was that you were saying about significantly slowing down the process by inserting
> extra steps?
Hey, if you're the one who wants extra steps to happen and you pay the performance cost... that's ok. If you want everyone else to pay performance costs for things you want and they don't, then some careful thinking about tradeoffs needs to happen.
> seriously, do you know what people do with fucking browsers? what kind of content is
> transferred?
Yeah. I actually do. They browse HTML, and XSLT is not involved. To a first approximation, of course. We could remove our XSLT support tomorrow, and fewer pages would break than broke when we stopped allowing them to read the full filepath from a file input....
I'm saying that XSLT transforms a DOM into a DOM. To get the behavior you want you'd then have to serialize that DOM. The parsing afterwards is not that much of a problem, of course.
That said, the whole point is that it would significantly slow down the process by inserting extra steps for all XSLT users, to benefit the small minority who want disable-output-escaping. That hasn't seemed like a good tradeoff in the past, and still doesn't now.
I think you pretty much completely misunderstood the FAQ. Right now XSLT in Firefox transforms one DOM into another. There is no output happening, so no output escaping relevant.
What you want is to transform one DOM into another, then serialize the second DOM, without escaping things, then reparse it into a third DOM, different from the second DOM (because you put things like '' in your text nodes and asked for them to not be escaped).
That's a fine desire, but it adds a lot of complications and the use cases really just aren't that compelling.
Now in XSLT engines that have to create text anyway (e.g. IE, because the XML DOM and the browser DOM are completely different things implemented by different applications in that case, and are totally incompatible, so the output of the XML library _has_ to get serialized), there is no additional price to pay for supporting disable-output-escaping on top of their _existing_ serialization mechanism. So they do.
> no transmission of entered URLs/searches to third parties
For URLs this is the case by default. For searches, set browser.search.suggest.enabled to false (though effectively the default setting sends your partial search to the same search engine your final search will go to, iirc; whether you want that is up to you).
> no "auto-complete" with www. and .com/.net
I assume you still want your "http://" tossed in front? If so, set browser.fixup.alternate.enabled to false. You probably also want keyword.enabled set to false too. If you want to always type your protocol by hand, that will take more work; there's no pref for that. You can do it with an extension that replaces the URI fixup service, of course.
> and any of that bullshit that has become accepted nowadays?
If that's a non-rhetorical question, then it's hard to answer without more details.
Honestly, given that your OS is not getting security updates I guess you don't need to worry much about your browser getting them....
It's really your call whether you want to use a browser that's not getting security updates, especially when a newer one _is_ available and supported (through your existing support contract, event!).
You might want to point out the security issues here to corporate IT (which is sounding like it's being boneheaded to me).
For what it's worth, some distros are in fact still maintaining Firefox 1.5 (and even 1.0). So yes, they could maintain Firefox 2.
They could also just ship Firefox 3 (statically linked against a newer GTK2 if needed), of course.
Distros were planning to ship Firefox 3 on their supported long-life products (e.g. RedHat on RHEL). They'll probably have to statically link with a newer GTK2 and so forth, but they're doing it.
If your complaint is that you're using a distro that doesn't do long-term support in a situation where you need long-term support.... then I'm not quite sure what to tell you.
I don't see a big difference in mathematical content between "if you start with this state, and perform these transformations you will have this other state" and "if you start with this state, and perform some transformations, then you will have this other state".
Those are descriptions of classical and quantum algorithms, basically.
Now the only question is how to translate the final state into "the answer". In the case of classical algorithms the translation is usually very simple. In the quantum case, the final state is a probability distribution, and "the answer" is the mean of the distribution.
That's if you're talking about the computer science aspect of the whole thing. If you're talking about actually building a computer, that's a different story, and you need to worry about your distribution's standard deviation, etc, but let's not mistake that for the theory part.
I should note that there is a long tradition of probabilistic algorithms in classical computer science, by the way.
I should also note that probability theory is generally considered "pure math".
Of course any quantum computing algorithm (including Shor's) has the same issue.
In practice, once the probability of the answer being incorrect is smaller than some threshold (e.g. the probability of the classical computer giving a wrong answer due to cosmic rays) it really doesn't matter that you're using a probabilistic algorithm.
Add-ons (extensions) have to come from a site that's trusted.
By default the only trusted site for that purpose is addons.mozilla.org. Any attempt to install an add-on from another site will show an infobar explaining that the site is asking to install software on your computer and asking whether you trust them to do this. If you say yes, and click the button _again_, you will be prompted (dialog, not infobar, with a timer so you can't click OK for at least 5 seconds after the dialog appears) whether to install the add-on.
That said, installing an add-on just means putting it in a particular place on disk. So if something else can write to your disk, it can install add-ons. Of course it could also overwrite the Firefox binary with a custom-compiled one that has a Trojan built in, so once something is writing to your disk you just lose.
Since the JS can also just change the form action to evil.com and submit the form, there's not much mileage here.
The file control sends the file but NOT the file path to the server. There are proposals to allow JS access to the file content of the selected file (but still not the path).
Basically, anything JS can send to the server might as well be available to the JS directly.
Note that part of the problem here is that as far as anyone can tell OS X 10.3.x is no longer supported by Apple in terms of security fixes.... so the unsecured browser might be the least of your problems. :(
Actually, in a lot of cases it's more than twice as much work (when the Fx 3 fix depends on a whole bunch of changes so that lots of stuff has to be backported or a more complicated fix has to be done on the Fx 2 branch).