Collectively, consumers have vastly deeper pockets than any corporation could ever dream of, and they hold the ultimate power over regulation -- the vote. The problem is ultimately just that not enough of them care.
It surprises me that these corporations don't just say stuff like that at this point. They own our government, and the vast majority of people don't even give a shit. Why be coy? There are no repercussions anyway.
When the conclusions logically drawn from your premises don't match observed behavior, it's a good idea to check your premises.
Zero, if you exclude the Chinese-language market (which is presumably of little interest to US regulators). Google's market share is somewhere around 10x all their main English-language competitors combined.
I'm not sure it has ever been true that Google had >91% of the search market, but it's certainly not true now.
Google's US search market share for August 2011 was 64.8%. The next largest competitor is Yahoo, with 16.3%, followed by Microsoft with 14.7%. But since Yahoo search is actually Microsoft also, really MS has 31%. So Google has barely double Microsoft's share.
In terms of the measurement you used, Google has 1.8x the share of all of their competitors combined in the US. That's a far cry from 10x, and clearly not a monopoly.
If you want to look at this stuff, Microsoft's remaining desktop OS share is greater than Google's search share, and Microsoft clearly and unashamedly exploits their desktop share to boost their search market share. I recently bought a new PC, which came with Windows 7. I didn't use Windows/IE for long; mostly I just downloaded an Ubuntu ISO. But I did notice something that made me shake my head and chuckle.
When you install Google Chrome, the first thing it does upon starting up is ask you which search engine you want to use; Google, Yahoo or Bing. When you use IE you get Bing. Period. Even if you go into the setup to "manage search engines", I think it was called, Google is not offered as an option. I'm sure if I'd dug one level deeper there would have been a way to type in an appropriately-formatted URL to make Google IE's default search engine, but it would have required a little research.
Microsoft is not one who should be accusing Google of leveraging monopolies.
There's no point in getting hung up on the nuances of the definition of Ponzi. The core element of a Ponzi scheme is that original investors are paid with the money from new investors, not the contents of the prospectus. Yes, in most classic Ponzi schemes the structure is hidden from the investors, but that's not true in all cases, though perhaps the more open schemes should more appropriately be called "pyramid", not Ponzi. In practice, the label "Ponzi" is used to describe all sorts of schemes with this core element: Old investors receive the money of new investors, until it becomes insolvent.
And the SS system does indeed fit, in part, that core element: Those paying into SS do not receive their own money back upon retirement, they receive the money which other workers are "investing", and should outflows exceed inflows the system is in trouble. This is fundamentally different from true investment.
Anyway, regardless of the semantics, my true core point is that SS relies primarily on population growth to be sustainable. Extreme productivity growth could also make it sustainable, but thus far and for the foreseeable future population growth has swamped per-worker productivity growth and is the dominant factor.
That factor is going to flip the wrong way in a few years. If you're under 40, don't plan on ever seeing any significant return on your SS "investment". If you're under 50 you should be extremely cautious and try to self-fund your retirement. If you're already in your 60s, you're probably safe, though when SS gets into serious trouble you may find your payments being pinched somewhat.
The US Federal Government is "invested" in the prosperity of the US.
No, the social security system is invested in the working population of the US, or, more precisely, the ratio of working to retired. While the working population grows faster than the retired population, or at least maintains a reasonable ratio, the system remains solvent. When the working population dwindles too much, or the retired population grows too much, the system will fail. Given our declining birth rates and increasing longevity, only large-scale immigration and delaying retirement can keep the system going.
The social security system is much like a Ponzi scheme in that it depends on a continual influx of new blood in order to avoid failure. It's different in that it also has an outlet for the beneficiaries, a way to remove the top of the pyramid (death), but because we need many workers to support each retiree it's solvency is effectively contingent on continual population growth.
No, instead we should arbitrarily break shit simply because we can, serving no real purpose whatsoever aside from turning what was previously exceptionally stable into something that's shaky at best. Clown.
Well, part of the goal of an agile process is to reduce the amount of changes in each release, precisely for the purpose of minimizing breakage and increasing stability. I haven't used FF much lately so I can't comment on what they have or haven't achieved, but that's part of the goal.
What I don't understand is why they don't do a half way and release a new minor every 6 weeks and save the major versions for...well...major versions?
They'd never release a "major version".
The idea of a major version release is that it's one which changes a lot of things, or adds a large number of new features or a few very large features. But the idea of an agile development process, with a very short release cycle, is that you never do that. You change a few things in each release, or add a few features. When it comes to big features, you find ways to break them down into smaller features and add those incrementally. If a feature is not decomposable, then you incrementally add all of the support structure and then when you're ready you make a release that essentially does nothing but turn on that big feature.
In an agile release cycle, all releases are small updates. There just isn't time between releases to do a lot of work.
You don't understand. Displaying an advert with a custom "sale" that the user then avails themselves of is enough to transfer that information to the company that purchased the ad.
AFAIK, Google doesn't target ads that way. The advertiser doesn't get to decide what demographics see their ad; rather the ad is displayed to everyone Google's algorithms think are likely to click on it. This is actually a feature that Google touts to advertisers.
For example, think of an advertisement for a free candy bar targeted only at mormons who have also bought condoms. Ever candy bar mailed out will go to a person who isn't following their church's doctrine.
Aside: Mormon doctrine does not oppose the use of condoms or other birth control devices. Members are encouraged to have all of the children they can support, where "support" means not just financial support but all form of love, emotional support, attention, etc., but discouraged from having more children than they can manage, and ultimately the choice is left entirely up to the individual. No one questions those with small families and there aren't even any Sunday School lessons encouraging large families. Nearly all Mormon families practice some form of birth control, if for no other reason than to keep the children from coming closer together than can be managed.
Its only difference of degree, not kind, between outright selling a list of who bought item X and selling ads that are only displayed to people to purchased item X.
I disagree.
If the information itself is divulged, there is no limit to the damage that can be done, and once transferred the information can't be taken back.
If Google keeps and uses the information in-house, the uses will only be those that Google makes, and at least under Google's present policies, customers will have the ability to see exactly what Google tracks about them and to request that it be deleted.
So, the difference is between whether or not you can trust one party (Google) to honor their promises vs whether you can trust any number of unknown parties who have made no promises. Even if you don't trust the one party, there's still a very large difference between one known entity and an arbitrary number of unknown entities. A difference of kind, not just degree, because in the former case if you discover abuses at least you know who to blame.
Of course Google would love to use their privileged access to become the only company capable of providing such a cross-referencing service, so the idea is moot in this context.
You think? I don't. That would be a radical change in approach for Google.
Now, Google would offer merchants the ability to advertise through Google, with Google exploiting knowledge of where you shop and what you buy to improve ad targeting, but I can't see Google selling the information directly.
I'm not going to store my financials on a phone that doesn't have an encrypted data store. These guys are making great progress towards it, but Google needs to 'send beer' and take the patches.
The Google Wallet doesn't store your financial data on the phone, it stores it in a special security chip embedded in the phone. The data does pass through your phone when you first enter it, but is not stored in the handset main memory.
You're absolutely right, and your point is completely irrelevant. Far too many people make far too much money from copyright as it is. In order to get rid of it, you'll first need to establish alternative business models and then change the law. I'm not even talking about the typical "corps own Congress" argument, either. Even if corporate influence were to disappear overnight, there are too many individuals authors/artists/etc. whose livelihoods depend on copyright law.
No, the first step is to rationalize damages, putting P2P filesharing damages in line with reality. Stop the madness first, then gradually work to transition to a system that takes the realities of the digital age into account.
Because different verbiage can be used to implement the same thing...and in fact, a compiler could compile code in such a way that it BECOMES infringing code without the developers knowing it.
Most of the software patents I've read are written at far too high a level for either of those to be a concern; and in the second case you'd have a strong argument that it's the compiler writers who infringed, not you.
Yep. Which is why attorneys always tell software engineers NOT to search for infringing patents. Odds are that you'll find plenty if you look, and that there's really no point in working around them because they'll never come up in a lawsuit... but if you looked, and you didn't fix or license, then you're willfully infringing and are liable for treble damages. All in all, it's better just not to look and to build up a big defensive portfolio in case you get sued.
All of which just shows how badly broken the system is.
I think what's really stupid about software patents is that you can't find out what part of your software is infringing on another company's patents.
Sure you can. It's a huge amount of work, and generally not worth the effort, but it's certainly possible. And it's no different from hardware patents in that regard. What makes you think they're different?
You're assuming only public keys were compromised. If they had private keys enabling login to other hosts stored on said systems (yes, retarded, but...) then those keys are compromised.
A little more than retarded... in order for someone to do that they'd have to have never heard of ssh-agent.
How could an attacker getting hold of the public key "compromise" anything? It doesn't contain any personal information, and -- barring an earth-shattering breakthrough in cryptanalysis of RSA (or DSA, if you chose a DSA key pair) -- it can't be used to gain access to anything, not even the system it was stolen from.
That's the whole point of using asymmetric cryptography for authentication!
I'm not an electrical engineer. Why is using DC more efficient than AC? I'm assuming it arrives in the building as AC.
Computers use DC, not AC.
This means that at some point you have to do the conversion. The question is whether it's more efficient to do it in a small converter in each machine (traditional power supply unit), or to do it in a big converter that then feeds many boxes. The question isn't trivial because even though the big converter is unquestionably more efficient, you then have to deliver the DC power to the machines, and DC transmission is less efficient than AC transmission, meaning you either lose more energy to resistance or have to use bigger wires. Another common wrinkle is to convert AC to 48-volt DC then put small step-down transformers in each server or perhaps on each rack. This is because transmission of higher voltages is more efficient.
Bottom line is that there are a lot of tradeoffs and it's really not obvious what the best way to do it is, and Google's put a lot of skull sweat and experimentation into figuring out what's most efficient, and has (I think) published it.
(Disclaimer: I work for Google, but don't know anything about how power is managed in Google data centers, and haven't even read what Google has published to the world on the topic. Oh, and I am not an electrical engineer either.)
There's a single point of failure: the notary list. If you can manage to provide your own, you're set, no matter how many notaries there are.
That's more of an issue with the plugin than the system. The eventual idea is that notary lists would be distributed with the browser, the same way you get your CA list now.
Also all of the notaries are on the same domain
Another implementation flaw, not a design flaw. If this took off, I'd expect to see lots of major Internet companies providing notaries, scattered all over the Internet, across many domains and networks. Google alone could provide a fault-tolerant, highly-distributed notary network, and spoofing or blocking DNS service for google.com is obviously something Google takes pains to make very, very difficult.
Realistically most of the time you'll be seeing false positives from Perspectives.
No, for two reasons, one trivial, and one fairly profound:
First, well-managed sites deploy new certs before the old ones expire. If that weren't the case you'd see a lot of expired cert warnings now, because this is just as much a problem for the CA-based PKI than it could be for Perspectives.
Second, Perspectives really has no reason to care about certificate expirations. Its purpose is to verify that the cert being seen by the client is the same one being seen by the network of notaries. Period. Dates don't matter, name and domain fields don't matter, etc. Clients may want to check these anyway, just out of an abundance of caution, but, fundamentally, if every notary sees the same cert from a given site, then either (a) no MITM attack is being carried out on that site or (b) a MITM attack is being carried out on the site's sole connection to the Internet. And it's easy for sites to mitigate (b), by periodically querying the notaries themselves, asking what cert the notaries are seeing. The attacker can't alter the notary replies, so the very best he can do is to notice when the site makes a request and then cease his MITM attack until the notaries check and return the true cert... but that will cause notaries to see an "oscillating" certificate which is a clear warning sign, and in any case the site operator can completely defeat it by tunneling out or hitting the notaries from somewhere else.
Of course, this could backfire and Google could, wisely, realize that Yahoo offers nothing they don't already have and let Microsoft waste their cash.
This. I can't see Google even bothering, even assuming that regulators would allow it. Regulators tend not to like the biggest player in a market buying the second-biggest player in the market. Plus, it's just not Google's style.
(Disclaimer: I work for Google but I don't make strategic decisions nor do I talk to people who do. I just write code.)
Come work for me for free and I'll give you 100% of the employee stock that cannot be traded. You can keep yourself warm and fed by looking at how much value you have in the stock.
It would have to be dividend-paying stock, or would have to convert to common stock at some point in the far future. But it's not a bad idea, and it might be useful if implemented well.
It is just as hackable as any other CA, though I guess it does have the slight advantage of the attacker to modify their servers and keep the intrusion active, instead of breaking in, making a few certs, removing traces and disappearing.
I disagree.
The idea is that the client doesn't rely on just one notary, the client checks several of them, chosen at random from a large list. So the attacker has to compromise all of the notaries the client chooses to use, simultaneously, and without knowing which notaries the client might use. The attacker could block access to all of the notaries but the one he's compromised, but that's trivially defeated by configuring the client to require multiple successful validations, and to refuse to validate at all if many notaries appear to be offline.
Further, keep in mind that Marlinspike's system doesn't have to be a replacement for the existing PKI. It can stand beside it, and clients can be configured to require both systems validate a server's certificate before considering it valid. This would make the attacker's job nearly impossible.
The biggest disadvantage I can see is that having to connect to multiple notaries in order to establish an SSL connection to the server you want to get to would be slow. But it's really only necessary to do that the first time you connect to a site. After that, your browser can remember that this is the cert it's seen before for this site and simply connect without checking -- or, better yet, do the checks in a background thread after already having established the connection.
But that's not very useful, because compromising one CA gets you back to the same situation again.
No, that's the whole point, compromising one notary does NOT get you back to the same situation.
A client should contact more than one notary when it sees a new site certificate, so a single compromised notary can't fool it. Even more important, if a notary proves untrustworthy browser makers can remove that notary's certificate from their list and push an update. Under the current system, removing a CA's cert means that all sites certified by that CA lose certification, which means that shutting off Verisign or Thawte would basically make SSL stop working. But removing one notary of many wouldn't have any impact, because the remaining notaries can still vouch for all certs.
One thing that people often miss about Marlinspike's approach is that it isn't necessarily a replacement for the CA system, it can simply be an augmentation. There's nothing preventing clients from using both and only accepting a site certificate if both systems show it as valid. That would make attacks nearly impossible.
Compilers can be built up incrementally. A tiny subset of the language can be written in another language, then a more complete version of the language written in the subset, etc. New languages typically become self-hosting long before the first complete compiler for the language is produced -- or even before the language is fully designed.
Slashdot Mirror
I'm not sure it has ever been true that Google had >91% of the search market, but it's certainly not true now. .
Think global, my friend (Google certainly would)
Indeed, but that's not relevant to US regulators, which is the topic under discussion.
With deep pockets? No.
Collectively, consumers have vastly deeper pockets than any corporation could ever dream of, and they hold the ultimate power over regulation -- the vote. The problem is ultimately just that not enough of them care.
It surprises me that these corporations don't just say stuff like that at this point. They own our government, and the vast majority of people don't even give a shit. Why be coy? There are no repercussions anyway.
When the conclusions logically drawn from your premises don't match observed behavior, it's a good idea to check your premises.
Zero, if you exclude the Chinese-language market (which is presumably of little interest to US regulators). Google's market share is somewhere around 10x all their main English-language competitors combined.
I'm not sure it has ever been true that Google had >91% of the search market, but it's certainly not true now.
Google's US search market share for August 2011 was 64.8%. The next largest competitor is Yahoo, with 16.3%, followed by Microsoft with 14.7%. But since Yahoo search is actually Microsoft also, really MS has 31%. So Google has barely double Microsoft's share.
In terms of the measurement you used, Google has 1.8x the share of all of their competitors combined in the US. That's a far cry from 10x, and clearly not a monopoly.
If you want to look at this stuff, Microsoft's remaining desktop OS share is greater than Google's search share, and Microsoft clearly and unashamedly exploits their desktop share to boost their search market share. I recently bought a new PC, which came with Windows 7. I didn't use Windows/IE for long; mostly I just downloaded an Ubuntu ISO. But I did notice something that made me shake my head and chuckle.
When you install Google Chrome, the first thing it does upon starting up is ask you which search engine you want to use; Google, Yahoo or Bing. When you use IE you get Bing. Period. Even if you go into the setup to "manage search engines", I think it was called, Google is not offered as an option. I'm sure if I'd dug one level deeper there would have been a way to type in an appropriately-formatted URL to make Google IE's default search engine, but it would have required a little research.
Microsoft is not one who should be accusing Google of leveraging monopolies.
There's no point in getting hung up on the nuances of the definition of Ponzi. The core element of a Ponzi scheme is that original investors are paid with the money from new investors, not the contents of the prospectus. Yes, in most classic Ponzi schemes the structure is hidden from the investors, but that's not true in all cases, though perhaps the more open schemes should more appropriately be called "pyramid", not Ponzi. In practice, the label "Ponzi" is used to describe all sorts of schemes with this core element: Old investors receive the money of new investors, until it becomes insolvent.
And the SS system does indeed fit, in part, that core element: Those paying into SS do not receive their own money back upon retirement, they receive the money which other workers are "investing", and should outflows exceed inflows the system is in trouble. This is fundamentally different from true investment.
Anyway, regardless of the semantics, my true core point is that SS relies primarily on population growth to be sustainable. Extreme productivity growth could also make it sustainable, but thus far and for the foreseeable future population growth has swamped per-worker productivity growth and is the dominant factor.
That factor is going to flip the wrong way in a few years. If you're under 40, don't plan on ever seeing any significant return on your SS "investment". If you're under 50 you should be extremely cautious and try to self-fund your retirement. If you're already in your 60s, you're probably safe, though when SS gets into serious trouble you may find your payments being pinched somewhat.
The US Federal Government is "invested" in the prosperity of the US.
No, the social security system is invested in the working population of the US, or, more precisely, the ratio of working to retired. While the working population grows faster than the retired population, or at least maintains a reasonable ratio, the system remains solvent. When the working population dwindles too much, or the retired population grows too much, the system will fail. Given our declining birth rates and increasing longevity, only large-scale immigration and delaying retirement can keep the system going.
The social security system is much like a Ponzi scheme in that it depends on a continual influx of new blood in order to avoid failure. It's different in that it also has an outlet for the beneficiaries, a way to remove the top of the pyramid (death), but because we need many workers to support each retiree it's solvency is effectively contingent on continual population growth.
No, instead we should arbitrarily break shit simply because we can, serving no real purpose whatsoever aside from turning what was previously exceptionally stable into something that's shaky at best. Clown.
Well, part of the goal of an agile process is to reduce the amount of changes in each release, precisely for the purpose of minimizing breakage and increasing stability. I haven't used FF much lately so I can't comment on what they have or haven't achieved, but that's part of the goal.
What I don't understand is why they don't do a half way and release a new minor every 6 weeks and save the major versions for...well...major versions?
They'd never release a "major version".
The idea of a major version release is that it's one which changes a lot of things, or adds a large number of new features or a few very large features. But the idea of an agile development process, with a very short release cycle, is that you never do that. You change a few things in each release, or add a few features. When it comes to big features, you find ways to break them down into smaller features and add those incrementally. If a feature is not decomposable, then you incrementally add all of the support structure and then when you're ready you make a release that essentially does nothing but turn on that big feature.
In an agile release cycle, all releases are small updates. There just isn't time between releases to do a lot of work.
You don't understand. Displaying an advert with a custom "sale" that the user then avails themselves of is enough to transfer that information to the company that purchased the ad.
AFAIK, Google doesn't target ads that way. The advertiser doesn't get to decide what demographics see their ad; rather the ad is displayed to everyone Google's algorithms think are likely to click on it. This is actually a feature that Google touts to advertisers.
For example, think of an advertisement for a free candy bar targeted only at mormons who have also bought condoms. Ever candy bar mailed out will go to a person who isn't following their church's doctrine.
Aside: Mormon doctrine does not oppose the use of condoms or other birth control devices. Members are encouraged to have all of the children they can support, where "support" means not just financial support but all form of love, emotional support, attention, etc., but discouraged from having more children than they can manage, and ultimately the choice is left entirely up to the individual. No one questions those with small families and there aren't even any Sunday School lessons encouraging large families. Nearly all Mormon families practice some form of birth control, if for no other reason than to keep the children from coming closer together than can be managed.
Its only difference of degree, not kind, between outright selling a list of who bought item X and selling ads that are only displayed to people to purchased item X.
I disagree.
If the information itself is divulged, there is no limit to the damage that can be done, and once transferred the information can't be taken back.
If Google keeps and uses the information in-house, the uses will only be those that Google makes, and at least under Google's present policies, customers will have the ability to see exactly what Google tracks about them and to request that it be deleted.
So, the difference is between whether or not you can trust one party (Google) to honor their promises vs whether you can trust any number of unknown parties who have made no promises. Even if you don't trust the one party, there's still a very large difference between one known entity and an arbitrary number of unknown entities. A difference of kind, not just degree, because in the former case if you discover abuses at least you know who to blame.
Of course Google would love to use their privileged access to become the only company capable of providing such a cross-referencing service, so the idea is moot in this context.
You think? I don't. That would be a radical change in approach for Google.
Now, Google would offer merchants the ability to advertise through Google, with Google exploiting knowledge of where you shop and what you buy to improve ad targeting, but I can't see Google selling the information directly.
I'm not going to store my financials on a phone that doesn't have an encrypted data store. These guys are making great progress towards it, but Google needs to 'send beer' and take the patches.
The Google Wallet doesn't store your financial data on the phone, it stores it in a special security chip embedded in the phone. The data does pass through your phone when you first enter it, but is not stored in the handset main memory.
You're absolutely right, and your point is completely irrelevant. Far too many people make far too much money from copyright as it is. In order to get rid of it, you'll first need to establish alternative business models and then change the law. I'm not even talking about the typical "corps own Congress" argument, either. Even if corporate influence were to disappear overnight, there are too many individuals authors/artists/etc. whose livelihoods depend on copyright law.
No, the first step is to rationalize damages, putting P2P filesharing damages in line with reality. Stop the madness first, then gradually work to transition to a system that takes the realities of the digital age into account.
Because different verbiage can be used to implement the same thing...and in fact, a compiler could compile code in such a way that it BECOMES infringing code without the developers knowing it.
Most of the software patents I've read are written at far too high a level for either of those to be a concern; and in the second case you'd have a strong argument that it's the compiler writers who infringed, not you.
Yep. Which is why attorneys always tell software engineers NOT to search for infringing patents. Odds are that you'll find plenty if you look, and that there's really no point in working around them because they'll never come up in a lawsuit... but if you looked, and you didn't fix or license, then you're willfully infringing and are liable for treble damages. All in all, it's better just not to look and to build up a big defensive portfolio in case you get sued.
All of which just shows how badly broken the system is.
I think what's really stupid about software patents is that you can't find out what part of your software is infringing on another company's patents.
Sure you can. It's a huge amount of work, and generally not worth the effort, but it's certainly possible. And it's no different from hardware patents in that regard. What makes you think they're different?
You're assuming only public keys were compromised. If they had private keys enabling login to other hosts stored on said systems (yes, retarded, but...) then those keys are compromised.
A little more than retarded... in order for someone to do that they'd have to have never heard of ssh-agent.
How could an attacker getting hold of the public key "compromise" anything? It doesn't contain any personal information, and -- barring an earth-shattering breakthrough in cryptanalysis of RSA (or DSA, if you chose a DSA key pair) -- it can't be used to gain access to anything, not even the system it was stolen from.
That's the whole point of using asymmetric cryptography for authentication!
I'm not an electrical engineer. Why is using DC more efficient than AC? I'm assuming it arrives in the building as AC.
Computers use DC, not AC.
This means that at some point you have to do the conversion. The question is whether it's more efficient to do it in a small converter in each machine (traditional power supply unit), or to do it in a big converter that then feeds many boxes. The question isn't trivial because even though the big converter is unquestionably more efficient, you then have to deliver the DC power to the machines, and DC transmission is less efficient than AC transmission, meaning you either lose more energy to resistance or have to use bigger wires. Another common wrinkle is to convert AC to 48-volt DC then put small step-down transformers in each server or perhaps on each rack. This is because transmission of higher voltages is more efficient.
Bottom line is that there are a lot of tradeoffs and it's really not obvious what the best way to do it is, and Google's put a lot of skull sweat and experimentation into figuring out what's most efficient, and has (I think) published it.
(Disclaimer: I work for Google, but don't know anything about how power is managed in Google data centers, and haven't even read what Google has published to the world on the topic. Oh, and I am not an electrical engineer either.)
There's a single point of failure: the notary list. If you can manage to provide your own, you're set, no matter how many notaries there are.
That's more of an issue with the plugin than the system. The eventual idea is that notary lists would be distributed with the browser, the same way you get your CA list now.
Also all of the notaries are on the same domain
Another implementation flaw, not a design flaw. If this took off, I'd expect to see lots of major Internet companies providing notaries, scattered all over the Internet, across many domains and networks. Google alone could provide a fault-tolerant, highly-distributed notary network, and spoofing or blocking DNS service for google.com is obviously something Google takes pains to make very, very difficult.
Realistically most of the time you'll be seeing false positives from Perspectives.
No, for two reasons, one trivial, and one fairly profound:
First, well-managed sites deploy new certs before the old ones expire. If that weren't the case you'd see a lot of expired cert warnings now, because this is just as much a problem for the CA-based PKI than it could be for Perspectives.
Second, Perspectives really has no reason to care about certificate expirations. Its purpose is to verify that the cert being seen by the client is the same one being seen by the network of notaries. Period. Dates don't matter, name and domain fields don't matter, etc. Clients may want to check these anyway, just out of an abundance of caution, but, fundamentally, if every notary sees the same cert from a given site, then either (a) no MITM attack is being carried out on that site or (b) a MITM attack is being carried out on the site's sole connection to the Internet. And it's easy for sites to mitigate (b), by periodically querying the notaries themselves, asking what cert the notaries are seeing. The attacker can't alter the notary replies, so the very best he can do is to notice when the site makes a request and then cease his MITM attack until the notaries check and return the true cert... but that will cause notaries to see an "oscillating" certificate which is a clear warning sign, and in any case the site operator can completely defeat it by tunneling out or hitting the notaries from somewhere else.
Of course, this could backfire and Google could, wisely, realize that Yahoo offers nothing they don't already have and let Microsoft waste their cash.
This. I can't see Google even bothering, even assuming that regulators would allow it. Regulators tend not to like the biggest player in a market buying the second-biggest player in the market. Plus, it's just not Google's style.
(Disclaimer: I work for Google but I don't make strategic decisions nor do I talk to people who do. I just write code.)
Come work for me for free and I'll give you 100% of the employee stock that cannot be traded. You can keep yourself warm and fed by looking at how much value you have in the stock.
It would have to be dividend-paying stock, or would have to convert to common stock at some point in the far future. But it's not a bad idea, and it might be useful if implemented well.
It is just as hackable as any other CA, though I guess it does have the slight advantage of the attacker to modify their servers and keep the intrusion active, instead of breaking in, making a few certs, removing traces and disappearing.
I disagree.
The idea is that the client doesn't rely on just one notary, the client checks several of them, chosen at random from a large list. So the attacker has to compromise all of the notaries the client chooses to use, simultaneously, and without knowing which notaries the client might use. The attacker could block access to all of the notaries but the one he's compromised, but that's trivially defeated by configuring the client to require multiple successful validations, and to refuse to validate at all if many notaries appear to be offline.
Further, keep in mind that Marlinspike's system doesn't have to be a replacement for the existing PKI. It can stand beside it, and clients can be configured to require both systems validate a server's certificate before considering it valid. This would make the attacker's job nearly impossible.
The biggest disadvantage I can see is that having to connect to multiple notaries in order to establish an SSL connection to the server you want to get to would be slow. But it's really only necessary to do that the first time you connect to a site. After that, your browser can remember that this is the cert it's seen before for this site and simply connect without checking -- or, better yet, do the checks in a background thread after already having established the connection.
But that's not very useful, because compromising one CA gets you back to the same situation again.
No, that's the whole point, compromising one notary does NOT get you back to the same situation.
A client should contact more than one notary when it sees a new site certificate, so a single compromised notary can't fool it. Even more important, if a notary proves untrustworthy browser makers can remove that notary's certificate from their list and push an update. Under the current system, removing a CA's cert means that all sites certified by that CA lose certification, which means that shutting off Verisign or Thawte would basically make SSL stop working. But removing one notary of many wouldn't have any impact, because the remaining notaries can still vouch for all certs.
One thing that people often miss about Marlinspike's approach is that it isn't necessarily a replacement for the CA system, it can simply be an augmentation. There's nothing preventing clients from using both and only accepting a site certificate if both systems show it as valid. That would make attacks nearly impossible.
Compilers can be built up incrementally. A tiny subset of the language can be written in another language, then a more complete version of the language written in the subset, etc. New languages typically become self-hosting long before the first complete compiler for the language is produced -- or even before the language is fully designed.