"But even then, 1% could be overclocking or, as the author of TFA says, heat or PSU undersupply issues. That's not 'defective' hardware, that's temperamental hardware or the user doing it wrong."
The hardware produced the wrong results. That is the very definition of a defect. The concept of who is at fault is completely orthogonal to whether or not the hardware is functioning properly. No, it's not a manufacturing defect, not the kind of defect that would give you a right to RMA, but it is still operating in a defective state. From the perspective of the person researching the crash report, they are wanting to know "Is it my software, or their hardware?" Once they determine it's the hardware, that's the end of the line for them. It isn't the software engineer's job to go further down the rabbit hole and help the user test his PSU, or determine if overclocking is the cause. They are not doing support. Their goal is to determine if there is a bug that is causing the crash, and as a first step in that, rule out other possibilities.
"And because it's rare it's not necessarily serious, most users can handle the odd application crash in something like an MMO once every few days." From the perspective of a developer, if I have a bug that causes a crash for all users every few days, that is a huge issue and worth investigating. 1) The amount of work that goes into eliminating that bug probably would be very small in comparison to the thousands of minutes that would accumulate in user's wasted time, restarting the app and getting back to where they left off. If it is indeed a legitimate bug, and is effecting all users every few days, that is a huge amount of time and frustration that accumulates over the lifetime of that application. 2) If you are lazy about not investigating such a bug, as the app evolves over time and new bugs crop up unfixed, you will slowly accumulate many such bugs over time. Eventually you're game/app will be one of those that is well known for random crashes. The job of pinpointing the cause will be more difficult. If you investigate bugs as they are discovered, you can focus on recently changed code as a potential cause. Additionally, as you collect crash logs, it will be hard to focus on a single bug, because you could have three different bugs causing crashes, and so trying to find commonality between crash reports will be very difficult.
Some shops are very ignorant of how buggy their applications are. They don't realize that for every person that reports a bug, there's many more experiencing that bug. The kind of people who take the time to email/file a bug report are pretty rare.
SSH comes to mind quite often when thinking about these kinds of things. In most places, users see prompts about accepting a public key so often that it becomes second nature. No one goes to the IT admin and is like "Hey, did something change on the server that would cause me to see this message today, or is someone intercepting my connection and providing their own public key?". Maybe not in that wording, but the point being, even savvy users in a computer science department generally ignore these messages and happily accept the key even when they've connected to the server before.
Exactly. To say "Obviously IE works with SSL" is the opposite of "IE doesn't support SSL at all", which was the point I was trying to make with the phone analogy.
I just tire of people taking the most extreme position they can on something, when they could have conveyed the same without the inflammatory fluff. Instead of contributing to the conversation by clarifying that SNI support is tied to the OS instead of IE version, he couldn't help but quote the OP and then state exactly the opposite regardless of how twisted the wording was:
"(supported by IE8+)/IE doesn't support SSL at all"
I didn't make the leap from "IE doesn't support SSL at all" to "IE doesn't support SSL at all with 1 IP hosting several SSL-enabled domains" since the "at all" part implied that he was throwing out the previous context and making a blanket statement about IE lacking SSL support.
Agree completely, they took a step in the right direction. Otherwise China can man-in-the-middle of someone retrieving email over a connection with a self-signed cert, and then find and arrests activists retrieving their email that way. It might be misleading to use Gmail in the "Only SSL" mode, not reallizing that the connection from Gmail to third party pop3 is not secure at all.
It is a big deal for a CA to be compromised, I agree on that. However, to use that to then say signed certs are completely useless is not just an exaggeration, it is completely wrong and inaccurate. You sir, are an alarmist
You threw the baby out with the bathwater... oh the horror. Someone go get the baby back.
The incidents you describe did not compromise the vast majority of SSL connections. Only a tiny fraction, and only for a limited time span, since the beauty of the CA system is they are able to revoke cert's once discovered to be invalid. Although that can take some time to trickle down since many OS's cache the CA's public key, and is only changed via a system update.
Self signed certs are far more insecure. At least with CA certs you have a 99.9%+ chance of having a secure connection. With self signed certs, you have 0% guarantee unless you've been communicating public keys out of channel.
I'm not sure what "job" you are referring to is more difficult. There is a vast wealth of libraries and applications that support SSL, making any "job" involving supporting SSL easy. If that is difficult for you, maybe you should get a different job.
If you want to take the lead on implementing a new system that provides the same level of security then be my guest. Otherwise all I hear is a bunch of CA bashing non-sense that has no root in statistics.
They are still very usable in server-to-server communications, or some client-server scenarios. You can provide the respective public key's manually out-of-channel so each server can identify the other securely, and benefit from the security of SSL without the need of a CA signed cert. A devil's advocate would say someone with access to the server could swap the public key maliciously, but the same is true of the CA's public key. (If someone with malicious intents has that level of access to your server, you are screwed in 100 other ways anyhow.)
There would be a bigger place for self signed certs if there were more user friendly means to manage public keys out-of-channel, but the majority of the public would not endure that minor annoyance without understanding the value. Additionally, they would be more vulnerable to social engineering attacks of the form "Share this public key with your friends, copy and paste to 10 friends and you could win $1000!" if the system wasn't designed thoughtfully.
There are distributions of Linux and Windows Server that make it pretty easy to setup. The hardest part will be configuring DNS, and the possibility that your ISP won't allow it. If they did allow it, they'd have trouble with their IPs getting blacklisted on account of people spamming from their home email servers.
A signed cert is tied to a domain. Google will not accept a signed cert when connecting to domain X.com if the cert presented is for Y.com. Signed the cert is signed by the CA, it is cryptographically secure from being tampered with, such that the person holding the cert cannot manipulate the domain attribute to a different value.
I like self-signed certs because they are away to leverage SSL support for encrypted connections, but they are vulnerable to man-in-the-middle attacks. Hence the suggested workaround of providing the public key in the Google account so that Google can prevent man-in-the-middle attacks. IMO that is a reasonable suggestion, but many tools for creating self signed certs don't give you an easy way to separate the public key without opening the file and being knowledgeable of it's format. It would be a feature used by probably a tiny percentage of users, and be a point of what-the-heck-is-that-option for the rest. The lack of user understanding would also be a vulnerability, where people might be duped into providing a different public key with malicious origins.
This has nothing to do with the inflammatory "valid" vs. "paid" statement. There are CAs that provide free certificates, and thus are not vulnerable to man-in-middle-attacks because of the verifiable chain. So they are indeed valid in a sense that there is the trust chain, yet not paid, making the summary's inflammatory statement INVALID. No one is trying to claim self signed certs are invalid, they just leave users vulnerable.
The last statement about CA's being compromised is somewhat irrelevant to the subject at hand. They seem to be trying to make the point of Google unfairly favoring CA signed certs over self signed certs. So they either feel that Google should also do away with CA signed cert support, or not do away with self signed certs on the basis that CA signed certs are no more secure(as a result of CA's being compromised). I will address both of these possibilities.
1) Doing away with self signed certs prevents vulnerabilities that most users are probably unaware exist. Thus avoiding more shenanigans like Chinese activists getting arrested when the government snoops their communications using man-in-the-middle attacks. So this is definitely a step in the right direction(although perhaps alternatively could have supported providing public keys out of channel as summary suggests).
2) Doing away with support for CA signed certs to close the potential vulnerability of relatively rare forged certs? That's like throwing the baby out with the bath water. The system in place significantly improves security for the vast majority of connections. It allows certs to be revoked when found to be forged, and provides a secure connection that cannot be snooped(with the exception of the tiny fraction of invalid certs, which that get revoked anyhow). Self signed certs cannot offer either of these features transparently(without requiring users to setup public keys).
Self-signed certs can be "forged" in the sense that a man-in-the-middle can present a completely different cert. as the original, and there is no third party verification that would allow that cert to be revoked. Even if it were revoked("hey bob, just calling to tell you to look at the cert on that connection when you get your email and if the key read f0a135... then disconnect" I kid, I kid), the malicious snooper would just create a new self-signed cert for another man-in-the-middle the next time a connection is initiated. For those same reasons, connections made with self-signed certs have very little guarantee of security.
Usually I'm not concerned about man-in-the-middle attacks, since if someone has gained that level of access to the network I'm connecting over, then things are looking bad already. In places like China though, where the people who control the network are the people who want to snoop on you, it is a ever present danger.
If there were more user friendly systems in place for managing/retrieving public keys, then self signed certs would be great. Even when I know a cert. is valid, some make it very hard to permanently add the public key as trusted, and thus prompt me with an extra step every time I restart my browser and try to access a page using one.
That is called practicing for using it for its intended purpose. Why do cops go to a shooting range? Using it has to be a reflex that is familiar to you, so that when you are in a situation that requires its use, then you will be effective. So in reality, whether you agree/disagree with gun control, the reality is you are practicing for its intended purpose.
That purpose is either to kill people, kill animals, or competitive shooting. Each of those three categories generally has guns better suited for each purpose.
Just to clarify, the second win is because the cult used their money for something useful, and has less money left to do silly things with, such as buying Nike's, barbiturates, and Vodka.
If not, someone should perhaps start some projects like this, such that doomsday cults funnel their money into useful research projects. Win-win for everyone, unless the cult turns out to be right.
Yes, if the lake is actually filled with millions of giant underwater ice spiders, and 0.1% of them have a genetic variation that makes them resistant to sterilized boiling water, then that 0.1% can survive the trip to the surface. Thus creating a dual resistance super bug(literally, or you might technically say spiders are not bug, meh).
Agree, I would have hoped they would have used "sterilised water at near boiling point to blast a passage through" one more time. Maybe even spelling it sterilized that last time just to see if people are on their toes.
Having the same language client and server side definitely is a big plus, and something I've strongly desired for a long time. There's alot of things you can do server side that you can't do so well client side due to lack of implementing libraries in the client-side language.
I just wish it was with a different language. Not trying to flame JS, just not my personal preference if I had to code a medium or large application/API/framework.
I really think desktop applications could have done this, but various shenanigans made it difficult to do this successfully on a wide enough range of devices without a great deal of trouble.
"If it comes to a root, people can trace it up to the root."
Maybe I misunderstand what you mean here. Yes, they can trace it to the certificate authority. This is like knowing who issued the ID, it doesn't tell you anything about the ID itself. In fact, this is property is key to ensuring the ID isn't forged/self signed, because anyone can verify it with the cert authority. It is like a client side SSL certificate that doesn't include any of the attributes that identify the organization/company. All you know is that, yes this is a valid ID (which can optionally be used only at such-and-such domain).
True that the authority is a single point of failure, and would have to have some oversight to ensure they were not collecting usage data. While they'd be able to track what IDs for what domains were issued, in my design, they can't track usage since the ID can be cryptographically verified with the authorities public key, without ever requesting validation with the authority. So when I visit facebook.com with my ID, the authority that issued my ID doesn't know when or how much I visist that site.
The trusted authority is not any different then any other link in the chain, whether it be our own devices, connection, ISP, email provider, etc. where there is a constant battle between government oversight, law enforcement surveillance, malicious abuse, marketing data, and user freedom. It's not like the web hasn't been hinged upon many single points of failure already. You compromise any authority, whether it be SSL certs, OpenID, email provider(reset passwords of any accounts using the email as recovery) etc. and then you can do a huge amount of malicious things.
This is like saying houses are bad because they don't protect you from sudden massive sinkholes swallowing you and your house up. Yes there are scenarios that break these systems, but that is why they take security seriously in those contexts. None of these things mean that the SSL system, email providers, or OpenID are terrible systems. It's like throwing the baby out with the dirty bath water.
"You want non-anonymous access[...]" No, that's the opposite of what I said I want! That will never get public acceptance or broad usage. There has to be some anonymous element to it for public accept it.
Nor can we trust law enforcement to manage the system. I'm not a law enforcement hater, but within law enforcement there are many individuals who will put their own twist on the law, or sometimes simply abuse their access to surveillance for malicious purposes. The combination of authority and access is a very bad combination. That's why it needs to be a non-commercial organization, not affiliated with a particular nation.
The great thing about the ID is that anyone requiring it will be able to deny access on a first offense, and not worry about someone coming back with a different ID.
Some forms of denial-of-service attacks could be prevented(many systems minimize sessions overhead for non-authneticated users, thus you have to use a bot-net that steals/everages local user's ID for DOS) You would greatly minimize botnet attacks from leverage ID's by using smart card systems that require a challenge-response device be in hand. These types of IDs are used in other countries but have had resistance in the US due to anonymity concerns. I'm simply advocating for the Identifying information to be kept private at the cert. authority to help make the IDs more acceptable to the public, and be non-government affiliated.
The benefits for the security of systems/sites that use these for authentication would be profound. Imagine Diablo 2 where each patch was responded to with new hacks that worked around hack detection. People who got banned when the new patch came out, or because they were testing a modification to the hack to make it work with the new patch, would simply obtain stolen keys or purchase new ones(usually at a very low cost through markets that dealt in "stolen" keys because you could determine
Do you believe everyone could be issued an ID, and still remain anonymous? What I mean is, I believe that you could ensure each of your users is unique, but not necessarily know who they are. If everyone is issued a certificate signed by some trusted authority, one could verify that the certificate is valid, without the certificate exposing the information about who you are. You could even have a scheme that lets the authority issue you multiple IDs, but only one for each unique ForUseWithDomain attribute, such that if you wanted to keep your identity from being correlated across different sites, you could do so. This could probably even be automated.
This would ensure that if you banned a malicious user from your site, they wouldn't be able to come back without compromising someone else's certificate. Yet, you still get a high level of anonymity.
Sites that require non-anonymous access could deny anonymous certificates, and require that you authorize access to full name perhaps. This would be like OpenID in the way it will prompt you for a site requesting additional information, like your email.
Slashdot Mirror
"But even then, 1% could be overclocking or, as the author of TFA says, heat or PSU undersupply issues. That's not 'defective' hardware, that's temperamental hardware or the user doing it wrong."
The hardware produced the wrong results. That is the very definition of a defect. The concept of who is at fault is completely orthogonal to whether or not the hardware is functioning properly. No, it's not a manufacturing defect, not the kind of defect that would give you a right to RMA, but it is still operating in a defective state. From the perspective of the person researching the crash report, they are wanting to know "Is it my software, or their hardware?" Once they determine it's the hardware, that's the end of the line for them. It isn't the software engineer's job to go further down the rabbit hole and help the user test his PSU, or determine if overclocking is the cause. They are not doing support. Their goal is to determine if there is a bug that is causing the crash, and as a first step in that, rule out other possibilities.
"And because it's rare it's not necessarily serious, most users can handle the odd application crash in something like an MMO once every few days."
From the perspective of a developer, if I have a bug that causes a crash for all users every few days, that is a huge issue and worth investigating.
1) The amount of work that goes into eliminating that bug probably would be very small in comparison to the thousands of minutes that would accumulate in user's wasted time, restarting the app and getting back to where they left off. If it is indeed a legitimate bug, and is effecting all users every few days, that is a huge amount of time and frustration that accumulates over the lifetime of that application.
2) If you are lazy about not investigating such a bug, as the app evolves over time and new bugs crop up unfixed, you will slowly accumulate many such bugs over time. Eventually you're game/app will be one of those that is well known for random crashes. The job of pinpointing the cause will be more difficult. If you investigate bugs as they are discovered, you can focus on recently changed code as a potential cause. Additionally, as you collect crash logs, it will be hard to focus on a single bug, because you could have three different bugs causing crashes, and so trying to find commonality between crash reports will be very difficult.
Some shops are very ignorant of how buggy their applications are. They don't realize that for every person that reports a bug, there's many more experiencing that bug. The kind of people who take the time to email/file a bug report are pretty rare.
Funny though, I like what you did there.
He didn't say anything about a computer: "In my field, if YOU can survive"... scary...
"The defect rate on hardware is so low you don't need to"
I think the point of the article is to cast significant doubt on statements like this.
SSH comes to mind quite often when thinking about these kinds of things. In most places, users see prompts about accepting a public key so often that it becomes second nature. No one goes to the IT admin and is like "Hey, did something change on the server that would cause me to see this message today, or is someone intercepting my connection and providing their own public key?". Maybe not in that wording, but the point being, even savvy users in a computer science department generally ignore these messages and happily accept the key even when they've connected to the server before.
Exactly. To say "Obviously IE works with SSL" is the opposite of "IE doesn't support SSL at all", which was the point I was trying to make with the phone analogy.
I just tire of people taking the most extreme position they can on something, when they could have conveyed the same without the inflammatory fluff. Instead of contributing to the conversation by clarifying that SNI support is tied to the OS instead of IE version, he couldn't help but quote the OP and then state exactly the opposite regardless of how twisted the wording was:
"(supported by IE8+)/IE doesn't support SSL at all"
I didn't make the leap from "IE doesn't support SSL at all" to "IE doesn't support SSL at all with 1 IP hosting several SSL-enabled domains" since the "at all" part implied that he was throwing out the previous context and making a blanket statement about IE lacking SSL support.
Agree completely, they took a step in the right direction. Otherwise China can man-in-the-middle of someone retrieving email over a connection with a self-signed cert, and then find and arrests activists retrieving their email that way. It might be misleading to use Gmail in the "Only SSL" mode, not reallizing that the connection from Gmail to third party pop3 is not secure at all.
It is a big deal for a CA to be compromised, I agree on that. However, to use that to then say signed certs are completely useless is not just an exaggeration, it is completely wrong and inaccurate. You sir, are an alarmist
You threw the baby out with the bathwater... oh the horror. Someone go get the baby back.
The incidents you describe did not compromise the vast majority of SSL connections. Only a tiny fraction, and only for a limited time span, since the beauty of the CA system is they are able to revoke cert's once discovered to be invalid. Although that can take some time to trickle down since many OS's cache the CA's public key, and is only changed via a system update.
Self signed certs are far more insecure. At least with CA certs you have a 99.9%+ chance of having a secure connection. With self signed certs, you have 0% guarantee unless you've been communicating public keys out of channel.
I'm not sure what "job" you are referring to is more difficult. There is a vast wealth of libraries and applications that support SSL, making any "job" involving supporting SSL easy. If that is difficult for you, maybe you should get a different job.
If you want to take the lead on implementing a new system that provides the same level of security then be my guest. Otherwise all I hear is a bunch of CA bashing non-sense that has no root in statistics.
(Nods head in approval)
They are still very usable in server-to-server communications, or some client-server scenarios. You can provide the respective public key's manually out-of-channel so each server can identify the other securely, and benefit from the security of SSL without the need of a CA signed cert. A devil's advocate would say someone with access to the server could swap the public key maliciously, but the same is true of the CA's public key. (If someone with malicious intents has that level of access to your server, you are screwed in 100 other ways anyhow.)
There would be a bigger place for self signed certs if there were more user friendly means to manage public keys out-of-channel, but the majority of the public would not endure that minor annoyance without understanding the value. Additionally, they would be more vulnerable to social engineering attacks of the form "Share this public key with your friends, copy and paste to 10 friends and you could win $1000!" if the system wasn't designed thoughtfully.
That's like saying the Nexus One doesn't support making phone calls, it's all the antennas and chips inside.
There are distributions of Linux and Windows Server that make it pretty easy to setup. The hardest part will be configuring DNS, and the possibility that your ISP won't allow it. If they did allow it, they'd have trouble with their IPs getting blacklisted on account of people spamming from their home email servers.
A signed cert is tied to a domain. Google will not accept a signed cert when connecting to domain X.com if the cert presented is for Y.com. Signed the cert is signed by the CA, it is cryptographically secure from being tampered with, such that the person holding the cert cannot manipulate the domain attribute to a different value.
I like self-signed certs because they are away to leverage SSL support for encrypted connections, but they are vulnerable to man-in-the-middle attacks. Hence the suggested workaround of providing the public key in the Google account so that Google can prevent man-in-the-middle attacks. IMO that is a reasonable suggestion, but many tools for creating self signed certs don't give you an easy way to separate the public key without opening the file and being knowledgeable of it's format. It would be a feature used by probably a tiny percentage of users, and be a point of what-the-heck-is-that-option for the rest. The lack of user understanding would also be a vulnerability, where people might be duped into providing a different public key with malicious origins.
This has nothing to do with the inflammatory "valid" vs. "paid" statement. There are CAs that provide free certificates, and thus are not vulnerable to man-in-middle-attacks because of the verifiable chain. So they are indeed valid in a sense that there is the trust chain, yet not paid, making the summary's inflammatory statement INVALID. No one is trying to claim self signed certs are invalid, they just leave users vulnerable.
The last statement about CA's being compromised is somewhat irrelevant to the subject at hand. They seem to be trying to make the point of Google unfairly favoring CA signed certs over self signed certs. So they either feel that Google should also do away with CA signed cert support, or not do away with self signed certs on the basis that CA signed certs are no more secure(as a result of CA's being compromised). I will address both of these possibilities.
1) Doing away with self signed certs prevents vulnerabilities that most users are probably unaware exist. Thus avoiding more shenanigans like Chinese activists getting arrested when the government snoops their communications using man-in-the-middle attacks. So this is definitely a step in the right direction(although perhaps alternatively could have supported providing public keys out of channel as summary suggests).
2) Doing away with support for CA signed certs to close the potential vulnerability of relatively rare forged certs? That's like throwing the baby out with the bath water. The system in place significantly improves security for the vast majority of connections. It allows certs to be revoked when found to be forged, and provides a secure connection that cannot be snooped(with the exception of the tiny fraction of invalid certs, which that get revoked anyhow). Self signed certs cannot offer either of these features transparently(without requiring users to setup public keys).
Self-signed certs can be "forged" in the sense that a man-in-the-middle can present a completely different cert. as the original, and there is no third party verification that would allow that cert to be revoked. Even if it were revoked("hey bob, just calling to tell you to look at the cert on that connection when you get your email and if the key read f0a135... then disconnect" I kid, I kid), the malicious snooper would just create a new self-signed cert for another man-in-the-middle the next time a connection is initiated. For those same reasons, connections made with self-signed certs have very little guarantee of security.
Usually I'm not concerned about man-in-the-middle attacks, since if someone has gained that level of access to the network I'm connecting over, then things are looking bad already. In places like China though, where the people who control the network are the people who want to snoop on you, it is a ever present danger.
If there were more user friendly systems in place for managing/retrieving public keys, then self signed certs would be great. Even when I know a cert. is valid, some make it very hard to permanently add the public key as trusted, and thus prompt me with an extra step every time I restart my browser and try to access a page using one.
That is called practicing for using it for its intended purpose. Why do cops go to a shooting range? Using it has to be a reflex that is familiar to you, so that when you are in a situation that requires its use, then you will be effective. So in reality, whether you agree/disagree with gun control, the reality is you are practicing for its intended purpose.
That purpose is either to kill people, kill animals, or competitive shooting. Each of those three categories generally has guns better suited for each purpose.
Just to clarify, the second win is because the cult used their money for something useful, and has less money left to do silly things with, such as buying Nike's, barbiturates, and Vodka.
If not, someone should perhaps start some projects like this, such that doomsday cults funnel their money into useful research projects. Win-win for everyone, unless the cult turns out to be right.
Yes, if the lake is actually filled with millions of giant underwater ice spiders, and 0.1% of them have a genetic variation that makes them resistant to sterilized boiling water, then that 0.1% can survive the trip to the surface. Thus creating a dual resistance super bug(literally, or you might technically say spiders are not bug, meh).
Yours probably didn't clarify with enough clarity the clearness that this article clearly has.
But I feel your pain.
Maybe it's not a drill bit at all, but some sort of really hot water. I'm not really sure though.
Agree, I would have hoped they would have used "sterilised water at near boiling point to blast a passage through" one more time. Maybe even spelling it sterilized that last time just to see if people are on their toes.
Having the same language client and server side definitely is a big plus, and something I've strongly desired for a long time. There's alot of things you can do server side that you can't do so well client side due to lack of implementing libraries in the client-side language.
I just wish it was with a different language. Not trying to flame JS, just not my personal preference if I had to code a medium or large application/API/framework.
I really think desktop applications could have done this, but various shenanigans made it difficult to do this successfully on a wide enough range of devices without a great deal of trouble.
I wasn't going to be the one to say it, so I just scrolled knowing I'd be satisfied with seeing someone else say it.
"If it comes to a root, people can trace it up to the root."
Maybe I misunderstand what you mean here. Yes, they can trace it to the certificate authority. This is like knowing who issued the ID, it doesn't tell you anything about the ID itself. In fact, this is property is key to ensuring the ID isn't forged/self signed, because anyone can verify it with the cert authority. It is like a client side SSL certificate that doesn't include any of the attributes that identify the organization/company. All you know is that, yes this is a valid ID (which can optionally be used only at such-and-such domain).
True that the authority is a single point of failure, and would have to have some oversight to ensure they were not collecting usage data. While they'd be able to track what IDs for what domains were issued, in my design, they can't track usage since the ID can be cryptographically verified with the authorities public key, without ever requesting validation with the authority. So when I visit facebook.com with my ID, the authority that issued my ID doesn't know when or how much I visist that site.
The trusted authority is not any different then any other link in the chain, whether it be our own devices, connection, ISP, email provider, etc. where there is a constant battle between government oversight, law enforcement surveillance, malicious abuse, marketing data, and user freedom. It's not like the web hasn't been hinged upon many single points of failure already. You compromise any authority, whether it be SSL certs, OpenID, email provider(reset passwords of any accounts using the email as recovery) etc. and then you can do a huge amount of malicious things.
This is like saying houses are bad because they don't protect you from sudden massive sinkholes swallowing you and your house up. Yes there are scenarios that break these systems, but that is why they take security seriously in those contexts. None of these things mean that the SSL system, email providers, or OpenID are terrible systems. It's like throwing the baby out with the dirty bath water.
"You want non-anonymous access[...]"
No, that's the opposite of what I said I want! That will never get public acceptance or broad usage. There has to be some anonymous element to it for public accept it.
Nor can we trust law enforcement to manage the system. I'm not a law enforcement hater, but within law enforcement there are many individuals who will put their own twist on the law, or sometimes simply abuse their access to surveillance for malicious purposes. The combination of authority and access is a very bad combination. That's why it needs to be a non-commercial organization, not affiliated with a particular nation.
The great thing about the ID is that anyone requiring it will be able to deny access on a first offense, and not worry about someone coming back with a different ID.
Some forms of denial-of-service attacks could be prevented(many systems minimize sessions overhead for non-authneticated users, thus you have to use a bot-net that steals/everages local user's ID for DOS) You would greatly minimize botnet attacks from leverage ID's by using smart card systems that require a challenge-response device be in hand. These types of IDs are used in other countries but have had resistance in the US due to anonymity concerns. I'm simply advocating for the Identifying information to be kept private at the cert. authority to help make the IDs more acceptable to the public, and be non-government affiliated.
The benefits for the security of systems/sites that use these for authentication would be profound. Imagine Diablo 2 where each patch was responded to with new hacks that worked around hack detection. People who got banned when the new patch came out, or because they were testing a modification to the hack to make it work with the new patch, would simply obtain stolen keys or purchase new ones(usually at a very low cost through markets that dealt in "stolen" keys because you could determine
Do you believe everyone could be issued an ID, and still remain anonymous? What I mean is, I believe that you could ensure each of your users is unique, but not necessarily know who they are. If everyone is issued a certificate signed by some trusted authority, one could verify that the certificate is valid, without the certificate exposing the information about who you are. You could even have a scheme that lets the authority issue you multiple IDs, but only one for each unique ForUseWithDomain attribute, such that if you wanted to keep your identity from being correlated across different sites, you could do so. This could probably even be automated.
This would ensure that if you banned a malicious user from your site, they wouldn't be able to come back without compromising someone else's certificate. Yet, you still get a high level of anonymity.
Sites that require non-anonymous access could deny anonymous certificates, and require that you authorize access to full name perhaps. This would be like OpenID in the way it will prompt you for a site requesting additional information, like your email.