It should be stressed that this thread only concerns the policy for new works going forward - it does absolutely nothing to justify the absurd notion that existing copyrights be retroactively extended.
90% of all that is adequately explained by the fact that Europe was first to begin the project of colonialism.
hint: Leaving aside the eurocentric connotations of the "nation" concept, let's try naming a black population which had a chance to try and create a stable nation without white intervention - there aren't any. because whites always, um, intervened.
Are you questioning the value of mutual coercion in society?
Do you only believe in private property if other people are FORCED to respect it too? Or would you dutifully subsist on only those things which you "owned" if you lived in a society which observed no such conventions and everyone else considered it their right to whatever "possessions" you couldn't successfully defend from them?
Hackers aren't great software customers but they're great hardware customers.
Since hardware and software companies(or perhaps the service providers) want to be able to team up to sell a unified, coherent stack, the hackers are a source of tension between them.
I expect this will culminate in the hardware designs being a bit two-faced; they'll play ball with the DRM-aware, trusted-platform specs well enough to not lose their service-provider contracts and be accused of bad faith, but poorly enough that savvy customers can still jailbreak them and run what they want to. This is a good way for hardware manufacturers to have their cake and eat it too.
but issue a 'retransmit' after every nth packet, where n is your encrypted data stream.
So it's like: Bob: The quick brown fox jumps over the lazy d%g. (The corrupted character is the 42nd character in this message.) Dave: the lazy what? Bob: Dog. Dave: Oh, I understand. (That was the 42nd character he just repaired! I'll append a "42" to my ciphertext now.)
I'd envision the "real criminals" are almost certainly gonna be the early adopters of non-port-443, obfuscated, encapsulated-in-cleartext-protocols tunneling tools, aren't they? After a couple of months the only people left on port 443 will probably be botnet clients running on people not savvy enough to monitor their own machine's traffic.
You need to put your encrypted data somewhere that it's actually plausible for randomness to arise in your messages. Send a copy of the Quran unencrypted, but issue a 'retransmit' after every nth packet, where n is your encrypted data stream.
"I don't know why these packets got retransmitted and others didn't! I was using wifi! packet loss!" No one's gonna ask you why that distribution looks random - it's supposed to.
Who says padding has to be obvious? You're absolutely right; hiding your crypto from human inspection is harder than hiding it from any given watchdog algorithm. The comment above me was referring to Shannon entropy, which I presume was meant as a form of wide-deployment, automated snooping. You can dodge "entropy" by just adding huge blocks of zeroes to your data stream; but I'd never suggest actually doing that. Better chaff would be, say, the output of some conversational AIs, Viagra ads, paragraphs of Hemingway, or whatever kind of human-readable content might plausibly be emanating from the server in question.
Because there are only two possible ways the government could possibly be "banning encryption":
1) with an accept-by-default policy, blacklisting all 'known' protocols for transferring encrypted data (of which SSL is one), or 2) with a deny-by-default policy, whitelisting all 'known' cleartext protocols.
In either case, SSL traffic won't make the cut. With 1), the workaround is super-easy because they can't possibly have an exhaustive description of all encrypted protocols, and it's trivial to devise a new one that lacks whatever features the blacklist is looking for. With 2), the bypass is only very easy because you have to encapsulate an encrypted stream inside a protocol which is "known" as a cleartext one - HTTP being the best candidate because it's among the protocols least likely to get blocked outright.
It's also trivially easy to add as much redundant data (or, "chaff") as you like to an encrypted stream in order to make its entropy as low as you like.
By checking the "encrypted" bit in the TCP/IP packet header. It's right next to the "evil" bit.
I say, that's an ingenious bit of protocol design! In other news, the Entscheidungsproblem has been solved. Turns out you just check for the "__does_program_halt__" flag that's present in all ELF binaries.
Slashdot Mirror
It should be stressed that this thread only concerns the policy for new works going forward - it does absolutely nothing to justify the absurd notion that existing copyrights be retroactively extended.
Would you by any chance be white?
though you can't do bidirectional synchronization with that.
OCFS2 over DRBD actually supports "multi-master mode" replication just fine.
90% of all that is adequately explained by the fact that Europe was first to begin the project of colonialism.
hint: Leaving aside the eurocentric connotations of the "nation" concept, let's try naming a black population which had a chance to try and create a stable nation without white intervention - there aren't any. because whites always, um, intervened.
I think you're a bit Confuced.
Horribly loud. Though, doing this with a smaller, quieter Wii might be just the ticket.
Backdoors'll do that.
This is why it needs to be easier to countersue for your legal expenses and time.
So what you're saying is your wife will make me a sandwich too?
Oh exploitable!
Ah, I getcha. Yeah, that's a cromulent comparison.
They could take a lesson from the CPU manufacturers. Serial murder just doesn't scale as well as parallel murder.
Unfortunately people, unlike companies, have a body to incarcerate. :(
Are you questioning the value of mutual coercion in society?
Do you only believe in private property if other people are FORCED to respect it too? Or would you dutifully subsist on only those things which you "owned" if you lived in a society which observed no such conventions and everyone else considered it their right to whatever "possessions" you couldn't successfully defend from them?
I think it's more like 2000 was the spiritual successor of NT4, and ME was the successor of 98.
Hackers aren't great software customers but they're great hardware customers.
Since hardware and software companies(or perhaps the service providers) want to be able to team up to sell a unified, coherent stack, the hackers are a source of tension between them.
I expect this will culminate in the hardware designs being a bit two-faced; they'll play ball with the DRM-aware, trusted-platform specs well enough to not lose their service-provider contracts and be accused of bad faith, but poorly enough that savvy customers can still jailbreak them and run what they want to. This is a good way for hardware manufacturers to have their cake and eat it too.
I'm just gonna come out and say it.
Science is horrible
Now how the hell am I supposed to write C++ methods that manipulate their parent object?
You misunderstand.
but issue a 'retransmit' after every nth packet, where n is your encrypted data stream.
So it's like:
Bob: The quick brown fox jumps over the lazy d%g. (The corrupted character is the 42nd character in this message.)
Dave: the lazy what?
Bob: Dog.
Dave: Oh, I understand. (That was the 42nd character he just repaired! I'll append a "42" to my ciphertext now.)
I'd envision the "real criminals" are almost certainly gonna be the early adopters of non-port-443, obfuscated, encapsulated-in-cleartext-protocols tunneling tools, aren't they? After a couple of months the only people left on port 443 will probably be botnet clients running on people not savvy enough to monitor their own machine's traffic.
You need to put your encrypted data somewhere that it's actually plausible for randomness to arise in your messages.
Send a copy of the Quran unencrypted, but issue a 'retransmit' after every nth packet, where n is your encrypted data stream.
"I don't know why these packets got retransmitted and others didn't! I was using wifi! packet loss!" No one's gonna ask you why that distribution looks random - it's supposed to.
Who says padding has to be obvious? You're absolutely right; hiding your crypto from human inspection is harder than hiding it from any given watchdog algorithm. The comment above me was referring to Shannon entropy, which I presume was meant as a form of wide-deployment, automated snooping. You can dodge "entropy" by just adding huge blocks of zeroes to your data stream; but I'd never suggest actually doing that. Better chaff would be, say, the output of some conversational AIs, Viagra ads, paragraphs of Hemingway, or whatever kind of human-readable content might plausibly be emanating from the server in question.
no way to block OpenVPN without blocking every single TLS connection
Um, I got the impression from the article that that's exactly what they're doing.
Because there are only two possible ways the government could possibly be "banning encryption":
1) with an accept-by-default policy, blacklisting all 'known' protocols for transferring encrypted data (of which SSL is one), or
2) with a deny-by-default policy, whitelisting all 'known' cleartext protocols.
In either case, SSL traffic won't make the cut. With 1), the workaround is super-easy because they can't possibly have an exhaustive description of all encrypted protocols, and it's trivial to devise a new one that lacks whatever features the blacklist is looking for. With 2), the bypass is only very easy because you have to encapsulate an encrypted stream inside a protocol which is "known" as a cleartext one - HTTP being the best candidate because it's among the protocols least likely to get blocked outright.
It's also trivially easy to add as much redundant data (or, "chaff") as you like to an encrypted stream in order to make its entropy as low as you like.
By checking the "encrypted" bit in the TCP/IP packet header. It's right next to the "evil" bit.
I say, that's an ingenious bit of protocol design! In other news, the Entscheidungsproblem has been solved. Turns out you just check for the "__does_program_halt__" flag that's present in all ELF binaries.