Yes. Or even better: Tibet (whose culture they keep destroying). But the analogy is still slightly flawed. China considers Taiwan to be part of its territory while the US doesn't claim to own the Palestinian territories.
Suspicion is fueled by ignorance - something seems scary when it is only half-visible. This man's strategy was, in part, to illuminate that previously invisible half.
The scary thing here is that he felt compelled to use this unorthodox strategy to long-term prove his innocence. What happened to "innocent until proven guilty?" How comes everyone is now considered suspect, until he gets a clean bill of innocence by some partially obscure 3 letter agencies? I wouldn't spend as much time discussing "public privacy" than the more urgent fact that we're diving even deeper in this Nineteeneightyfour-ish nightmare we're already in.
don't see how this is a threat to my privacy or anything
Never underestimate the danger of corporate data mining.
Want an example how this can be abused? Alright. Suppose someone with a minor disease visits websites or forums talking about that. Fast forward a few years. Said person seeks health insurance, but can't get any, because the insurance companies will have access to that person's surfing habit, and will flag this person as undesirable customer. So no coverage, right?
This is just one of many, many examples what can all go wrong and it's barely scratching the surface.
How many of them are doing online banking with foreign banks anyway? If they blocked encrypted traffic at the international peering point(s), it wouldn't break their internal internet banking system at all.
I'm working at the Network Operation Center (NOC) of a major Tier-1 backbone operator, and I'm somewhat familiar with the Nokia-Siemens DPI software used in some places of the world, including Iran. And guess what? I'm NOT surprised that they were able to block VPN traffic, even encrypted one at this point.
Unencrypted VPN traffic is incredibly easy to flag anyway, and even the handshake of popular encrypted VPN tunnels has a pattern that's predictable enough to be quite effective. I don't need to point out that ALL ports are affected. Switching to another port is basically useless in this context.
All this DPI doesn't require huge CPU processing power, as one would naively expect; since it (currently) happens only at the beginning of a session (yes, including UDP). And that is currently the Achilles' heel of this filter: if you initiate a "harmless" (as in allowed-by-policy) connection, and switch to encryption a couple of 10k packets later, you slip right through the firewall. Try it. If it doesn't work, they've upgraded to a new release and had to invest heavily in additional routers.
Actually, I don't think the US Governments look all that bad in the cables. But maybe that's just me, having expected them to come out a LOT worse than they did. I haven't read all cables yet (of course), but what I've gathered from them so far is rather benign. Not all of it as morally crystal clear as one would hope, but neither is it all thuggery. IMHO, the US Govt. shouldn't worry about those cables. Furthermore, they are more or less ancient history by now.
Now, a leak in the CIA or NSA... that could prove to be a lot more embarrassing to the US Govt!
The early years of the internet were plagued with issues on how Flash was used: long Flash intro's to websites,
The early years of the internet were plagued with slow 300 kbps modems, and admins struggling with UUCP-to-SMTP gateways. And the early years of the web were plagued by horribly designed amateurish websites on Geocities.
Encrypt it with a secret password, and release it into the wild through WikiLeaks, using a catchy file name. This way, all you need to backup is the password.
Speaking from experience, it is usually more than enough to overwrite the whole disk with random data. Even a single pass is usually enough to thwart any attempt at reconstruction.
But, for the truly paranoid, you have to bypass or trick the controller to also overwrite the remapped bad sectors. That's not trivial a task, or, more precisely, it depends heavily on the controller's firmware and drive model.
Last time we checked we would need at least 3-4 times the hardware if we wanted to move to PostgreSQL.
I've migrated dozens of BIG sites from MySQL to PostgreSQL over the last couple of years, and I can confirm that more RAM was needed in some cases. But since this was on enterprise-class servers running 64-bit OSes (on SPARC and amd64), adding some GB RAM wasn't a big deal. The result was even better performance, both on Solaris and FreeBSD. The applications were never short of CPU cycles though.
So if you need 3-4 times the hardware, you're doing something wrong. Definitely wrong.
That's exactly the same in most other countries. A hand signed fax is a legally binding document, an e-mail of a hand signed and scanned document isn't. Can't be. For good reasons. Some jurisdictions accept digitally signed e-mails, but most of the world hasn't caught on yet. Also, for good reasons (cf. the recent leaks of CA cert keys). So the fax will continue to live on for quite some time.
I'm divided on the issue. On one hand, protecting whistle blowers, informants and the like is sometimes necessary... but in the mean time, most of them should have got advance warning and couldn't rely on their identities to remain undisclosed for long. So they either left the country, or they came clear with their governments (assuming they didn't get permission or even the order by their governments to talk to US embassy personnel in the first place).
On the other hand, this full list of cables is invaluable for historians, both US historians and historians of the concerned countries. Knowing how the US government interacted with their governments is very important for the public to know. So this full disclosure is overall a good thing. However, those cables would have been declassified -- redacted -- in relatively short terms (10 years was typical for most of them), and for historians, 10 years isn't all that much to wait. But knowing in near real-time what lead up to the Arab Spring is still quite intriguing.
As an extension language, something like ANSI Common Lisp would have been an extremely bloated language. As a general purpose language, it is fine though. On the other hand, Scheme is lightweight enough to be linked as a library to any application, even running in the most constrained environment.
You only see the buttons if you are logged on to your Google+ account.
I don't have a Google+ account (only a regular Google Account), but I see the +1 buttons in the search results too. Just not being able to use them without getting a Google Profile (which I won't at the moment for obvious privacy reasons).
it's cheaper to just buy a new machine to use for a home server than pay for the electricity hogged up by old hardware
Tell that people who run non-x86 architectures (like, say, SPARC, PowerPC, etc...) for all kinds of reasons. And before you ask why we don't just migrate to x86, remember that quality OSS software also depends on us testing it on non mainstream arches, uncovering a lot of obscure bugs that you x86-only guys won't trigger at all, but that are still there, lurking.
I'm typing this on a FreeBSD machine with an R128 graphics card and 128 MB of system RAM
Same here, but on UltraSPARC IIIi based SunBlade workstations running X on a R128 under Solaris 10, Debian Linux/SPARC 6.0.1a, FreeBSD 8.2-STABLE, and OpenBSD 4.9. It's the only card I was able to find with embedded FCode (needed by the SUN firmware) that runs perfectly on this architecture. It's a shame to see MESA guys so trigger happy dropping support for chips that are still running perfectly, albeit somewhat slowly.
The speed and memory overhead differences of C++ are large and noticeable.
Speaking of kernels, it IS possible to write efficient and fast ones in C++ too, e.g. L4Ka::Pistachio. You only have to know C++ very well to avoid its weaknesses.
Slashdot Mirror
Yes. Or even better: Tibet (whose culture they keep destroying). But the analogy is still slightly flawed. China considers Taiwan to be part of its territory while the US doesn't claim to own the Palestinian territories.
The scary thing here is that he felt compelled to use this unorthodox strategy to long-term prove his innocence. What happened to "innocent until proven guilty?" How comes everyone is now considered suspect, until he gets a clean bill of innocence by some partially obscure 3 letter agencies? I wouldn't spend as much time discussing "public privacy" than the more urgent fact that we're diving even deeper in this Nineteeneightyfour-ish nightmare we're already in.
They don't need Cleanfeed to block IP netblocks. Plain old Cisco's IOS access lists are all they need.
Not to forget Axiom.
Never underestimate the danger of corporate data mining.
Want an example how this can be abused? Alright. Suppose someone with a minor disease visits websites or forums talking about that. Fast forward a few years. Said person seeks health insurance, but can't get any, because the insurance companies will have access to that person's surfing habit, and will flag this person as undesirable customer. So no coverage, right?
This is just one of many, many examples what can all go wrong and it's barely scratching the surface.
Amazon's "Big Browser" shows that even non-slashdotters can come up with a catchy new meme every now and then.
How many of them are doing online banking with foreign banks anyway? If they blocked encrypted traffic at the international peering point(s), it wouldn't break their internal internet banking system at all.
Unencrypted VPN traffic is incredibly easy to flag anyway, and even the handshake of popular encrypted VPN tunnels has a pattern that's predictable enough to be quite effective. I don't need to point out that ALL ports are affected. Switching to another port is basically useless in this context.
All this DPI doesn't require huge CPU processing power, as one would naively expect; since it (currently) happens only at the beginning of a session (yes, including UDP). And that is currently the Achilles' heel of this filter: if you initiate a "harmless" (as in allowed-by-policy) connection, and switch to encryption a couple of 10k packets later, you slip right through the firewall. Try it. If it doesn't work, they've upgraded to a new release and had to invest heavily in additional routers.
Now, a leak in the CIA or NSA... that could prove to be a lot more embarrassing to the US Govt!
The early years of the internet were plagued with slow 300 kbps modems, and admins struggling with UUCP-to-SMTP gateways. And the early years of the web were plagued by horribly designed amateurish websites on Geocities.
Nope, not the lawyers. The banks are winning right now.
Maybe a post-western world will be a more peaceful world. Or maybe not.
Encrypt it with a secret password, and release it into the wild through WikiLeaks, using a catchy file name. This way, all you need to backup is the password.
But, for the truly paranoid, you have to bypass or trick the controller to also overwrite the remapped bad sectors. That's not trivial a task, or, more precisely, it depends heavily on the controller's firmware and drive model.
I've migrated dozens of BIG sites from MySQL to PostgreSQL over the last couple of years, and I can confirm that more RAM was needed in some cases. But since this was on enterprise-class servers running 64-bit OSes (on SPARC and amd64), adding some GB RAM wasn't a big deal. The result was even better performance, both on Solaris and FreeBSD. The applications were never short of CPU cycles though.
So if you need 3-4 times the hardware, you're doing something wrong. Definitely wrong.
Not only that, it's a rounded iRectangle(tm)
That's exactly the same in most other countries. A hand signed fax is a legally binding document, an e-mail of a hand signed and scanned document isn't. Can't be. For good reasons. Some jurisdictions accept digitally signed e-mails, but most of the world hasn't caught on yet. Also, for good reasons (cf. the recent leaks of CA cert keys). So the fax will continue to live on for quite some time.
On the other hand, this full list of cables is invaluable for historians, both US historians and historians of the concerned countries. Knowing how the US government interacted with their governments is very important for the public to know. So this full disclosure is overall a good thing. However, those cables would have been declassified -- redacted -- in relatively short terms (10 years was typical for most of them), and for historians, 10 years isn't all that much to wait. But knowing in near real-time what lead up to the Arab Spring is still quite intriguing.
As an extension language, something like ANSI Common Lisp would have been an extremely bloated language. As a general purpose language, it is fine though. On the other hand, Scheme is lightweight enough to be linked as a library to any application, even running in the most constrained environment.
How about, you know, TPB?
I don't have a Google+ account (only a regular Google Account), but I see the +1 buttons in the search results too. Just not being able to use them without getting a Google Profile (which I won't at the moment for obvious privacy reasons).
Tell that people who run non-x86 architectures (like, say, SPARC, PowerPC, etc...) for all kinds of reasons. And before you ask why we don't just migrate to x86, remember that quality OSS software also depends on us testing it on non mainstream arches, uncovering a lot of obscure bugs that you x86-only guys won't trigger at all, but that are still there, lurking.
Same here, but on UltraSPARC IIIi based SunBlade workstations running X on a R128 under Solaris 10, Debian Linux/SPARC 6.0.1a, FreeBSD 8.2-STABLE, and OpenBSD 4.9. It's the only card I was able to find with embedded FCode (needed by the SUN firmware) that runs perfectly on this architecture. It's a shame to see MESA guys so trigger happy dropping support for chips that are still running perfectly, albeit somewhat slowly.
Speaking of kernels, it IS possible to write efficient and fast ones in C++ too, e.g. L4Ka::Pistachio. You only have to know C++ very well to avoid its weaknesses.