Ultimately, it comes down to the people making movies being in it only for the money. It stopped being about talent and drive to create something amazing a long time ago. These days, it's about maximizing profit. That will continue until such time as enough small teams are creating good movies and cleaning their chronometers.
And really, that's for the best. Back when film was the only way to do things, making a movie was really expensive, both in terms of equipment and film/processing/editing, so it made sense to have a few big companies that controlled the production. And showing movies was expensive, so it made sense to have those movie production houses also own theater chains, etc. These days, making movies is cheap, and distributing movies is cheap, making these behemoths largely obsolete. Over time, they will be replaced by smaller firms doing the same thing, and those firms will be driven more by the art than by the dollar because they will be run by creative people instead of by MBAs. And if they end up being run by MBAs, it will be cheap enough for new people to create new firms to push them out of the way.
Along with the OCSP infrastructure, plus the additional manpower and infrastructure to provide a way for users to generate a new cert for their signing key every couple of years.
A crypto key is free to generate. Certs are not, and without a cert, a bare crypto key provides no additional security.
You're arguing that the right to write code on an arbitrary device that was not designed to run third-party code is an essential liberty. I would argue that this is a pretty serious stretch.
As for comparing the GPLv3 situation to China, that's a ludicrous stretch. China blocks content because it is harmful to the Chinese government, not because it is harmful to the Chinese people. By your argument, we should not have a border patrol or a police force because they can deprive people of the right to commit mass murder.
Freedom does bring risk, and it is messy, but without limits, there can be no freedom. Freedom without limits cannot truly exist for any person unless you deny someone else freedom without limits. By its very nature, I cannot be free to shoot a firearm anywhere I want to without depriving others of one of their inalienable rights—that of life, specifically. So the notion of pure freedom is really just a pipe dream constructed by people in ivory towers looking down on the real world.
In the real world, freedom must be balanced by responsibility, and when it is not balanced by responsibility, it must be balanced by rules to ensure that, as Oliver Wendell Holmes Jr. put it, "the freedom to swing my fist ends where the other man's nose begins."
iPhone and friends do provide a way to import a signing certificate. It just costs money to obtain the certs because the infrastructure needed to support those certs costs money. Therefore, the GPL effectively prevents any useful implementation of code signing.
If you allow import of arbitrary (self-signed) certs, you might as well be allowing unsigned code, and if you put in a switch to allow unsigned code, somebody is going to find a way to throw that switch without the user's knowledge. It's inevitable. At that point, you have no security.
And if you allow import of certs signed by a large number of authorities, you have the problem that none of those CAs support extensions to limit the code to a specific device, which effectively means that a virus, trojan, worm, etc. signed with their certs can run rampant.
I've thought about this a lot, and I really don't see a better way that retains even a modicum of security from code signing. Either way, the point is that it isn't a case of wanting control for control's sake, but rather wanting control to prevent harm to the users. I realize that the notion of absolute freedom meaning absolute anarchy seems like a good idea to some folks, but most folks would prefer at least some limits to protect them from harm.
That said, I do wish Apple would come up with a way for people to (for free) register their own personal devices and obtain a signing key for those devices. I don't expect it because, as I've noted, it costs money to run a CA, but it would be nice.
Which does exactly two things for security: jack and squat. If somebody finds a way to maliciously modify the daemon, do you really think they can't modify a signature file, too?
And besides, the real security comes not from preventing on-disk modification, but from preventing modification during execution, which means there's a significant win to having the signature information as part of the binary itself. This really has to be done at the kernel level.
No, that actually doesn't solve the problem. Do you know how many security exploits there have been in which a user was tricked into installing something? So as I said before, allowing self-signed certs is not significantly better in practice than allowing unsigned binaries.
The GPLv2 allowed them to do an end run where you could modify and use the software, but never on the device that it was distributed on. This was corrected in GPLv3, and control-freak assholes are having a problem with it.
It's not just control freaks that have a problem with it. It's also security-conscious engineering teams. Those bits of GPLv3 betray a fundamental lack of understanding of the need for proper code signing.
First of all, there is no good way to prevent unsigned virus code from running without preventing unsigned user code from running on a device. The last thing you want is a news story talking about how your phone has been compromised by a virus that spreads across the cell network by SMS and has turned your entire ecosystem into the cell phone equivalent of WinZombies. This goes triply for daemons like Samba, which represent prime attack vectors into home and corporate computers, and thus are in desperate need of signature checks.
Unfortunately, any OS vendor that wants to deploy Samba cannot require that it be signed by a proper, valid code signing cert because those cost money, and would represent an additional restriction on the end user's ability to recompile Samba and run the new version. This makes the GPLv3 fundamentally antithetical to proper security as written, at least by my reading. And I'm not the only one who interprets it this way.
More to the point, you cannot create an arbitrarily open ecosystem that allows for anyone to get a code signing cert from anywhere, as this gives you no additional protection over not requiring signing. If you can get a free cert that allows you to run code on arbitrary hardware, then a a virus writer can, too. Thus, the infrastructure must inherently be designed so that third-party code can be authorized on a per-device basis. This is nontrivial, and costs money to maintain. Yet the GPLv3 would require that such a service be free to use in order to comply with a strict reading of its terms. Clearly, this is an untenable position.
In short, this isn't a knee jerk reaction by a bunch of control freaks. Quite the opposite, really. The GPLv3 was a poorly thought out knee jerk reaction to a bunch of control freaks that had a negative impact on consumers. So although I understand why the GPL proponents want these clauses, in the end, they're doing a disservice to themselves and to the community by policies that effectively prevent the proper use of signed binaries.
Are you saying that SSH is not useful? Read my post again.
should be treated as a production cert, but with permanent memorization.
Emphasis mine. Yes, it is vulnerable to a man-in-the-middle attack. Exactly once. After you've made one connection, you're safe to connect to that particular host forever and ever... unless and until somebody legitimately has to change keys and certs without signing the new one with the same CA cert. At that point, you're unsafe one more time (and, hopefully, suspicious about the competence of the site's admins by this point).
And if you connect to the site, then take your computer to a different network and make the connection again and don't get screamed at (because the host key has changed), you can pretty much feel confident that you aren't getting hit by a man-in-the middle attack unless your computer is thoroughly 0wn3d, in which case it really doesn't matter if the traffic is encrypted because your keystrokes are probably being sniffed anyway.:-)
Let me just make sure I'm making myself clear here. It is very important that the browser permanently remember the cert authorized for a given site. Without that, an encrypted connection is easy enough to spoof that it would not be significantly safer than plain HTTP.
Such a system is technically vulnerable to a man-in-the-middle attack, true, but only the very first time you connect to a site. And if you're really paranoid, you could connect to the site from home, then connect to the same site from work and make sure you don't get a "host key has changed" dialog before you trust the site with any personal info.
The point is that most people would not describe SSH as particularly insecure. Each client computer keeps track of the keys, and if they change, it screams bloody murder. Modify that slightly to use self-signed SSL certs, and make the browser also remember the fake CA cert used to sign the cert and make the browser allow that CA cert to sign new certs (including new versions of the CA cert) in the future. With that relatively small change to the SSL infrastructure on the policy side, you would avoid warnings even as self-signed certs expire (as long as people take the time to update their certs once in a while).
In effect, such a scheme would be "good enough" for pretty much everything but e-commerce sites.
Yup. That would be because my box hosts a couple of dozen domains, and SSL sucks at virtual hosting. If there were a solution for encryption that didn't involve your immortal soul every year for a multi-site cert, all my sites would be encrypted. Something like I suggested would completely solve that problem because you would be able to self-sign a single cert for multiple domains, and everyone's computer would simply remember that cert.
The only options for me right now would be to either spend a fortune on a multi-site cert or use a separate IP for each site. Neither of these is feasible for sites run out of somebody's home, hence I had to pick and choose what to encrypt with SSL. I don't like it, but I didn't really have any other good options. Indeed, it's my inability to do the encryption that I feel like my site needs that is the driving force behind my desire for improvements in the system.
Well, ultimately, the flaw is that the CAs are allowed to deliberately conflate identity with encryption to boost sales. The fact is that 99.999% of sites do NOT need rigorous identity checks, but 100% of all websites SHOULD use encryption.
In parallel with SSL, we should adopt a protocol similar to what SSH does, in which, upon connecting to a service, you decide if you trust it, and then your browser remembers the key fingerprint for that browser. This should not be in the form of a scary "this site may be masquerading as another site" dialog, but rather as a legitimate alternative that establishes encryption without establishing identity. Essentially, it should be a special flag that indicates that this self-signed cert should be treated as a production cert, but with permanent memorization.
By having such a system, true, high-security systems like banks would continue to pay their small fortune to a CA to get an EV cert. Normal certs would go away because as we know, they really don't provide any real value from an identity perspective anyway, and their very existence lulls people into a false sense of security.
On the other hand, if the phone manufacturers did not distribute the software at all, but rather required you to run a piece of software that downloads and installs the OS directly from Google, it would likely absolve them. I think that's what the GP was trying to get at. Or maybe not. Hard to say. My interpretation was that they were looking for a way to shift the patent suits to Google (where they belong) instead of to a mere distributor.
Actually, this is one thing that bothers me about patent law. I'm of the opinion that one tiny change would make it much, much better: require that any lawsuit over patent infringement must first occur with the first party in the supply chain that ostensibly infringed the patent. In this case, it would be Google. In the case of commercial codec licensing, it would be the manufacturer of the video gear that did not pay a commercial use licensing fee, but who should reasonably have known when they sold the product to you that it would be used commercially. In the case of a chip vendor suing a product vendor for using their patented technology, that product vendor could simply point up the chain and say, "You have to sue the chip vendor that provided us with those parts first." And so on.
Require a judgment for each vendor in the chain prior to filing suit against the next vendor, and make it grounds for dismissal of the case (with prejudice for repeat offenders) if this rule is not followed. Finally, make it such that if the previous case did not find in favor of the plaintiff, the plaintiff must prove that the primary reason for that loss was that the earlier vendor could not have been aware that the later vendor was going to use the product in an infringing way.
*shrugs* I'm just basing my comment on what the blurb at the top says the patent is about. This is Slashdot. Do you really expect me to read the article, much less the patent linked to by the article?
Not when they act in ways that looks an awful lot like collusion (one service raises rates and the other immediately follows, one service cuts services and the other immediately follows, etc.).
Ultimately, whether they really are colluding or not isn't really the point. From a consumer's point of view, they act in lockstep, so they aren't really competing in any useful sense of the word..
FWIW, I had no trouble getting my ATTWS blue phone unlocked by the new AT&T, and further, I continued to use my blue phone plan and (GSM) SIM up until I got my iPhone in 2007 (at which point they told me that my legacy plan was not supported for iPhone customers), so that problem is not universal. I did hear stories about such problems for people who were on *other* companies that Cingular gobbled up, though, and they did force all the legacy TDMA users to switch.
I don't think the melting point of beryllium would be a problem. The moderator is inside the sphere, not on the surface. The outer shell is ceramic. Thus, even at maximum operating temperature, it shouldn't be an issue. Besides, the uranium itself is liquid at the specified maximum operating temperature. I'm not sure how much difference it makes for the moderator to also be liquid, so long as it is still able to adequately moderate neutron emissions. (This might require an extra layer of ceramic to separate the two. I'm not sure.)
Then again, the only time the graphite would be an issue would be if the ceramic cracks, so you'd still experience a serious failure under the same conditions, just without the same devastating result (nuclear fallout) under said conditions.
***Humorously, the reason I originally switched from AT&T was because their capacity was so poor that on a regular basis, whenever I tried to make a call from the Livonia, MI area (which is a large suburb smack dab in the of the metro Detroit area, nowhere near the outskirts of the densely populated area, and right along one of the major expressways), they would connect me to a competitors tower and charge me roaming fees.
That usually indicates a dead spot, not congestion. Also, it's your phone that chooses which towers to roam onto, or at least does the priority ranking. You can tell your phone to not use other companies' towers. I bet if you did this, you would find that there's little or no AT&T signal at that location.
At least you're not far enough North to be roaming onto Canadian towers.
Most of those problems are about shielding and disposing of the plant when you shut it down. The remainder can be solved by using a moderator that doesn't burn. You don't have to use graphite. You could, for example, use beryllium....
I would argue that AT&T has already abused their near-monopoly position in ways that violate anti-trust laws, and that the whole purpose of the DOJ's trust busting is to prevent mergers and combinations that would result in increased violations of those laws.
Slashdot Mirror
Ultimately, it comes down to the people making movies being in it only for the money. It stopped being about talent and drive to create something amazing a long time ago. These days, it's about maximizing profit. That will continue until such time as enough small teams are creating good movies and cleaning their chronometers.
And really, that's for the best. Back when film was the only way to do things, making a movie was really expensive, both in terms of equipment and film/processing/editing, so it made sense to have a few big companies that controlled the production. And showing movies was expensive, so it made sense to have those movie production houses also own theater chains, etc. These days, making movies is cheap, and distributing movies is cheap, making these behemoths largely obsolete. Over time, they will be replaced by smaller firms doing the same thing, and those firms will be driven more by the art than by the dollar because they will be run by creative people instead of by MBAs. And if they end up being run by MBAs, it will be cheap enough for new people to create new firms to push them out of the way.
Along with the OCSP infrastructure, plus the additional manpower and infrastructure to provide a way for users to generate a new cert for their signing key every couple of years.
A crypto key is free to generate. Certs are not, and without a cert, a bare crypto key provides no additional security.
You're arguing that the right to write code on an arbitrary device that was not designed to run third-party code is an essential liberty. I would argue that this is a pretty serious stretch.
As for comparing the GPLv3 situation to China, that's a ludicrous stretch. China blocks content because it is harmful to the Chinese government, not because it is harmful to the Chinese people. By your argument, we should not have a border patrol or a police force because they can deprive people of the right to commit mass murder.
Freedom does bring risk, and it is messy, but without limits, there can be no freedom. Freedom without limits cannot truly exist for any person unless you deny someone else freedom without limits. By its very nature, I cannot be free to shoot a firearm anywhere I want to without depriving others of one of their inalienable rights—that of life, specifically. So the notion of pure freedom is really just a pipe dream constructed by people in ivory towers looking down on the real world.
In the real world, freedom must be balanced by responsibility, and when it is not balanced by responsibility, it must be balanced by rules to ensure that, as Oliver Wendell Holmes Jr. put it, "the freedom to swing my fist ends where the other man's nose begins."
iPhone and friends do provide a way to import a signing certificate. It just costs money to obtain the certs because the infrastructure needed to support those certs costs money. Therefore, the GPL effectively prevents any useful implementation of code signing.
If you allow import of arbitrary (self-signed) certs, you might as well be allowing unsigned code, and if you put in a switch to allow unsigned code, somebody is going to find a way to throw that switch without the user's knowledge. It's inevitable. At that point, you have no security.
And if you allow import of certs signed by a large number of authorities, you have the problem that none of those CAs support extensions to limit the code to a specific device, which effectively means that a virus, trojan, worm, etc. signed with their certs can run rampant.
I've thought about this a lot, and I really don't see a better way that retains even a modicum of security from code signing. Either way, the point is that it isn't a case of wanting control for control's sake, but rather wanting control to prevent harm to the users. I realize that the notion of absolute freedom meaning absolute anarchy seems like a good idea to some folks, but most folks would prefer at least some limits to protect them from harm.
That said, I do wish Apple would come up with a way for people to (for free) register their own personal devices and obtain a signing key for those devices. I don't expect it because, as I've noted, it costs money to run a CA, but it would be nice.
Which does exactly two things for security: jack and squat. If somebody finds a way to maliciously modify the daemon, do you really think they can't modify a signature file, too?
And besides, the real security comes not from preventing on-disk modification, but from preventing modification during execution, which means there's a significant win to having the signature information as part of the binary itself. This really has to be done at the kernel level.
No, that actually doesn't solve the problem. Do you know how many security exploits there have been in which a user was tricked into installing something? So as I said before, allowing self-signed certs is not significantly better in practice than allowing unsigned binaries.
It's not just control freaks that have a problem with it. It's also security-conscious engineering teams. Those bits of GPLv3 betray a fundamental lack of understanding of the need for proper code signing.
First of all, there is no good way to prevent unsigned virus code from running without preventing unsigned user code from running on a device. The last thing you want is a news story talking about how your phone has been compromised by a virus that spreads across the cell network by SMS and has turned your entire ecosystem into the cell phone equivalent of WinZombies. This goes triply for daemons like Samba, which represent prime attack vectors into home and corporate computers, and thus are in desperate need of signature checks.
Unfortunately, any OS vendor that wants to deploy Samba cannot require that it be signed by a proper, valid code signing cert because those cost money, and would represent an additional restriction on the end user's ability to recompile Samba and run the new version. This makes the GPLv3 fundamentally antithetical to proper security as written, at least by my reading. And I'm not the only one who interprets it this way.
More to the point, you cannot create an arbitrarily open ecosystem that allows for anyone to get a code signing cert from anywhere, as this gives you no additional protection over not requiring signing. If you can get a free cert that allows you to run code on arbitrary hardware, then a a virus writer can, too. Thus, the infrastructure must inherently be designed so that third-party code can be authorized on a per-device basis. This is nontrivial, and costs money to maintain. Yet the GPLv3 would require that such a service be free to use in order to comply with a strict reading of its terms. Clearly, this is an untenable position.
In short, this isn't a knee jerk reaction by a bunch of control freaks. Quite the opposite, really. The GPLv3 was a poorly thought out knee jerk reaction to a bunch of control freaks that had a negative impact on consumers. So although I understand why the GPL proponents want these clauses, in the end, they're doing a disservice to themselves and to the community by policies that effectively prevent the proper use of signed binaries.
Are you saying that SSH is not useful? Read my post again.
Emphasis mine. Yes, it is vulnerable to a man-in-the-middle attack. Exactly once. After you've made one connection, you're safe to connect to that particular host forever and ever... unless and until somebody legitimately has to change keys and certs without signing the new one with the same CA cert. At that point, you're unsafe one more time (and, hopefully, suspicious about the competence of the site's admins by this point).
And if you connect to the site, then take your computer to a different network and make the connection again and don't get screamed at (because the host key has changed), you can pretty much feel confident that you aren't getting hit by a man-in-the middle attack unless your computer is thoroughly 0wn3d, in which case it really doesn't matter if the traffic is encrypted because your keystrokes are probably being sniffed anyway. :-)
Let me just make sure I'm making myself clear here. It is very important that the browser permanently remember the cert authorized for a given site. Without that, an encrypted connection is easy enough to spoof that it would not be significantly safer than plain HTTP.
Such a system is technically vulnerable to a man-in-the-middle attack, true, but only the very first time you connect to a site. And if you're really paranoid, you could connect to the site from home, then connect to the same site from work and make sure you don't get a "host key has changed" dialog before you trust the site with any personal info.
The point is that most people would not describe SSH as particularly insecure. Each client computer keeps track of the keys, and if they change, it screams bloody murder. Modify that slightly to use self-signed SSL certs, and make the browser also remember the fake CA cert used to sign the cert and make the browser allow that CA cert to sign new certs (including new versions of the CA cert) in the future. With that relatively small change to the SSL infrastructure on the policy side, you would avoid warnings even as self-signed certs expire (as long as people take the time to update their certs once in a while).
In effect, such a scheme would be "good enough" for pretty much everything but e-commerce sites.
Yup. That would be because my box hosts a couple of dozen domains, and SSL sucks at virtual hosting. If there were a solution for encryption that didn't involve your immortal soul every year for a multi-site cert, all my sites would be encrypted. Something like I suggested would completely solve that problem because you would be able to self-sign a single cert for multiple domains, and everyone's computer would simply remember that cert.
The only options for me right now would be to either spend a fortune on a multi-site cert or use a separate IP for each site. Neither of these is feasible for sites run out of somebody's home, hence I had to pick and choose what to encrypt with SSL. I don't like it, but I didn't really have any other good options. Indeed, it's my inability to do the encryption that I feel like my site needs that is the driving force behind my desire for improvements in the system.
Yeah, but for that short period of time, a bunch of manufacturers found themselves in a sticky situation.
Obligatory HHGG reference: It wioll haven be posted?
Well, ultimately, the flaw is that the CAs are allowed to deliberately conflate identity with encryption to boost sales. The fact is that 99.999% of sites do NOT need rigorous identity checks, but 100% of all websites SHOULD use encryption.
In parallel with SSL, we should adopt a protocol similar to what SSH does, in which, upon connecting to a service, you decide if you trust it, and then your browser remembers the key fingerprint for that browser. This should not be in the form of a scary "this site may be masquerading as another site" dialog, but rather as a legitimate alternative that establishes encryption without establishing identity. Essentially, it should be a special flag that indicates that this self-signed cert should be treated as a production cert, but with permanent memorization.
By having such a system, true, high-security systems like banks would continue to pay their small fortune to a CA to get an EV cert. Normal certs would go away because as we know, they really don't provide any real value from an identity perspective anyway, and their very existence lulls people into a false sense of security.
On the other hand, if the phone manufacturers did not distribute the software at all, but rather required you to run a piece of software that downloads and installs the OS directly from Google, it would likely absolve them. I think that's what the GP was trying to get at. Or maybe not. Hard to say. My interpretation was that they were looking for a way to shift the patent suits to Google (where they belong) instead of to a mere distributor.
Actually, this is one thing that bothers me about patent law. I'm of the opinion that one tiny change would make it much, much better: require that any lawsuit over patent infringement must first occur with the first party in the supply chain that ostensibly infringed the patent. In this case, it would be Google. In the case of commercial codec licensing, it would be the manufacturer of the video gear that did not pay a commercial use licensing fee, but who should reasonably have known when they sold the product to you that it would be used commercially. In the case of a chip vendor suing a product vendor for using their patented technology, that product vendor could simply point up the chain and say, "You have to sue the chip vendor that provided us with those parts first." And so on.
Require a judgment for each vendor in the chain prior to filing suit against the next vendor, and make it grounds for dismissal of the case (with prejudice for repeat offenders) if this rule is not followed. Finally, make it such that if the previous case did not find in favor of the plaintiff, the plaintiff must prove that the primary reason for that loss was that the earlier vendor could not have been aware that the later vendor was going to use the product in an infringing way.
Or slashdot rounds the percentages to the nearest tens place. 33.33333% rounds down to 30%, 66.66666 rounds up to 70%.
*shrugs* I'm just basing my comment on what the blurb at the top says the patent is about. This is Slashdot. Do you really expect me to read the article, much less the patent linked to by the article?
Um.... You're not supposed to swallow the balls of fuel....
Not when they act in ways that looks an awful lot like collusion (one service raises rates and the other immediately follows, one service cuts services and the other immediately follows, etc.).
Ultimately, whether they really are colluding or not isn't really the point. From a consumer's point of view, they act in lockstep, so they aren't really competing in any useful sense of the word..
FWIW, I had no trouble getting my ATTWS blue phone unlocked by the new AT&T, and further, I continued to use my blue phone plan and (GSM) SIM up until I got my iPhone in 2007 (at which point they told me that my legacy plan was not supported for iPhone customers), so that problem is not universal. I did hear stories about such problems for people who were on *other* companies that Cingular gobbled up, though, and they did force all the legacy TDMA users to switch.
I don't think the melting point of beryllium would be a problem. The moderator is inside the sphere, not on the surface. The outer shell is ceramic. Thus, even at maximum operating temperature, it shouldn't be an issue. Besides, the uranium itself is liquid at the specified maximum operating temperature. I'm not sure how much difference it makes for the moderator to also be liquid, so long as it is still able to adequately moderate neutron emissions. (This might require an extra layer of ceramic to separate the two. I'm not sure.)
Then again, the only time the graphite would be an issue would be if the ceramic cracks, so you'd still experience a serious failure under the same conditions, just without the same devastating result (nuclear fallout) under said conditions.
That usually indicates a dead spot, not congestion. Also, it's your phone that chooses which towers to roam onto, or at least does the priority ranking. You can tell your phone to not use other companies' towers. I bet if you did this, you would find that there's little or no AT&T signal at that location.
At least you're not far enough North to be roaming onto Canadian towers.
Yeah, I mean misogyny in a Duke Nukem game, I can believe, but do you really expect me to believe that DNF is going to ship!?!
Most of those problems are about shielding and disposing of the plant when you shut it down. The remainder can be solved by using a moderator that doesn't burn. You don't have to use graphite. You could, for example, use beryllium....
Didn't Netscape 1.0 do this? You know, before the background attribute was added? So they have a patent on programmatic regression?
I would argue that AT&T has already abused their near-monopoly position in ways that violate anti-trust laws, and that the whole purpose of the DOJ's trust busting is to prevent mergers and combinations that would result in increased violations of those laws.