Indeed. But it's not a stack of turtles, but on top of each turtle, there are several smaller turles, each one moving around on the back of the turtle below it according to its own LOGO program. Together they make a nice dynamic fractal.
Maybe that can be prevented with a counter-test: Have another group of experts see the same picture together with pictures identified as child porn, and let them identify the picture which is least pornographic. If the picture isn't pornographic, it should be selected by most of the experts, but this time the force goes into the opposite direction: If it is only slightly less pornographic than the others, the experts are more likely to not select it as the least-pornographic.
If both tests give a consistent result, it's an obvious case, and the picture can be clearly sorted into one category. If both tests give different results, then the picture is obviously at the border; it shouldn't lead by itself to conviction due to the benefit of the doubt, but it also shouldn't be entered into the repository of clearly non-pornographic pictures (nor into the repository of clearly pornographic ones, of course).
Thinking more about it, I came to the conclusion that the protocol should be slightly modified: * With the current scheme, your receiver cannot be sure that you gave him a valid cheque, and that you really have the amount of money. * Also, since the signature is only checked at your account provider (despite the name, only your account provider has your public key), the only thing which should be in the signed part is the amount of money, so only that part goes back to your account provider (it's the only thing, apart from your account number, he must know).
To address the first point, the scheme could be that you first send your digital cheque with only the UCID, the amount of money and a random token previously sent to you by the receiver, signed with your private key, to your account provider, who checks that this UCID wasn't yet used for a digital cheque and that you indeed have that much payable money on your account, blocks the corresponding money (so it can only be payed using this special digital cheque), signs the DS with his private key (for which the corresponding public key indeed is public), and then sends the signed DS back to you, so you can rtansmit it to the receiver. Now the receiver knows that * you didn't use the same UCID before (if you had created another cheque with the same UCID before, the account provider would not have signed it; also the token proves that you created it for the exact transaction, and did not reuse an older one), and * you really have the money (again, the account provider would not have signed it if you hadn't, and it's now blocked).
I'm not aware of any. But it's an interesting question what such a payment system would have to look like. Maybe it would be a money account with no name stored, but the only way you identify is by having the private part of a public/private key pair. However, there's still the question how you get your money on that account without identifying yourself (assuming you are earning your money through the normal payment systems), or how you get your money back into the normal payment systems. But then, maybe having several accounts with different providers would be enough.
Payment would probably be made by a digital analog of a cheque: The first step would probably be to generate an unique identifier. This unique identifier and your account number would then together be encrypted with your account provider's public key to form an unique cheque ID (UCID). The reason for this is twofold: First, it would prevent the receiver to identify that two different cheques come from the same person (just encrypting your bank account number would not suffice, but the unique identifier would provide the needed randomness), and second, it would make sure that the cheque can only be used once: The account provider would not pay out a digital cheque if the same UCID was already used. To this UCID you would add the payment data (amount of money, purpose, etc, and of course your account provider, so it's clear where to get the money from), and sign the whole thing with your private key.
Securely passing that cheque to the receiver would be something outside of the scope of the system (e.g. if you would pay for access to a web site, you could simply transfer it over the SSL protected connection to the web site owner).
The receiver would then pass it to his anonymous account provider (again, the security of this step is up to the account provider; of course he would have to identify as account owner with his private account key), who would note the ID and receiver account, and then pass it on to your account provider. Your account provider would check that the cheque wasn't yet used (i.e. check if the UCID was already used), then he would decrypt the UCID with his private key to find out your account number. Since he now knows which account the money is to be payed from, he can check your signature with the public key of your account. If the check is successful (so he knows that the digital cheque is valid), he sends the money to the receipient's account provider (identifying the payment with the UCID), who then can book it to the receiver's account.
This should be anonymous: * You don't need to know more about the receiver but how to securely get your digital cheque to him. * The receiver knows your account provider, but not your account number (presumably, the same account provider administrates many accounts). The same is true for the receiver's account provider. * Your account provider only knows to which account provider the money goes, but not to which account there. * Even if your account provider and you receiver's account provider are the same, the account provider only knows from which account to which account the money went, not who owns those accounts.
It also should be secure (assuming all involved systems and transmissions are well secured, and the keys are not broken, of course): * The UCID makes sure that the same cheque can only be payed once. * You need your private signature (known only to you, not even to your account provider) in order to create a digital cheque.
One of the big differences is that you can actually have a border around your property.
I cannot have a border around my life, my health, or my freedom of speech. Therefore I conclude life, health and freedom of speech are not human rights?
Note: I didn't ask you about the differences between property and "IP" (I know those), I asked you about why you think property is a human right, and "IP" isn't.
You didn't answer my question. How did you determine that (normal) property rights are human rights? And how did you determine that "IP" rights are not?
What method do you use to distinguish human rights from other rights? And how does this method detect normal property rights as human rights, but "IP" rights as other rights?
What about having both a local and a net backup? In most cases, the local, non-networked backup should work just fine, and it would be really bad luck if the data, the local backup and the external backup would be destroyed at the same time.
As the article states: "The key is in a technology called Trust Metrics. In essence this is a technique for rating each other, but with the key distinction that the way ratings are calculated makes cheating ineffective. This is a new technology, which has not been applied for this purpose before, but it has already proven itself as the underlying principle behind such well known technologies as Googles pagerank and the certifications on Advogato."
Google's pagerank makes cheating ineffective? I guess all those google bombs existed only in my imagination...
Indeed, even waving your hand creates gravitational waves. The real question is: Will it create gravitational waves which are strong enough for us to detect? Another question is: Could the superconductor deformation by the gravitational wave produce other effects (probably electromagnetic ones) which are large enough for us to detect? In that case, the superconductor could be used as a new type of gravitational wave detector.
Maybe the true reason we haven't found any alien communication is that we listened at the wrong wave type (EM instead of gravitational). After all, they surely prefer their communication not to disturbed too much by all that dust flying around in the universe...
OK: Imagine a street full of cars. Now at some place the cars are denser. This denser area doesn't move with the same speed as the cars themselves, because cars are entering the dense area from behind, and leave it at the front. Now that dense area is a car wave. Reflecting the car wave means the dense area now goes into the opposite direction. The cars however still go into the same direction they did previously. They neither got shielded, nor reflected.
I think his problem is with the obfuscation of said javascript and HTML code. His example points to the google code which is supplied with no comments and method naming which has been intentionally obfuscated. A normal web developer has no need to obfuscate the code.
Bandwidth? Note that the obfuscation is in removing whitespace and using one-letter method names. Exactly what you would do in order to reduce the transmitted size.
Slashdot Mirror
It really *is* turtles all the way down??
Indeed. But it's not a stack of turtles, but on top of each turtle, there are several smaller turles, each one moving around on the back of the turtle below it according to its own LOGO program. Together they make a nice dynamic fractal.
God is one of these role-play nerds then, with his 20 dimensional dice.
Typical ignorance from a whole number dimensional being. God's fractal dice have 23.5 dimensions.
No, his dice has e^pi dimensions. How could you ever think God's dice would not be transcendental?
Maybe that can be prevented with a counter-test: Have another group of experts see the same picture together with pictures identified as child porn, and let them identify the picture which is least pornographic. If the picture isn't pornographic, it should be selected by most of the experts, but this time the force goes into the opposite direction: If it is only slightly less pornographic than the others, the experts are more likely to not select it as the least-pornographic.
If both tests give a consistent result, it's an obvious case, and the picture can be clearly sorted into one category. If both tests give different results, then the picture is obviously at the border; it shouldn't lead by itself to conviction due to the benefit of the doubt, but it also shouldn't be entered into the repository of clearly non-pornographic pictures (nor into the repository of clearly pornographic ones, of course).
Thinking more about it, I came to the conclusion that the protocol should be slightly modified:
* With the current scheme, your receiver cannot be sure that you gave him a valid cheque, and that you really have the amount of money.
* Also, since the signature is only checked at your account provider (despite the name, only your account provider has your public key), the only thing which should be in the signed part is the amount of money, so only that part goes back to your account provider (it's the only thing, apart from your account number, he must know).
To address the first point, the scheme could be that you first send your digital cheque with only the UCID, the amount of money and a random token previously sent to you by the receiver, signed with your private key, to your account provider, who checks that this UCID wasn't yet used for a digital cheque and that you indeed have that much payable money on your account, blocks the corresponding money (so it can only be payed using this special digital cheque), signs the DS with his private key (for which the corresponding public key indeed is public), and then sends the signed DS back to you, so you can rtansmit it to the receiver. Now the receiver knows that
* you didn't use the same UCID before (if you had created another cheque with the same UCID before, the account provider would not have signed it; also the token proves that you created it for the exact transaction, and did not reuse an older one), and
* you really have the money (again, the account provider would not have signed it if you hadn't, and it's now blocked).
I'm not aware of any. But it's an interesting question what such a payment system would have to look like.
Maybe it would be a money account with no name stored, but the only way you identify is by having the private part of a public/private key pair. However, there's still the question how you get your money on that account without identifying yourself (assuming you are earning your money through the normal payment systems), or how you get your money back into the normal payment systems. But then, maybe having several accounts with different providers would be enough.
Payment would probably be made by a digital analog of a cheque: The first step would probably be to generate an unique identifier. This unique identifier and your account number would then together be encrypted with your account provider's public key to form an unique cheque ID (UCID). The reason for this is twofold: First, it would prevent the receiver to identify that two different cheques come from the same person (just encrypting your bank account number would not suffice, but the unique identifier would provide the needed randomness), and second, it would make sure that the cheque can only be used once: The account provider would not pay out a digital cheque if the same UCID was already used. To this UCID you would add the payment data (amount of money, purpose, etc, and of course your account provider, so it's clear where to get the money from), and sign the whole thing with your private key.
Securely passing that cheque to the receiver would be something outside of the scope of the system (e.g. if you would pay for access to a web site, you could simply transfer it over the SSL protected connection to the web site owner).
The receiver would then pass it to his anonymous account provider (again, the security of this step is up to the account provider; of course he would have to identify as account owner with his private account key), who would note the ID and receiver account, and then pass it on to your account provider. Your account provider would check that the cheque wasn't yet used (i.e. check if the UCID was already used), then he would decrypt the UCID with his private key to find out your account number. Since he now knows which account the money is to be payed from, he can check your signature with the public key of your account. If the check is successful (so he knows that the digital cheque is valid), he sends the money to the receipient's account provider (identifying the payment with the UCID), who then can book it to the receiver's account.
This should be anonymous:
* You don't need to know more about the receiver but how to securely get your digital cheque to him.
* The receiver knows your account provider, but not your account number (presumably, the same account provider administrates many accounts). The same is true for the receiver's account provider.
* Your account provider only knows to which account provider the money goes, but not to which account there.
* Even if your account provider and you receiver's account provider are the same, the account provider only knows from which account to which account the money went, not who owns those accounts.
It also should be secure (assuming all involved systems and transmissions are well secured, and the keys are not broken, of course):
* The UCID makes sure that the same cheque can only be payed once.
* You need your private signature (known only to you, not even to your account provider) in order to create a digital cheque.
I think you underestimate the intelligence of toasters.
Indeed, the intelligence of toasters is readily shown by the fact that they never would participate in a turing test.
I cannot have a border around my life, my health, or my freedom of speech. Therefore I conclude life, health and freedom of speech are not human rights?
Note: I didn't ask you about the differences between property and "IP" (I know those), I asked you about why you think property is a human right, and "IP" isn't.
You didn't answer my question. How did you determine that (normal) property rights are human rights? And how did you determine that "IP" rights are not?
What method do you use to distinguish human rights from other rights? And how does this method detect normal property rights as human rights, but "IP" rights as other rights?
If it had been slashdotted, you couldn't post here. It links straight to the summary itself.
Sweet, a link in a summary to the summary itself. Just what I've always wanted!
Indeed, what an earth-shattering innovation!
Usually the ones that cost about $35k/terrabyte as opposed to the ones that cost $99/terrabyte at newegg.
Well, if it comes to earthquakes, terrabytes surely beat terabytes. After all, it's not a monsterquake! :-)
What about having both a local and a net backup? In most cases, the local, non-networked backup should work just fine, and it would be really bad luck if the data, the local backup and the external backup would be destroyed at the same time.
You can write control characters using e.g. &x200F;
However, it should completely suffice to filter out control characters.
As the article states: "The key is in a technology called Trust Metrics. In essence this is a technique for rating each other, but with the key distinction that the way ratings are calculated makes cheating ineffective. This is a new technology, which has not been applied for this purpose before, but it has already proven itself as the underlying principle behind such well known technologies as Googles pagerank and the certifications on Advogato."
Google's pagerank makes cheating ineffective? I guess all those google bombs existed only in my imagination ...
Indeed, even waving your hand creates gravitational waves. The real question is: Will it create gravitational waves which are strong enough for us to detect?
Another question is: Could the superconductor deformation by the gravitational wave produce other effects (probably electromagnetic ones) which are large enough for us to detect? In that case, the superconductor could be used as a new type of gravitational wave detector.
Maybe the true reason we haven't found any alien communication is that we listened at the wrong wave type (EM instead of gravitational). After all, they surely prefer their communication not to disturbed too much by all that dust flying around in the universe ...
Would be really cool technology, wouldn't it?
Gravitational waves have been shown to exist by observing binary pulsars. So we have both a theory which predicts them, and which up to now has survived every test, and an observation which confirms them (the binary pulsar).
Loop quantum gravity is very decidedly not trying to come up with a Grand Unified Theory. It "just" tries to provide a quantum theory of gravitation.
OK: Imagine a street full of cars. Now at some place the cars are denser. This denser area doesn't move with the same speed as the cars themselves, because cars are entering the dense area from behind, and leave it at the front. Now that dense area is a car wave. Reflecting the car wave means the dense area now goes into the opposite direction. The cars however still go into the same direction they did previously. They neither got shielded, nor reflected.
Well, obviously k < 1 + 1/9000
Of course he meant 9*6, because 9*7 obviously is 4B.
BTW, 63 is 9*9.
Well, you should do some reflections before you write such comments.
Bandwidth?
Note that the obfuscation is in removing whitespace and using one-letter method names. Exactly what you would do in order to reduce the transmitted size.