The purpose of this is simply to provide a translation guide. It's not designed to pass on any relevant information.
Let's take a look at the contents. Over 1500 languages. Genesis 1-3 in each language and list of most common words with pronunciation guide.
What you now have is a listing to cross-reference identical phrases in a multitude of language. You can find what the word "the" in English translates to in other languages. The main value of this disk will be to provide the framework for other civilizations to translate OTHER documents.
You are quite correct, but its amazing that you would need to explain this given the reference to the Rosetta stone (which, of course, was not intended for that purpose, but is best known as having been useful in that role.)
If one or more notaries report authentication information that is different than that received by the browser or other notaries, a computer user would have reason to suspect that an attacker has compromised the connection."
This helps against some MitM attacks, but not against outright false-flag scams. Also, it provides limited help against MitM attacks where the "middle" is close enough to the other end that it is between all the notaries and the site to be verified. (Though monitoring certificates received over time may help with that in many cases.)
If this was offered as an add-on to the use of signed certs rather than a security alternative, it would be a good system.
Actually, if JS gets fast enough, it could rival Flash.
Since the speed of Flash is largely due to it having a very fast ECMAScript engine, and since the same engine is the center of Mozilla/Adobe cooperation, I don't think expecting Mozilla's JavaScript implementation to become exactly as fast as Flash's ActionScript implementation is all that unreasonable.
Because with AMD (since the ATI acquisition) producing CPUs, chipsets, and GPUs, and Intel gearing up to produce CPUs, chipsets, and GPUs, if both of them do that, and do good enough (they don't have to be the best) at the chipset and GPU part, there is a lot less demand for nVidia's products in general. 3rd-party GPUs may go the way of 3rd party FPUs.
When Intel says "graphics", they mean movie studios, etc.
I don't really think they do anymore; I think they are now focussed on dealing with AMD, and part of that is providing complete CPU/chipset/GPU solutions to OEMs, including for consumer systems. nVidia needs to do the best it can slowing acceptance of any serious Intel GPU effort while it establishes its business outside of the graphics-specific area (e.g., the Tesla GPU computing systems,the rumored x86 CPU, etc.)
Blocking the site completely (and yes, the firefox behavior amounts to a total block) is a far cry from simply providing user feedback.
Treating a TLS 1.0 mandatory fatal condition as a fatal condition is a perfectly reasonably thing to do.
In fact, its exactly what you'd expect of something that implemented TLS 1.0.
Only a relatively sophisticated user will recognize the so-called implicit claims that you describe. They are not the ones harmed by this behavior, because they know how to add security exceptions.
I'm not convinced that anyone is harmed by this behavior, because I'm not convinced that there is ever a valid use of self-signed certs except by those exact relatively sophisticated users you point out are not harmed.
I wonder if you have ever used ssh. Anyone can generate an ssh public key without contacting a CA.
And any one can create a fully validated SSL certificate without "contacting" a CA, since anyone can be a root CA; all they have to do is convince someone to trust them once, in the exact same way that is necessary for a self-signed cert to provide any security.
The only thing ssh checks is whether the key is unchanged from what it was before.
Right. SSH relies on out-of-band verification of the validity of the key before it is initially accepted, and then validates that it doesn't change. SSL (and TLS) rely on out-of-band validation of root CA keys before acceptance, and then delegate validation of individual certificates to root CAs. A relatively sophisticated user knows not just how to add a security exception but, more importantly how (and why it is important) to validate the validity of the key out-of-band before accepting it.
Are you therefore suggesting that ssh should be blocked, and unencrypted telnet should be allowed?
No, but I would say that the security practices required to make SSH work (presuming you aren't using certs, which as I understand SSH can though it doesn't need to) -- where the key acceptor (in the SSH case this is the server, in the most common SSL/TLS case it is the client) must independently validate each key out of bad without reliance on a delegated verifier like a CA -- isn't workable for the use case of SSL/TLS. In the case of SSH, often enough the server and the client are really the same identity, so out-of-band validation is a non-issue. When I add my key to my ~/.ssh/authorized_keys file, I am confident that it is mine. If I transfer it to a different system, that system -- or a human administrator -- will (at least it better!) verify my identity by some other means before it lets me do so.
How do you work that for the uses for which SSL/TLS is used (in web browsers at least; there are actually lots of other places where the SSH model is actually more sensible)?
CAs are part of the problem since the phisher can always choose which ones to use, so the solution should be something that doesn't rely on the site in question making the choice of who verifies there identity.
Seems to me one conceptually sensible way (the most obvious one to me, though not necessarily the best) to do that doesn't eliminate the CA; the site still provides a CA signed cert, which the user agent validates itself passively just as now, and then actively validates with independent "trust brokers". This also gets you the advantage of identifying a tie to a particular real identity, rather than just stability of identity, as well as current certificates for those who care for that. I don't see why one should trade one important security feature for another.
(Then again, I'd argue, in the current model, normal UA behavior ought to be pop-up the certificate details the first time a new valid certificate is encountered, but as yet no one has made me King of the Internet.)
That doesn't automatically make it the right choice... having a CA isn't necessarily the only way to verify things.
I haven't yet seen a credible alternative to having a CA. I'd agree that the binary trust distinctions currently used are a rather blunt tool, though.
If a popular browser trusts one evil/incompetent CA, a lot of people are hosed.
This is a real vulnerability with the simple binary trust system currently used, I'd agree.
A better system would only rely on the trustworthiness of most of the trusted parties, if 9/10 verification servers say that that site isn't using the cert you see it using, you know to ignore (and maybe report for auditing) the 1 that says you're safe.
This is an interesting idea, but it then requires people to get certs from all (or most) CA's. I think a really good system would need to both have simple but robust user preference control and use some kind of distributed trust mechanism for relaying reliability information about different CAs. But ultimately its still going to rely on cryptographic verification of claims of reliability, which gets you back to having CAs even if you call them something else.
Obviously, self signing is meaningless for anonymous strangers. It works just fine for you and your friends/colleagues, but not for anyone outside your immediately trusted group.
Between your friends and colleagues, you can generate your own root CA certs, and distribute them out-of-band, so you don't need self-signed certs there, either. Any place where a self-signed certificate is trustworthy, you don't need a cert at all. (Though they may, obviously, be useful for testing purposes.)
The only thing you can establish with a self-signed cert that is that the cert has not changed. For this to be secure, you need the first time you see the cert for it to be accurate.
And, in any case where you have a means of establishing that initial trusted connection, you can use that trusted connection to get a root certificate to import into your UA so that you can trust certificates signed by that source in the future.
Plain http is even more questionable, and somehow it doesn't complain about that.
Plain HTTP doesn't profess to be secure. https does. Further, the TLS 1.0 and later standards mandate that an unknown CA produces an alert that is always fatal, never a warning.
Also, some people tend to think that CAs are more security theater than real security, and there are better ways to do things.
The chain-of-trust mechanism with root CA's at the top is a mechanism that can provide real security; the behavior of particular actual root CA's may not be trustworthy, but then most user agents let you add and remove root CA certificates, and trust who you want to trust. This could probably be done with more flexibility (such as using levels of trust to different CA's, and putting boundaries on trust for particular CAs, and providing a decent UI identifying that), but I don't see where trusting self-signed certificates makes sense as part of that. If you can trust the source independently of the certificate, they should be able to provide you a certificate to install as a root CA in your user agent so it can trust certificates they sign.
That URL 99% of the time includes a named address, via the DNS system which is unreliable and insecure.
Which, of course, is one reason you might want a verifiable cryptographic validation that the content you receive was sent by someone associated with claimed domain, independent of the fact that you happened to get the IP address supposedly associated with that domain through DNs; fortunately, that is exactly what is provided by a site certificate signed by a trusted CA. (Of course, whether the verification procedures provided by most actual CAs is worthy of trust is another question, but as long as, regardless of the defaults, an application which uses CA certs lets you choose to install new ones and uninstall old ones, the user has control over that trust.)
Typically, you first encounter a self-signed cert in a secure context (for example, setting up such an appliance by plugging it directly into your PC and visiting the web interface).
Anything you can encounter in a known secure context could, if designed to do so, provide you it's signing key to import as a root CA key in that secure context, and thus never have to worry about being rejected as self-signed. If it doesn't do so, this is not the browser's or other client application's fault, its the fault of the thing that failed to give you a CA key to import when you had a known-secure context in which to do so (or its designer), or your fault if it presented that option and you didn't take advantage of it.
Expecting browsers to accept self-signed keys is not the right solution. Adding root CA's when you have a secure context in which to establish trust is the right solution.
Back in 1995 the Netscape folk decided to write the protocol in such a way that you had to have authentication of the server public key to do encryption.
The SSL v3 spec (1996) (and presumably earlier SSL v2 and earlier, I didn't check) does not include an unknown CA as a fatal error condition, though it could fall into a number of other conditions that could be warning of fatal conditions at the applications discretion. Unknown CA as an always fatal alert condition was introduced in TLS 1.0 (and maintained in TLS 1.1 and 1.2).
I have also argued to make use of self-signed certificates easier as we should be moving to a position where security is the default on the Web.
Self-signed certs do not provide security, only certs that can be verified against certificates received out-of-band from a trusted source provide any security. Now, making it easier for people to import root CA's and to distinguish at a glance which root CA is validating a particular site might help move toward a "default security" sate on the web, but those are UI features, not protocol features.
if this is your first visit then it shouldn't be more creepy than simple http(no warning at all so your average mom and pop won't even think they're being scammed).
Arguably, yes, it should, since an https URL is, in and of itself, a claim of security.
If Apple didnt pay for their product placement, they would be sueing large corporations that are using their brands image, products and so forth... for financial gain.
If Apple gains from product placement, and the users of the image gain from the pre-existing popularity of the image, why wouldn't both agree to do it for free? It's still a business deal, but there doesn't need to be any money changing hands.
The combination of HTML's form controls and Javascript's XMLHttpRequest gives web app designers the power they need to implement 99% of applications as webapps with very little compromise vs. thick-client apps.
For a ridiculously tolerant definition of "very little"; there is a reason that all kinds of new features like local storage to support webapps integrated into the browser are being added to support web apps, its because HTML form controls but XMLHttpRequest without a whole lot of other things that are only just starting to become available make 99% of applications absolutely horrible compared to thick client apps.
Those new features will probably knock that percentage somewhere into the mid-80s.
Yes, my percentages are completely made up, but no more than yours.
But that is a compatibility problem that is under your control. Just like you dont have to target.NET 3.5, you dont have to "upgrade" your Silverlight app until you are ready.
Or until the old Silverlight runtime has incompatibilities with newer platforms that force you to upgrade or not be able to reach users.
If I target Silverlight/Flex and Firefox 3 broke their support for Silverlight/Flex, there would be a *lot* of other websites (say, youtube) that would be broken and visitors would blame the browser, not my website.
Or maybe their wouldn't be, because the "lots of other websites" would have upgraded their target version before you did. Silverlight adds another level of platform that can get broken when anything in the chain of platforms from the OS, the browser, etc., changes.
The browser model allows for languages other than Javascript. (e.g. VBScript is somewhat popular in IE-only applications.) It's just that no one has come up with a better language.
No one has come up with a more popular language for use in the browser, but the most important feature for users is what it can access, and the most important feature for developers is what browsers that users have support, so the fact that JavaScript got in and got established early means its fairly sticky and, regardless of features or quality, its pretty difficult for anything else to get established.
Yes, it certainly DOES mean that it is unfeasible. Profitability runs this country. If it is not profitable, then the government pays for it. If the government pays for it, then you pay for it. In summary, you are willing to lose money (no profitability) so that broadband can be delivered to you.
Uh, no, I already have broadband. Just like most of the people that supported (and paid for) the government initiative for rural electrification already had electricity. Now, I think I gain a benefit (and a financial one, in the long term) from the overall economic improvements that increased access would bring, but its not the kind that creates a private profit motive, because the benefit is diffuse and not very large on an individual scale, such that everyone is better off if someone does it, but no individual or corporation has an incentive to fund it themselves, since the net benefit to the funder would be negative.
Into simple words: Any code needs to be easy readable by anyone on team (not just the super-duper "the chosen one" coding guru of ). For example, yours maybe hate BASIC, but anyone can understand what a BASIC-written code does.
The biggest problem with BASIC is that that is (as people complain of for Perl) mostly true for very small programs and untrue for larger programs in the language, when compared to other programming languages.
Well, most languages now have very similar regular expression support.
Most languages with similar regular expression support make it much more clear what you are doing with the regex, even if the regex itself looks pretty similar.
Slashdot Mirror
Except that the Catholic Church doesn't promote the idea at issue (that the seven days of creation in Genesis 1 must be viewed literally).
This helps against some MitM attacks, but not against outright false-flag scams. Also, it provides limited help against MitM attacks where the "middle" is close enough to the other end that it is between all the notaries and the site to be verified. (Though monitoring certificates received over time may help with that in many cases.)
If this was offered as an add-on to the use of signed certs rather than a security alternative, it would be a good system.
Since the speed of Flash is largely due to it having a very fast ECMAScript engine, and since the same engine is the center of Mozilla/Adobe cooperation, I don't think expecting Mozilla's JavaScript implementation to become exactly as fast as Flash's ActionScript implementation is all that unreasonable.
Because with AMD (since the ATI acquisition) producing CPUs, chipsets, and GPUs, and Intel gearing up to produce CPUs, chipsets, and GPUs, if both of them do that, and do good enough (they don't have to be the best) at the chipset and GPU part, there is a lot less demand for nVidia's products in general. 3rd-party GPUs may go the way of 3rd party FPUs.
I don't really think they do anymore; I think they are now focussed on dealing with AMD, and part of that is providing complete CPU/chipset/GPU solutions to OEMs, including for consumer systems. nVidia needs to do the best it can slowing acceptance of any serious Intel GPU effort while it establishes its business outside of the graphics-specific area (e.g., the Tesla GPU computing systems,the rumored x86 CPU, etc.)
Seems to me one conceptually sensible way (the most obvious one to me, though not necessarily the best) to do that doesn't eliminate the CA; the site still provides a CA signed cert, which the user agent validates itself passively just as now, and then actively validates with independent "trust brokers". This also gets you the advantage of identifying a tie to a particular real identity, rather than just stability of identity, as well as current certificates for those who care for that. I don't see why one should trade one important security feature for another.
(Then again, I'd argue, in the current model, normal UA behavior ought to be pop-up the certificate details the first time a new valid certificate is encountered, but as yet no one has made me King of the Internet.)
I haven't yet seen a credible alternative to having a CA. I'd agree that the binary trust distinctions currently used are a rather blunt tool, though.
This is a real vulnerability with the simple binary trust system currently used, I'd agree.
This is an interesting idea, but it then requires people to get certs from all (or most) CA's. I think a really good system would need to both have simple but robust user preference control and use some kind of distributed trust mechanism for relaying reliability information about different CAs. But ultimately its still going to rely on cryptographic verification of claims of reliability, which gets you back to having CAs even if you call them something else.
Between your friends and colleagues, you can generate your own root CA certs, and distribute them out-of-band, so you don't need self-signed certs there, either. Any place where a self-signed certificate is trustworthy, you don't need a cert at all. (Though they may, obviously, be useful for testing purposes.)
And, in any case where you have a means of establishing that initial trusted connection, you can use that trusted connection to get a root certificate to import into your UA so that you can trust certificates signed by that source in the future.
Plain HTTP doesn't profess to be secure. https does. Further, the TLS 1.0 and later standards mandate that an unknown CA produces an alert that is always fatal, never a warning.
The chain-of-trust mechanism with root CA's at the top is a mechanism that can provide real security; the behavior of particular actual root CA's may not be trustworthy, but then most user agents let you add and remove root CA certificates, and trust who you want to trust. This could probably be done with more flexibility (such as using levels of trust to different CA's, and putting boundaries on trust for particular CAs, and providing a decent UI identifying that), but I don't see where trusting self-signed certificates makes sense as part of that. If you can trust the source independently of the certificate, they should be able to provide you a certificate to install as a root CA in your user agent so it can trust certificates they sign.
Which, of course, is one reason you might want a verifiable cryptographic validation that the content you receive was sent by someone associated with claimed domain, independent of the fact that you happened to get the IP address supposedly associated with that domain through DNs; fortunately, that is exactly what is provided by a site certificate signed by a trusted CA. (Of course, whether the verification procedures provided by most actual CAs is worthy of trust is another question, but as long as, regardless of the defaults, an application which uses CA certs lets you choose to install new ones and uninstall old ones, the user has control over that trust.)
Anything you can encounter in a known secure context could, if designed to do so, provide you it's signing key to import as a root CA key in that secure context, and thus never have to worry about being rejected as self-signed. If it doesn't do so, this is not the browser's or other client application's fault, its the fault of the thing that failed to give you a CA key to import when you had a known-secure context in which to do so (or its designer), or your fault if it presented that option and you didn't take advantage of it.
Expecting browsers to accept self-signed keys is not the right solution. Adding root CA's when you have a secure context in which to establish trust is the right solution.
It can't, because it needs to provide the user feedback that the claim implicit in the URL is not supported.
An http URL is not a security claim, so the browser does not need to warn that it is insecure under normal circumstances.
Which is exactly what it should do.
The SSL v3 spec (1996) (and presumably earlier SSL v2 and earlier, I didn't check) does not include an unknown CA as a fatal error condition, though it could fall into a number of other conditions that could be warning of fatal conditions at the applications discretion. Unknown CA as an always fatal alert condition was introduced in TLS 1.0 (and maintained in TLS 1.1 and 1.2).
Self-signed certs do not provide security, only certs that can be verified against certificates received out-of-band from a trusted source provide any security. Now, making it easier for people to import root CA's and to distinguish at a glance which root CA is validating a particular site might help move toward a "default security" sate on the web, but those are UI features, not protocol features.
Arguably, yes, it should, since an https URL is, in and of itself, a claim of security.
Sometimes go in the opposite direction from longer term patterns.
Film at 11.
If Apple gains from product placement, and the users of the image gain from the pre-existing popularity of the image, why wouldn't both agree to do it for free? It's still a business deal, but there doesn't need to be any money changing hands.
For a ridiculously tolerant definition of "very little"; there is a reason that all kinds of new features like local storage to support webapps integrated into the browser are being added to support web apps, its because HTML form controls but XMLHttpRequest without a whole lot of other things that are only just starting to become available make 99% of applications absolutely horrible compared to thick client apps.
Those new features will probably knock that percentage somewhere into the mid-80s.
Yes, my percentages are completely made up, but no more than yours.
Or until the old Silverlight runtime has incompatibilities with newer platforms that force you to upgrade or not be able to reach users.
Or maybe their wouldn't be, because the "lots of other websites" would have upgraded their target version before you did. Silverlight adds another level of platform that can get broken when anything in the chain of platforms from the OS, the browser, etc., changes.
No one has come up with a more popular language for use in the browser, but the most important feature for users is what it can access, and the most important feature for developers is what browsers that users have support, so the fact that JavaScript got in and got established early means its fairly sticky and, regardless of features or quality, its pretty difficult for anything else to get established.
Uh, no, I already have broadband. Just like most of the people that supported (and paid for) the government initiative for rural electrification already had electricity. Now, I think I gain a benefit (and a financial one, in the long term) from the overall economic improvements that increased access would bring, but its not the kind that creates a private profit motive, because the benefit is diffuse and not very large on an individual scale, such that everyone is better off if someone does it, but no individual or corporation has an incentive to fund it themselves, since the net benefit to the funder would be negative.
The biggest problem with BASIC is that that is (as people complain of for Perl) mostly true for very small programs and untrue for larger programs in the language, when compared to other programming languages.
Most languages with similar regular expression support make it much more clear what you are doing with the regex, even if the regex itself looks pretty similar.
Or, more recently, Transmeta or Via.