...permanently owns all content related to your social networking a la facebook...
And everyone else...
This is pretty obviously done because no social networking site wants:
a) Every money grabbing moron suing them for redistributing the valuable IP contained in their "LOL BRB, Taking a dump" status line.
b) Dealing with making sure every piece of random garbage which is attached to every other piece of random garbage is removed when you cancel your account.
This could be averted with an irrevocable (and non-exclusive) license to redistribute the content within certain terms. They don't need to own it.
If no system calls are present in the code, there can be no output...
Well, technically there can be. E.g., you could write to mmap()ed memory. But it was poorly phrased anyway. The point is that you'd require the code to call special safe functions that would in turn make system calls after carefully validating their input. It might be possible to break out of the sandbox, but only if the safe functions (or the validity checking) are buggy. There is absolutely no reason in principle why this must be breakable, let alone by a 14-year-old.
It's very similar to virtual machines. Client operating systems on a VM host cannot break out of the jail and take over the real hardware, even though they're running machine code. The sandboxing makes sure that no bad code runs, rewriting if necessary. The approach taken here is somewhat different, because it requires a recompile, so it can make the sandboxing much simpler (refuse to run instead of rewriting, and very harsh restrictions to make it easier to validate).
We're talking about something that's got to be turring-complete in the end, gets evaluated before hand, turned loose to run directly on the processor. I can break that sandbox. A 14 year old could break that sandbox. There is no magically unsafe instruction.
"Turing-complete" means "capable of performing any computation", not "capable of having malicious side-effects". Turing-completeness has nothing to do with exploitability. It doesn't matter whether you're Turing-complete: if no system calls are present in the code, you can do absolutely nothing to the system.
Not to knock Google's approach, for it does seem (from what I've read so far) well-thought out. What I am wondering, though, is what advantage they are seeking in choosing directly-native code over something like Java or.NET. If I recall, most modern Java metrics show it performing competitively with native code.
The very first paragraph of TFA mentions features like "instruction set extensions such as SSE, and use of compiler intrinsics and hand-coded assembler". They're talking about where you want serious performance. Maybe computer games, for instance.
NaCl is also probably going to end up more secure than Java. It's not implementing a whole programming language, after all. From the article:
Our validator implementation requires less than 500 C statements (semicolons), including an x86 decoder and cpuid decoding. This compiles into about 6000 bytes of executable code (Linux optimized build) of which about 900 bytes are the cpuid implementation, 1700 bytes the decoder, and 3400 bytes the validator logic.
No way is Java or whatever going to be as secure as such a tiny application.
If machine code is allowed, you also aren't forced to use Java. I mean, it's an okay language, but it's not everyone's favorite. If you have some application already written in C++ and suddenly decide you want it to be runnable from a browser environment . . . now you can, without having to rewrite the whole thing in Java. You can use any library from any language provided it can be compiled to machine code. Etc. Patching a compiler to support NaCl is very simple, according to the paper.
Of course, forcing everyone to use x86 is a pain, but honestly, it doesn't look likely at this point that we're all suddenly going to move to a different architecture. Allowing websites to run native-speed executables clearly fits in with Google's goal of making web applications superior to native ones.
16GB? Are you mad? Anything beyond 1GB should be enough to handle 1000 unique visitors per day. If you want to virtualize the system and have a separate web- and database server, 2GB should be enough already, if you ant to go further and have a separate virtual mail server in there, 2GB is still sufficient and 3GB is plenty.
My site gets 50,000 visits a day (>100 req/s peak) and I do just fine on a single server with 16 GB of RAM. And that's probably more than I really need -- I could make do with 8 GB, and less if my application (vBulletin) were more scalable.
Every time I find myself on a Windows box using any other browser I wish I could expand text boxes (like the one I'm typing in now) to be able to see my whole comment. It's been years now.
You mean "any other browser but Chrome"? That's a WebKit feature, and works perfectly fine in Chrome last I checked.
I know that, if I ever have to hire an IT manager my first question will be "which browser do you use". Anything that begin with an I, and I'll just say "next!"
Until that day, the alternative to assuming IE exists on every machine is every program even remotely related to the internets writing their own browser.
It's not like there are any LGPL rendering engines available for HTML they could just link in for free on all platforms, right? Oh, wait . ..
OK if that's the case how does this sidestep fees (see what I'm replying to)?
Are you so sure it's all going to be done for free?
Isn't this more likely to happen:
. (root) signs.org and.com etc and charges them $$$$$$$/year.com charges $$/year per domain to sign cnn.com, ebay.com, google.com.org charges $$/year per domain to sign slashdot.org, kernel.org etc
All possible in principle, but whether it happens in practice depends on who does the signing. The scenario you describe could perfectly well happen right now with DNS. The root registrar (ICANN) could charge an exorbitant sum of money to be the.com registrar, maybe selling it to the highest bidder with no strings attached; and then the.com registrar (VeriSign or whoever) could charge $1000/year for all.com domain names. But this hasn't, in fact, happened. If the root certifier for DNSSEC is ICANN, which seems as likely as anything (if there will be a root certifier at all), there's no reason they'll be any more exploitative for certificates than for DNS generally.
DNS and IP assignments have always been the only really centralized parts of the Internet. Despite that, they've always worked pretty well. Prices are reasonable and probably not too far above cost. You have stuff like VeriSign's Site Finder, but ICANN et al. shut that down pretty quickly, and would likely shut down anything else that's clearly corporate abuse on the part of a root (non-national) registrar. It's a success story for corporate contracting.
the White House was occupied by the stupidest man to ever serve as President
Do you have any concrete evidence to back up this assertion? I'm pretty sure a lot of past presidents have been characterized as idiots by their political opponents. On the other hand, while you might not have to be a genius to get a BA from Yale and an MBA from Harvard, I'd imagine it would be fairly hard if you're genuinely stupid.
I understand why we didn't start with SSL as the default 15 years ago, but we could fix that now.
Computational costs for SSL are apparently not trivial, from what I've been told. Moreover, any kind of encryption completely kills caching proxies, which are essential to performance for a lot of large sites. Wikipedia uses Squids that can serve 3000 req/s per server easily on cache hits. The reason they can do this is because once the cache entry is located, it's simply a matter of instructing the OS to copy a string of bytes from a memory address to a network port and close the connection. There's no way you could achieve that level of performance if you had to negotiate SSL keys and encrypt the response.
One solution to the caching problem would be to permit authentication only, with no encryption (like DNSSEC itself, in fact). Then the authenticated response could be served just as efficiently as the unauthenticated response, except that it's somewhat longer. But there's no way to do this at present: SSL permits either both authentication and encryption, or neither.
"This theoretically enables the domain owner to publish his SSL certificate as a DNS record, sidestepping the whole SSL certificate authority hierarchy and the associated fees"
In that case if someone does an MITM (or other) attack, how do you know the published SSL cert in a DNS record is really the genuine cert?
Same way you know that a cert is genuine in SSL: a chain of trust. The browser will come hardcoded with a handful of root certs. Any certificate that's not signed (directly or indirectly) by a root certificate will be ignored. Only a very limited number of parties, perhaps domain name registrars, would be able to sign functional certificates. Therefore you can't forge a DNSSEC certificate unless you can compromise one of these small number of keyholders, which is likely to be difficult, and which can be mitigated by expiration/revocation if it does happen.
There are a couple solutions to the incentive problem:
Make users pay CAs to validate websites: this puts the economic incentives in the right place, but users will resent paying for what used to be "free". Personally, though, I'd subscribe to an enhanced validation service.
Change CAs into non-profits: the problem with this approach is that funding would then have to come from the government or some other organization. Can you imagine "PayPal, stop accepting payments for contraceptives or we'll revoke your certificate, you liberal hippies"?
I wish I could come up with better ideas.
Why don't you have the site's key certified by the registrar where it registered its domain name? They don't have to do any validation at all: they know you're the one who owns the domain, because they just sold it to you! If someone can get access to the registrar's web interface for controlling your domain names, they can point them to other servers anyway, so any further validation is superfluous.
The registrar is in a uniquely good position to validate your identity. They can do it for free, in fact. And there are no perverse incentives here: if they allow someone else to get a certificate for your domain, you're going to rightfully be extremely ticked off at them, and may move to another registrar.
As a final bonus, since validating your identity would be free, competition would likely force many big-name registrars to give away basic certificates for free. Then every site can use SSL, not just the ones that can afford certificate costs, resulting in a more secure web.
Putting the public key (no certificate required at all) in a DNSSEC entry would also be a good solution. Again, zero extra validation required, and no extra cost.
I'd like to see that as well, but for that to happen you need to provide a way for low risk and not for profit sites to get certificates that are accepted by browsers but without the fees. I've set up my email (Webmail, IMAP and SMTP) with SSL certificates, but it took some searching to find someone who would give me a free SSL certificate and even then the issuer isn't in most browser's approved list. I'm protecting a small amount of traffic from lazy eavesdroppers, not protecting a financial institution - I don't need the expense and the insurance.
I never understood why the chain of trust isn't just the same as the chain of domain name registration. There is one trusted authority that definitely knows that I own the domain name in question: the registrar I bought it from. In turn, the registrar for the TLD definitely knows that the registrar for my domain name is legit. And ICANN knows who the TLD registrars are.
So why don't we have one root certificate -- ICANN's. ICANN can then sign all the certificates of all the registrars it knows about, and those can sign those they know about, and so on. Finally, when you buy a domain name, your registrar can sign your private keys over the same web interface you used to buy the domain.
All of this can be covered by the fees that are already charged at every step along the way. Most of the bottom-level registrars are going to charge a fee for certificates commensurate with their costs, i.e., $0, because of competition. Everyone wins except the existing entrenched root authorities. What's the downside?
The Internet is used by billions of people. How do you propose to educate all of them? Even if you could, the technology changes on a year-to-year basis. Several years ago, IDN-based attacks weren't possible. Now the major browsers support IDNs, so suddenly you have a new attack avenue opening up.
Heck, look at non-computerized stuff. Tons of security advice is given out on a continuous basis, and people routinely ignore it. Do you report all the unattended bags that you see? I don't, even though I'm told to continually by the subway loudspeakers. Security advice that's a nuisance will be ignored.
The only real, working, full solution is going to be a technical one. It may require re-architecting the web or the Internet, but the problem is not impossible to solve technically. You have to make sure that there is no possible way for the user to submit any unencrypted info or receive any unsigned response from a sensitive website, that's all.
One way to do this, for instance, would be to get rid of HTTP altogether and use only HTTPS or some variant. Difficult and expensive? Sure. Impossible? Hardly. There are probably lesser measures that would work as well.
For now, of course, user education might be a good idea. But user education is never going to solve the problem, only mitigate it.
I have a technical solution, but it won't be popular: browsers should display a warning when submitting a form on an unencrypted page to an encrypted URL. Since web designers are afraid warnings will spook users, they'll switch to making the form-entry pages encrypted as well.
Or they'll say "your web browser sucks, use a better one". And the user quite possibly will, especially if the browser to implement the feature isn't MSIE. Browsers cannot afford to annoy their users more than the competition does.
We don't need an alternative to SSL. We need browsers to implement proper UI. The user MUST be made aware if clicking a button would transmit a password in cleartext. The user MUST be made aware exactly which domain they are connected to during an SSL session. On a large busy screen, a tiny bit of text in a corner is the wrong way to do this.
And yet we don't live in Imaginary-Land where users and administrators make careful decisions all the time. If you pop up a box every time users submit their credentials in plaintext, users will completely ignore the box. Period.
For real security on the general Internet, you need a solution that always work, without user knowledge.
A possible solution could be to present Windows users with a so-called "ballot screen" from which they would choose their browser.
Alternatively, it could be left up to computer or mobile phone manufacturers, such as Dell or Nokia, which support Microsoft Windows by default, to provide users with different browsers, in agreement with Microsoft.
Note the second paragraph. That sounds to me like a perfectly plausible outcome of the decision is that Microsoft is just forced to not pressure OEMs on what browser to offer. If the OEMs decide to keep offering IE as the default, that would be their decision. If Google or Opera wants to pay them to bundle their browser instead, they could do that.
The.secure TLD doesn't sound like a terrible idea, but wouldn't it be easier to approach this from the browser? We could accommodate the the keyboard-averse by having some gui element for "secure" urls, that would behave differently than the normal url bar, i.e. prepend "https://" instead of "http://". On the server side, no more responding to http. Instead show a static page telling the user how to access the site properly.
So you're requiring users to remember which sites they access are secure or not? Users will just use a different browser if they have to click an extra button every blasted time they want to go to Gmail or whatever (but not 95% of the other sites they use!). That much annoyance to users is probably just not worth the slight gain in security, in the same way that a highway speed limit of 30 MPH is not worth the lives it would save. Any good solution needs to add no noticeable burden to users' normal web browsing.
If they "would like it to be" secure all they would have to do is spend more money on their infrastructure to encrypt everything.
Wrong. User types "paypal.com" into their URL bar. Browser sends a request for http://paypal.com./ PayPal might automatically redirect to HTTPS (in fact it does, when I try it), but by then it's too late. A MITM can have already served up the fake page as HTTP, and few users will notice the difference.
What's needed is some way for the browser to know in advance that it should not accept any unencrypted traffic from the domain name. The only way I can see to do this is to encode that information in the domain name itself, for instance with a new.secure TLD. The only information available to the browser without going to the network is the domain name, so it seems like this is the only place to store "don't do stuff unencrypted" info.
I kind of agree with you about having something in DNS to tell the client that it must use SSL. When I read through the Powerpoint, I was wondering about using TXT records, or SRV records or some other type of DNS records to tell the client that it must connect using SSL.
You're talking about a situation where the attacker is in a MITM position. If they can intercept and rewrite HTTP traffic, they can intercept and rewrite DNS traffic too. A new TLD would solve this problem quite cleverly, although of course it brings its own problems.
...when articles are tagged with the dreaded "primary sources" tag? In case you're not familiar with this tag, it basically states that the integrity of an article is in question because there are not enough cites from secondary sources (no, not a typo) as opposed to primary sources!
Wrong. Wikipedia permits primary sources, and you can find them all over the place. What it does not permit is original research. You need to publish your work elsewhere before it can be cited on Wikipedia.
Slashdot Mirror
And everyone else...
This is pretty obviously done because no social networking site wants:
a) Every money grabbing moron suing them for redistributing the valuable IP contained in their "LOL BRB, Taking a dump" status line. b) Dealing with making sure every piece of random garbage which is attached to every other piece of random garbage is removed when you cancel your account.
This could be averted with an irrevocable (and non-exclusive) license to redistribute the content within certain terms. They don't need to own it.
If you really had one you would be using Lynx or HyperLink. So STFU and GTFO.
lynx on a Commodore 64?
$ wc -c < /usr/bin/lynx
1274912
The Commodore 64 had 64 KB of RAM. The lynx binary on my machine is 20 times that size.
(Yes, yes, I fail at previewing before posting.)
If you really had one you would be using Lynx or HyperLink. So STFU and GTFO.
lynx on a Commodore 64?
$ wc -c
The Commodore 64 had 64 KB of RAM. The lynx binary on my machine is 20 times that size.
If no system calls are present in the code, there can be no output...
Well, technically there can be. E.g., you could write to mmap()ed memory. But it was poorly phrased anyway. The point is that you'd require the code to call special safe functions that would in turn make system calls after carefully validating their input. It might be possible to break out of the sandbox, but only if the safe functions (or the validity checking) are buggy. There is absolutely no reason in principle why this must be breakable, let alone by a 14-year-old.
It's very similar to virtual machines. Client operating systems on a VM host cannot break out of the jail and take over the real hardware, even though they're running machine code. The sandboxing makes sure that no bad code runs, rewriting if necessary. The approach taken here is somewhat different, because it requires a recompile, so it can make the sandboxing much simpler (refuse to run instead of rewriting, and very harsh restrictions to make it easier to validate).
We're talking about something that's got to be turring-complete in the end, gets evaluated before hand, turned loose to run directly on the processor. I can break that sandbox. A 14 year old could break that sandbox. There is no magically unsafe instruction.
"Turing-complete" means "capable of performing any computation", not "capable of having malicious side-effects". Turing-completeness has nothing to do with exploitability. It doesn't matter whether you're Turing-complete: if no system calls are present in the code, you can do absolutely nothing to the system.
Not to knock Google's approach, for it does seem (from what I've read so far) well-thought out. What I am wondering, though, is what advantage they are seeking in choosing directly-native code over something like Java or .NET. If I recall, most modern Java metrics show it performing competitively with native code.
The very first paragraph of TFA mentions features like "instruction set extensions such as SSE, and use of compiler intrinsics and hand-coded assembler". They're talking about where you want serious performance. Maybe computer games, for instance.
NaCl is also probably going to end up more secure than Java. It's not implementing a whole programming language, after all. From the article:
Our validator implementation requires less than 500 C statements (semicolons), including an x86 decoder and cpuid decoding. This compiles into about 6000 bytes of executable code (Linux optimized build) of which about 900 bytes are the cpuid implementation, 1700 bytes the decoder, and 3400 bytes the validator logic.
No way is Java or whatever going to be as secure as such a tiny application.
If machine code is allowed, you also aren't forced to use Java. I mean, it's an okay language, but it's not everyone's favorite. If you have some application already written in C++ and suddenly decide you want it to be runnable from a browser environment . . . now you can, without having to rewrite the whole thing in Java. You can use any library from any language provided it can be compiled to machine code. Etc. Patching a compiler to support NaCl is very simple, according to the paper.
Of course, forcing everyone to use x86 is a pain, but honestly, it doesn't look likely at this point that we're all suddenly going to move to a different architecture. Allowing websites to run native-speed executables clearly fits in with Google's goal of making web applications superior to native ones.
16GB? Are you mad? Anything beyond 1GB should be enough to handle 1000 unique visitors per day. If you want to virtualize the system and have a separate web- and database server, 2GB should be enough already, if you ant to go further and have a separate virtual mail server in there, 2GB is still sufficient and 3GB is plenty.
My site gets 50,000 visits a day (>100 req/s peak) and I do just fine on a single server with 16 GB of RAM. And that's probably more than I really need -- I could make do with 8 GB, and less if my application (vBulletin) were more scalable.
Every time I find myself on a Windows box using any other browser I wish I could expand text boxes (like the one I'm typing in now) to be able to see my whole comment. It's been years now.
You mean "any other browser but Chrome"? That's a WebKit feature, and works perfectly fine in Chrome last I checked.
What do you have against iCab?!
Make that a Capital I :P
What do you have against Iceweasel?!
I know that, if I ever have to hire an IT manager my first question will be "which browser do you use". Anything that begin with an I, and I'll just say "next!"
What do you have against iCab?!
Until that day, the alternative to assuming IE exists on every machine is every program even remotely related to the internets writing their own browser.
It's not like there are any LGPL rendering engines available for HTML they could just link in for free on all platforms, right? Oh, wait . . .
OK if that's the case how does this sidestep fees (see what I'm replying to)?
Are you so sure it's all going to be done for free?
Isn't this more likely to happen:
. (root) signs .org and .com etc and charges them $$$$$$$/year .com charges $$/year per domain to sign cnn.com, ebay.com, google.com .org charges $$/year per domain to sign slashdot.org, kernel.org etc
All possible in principle, but whether it happens in practice depends on who does the signing. The scenario you describe could perfectly well happen right now with DNS. The root registrar (ICANN) could charge an exorbitant sum of money to be the .com registrar, maybe selling it to the highest bidder with no strings attached; and then the .com registrar (VeriSign or whoever) could charge $1000/year for all .com domain names. But this hasn't, in fact, happened. If the root certifier for DNSSEC is ICANN, which seems as likely as anything (if there will be a root certifier at all), there's no reason they'll be any more exploitative for certificates than for DNS generally.
DNS and IP assignments have always been the only really centralized parts of the Internet. Despite that, they've always worked pretty well. Prices are reasonable and probably not too far above cost. You have stuff like VeriSign's Site Finder, but ICANN et al. shut that down pretty quickly, and would likely shut down anything else that's clearly corporate abuse on the part of a root (non-national) registrar. It's a success story for corporate contracting.
the White House was occupied by the stupidest man to ever serve as President
Do you have any concrete evidence to back up this assertion? I'm pretty sure a lot of past presidents have been characterized as idiots by their political opponents. On the other hand, while you might not have to be a genius to get a BA from Yale and an MBA from Harvard, I'd imagine it would be fairly hard if you're genuinely stupid.
I understand why we didn't start with SSL as the default 15 years ago, but we could fix that now.
Computational costs for SSL are apparently not trivial, from what I've been told. Moreover, any kind of encryption completely kills caching proxies, which are essential to performance for a lot of large sites. Wikipedia uses Squids that can serve 3000 req/s per server easily on cache hits. The reason they can do this is because once the cache entry is located, it's simply a matter of instructing the OS to copy a string of bytes from a memory address to a network port and close the connection. There's no way you could achieve that level of performance if you had to negotiate SSL keys and encrypt the response.
One solution to the caching problem would be to permit authentication only, with no encryption (like DNSSEC itself, in fact). Then the authenticated response could be served just as efficiently as the unauthenticated response, except that it's somewhat longer. But there's no way to do this at present: SSL permits either both authentication and encryption, or neither.
"This theoretically enables the domain owner to publish his SSL certificate as a DNS record, sidestepping the whole SSL certificate authority hierarchy and the associated fees"
In that case if someone does an MITM (or other) attack, how do you know the published SSL cert in a DNS record is really the genuine cert?
Same way you know that a cert is genuine in SSL: a chain of trust. The browser will come hardcoded with a handful of root certs. Any certificate that's not signed (directly or indirectly) by a root certificate will be ignored. Only a very limited number of parties, perhaps domain name registrars, would be able to sign functional certificates. Therefore you can't forge a DNSSEC certificate unless you can compromise one of these small number of keyholders, which is likely to be difficult, and which can be mitigated by expiration/revocation if it does happen.
There are a couple solutions to the incentive problem:
I wish I could come up with better ideas.
Why don't you have the site's key certified by the registrar where it registered its domain name? They don't have to do any validation at all: they know you're the one who owns the domain, because they just sold it to you! If someone can get access to the registrar's web interface for controlling your domain names, they can point them to other servers anyway, so any further validation is superfluous.
The registrar is in a uniquely good position to validate your identity. They can do it for free, in fact. And there are no perverse incentives here: if they allow someone else to get a certificate for your domain, you're going to rightfully be extremely ticked off at them, and may move to another registrar.
As a final bonus, since validating your identity would be free, competition would likely force many big-name registrars to give away basic certificates for free. Then every site can use SSL, not just the ones that can afford certificate costs, resulting in a more secure web.
Putting the public key (no certificate required at all) in a DNSSEC entry would also be a good solution. Again, zero extra validation required, and no extra cost.
I'd like to see that as well, but for that to happen you need to provide a way for low risk and not for profit sites to get certificates that are accepted by browsers but without the fees. I've set up my email (Webmail, IMAP and SMTP) with SSL certificates, but it took some searching to find someone who would give me a free SSL certificate and even then the issuer isn't in most browser's approved list. I'm protecting a small amount of traffic from lazy eavesdroppers, not protecting a financial institution - I don't need the expense and the insurance.
I never understood why the chain of trust isn't just the same as the chain of domain name registration. There is one trusted authority that definitely knows that I own the domain name in question: the registrar I bought it from. In turn, the registrar for the TLD definitely knows that the registrar for my domain name is legit. And ICANN knows who the TLD registrars are.
So why don't we have one root certificate -- ICANN's. ICANN can then sign all the certificates of all the registrars it knows about, and those can sign those they know about, and so on. Finally, when you buy a domain name, your registrar can sign your private keys over the same web interface you used to buy the domain.
All of this can be covered by the fees that are already charged at every step along the way. Most of the bottom-level registrars are going to charge a fee for certificates commensurate with their costs, i.e., $0, because of competition. Everyone wins except the existing entrenched root authorities. What's the downside?
The solution is user education.
The Internet is used by billions of people. How do you propose to educate all of them? Even if you could, the technology changes on a year-to-year basis. Several years ago, IDN-based attacks weren't possible. Now the major browsers support IDNs, so suddenly you have a new attack avenue opening up.
Heck, look at non-computerized stuff. Tons of security advice is given out on a continuous basis, and people routinely ignore it. Do you report all the unattended bags that you see? I don't, even though I'm told to continually by the subway loudspeakers. Security advice that's a nuisance will be ignored.
The only real, working, full solution is going to be a technical one. It may require re-architecting the web or the Internet, but the problem is not impossible to solve technically. You have to make sure that there is no possible way for the user to submit any unencrypted info or receive any unsigned response from a sensitive website, that's all.
One way to do this, for instance, would be to get rid of HTTP altogether and use only HTTPS or some variant. Difficult and expensive? Sure. Impossible? Hardly. There are probably lesser measures that would work as well.
For now, of course, user education might be a good idea. But user education is never going to solve the problem, only mitigate it.
I have a technical solution, but it won't be popular: browsers should display a warning when submitting a form on an unencrypted page to an encrypted URL. Since web designers are afraid warnings will spook users, they'll switch to making the form-entry pages encrypted as well.
Or they'll say "your web browser sucks, use a better one". And the user quite possibly will, especially if the browser to implement the feature isn't MSIE. Browsers cannot afford to annoy their users more than the competition does.
We don't need an alternative to SSL. We need browsers to implement proper UI. The user MUST be made aware if clicking a button would transmit a password in cleartext. The user MUST be made aware exactly which domain they are connected to during an SSL session. On a large busy screen, a tiny bit of text in a corner is the wrong way to do this.
And yet we don't live in Imaginary-Land where users and administrators make careful decisions all the time. If you pop up a box every time users submit their credentials in plaintext, users will completely ignore the box. Period.
For real security on the general Internet, you need a solution that always work, without user knowledge.
A possible solution could be to present Windows users with a so-called "ballot screen" from which they would choose their browser.
Alternatively, it could be left up to computer or mobile phone manufacturers, such as Dell or Nokia, which support Microsoft Windows by default, to provide users with different browsers, in agreement with Microsoft.
Note the second paragraph. That sounds to me like a perfectly plausible outcome of the decision is that Microsoft is just forced to not pressure OEMs on what browser to offer. If the OEMs decide to keep offering IE as the default, that would be their decision. If Google or Opera wants to pay them to bundle their browser instead, they could do that.
Or in other words, pretty much the status quo.
The .secure TLD doesn't sound like a terrible idea, but wouldn't it be easier to approach this from the browser? We could accommodate the the keyboard-averse by having some gui element for "secure" urls, that would behave differently than the normal url bar, i.e. prepend "https://" instead of "http://". On the server side, no more responding to http. Instead show a static page telling the user how to access the site properly.
So you're requiring users to remember which sites they access are secure or not? Users will just use a different browser if they have to click an extra button every blasted time they want to go to Gmail or whatever (but not 95% of the other sites they use!). That much annoyance to users is probably just not worth the slight gain in security, in the same way that a highway speed limit of 30 MPH is not worth the lives it would save. Any good solution needs to add no noticeable burden to users' normal web browsing.
If they "would like it to be" secure all they would have to do is spend more money on their infrastructure to encrypt everything.
Wrong. User types "paypal.com" into their URL bar. Browser sends a request for http://paypal.com./ PayPal might automatically redirect to HTTPS (in fact it does, when I try it), but by then it's too late. A MITM can have already served up the fake page as HTTP, and few users will notice the difference.
What's needed is some way for the browser to know in advance that it should not accept any unencrypted traffic from the domain name. The only way I can see to do this is to encode that information in the domain name itself, for instance with a new .secure TLD. The only information available to the browser without going to the network is the domain name, so it seems like this is the only place to store "don't do stuff unencrypted" info.
I kind of agree with you about having something in DNS to tell the client that it must use SSL. When I read through the Powerpoint, I was wondering about using TXT records, or SRV records or some other type of DNS records to tell the client that it must connect using SSL.
You're talking about a situation where the attacker is in a MITM position. If they can intercept and rewrite HTTP traffic, they can intercept and rewrite DNS traffic too. A new TLD would solve this problem quite cleverly, although of course it brings its own problems.
...when articles are tagged with the dreaded "primary sources" tag? In case you're not familiar with this tag, it basically states that the integrity of an article is in question because there are not enough cites from secondary sources (no, not a typo) as opposed to primary sources!
Wrong. Wikipedia permits primary sources, and you can find them all over the place. What it does not permit is original research. You need to publish your work elsewhere before it can be cited on Wikipedia.