While some people have mentioned the "US-resident traveling abroad" scenario, that's not really the scenario that is driving this backlash. It's mostly non-US residents wanting to subscribe to the US version of Netflix.

As a side note, I've done what you described. I have 75/75mbps on Verizon FiOS. Unfortunately, I rarely actually get 75mbps upload in practice- presumably only to services co-located with Verizon, or direct peering arrangements. I'm lucky to sustain 10mbps when VPNing from the US. In Europe, I'm lucky to sustain 2mbps.

Wait... Why can't VPNing be stopped? Sure, you're not going to be able to stop them all, but it seems quite feasible to block the vast majority of them.

First, for consumers to be able to find VPNs, they have to be publicly-available and advertised. What percentage of VPN services control 95% of market? A wild guess, but I would bet it isn't above 50, and very well might be below 10. Monitoring the top 100 services wouldn't require inordinate resources, in part because there's a wide range of companies interested in identifying and blocking VPN traffic for various reasons.

Second, if that fails, there are various techniques Netflix could use to attempt to detect VPN traffic using automated or semi-automated means. Netflix gets to see the requesting IP addresses for all their traffic. They even get to run run code on the client platforms, either because they (directly or indirectly) control the app used to access the content, or because they have the market share to put VPN-detection capabilities in the EME code for browsers. They can look at things like the number of different users connecting through the same IP address, ping/traceroute times, server and client-side IP address checks, etc., to heuristically detect VPN usage. None of those are going to be perfect, but Netflix benefits greatly by their size- they see a massive amount of traffic. If they use everything that is available to them, they can probably very accurately detect VPN usage.

Would they do it? Probably not, because Netflix is simply trying to show that they're doing due-diligence, and blocking using IP address blocks for known VPN services is sufficient for that. But, no, this isn't an impossible game of wack-a-mole for Netflix. Scale is on their side.

Yes, I read the article. I know what quote you're referring to from the article. I'm skeptical it means what the NY Times thinks it means. Getting anything through a standards process is "a challenge in finesse."

No, the article wasn't referring to AES. AES was developed by a pair of Belgian cryptographers as part of an open competition. The NSA approves the use of AES to protect Top Secret information. They didn't put a back door in AES.

The article was referring to the Dual Elliptic Curve Deterministic Random Bit Generator (Dual EC DRBG), published as part of SP800-90. The DRBG uses a set of constants, like many crypto algorithms. The NSA, as the designer of the DRBG, selected the constants. Microsoft researchers noted that if the constants were carefully chosen, the NSA could predict future outputs of the DRBG. Despite what the New York Time article says, the NSA probably didn't do that. No one was going to use this DRBG anyway, except for the NSA and their partners, so they would have very little reason to sneak in a backdoor. Still, it's a bad property to have in a crypto algorithm. You should really explain the provenance of any constants used in a crypto algorithm, and there was no explanation of how the Dual EC DRBG constants were selected.

It's not quite as bad as you're suggesting. You don't need to install a different DRM plugin for each content provider. You just need different plugins for different forms of DRM. At least in practice, I suspect, most users (i.e., those running common browsers and operating systems) won't have to install anything- the DRM plugins will ship with the browser. That's the case now with the Chromebooks and Windows 8.1/IE11.

Whether their terms are generous or not really depends on who you think is holding the cards. A company like Verizon expects to be paid for transit because historically they could demand it. A company wanting to interconnect didn't have a choice if they wanted to send data to them.

Verizon here is sort of a special case. They're an incredibly large ISP, and they own a Tier 1 network (though I wonder whether they exclusively use them). If they were a small ISP that had to pay to connect to a Tier 1 their perspective would be very different. But, Netflix is a special case too. They offer a service that's in high demand by Verizon customers. I suppose you're right that Netflix and Cogent are looking for special treatment, but that's because they think they are special. And they might be, at least from a negotiating perspective.

Now, apparently Netflix knows they're not powerful enough to demand agreements on their terms. I suppose too many people don't have more than one plausible option for an ISP, so taking a harder stance than what they've done with SuperHD would be dangerous. Still, I think they ought to do more. It seems silly for Netflix to directly or indirectly pay Verizon for the privilege of sending data to Verizon customers that requested it. If Netflix or Cogent wanted to send traffic *through* Verizon's network and onto another network that would be different. It seems like making the sender pay can really let the ISPs hide shady practices and put content providers in a difficult pricing situation. What if, for example, Comcast charged Netflix much cheaper rates to send data to their customers than Verizon? What can Netflix do? Do you expect Netflix to charge Verizon customers more for service than Comcast? Out of fairness I suppose they should, but that seems like a terrible outcome. It seems like it would be a much better outcome if Comcast/Verizon charged their customers based how much it actually cost them to deliver the data they requested. At least, I think that would clean up some of the perverse incentives that seem to exist in the current pricing structures.

I think the author is vastly overestimating the importance of the box. Sure, I'll grant you that the Apple boxes are nice, but the only people that get that attached to the box are people that are already attached to the device inside. And that's pretty common for iDevices.

By the way, I didn't have any problems opening the Nexus 7 box. I saw the funny video before I got my device, so I was probably compensating. At least, I had a knife to cut the tape holding the box shut. After that it was smooth sailing. I don't know why the reviewers had such a hard time. Maybe they just had performance anxiety by being on video.

Again, I'll grant that the de-boxing process wasn't as nice as my iPad's box, but it wasn't unpleasant by any means. On a scale from 1-10, with 10 being an iPad box and 1 being the stupid sealed plastic containers, I'd put it at about a 7. It wasn't particularly memorable, and that's probably fine.

Wouldn't the hospitals and doctors still have a profit motive? And, with health insurance policies typically set up so the individual see's little cost to themselves for procedures and tests, who would be providing a counterbalance to the doctors' profit motives to keep costs moderately sane?

I actually think the public option was a good idea, although mostly for folks that don't/can't get insurance through their employer. But I don't think it was actually going to help noticeably with costs.

You were already doing that before, partly through your taxes, partly through effectively paying higher amounts to hospitals, in order to compensate hospitals for the all the ER visits they get from people without insurance (and thus likely never pay). You potentially could have ended up in the situation you were worried about if the Supreme Court struck down the individual mandate, but kept the rest of the law.

How would a TPM do that? TPMs, for the most part, can just do things the main CPU asks it to do, like storing hashes or performing digital signature operations. TPMs can't, despite widespread FUD, interfere with software running on the main CPU. And it certainly can't stop malicious software from overwriting critical OS files.

Actually, it's a one-time $99 fee to sign an unlimited number of binaries.

Secure boot is absolutely effective without a TPM. It's largely independent. As you seem to know, UEFI Secure Boot does a verified boot- verifying signatures on code before executing it. Systems with TPMs do a measured boot- hashing any code executed during boot and storing the hash (no, TPMs won't stop you from running software).

Now, what Ubuntu is apparently trying to do defeats the purpose of UEFI secure boot. They must be locking GRUB2 down in some way. If GRUB2 is left wide open, then the signed Ubuntu first stage bootloader, combined with GRUB2, can bypass the UEFI secure boot mechanisms on everyones' machines. If an attacker starts doing that, the Ubuntu bootloader signature is going to be revoked.

The difficulty in that is that there are still a lot of PCI/PCIe cards out there that don't have UEFI option ROMs. Notably, you might want to use that 2-year old video card when your system is booting. Or, maybe you have an I/O card that you're booting off of. Certainly not everyone is going to need that, but enough users are going to be pretty upset (think: big enterprise customers with lots of users) that I don't think they could do that. However, before Microsoft announced the requirement that systems ship with a UEFI Secure Boot off-switch, I thought some laptops might ship without that option. Still, I think there are enough corporate customers running older Windows OSes or Linux on new systems that OEMs wouldn't do that. I don't think Microsoft is planning a patch to Win7 so that it works with Secure Boot enabled. A lot of corporate customers will be running that for a while.

How/why would the chainloaded [modified] Windows boot manager refuse to run? The way UEFI Secure Boot works is that the UEFI BIOS will verify the signature on an EFI executable prior to passing control to it. The UEFI BIOS largely relinquishes control of the system to the bootloader when it executes it. The bootloader will itself call the next piece of code that runs, not the UEFI BIOS, which is why the bootloader needs to do its own signature verification on the OS (or second stage bootloader) to maintain the trust chain. But, the bootloader absolutely could pass control to something without verifying its signature. And, if that's a maliciously modified Windows bootloader, that second bootloader could be designed to execute a maliciously modified Windows kernel without verifying its signature first.

I've been an unRAID user for a couple years now and I'm reluctant to to strongly recommend it. Lime Technology, the small company behind unRAID, seems to be a one-man show. And that one man seems to disappear for weeks or months at a time. If customer service and technical support are important to you, and you desire timely updates for new features and bug fixes, then unRAID might not be for you. I've largely lost confidence in the unRAID developer. unRAID v5 has been in beta for almost 2 years. At first it seemed like the developer was struggling to fix some compatibility problems that plagued recent releases, but more recent messages indicated that he wasn't paying attention to all the people complaining about those compatibility problems. Now that's he's finally listening to the bug reports things are looking up. He released V5 RC1 about a week ago, but pulled it down after a day due to the bug reports he received. But, a couple days later he posted a new version that seemed to clear up the major compatibility issues people were having for the last 6 months. That was great, although part of me is even more upset now that I know he could have easily fixed the bugs introduced in the betas 6 months ago if he had just listened to the beta testers.

Anyways, unRAID's features are a pretty good fit for the OP, but as an overall product it might not be great for his needs if he wants good support and updates.