Anyone who pays any attention to DRM will extrapolate the general principle:
You can never prevent an end-user who has physical control of a device from breaking any DRM scheme you can invent.
Sony just learned their DRM lesson (again). I'm sure that people at Sony already know this principle, but some "suit" tells the engineers to "do something about the problem" so they implement a technical speed bump. That's all it is and will ever be.
This is an interesting article about recent studies in the psychology of honesty and lies. Turns out that it's possible for a clever person to determine lies based on predictive human behavior under certain social obligations. In other words, the presence of the lie is leaked information, divulged by other events-- a great read for those curious of information flow theory as it implies to security.
Some content providers, like Hulu, have restrictions on certain content to make it only available in specific countries. They implement these policy goals in the form of restricting access to foreign-looking IP addresses.
If you are behind a foreign IP address and wish to view the content anyway, the current solution is to just use a VPN service to appear local.
When Kenneth G. Lieberthal, a China expert at the Brookings Institution, travels to that country, he follows a routine that seems straight from a spy film.
He leaves his cellphone and laptop at home and instead brings “loaner” devices, which he erases before he leaves the United States and wipes clean the minute he returns. In China, he disables Bluetooth and Wi-Fi, never lets his phone out of his sight and, in meetings, not only turns off his phone but also removes the battery, for fear his microphone could be turned on remotely. He connects to the Internet only through an encrypted, password-protected channel, and copies and pastes his password from a USB thumb drive. He never types in a password directly, because, he said, “the Chinese are very good at installing key-logging software on your laptop.”
Never types his password in directly? News for you: if are concerned about only key stroke logging, you forget what other avenues of approach a threat can take if it's kernel resident. On-screen keyboards and even one time password tokens (e.g. RSA SecurID tokens) can and have been defeated as well. If this is your level of threat, these countermeasures aren't good enough. This should not be the extent of the threat to consider:
Both China and Russia prohibit travelers from entering the country with encrypted devices unless they have government permission.
Here's better advice:
Now, United States companies, government agencies and organizations are doing the same by imposing do-not-carry rules. Representative Mike Rogers, the Michigan Republican who is chairman of the House Intelligence Committee, said its members could bring only “clean” devices to China and were forbidden from connecting to the government’s network while abroad. As for himself, he said he traveled “electronically naked.”
and probably the best advice:
McAfee, the security company, said that if any employee’s device was inspected at the Chinese border, it could never be plugged into McAfee’s network again. Ever. “We just wouldn’t take the risk,” said Simon Hunt, a vice president.
The cost of doing business in places like that is the cost of "burn devices". The hardware, data, and software on them, should all be thrown away upon exit. Don't risk powering it back on. Like a disposable camera. Send your data in before you leave in-country, and let go of any and all emotional attachment to the hardware.
This is a very premature response to what I believe is the single best solution to dangers like SOPA, PIPA, and ACTA: DNSCrypt.
To be fair, I don't think DNSCrypt in and of itself would be a solution to draconian "take the free out of internet" laws; however, it's going to be a very necessary component to maximize liberty in the 21st century. It's amazing the web has lasted this long without end-to-end crypto for DNS.
As stated in the link above, DNSCrypt is no replacement for DNSSEC. In fact, the ideal solution would be to rebuild DNS from the ground up using more of a web-of-trust model and completely end-to-end confidential and authenticated channels everywhere, with the ability to determine which "authority" you subscribe to for DNS and with resources listing themselves with as many authorities as they wish to be associated, ending the centralized (yet distributed for availability) control of the web. There's probably no reason to put that much power in the hands of a single entity anyway, and as governments continue on the path they appear to be on, locking down the web, isolated technical solutions will essentially create black markets for essential services like DNS.
For maximum persistence, an ideally liberated DNS solution would also need to float through filters, learning what it can from protocols designed to do so, like bittorrent, IRC, and basically any "cloud service" an enterprise IT Security team would want to block (those online drive storage services always seem to find a way through!).
And ultimately, wide-scale adoption is very necessary. It's excellent to see the inklings of that plan in DNSCrypt. Look at the choice to use ECC to preserve confidentiality. ECC requires low CPU overhead compared to other public key schemes, like RSA encryption, making it perfect for small devices like phones, wireless routers, and other embedded platforms to natively support DNSCrypt. Also important is for large scale providers like OpenDNS to support it. But like so many great technical solutions to problems, market penetration has been the deciding factor what wins out and what doesn't.
Even if DNSCrypt isn't perfect, it's a step in the right direction.
I think I really like OpenDNS. It's intelligent. It's closer to the problem than existing solutions. And it's free.
OpenDNS works by using Anycast to redirect you to the best DNS servers based on where you are. But before it quickly gives you your response, it can optionally filter out unwanted content. OpenDNS partners with communities and service providers to maintain a database of adult content and malicious websites. If you choose to opt in, each DNS query that matches a known bad site returns your browser to a customizable page that explains why the page is not allowed.
Now, privacy advocates are well aware that there is a potential data collection and use problem. However, DNS queries already are a privacy risk, since an ISP can create quite the portfolio on you based on which names get resolved to numbers. OpenDNS can collect information about you, including statistics associated with DNS usage on the networks you manage, but that choice is not turned on by default-- you have to opt into it as well. So, all things considered, privacy is well managed.
I really like this approach to filtering unwanted HTTP content because it completely prevents any connection between clients and offending servers. In fact, clients don't even get to know who (if you can allow me to personify servers for a moment with the term "who") the server is or where it lives. But what I like even more is that this service is simple. There are no complicated client software installs (that users or children can figure out how to disable), no distributed copies of offending URL databases to replicate and synchronize, and no lexicons for users to tweak. It's lightweight. All it takes is updating a DHCP server's entries for DNS servers to point to 208.67.222.222 and 208.67.220.220 and checking a few boxes for which content is needed to be filtered in an intuitive web administration console. For a home user, that's as easy as updating the DNS server fields in a home router-- and all current and future clients are ready to go. An enterprise could use this service as well as its DNS Forwarders. And many larger customers do. A non-tech-savvy parent could turn on content filtering without the "my kids program the VCR" syndrome resulting in the kids bypassing the filters. Setting an IP Address for a DNS server doesn't stand out as a "net nanny" feature to kids who are left alone with the computer.
Okay, there have to be caveats, right? Here they are ...
If you're planning on using some third-party DNS service--especially one that is free-- it had better be performing well and it had better be a service that you trust (because DNS has been used in the past to send people to malicious sites). Since their inception in July 2006, OpenDNS has serviced over 500 Million DNS requests with a 100% perfect uptime track record. And from their open, collaborative stance on issues like phishing (see phishtank.com), you'll want to trust them.
Any DNS misses (except some common typos) will return you to an OpenDNS web page that tries to "help" you find what you missed. The results look like re-branded Google results. Users taking links off the OpenDNS results page is how OpenDNS makes their revenue--on a pay per click basis. That's how they keep the services free.
Dynamic IP Addresses can mess up a home user's ability to keep content filtering policies in-check (but this won't affect enterprises). But there are a number of ways to keep the policies in-synchrony, including their DNS-O-Matic service. What I'd like to see added on: native consumer router support for Dynamic IP address changes to keep content filtering policies in place no matter what the ISP does. [The Linksys WRT54G wireless router, for example, supports similar functions with TZO and DynDNS today-- it would be nice if OpenDNS was another choice in the drop-down menu.] If my neighbor enrolled in the service, it might be possible for me to get my neighbor's OpenDNS filtering policies if we share the same ISP and Dynamic IP pool, but again, that's what the dynamic IP updating services are for.
Enterprises who decide to use OpenDNS for their primary outgoing DNS resolvers must keep in mind that an offending internal user could simply specify a DNS server of their preference-- one that will let them bypass the content filters. However, a quick and simple firewall policy (not some complicated DMZ rule) to screen all DNS traffic (UDP/TCP 53) except traffic destined for OpenDNS servers (208.67.222.222 and 208.67.220.220) will quell that concern.
So the caveats really are not bad at all.
Since the company is a west coast (SF) startup and since the future seems bright for them as long as they can keep their revenue stream flowing, I imagine they'll be gobbled up by some larger fish [Google?].
...
This might seem like a blatant advertisement, but (number one) I rarely like a service well enough to advocate or recommend it and (number two) I am not financially affiliated with OpenDNS in any way.