Actually, depending on what the certificates are used for, if they were compromised any time during their lifetime, they may need to remain on a CRL effectively forever.
For example, if a certificate is used to sign code, and code signed after the certificate was compromised cannot be trusted. A validity check can occur even years after the certificate expired.
If it is only used for SSL, this is not an issue. But certificates are used for much more than that.
Suppose I forward a signed email to you that I received three years ago. The key that signed it may not be valid now -- but what you really do want to know is if it was valid at the time that email was sent.
But you only use one copy. The other copies are there to bypass functional checks. This is legal under scenes a faire.
To put it another way, the copy they patch is the one that you are lawfully using. The other copies exist only to pass a security check, where only that exact code will pass the check. Copyright doesn't cover cases where there is only one way to get something done, you need patent for that. Copyright only covers one way out of millions of equally good ways. What are the other equally good ways to pass Blizzard's security check?
This history of the Internet proves this attitude wrong. Sure, governments try to regulate the Internet and restrict the free flow of information. The problem is that they generally fail to do so, and as a result, freedom is making significant progress around the world.
Ubiquitous encryption is the next step in this same direction. This will force organizations in the United States to decide whether they want to try to clamp down on this or let it go free. They have been unable to clamp down in the past, and they know that if they clamp down, what can they say the next time China clamps down?
Freedom will win. Really. And encrypting everything, making encryption the norm, is a huge step towards that goal.
TOR is great if you know who you need to hide from. It's not so good when you don't want *anyone* to get your data.
Porn from work? TOR is great. Hiding the contents of an email from your ISP? TOR is great. Accessing a web site whose owners you don't want to know who is accessing it? TOR is great.
Sending something you don't want published in the New York Times? TOR is useless.
It also doesn't provide any sane way to determine whether or not a peer supports it. It also doesn't provide any way to hide the destination port.
It's going to be really hard to push through a general solution to this problem. Having people propose partial solutions doesn't help. It will just make the good suggestions get lost in the noise.
Note that a server that "appears vulnerable" may or may not actually be vulnerable. The tool only tests for a particular workaround, but you may or may not have the vulnerability that the workaround works around.
Reading the diffs doesn't help. The diffs randomize the source port. But the question is -- what's the problem if you don't randomize the source port?
There is no way to tell if our systems actually have a vulnerability. There is no obvious reason you should need to randomize the source port.
In fact, it's really unclear why randomizing the source port alone would do anything. Anyone who can send a single fake reply can send 10,000 fake replies to different ports.
You could do that if this system encrypted, like almost every other proposed distributed storage system. But this one doesn't.
In principle, someone could try new blocks uploaded to the system against all available other combinations of blocks (which can be pre-XORed to save time). If they find a combination of two blocks which, along with the block you just uploaded, XORs to a copyrighted work, you're screwed.
So, no, this system is worse than encrypting before uploading because it doesn't encrypt.
Perhaps you are talking about some other scheme, but this scheme does not remove redundancy. In fact, it increases it. Each block of data added to the system will, at minimum, require at least one more block to be stored of the same size as the block of data.
A "thought crime" is a crime that can occur entirely inside your head. Telling someone else something cannot occur entirely inside your head. Giving someone directions you intend them to follow when those directions result in a law being broken is perfectly ordinary criminal law.
"My brother will be leave work at around 5 PM on Friday. His car is the grey Mercedes, usually in the middle of the lot. Please kill him."
Saying that to someone, expecting them to follow your directions and break the law is a perfectly normal crime, not a "thought crime".
It doesn't matter. We should easily agree that the person who split the work into pieces from which the work can be reconstructed and distributed those pieces is violating copyright. We should easily agree that the person who put those pieces back together and reconstructed the original work is violating copyright.
The only issue is whether the people "in the middle" who stored and transferred pieces of the original work are. And the answer is the same whether they used this "split into pieces" method or any other method. If they knew about and intended to facilitate the end violations, yes. If not, no.
This method provides no advantage over simple encryption and provides a number of serious disadvantages.
The "key" to reassemble the pieces will be too large for humans to memorize, unlike conventional encryption. The download process will take three times as long. The data is not really protected since the key may be determinable by brute force. So this is really bad encryption (equivalent to a one-time pad) with a bunch of nonsense hand-waving about how it makes bad things go away.
I think you don't understand what the system actually does. Imagine, for the sake of argument, a work was exactly one block long, for simplicity. The system would randomly choose two non-random blocks (from the stored blocks that it knows about), XOR them with the data you want to store, and store that result of that operation.
Now if the data you're storing is The Bourne Supremacy, one of those blocks might be The Holy Bible, but the output block that you now have to store is useless for any purpose other than reconstructing The Bourne Supremacy.
This system cannot ever create a case where a copyrighted work can be constructed completely out of other works in there normal format. There will always be at least one "random-looking block" that, when it was created, served only to make the copyrighted content storable in the system.
I don't see why. The system does not really encrypt the files, just combines them. It always creates a "last block" that represents the copyrighted data's difference from existing known blocks. I don't see ho created that "last block" and uploading it wouldn't violate the copyright.
If that's what you want to do, simply encrypt the files and upload the encrypted versions. So long as you don't give out the key, I don't see that there's a problem. (And if you want to illicitly distribute with plausible deniability, distribute the key illicitly and tell people where to download the encrypted data.)
Right, but every form of encryption does this. Simply store the files encrypted and anyone who stores them for you or give them to someone else has plausible deniability.
This system doesn't add anything. Worse, its authors make numerous false claims about it.
FedEx probably occasionally ships child pornography through no fault of their own. But if you tell them "I'm going to be shipping 100 packages through you and 10 of them will be child pornography and you won't know which so it's not your problem" they will tell you to go take a hike. Anyone who joins this system specifically because it hides copyright is like FedEx taking that person's business.
That's the key question -- was the process of creating these models at least minimally creative?
I don't think you can say it wasn't just because they tried to be as accurate as possible. If I try to make a portrait of you that's as accurate as possible, the accuracy doesn't eliminate my copyright, even if I'm a very good artist.
That two people wouldn't do it the same doesn't mean much. Two people who go to the same concert, record the audio, and compress it to MP3 will not produce identical files. But I don't think either of them are entitled to copyright.
I think this case falls somewhere between those two cases. I'm not sure I could answer it except on a case-by-case basis and by looking in detail into exactly what process was used to produce the models.
None of the usual creative elements are present. There's no lighting, no shading. There's no choice of background or angle.
I think the clinching argument is intent. No matter how creative you are, if you are creatively trying to perfectly replicate something someone else has done, you don't get a copyright. The only exception is translation into another language, and that only because it is explicitly granted by statute.
The summary may be correct, but it's silly. Who care whether or not modelers can prevent others from copying their work? It's not the modelers you have to worry about. It's much more serious that Toyota can prevent a modeler from copying and distributing his own work, isn't it?
Umm, no. Copyright draws a *huge* distinction between copies made in a fixed medium and unfixed copies that are incidental to use. This is why you can't photocopy all of a book but you can make a 'copy' of it on your retina to read it.
Actually, it didn't even hold that a digital model is not subject to copyright. It held that the process of making a digital model doesn't add sufficient original content to *itself* justify copyright. This doesn't mean a digital model is not subject to copyright.
For example, a purse does not by itself contain $50. This doesn't mean a purse cannot contain $50.
In this case, all Meshwerks did was copy a Toyota as accurately as possible into another medium. The court held that this alone was insufficient to grant Meshwerks copyright in the models. It did not say that, for example, Toyota doesn't hold copyright to the models. It did not say that Meshwerks couldn't have gotten copyright had it done more.
As an analogy, if I make a photocopy of a JK Rowlings book, I cannot hold copyright in the photocopy. Merely photocopying another's work does not grant me copyright in the photocopy. It does not follow that anyone can copy my photocopy just because I don't have copyright in it.
The court found making this wire model to be like photocopying for copyright purposes, that is, no significant *creative* content was added.
You cannot earn a copyright by doing hard work, even if it's very hard. You have to do specifically creative work, and the court held Metrowerks was insufficiently creative.
People have no say in what genes they're born with, but they have no say in a lot of things that affect their lives. They have no say in whether they'll win the lottery or not, yet some people do and some people don't.
The biggest problem with GINA is it doesn't care whether it's something you can control or not. For example, smoking generally increases your risk of many diseases. But suppose it lowers the risk of one particular disease that I happen to be genetically pre-disposed to. GINA prevents an insurance company from reducing my rates for smoking and forces me to either take increased health risks by not smoking or pay more for insurance.
This is, of course, an extreme example. But every case GINA prevents is a case where people rationally respond to the actual risks they are exposed to.
Nope, they won't. This is a fairly fundamental problem and one that I've struggled with for about ten years now. You want to enable people who have valuable information to contribute it while protecting their identity, but you also need to keep out people who have malicious intent from disrupting open communication.
There does not seem to be anything remotely approaching a complete solution. There are easy ways to increase the cost of disruption that don't increase the cost of cooperation too much. A CAPTCHA is the most obvious example.
A 'probationary period' is another way, where you have to post a dozen or so insightful posts before you are gradually allowed to make more posts without them waiting for approval (you crowd-source the approval to your own users, much as/. does). This way it takes effort to get the ability to be disruptive, and that ability is then quickly lost.
It's still a tricky issue, especially in forums meant to be very fast or very distributed (such as USENET and IRC).
Vista fixed most of the reasons the majority of installers needed admin privileges. Sadly, because almost every program needs to support XP and managing two very different installation methods is a pain, most programs still wind up needing admin privileges on Vista.
Perhaps some day XP will be forgotten and Vista will be the primary target for many applications and they'll be coded to install the way Vista would like them to, without admin privileges. Then when all the XP-centric software is off our pure-Vista machines, we can turn off all the XP-compatability stuff and be left with a pure, clean, perfectly secure and usable system.
And then I'll sprout wings, fly to a land of candy canes where it only rains gumdrops, and live happily ever after.
First, let me start by saying that Vista's UAC is god-awful, worse than useless, and I hate it. I have disabled it on my Vista machine because it drives me nuts.
That said, this article is completely wrong. Here, UAC forced the application to ask for the permissions it needed and forced the application to implement proper privilege separation. I don't know if it was by design or happy accident, but UAC forced the application to be *properly* implemented. Now the privileged part does not contain the UI, and so a compromise of the UI still cannot compromise the privileged part. This is exactly right.
It may not matter for this particular application, and so there may be some collateral damage here. But there have certainly been historical cases where compromises to the piece that talks to the person allowed the part that interacts with the system to be compromised. The correct solution is exactly what was done here -- split into two piece and define precisely how the two pieces talk to each other.
Numerous security problems in SSH implementations were solved by doing precisely this. Google for 'SSH "privilege separation"' to read about them.
Ok, I'll bite (for the record). The question becomes: do you want 10 high speed cores that are capable of everything? Or do you want 20? Or, maybe 15 combined with 10 half speed cores for the same price (because slower cores are much much cheaper)?
For the moment, the way the economics (both hardware and software) work, 10 high speed cores is probably a better deal. Slower cores are really not cheaper. If you need a high-speed path to memory (and you almost always do), you need to be made on the latest processes anyway, and if all the cores are on one die, it doesn't take much more space to be faster. 90% of the space goes to memory (cache), not calculation.
By the way, this is already happening but only inside processors. Remember floating point units? ALU? Are those not specialized parts of the processor with a certain mix (of units) that is 'optimal' or sufficient according to a manufacturer? Why not have 10 processors with an extra ALU and 10 with an extra FPU? Would that not make a heterogeneous system (if only slightly)? Same price, extra performance.
You notice how that really didn't work out so well and you now find CPUs and FPUs are basically always paired one-to-one. The exceptions are only found in limited-purpose products.
You may be right for the more distant future. But the economies right now (both in hardware and in software) favor symmetric cores heavily. I don't think this will change in less than 20 years.
Slashdot Mirror
Actually, depending on what the certificates are used for, if they were compromised any time during their lifetime, they may need to remain on a CRL effectively forever.
For example, if a certificate is used to sign code, and code signed after the certificate was compromised cannot be trusted. A validity check can occur even years after the certificate expired.
If it is only used for SSL, this is not an issue. But certificates are used for much more than that.
Suppose I forward a signed email to you that I received three years ago. The key that signed it may not be valid now -- but what you really do want to know is if it was valid at the time that email was sent.
But you only use one copy. The other copies are there to bypass functional checks. This is legal under scenes a faire.
To put it another way, the copy they patch is the one that you are lawfully using. The other copies exist only to pass a security check, where only that exact code will pass the check. Copyright doesn't cover cases where there is only one way to get something done, you need patent for that. Copyright only covers one way out of millions of equally good ways. What are the other equally good ways to pass Blizzard's security check?
You've hit on the main thing their 'proposal' is missing. It provides no way to discover whether another end node supports the protocol or not.
This history of the Internet proves this attitude wrong. Sure, governments try to regulate the Internet and restrict the free flow of information. The problem is that they generally fail to do so, and as a result, freedom is making significant progress around the world.
Ubiquitous encryption is the next step in this same direction. This will force organizations in the United States to decide whether they want to try to clamp down on this or let it go free. They have been unable to clamp down in the past, and they know that if they clamp down, what can they say the next time China clamps down?
Freedom will win. Really. And encrypting everything, making encryption the norm, is a huge step towards that goal.
TOR is great if you know who you need to hide from. It's not so good when you don't want *anyone* to get your data.
Porn from work? TOR is great. Hiding the contents of an email from your ISP? TOR is great. Accessing a web site whose owners you don't want to know who is accessing it? TOR is great.
Sending something you don't want published in the New York Times? TOR is useless.
It also doesn't provide any sane way to determine whether or not a peer supports it. It also doesn't provide any way to hide the destination port.
It's going to be really hard to push through a general solution to this problem. Having people propose partial solutions doesn't help. It will just make the good suggestions get lost in the noise.
Note that a server that "appears vulnerable" may or may not actually be vulnerable. The tool only tests for a particular workaround, but you may or may not have the vulnerability that the workaround works around.
Reading the diffs doesn't help. The diffs randomize the source port. But the question is -- what's the problem if you don't randomize the source port?
There is no way to tell if our systems actually have a vulnerability. There is no obvious reason you should need to randomize the source port.
In fact, it's really unclear why randomizing the source port alone would do anything. Anyone who can send a single fake reply can send 10,000 fake replies to different ports.
You could do that if this system encrypted, like almost every other proposed distributed storage system. But this one doesn't.
In principle, someone could try new blocks uploaded to the system against all available other combinations of blocks (which can be pre-XORed to save time). If they find a combination of two blocks which, along with the block you just uploaded, XORs to a copyrighted work, you're screwed.
So, no, this system is worse than encrypting before uploading because it doesn't encrypt.
Perhaps you are talking about some other scheme, but this scheme does not remove redundancy. In fact, it increases it. Each block of data added to the system will, at minimum, require at least one more block to be stored of the same size as the block of data.
A "thought crime" is a crime that can occur entirely inside your head. Telling someone else something cannot occur entirely inside your head. Giving someone directions you intend them to follow when those directions result in a law being broken is perfectly ordinary criminal law.
"My brother will be leave work at around 5 PM on Friday. His car is the grey Mercedes, usually in the middle of the lot. Please kill him."
Saying that to someone, expecting them to follow your directions and break the law is a perfectly normal crime, not a "thought crime".
It doesn't matter. We should easily agree that the person who split the work into pieces from which the work can be reconstructed and distributed those pieces is violating copyright. We should easily agree that the person who put those pieces back together and reconstructed the original work is violating copyright.
The only issue is whether the people "in the middle" who stored and transferred pieces of the original work are. And the answer is the same whether they used this "split into pieces" method or any other method. If they knew about and intended to facilitate the end violations, yes. If not, no.
This method provides no advantage over simple encryption and provides a number of serious disadvantages.
The "key" to reassemble the pieces will be too large for humans to memorize, unlike conventional encryption. The download process will take three times as long. The data is not really protected since the key may be determinable by brute force. So this is really bad encryption (equivalent to a one-time pad) with a bunch of nonsense hand-waving about how it makes bad things go away.
I think you don't understand what the system actually does. Imagine, for the sake of argument, a work was exactly one block long, for simplicity. The system would randomly choose two non-random blocks (from the stored blocks that it knows about), XOR them with the data you want to store, and store that result of that operation.
Now if the data you're storing is The Bourne Supremacy, one of those blocks might be The Holy Bible, but the output block that you now have to store is useless for any purpose other than reconstructing The Bourne Supremacy.
This system cannot ever create a case where a copyrighted work can be constructed completely out of other works in there normal format. There will always be at least one "random-looking block" that, when it was created, served only to make the copyrighted content storable in the system.
I don't see why. The system does not really encrypt the files, just combines them. It always creates a "last block" that represents the copyrighted data's difference from existing known blocks. I don't see ho created that "last block" and uploading it wouldn't violate the copyright.
If that's what you want to do, simply encrypt the files and upload the encrypted versions. So long as you don't give out the key, I don't see that there's a problem. (And if you want to illicitly distribute with plausible deniability, distribute the key illicitly and tell people where to download the encrypted data.)
Right, but every form of encryption does this. Simply store the files encrypted and anyone who stores them for you or give them to someone else has plausible deniability.
This system doesn't add anything. Worse, its authors make numerous false claims about it.
FedEx probably occasionally ships child pornography through no fault of their own. But if you tell them "I'm going to be shipping 100 packages through you and 10 of them will be child pornography and you won't know which so it's not your problem" they will tell you to go take a hike. Anyone who joins this system specifically because it hides copyright is like FedEx taking that person's business.
It doesn't matter legally how you do it, it only matters what you do. This whole effort is completely pointless.
That's the key question -- was the process of creating these models at least minimally creative?
I don't think you can say it wasn't just because they tried to be as accurate as possible. If I try to make a portrait of you that's as accurate as possible, the accuracy doesn't eliminate my copyright, even if I'm a very good artist.
That two people wouldn't do it the same doesn't mean much. Two people who go to the same concert, record the audio, and compress it to MP3 will not produce identical files. But I don't think either of them are entitled to copyright.
I think this case falls somewhere between those two cases. I'm not sure I could answer it except on a case-by-case basis and by looking in detail into exactly what process was used to produce the models.
None of the usual creative elements are present. There's no lighting, no shading. There's no choice of background or angle.
I think the clinching argument is intent. No matter how creative you are, if you are creatively trying to perfectly replicate something someone else has done, you don't get a copyright. The only exception is translation into another language, and that only because it is explicitly granted by statute.
The summary may be correct, but it's silly. Who care whether or not modelers can prevent others from copying their work? It's not the modelers you have to worry about. It's much more serious that Toyota can prevent a modeler from copying and distributing his own work, isn't it?
Umm, no. Copyright draws a *huge* distinction between copies made in a fixed medium and unfixed copies that are incidental to use. This is why you can't photocopy all of a book but you can make a 'copy' of it on your retina to read it.
Actually, it didn't even hold that a digital model is not subject to copyright. It held that the process of making a digital model doesn't add sufficient original content to *itself* justify copyright. This doesn't mean a digital model is not subject to copyright.
For example, a purse does not by itself contain $50. This doesn't mean a purse cannot contain $50.
In this case, all Meshwerks did was copy a Toyota as accurately as possible into another medium. The court held that this alone was insufficient to grant Meshwerks copyright in the models. It did not say that, for example, Toyota doesn't hold copyright to the models. It did not say that Meshwerks couldn't have gotten copyright had it done more.
As an analogy, if I make a photocopy of a JK Rowlings book, I cannot hold copyright in the photocopy. Merely photocopying another's work does not grant me copyright in the photocopy. It does not follow that anyone can copy my photocopy just because I don't have copyright in it.
The court found making this wire model to be like photocopying for copyright purposes, that is, no significant *creative* content was added.
You cannot earn a copyright by doing hard work, even if it's very hard. You have to do specifically creative work, and the court held Metrowerks was insufficiently creative.
People have no say in what genes they're born with, but they have no say in a lot of things that affect their lives. They have no say in whether they'll win the lottery or not, yet some people do and some people don't.
The biggest problem with GINA is it doesn't care whether it's something you can control or not. For example, smoking generally increases your risk of many diseases. But suppose it lowers the risk of one particular disease that I happen to be genetically pre-disposed to. GINA prevents an insurance company from reducing my rates for smoking and forces me to either take increased health risks by not smoking or pay more for insurance.
This is, of course, an extreme example. But every case GINA prevents is a case where people rationally respond to the actual risks they are exposed to.
Nope, they won't. This is a fairly fundamental problem and one that I've struggled with for about ten years now. You want to enable people who have valuable information to contribute it while protecting their identity, but you also need to keep out people who have malicious intent from disrupting open communication.
/. does). This way it takes effort to get the ability to be disruptive, and that ability is then quickly lost.
There does not seem to be anything remotely approaching a complete solution. There are easy ways to increase the cost of disruption that don't increase the cost of cooperation too much. A CAPTCHA is the most obvious example.
A 'probationary period' is another way, where you have to post a dozen or so insightful posts before you are gradually allowed to make more posts without them waiting for approval (you crowd-source the approval to your own users, much as
It's still a tricky issue, especially in forums meant to be very fast or very distributed (such as USENET and IRC).
Of course, this guy is off the deep end.
Vista fixed most of the reasons the majority of installers needed admin privileges. Sadly, because almost every program needs to support XP and managing two very different installation methods is a pain, most programs still wind up needing admin privileges on Vista.
Perhaps some day XP will be forgotten and Vista will be the primary target for many applications and they'll be coded to install the way Vista would like them to, without admin privileges. Then when all the XP-centric software is off our pure-Vista machines, we can turn off all the XP-compatability stuff and be left with a pure, clean, perfectly secure and usable system.
And then I'll sprout wings, fly to a land of candy canes where it only rains gumdrops, and live happily ever after.
First, let me start by saying that Vista's UAC is god-awful, worse than useless, and I hate it. I have disabled it on my Vista machine because it drives me nuts.
That said, this article is completely wrong. Here, UAC forced the application to ask for the permissions it needed and forced the application to implement proper privilege separation. I don't know if it was by design or happy accident, but UAC forced the application to be *properly* implemented. Now the privileged part does not contain the UI, and so a compromise of the UI still cannot compromise the privileged part. This is exactly right.
It may not matter for this particular application, and so there may be some collateral damage here. But there have certainly been historical cases where compromises to the piece that talks to the person allowed the part that interacts with the system to be compromised. The correct solution is exactly what was done here -- split into two piece and define precisely how the two pieces talk to each other.
Numerous security problems in SSH implementations were solved by doing precisely this. Google for 'SSH "privilege separation"' to read about them.
For the moment, the way the economics (both hardware and software) work, 10 high speed cores is probably a better deal. Slower cores are really not cheaper. If you need a high-speed path to memory (and you almost always do), you need to be made on the latest processes anyway, and if all the cores are on one die, it doesn't take much more space to be faster. 90% of the space goes to memory (cache), not calculation.
You notice how that really didn't work out so well and you now find CPUs and FPUs are basically always paired one-to-one. The exceptions are only found in limited-purpose products.
You may be right for the more distant future. But the economies right now (both in hardware and in software) favor symmetric cores heavily. I don't think this will change in less than 20 years.