Why, yes, I would be happy to pay more (even substantially more) for an Internet connection unencumbered by technically nonsensical restrictions designed to protect the revenue streams of legacy products from the same company. I would much prefer that my ISP offer unbundled Internet access at a price that reflects their actual costs, rather than subsidize their Internet service with the profits from services I neither want nor need and then attempt to force me to use those services.
And Apple is not likely to say "Yeah, we can write this backdoor brute-force buddy software" because that would mean that someone else could write that software, which would mean that Apple's encryption now has a known point of potential compromise. So Apple will say it can't write that software. And then the US Attys will hopefully shut up about it already.
This isn't entirely true: as noted in the order, any OS-level software to be run on an iPhone needs to be signed by a cryptographic key held only by Apple unless it exploits a vulnerability in the phone's existing software to install itself (i.e. jailbreaking). It is therefore much easier for Apple to provide this kind of modified software than for a third party. The signature requirement also means that if, as requested in the order, Apple makes the putative custom OS image check the device ID of its host to ensure that it's running on the target device, that check will have teeth because if it's edited out the signature will no longer be valid.
Also, the modified software wouldn't actually weaken the disk encryption scheme itself. It would make it easier to attack weaknesses in the user's choice of key on this particular device, but if the user chose a decent password a brute-force search would still take prohibitively long.
Of course, that doesn't really change the likelihood of Apple complying with this order without a fight. It just affects your reasoning as to their motivations.
Ad blocking via DNS remapping (which is what modifying the hosts file does) isn't easily distinguished from real network issues, but it's certainly detectable.
While it may not be what they're doing now, it's possible for them to require all of the ads to load before they display the page content. Depending on how much they're willing to impact page load performance, they could go as far as making it impossible to fetch the actual content without submitting tokens included in the ads. That would mean the user's browser would need to at least fetch, if not actually display, the ads in order to get the page content.
That would impact their performance for users who don't block and would require significant additional resources and complexity on the server side, but that hasn't stopped people from using DRM before...
That's... just not true, at least for a properly set up TLS connection. They can't add to, remove from, or change anything that goes over a TLS channel in a way that either party will accept without knowing the session key. It doesn't just guarantee that nothing in a particular HTTP request will be altered, as you seem to imply. It guarantees that nothing sent over the TLS connection will be altered. Even were that not true, the header would need to be inserted into the middle of the user's HTTP request and would thus require alteration of the message itself.
If Verizon has a CA cert that's trusted by mobile browsers they could be MITM-ing the TLS negotiation. That's even plausible for phones distributed by Verizon. If that were the case, though, it'd be called out by the researchers who've been reporting on this. We'd also see calls for it to be removed from the trust roots.
Gumnos' concerns about TLS-stripping attacks are much more likely to be valid, although the particular case mentioned probably wasn't malicious.
This isn't good so much because the judiciary will be able to toss out bad suits on their own (though that would be awesome). It's good because it means that the initial complaint the defendant gets served with has to tell them what they're accused of doing wrong. Right now it's not uncommon for defendants to not know which of their products or processes is accused of infringing which patent claims until discovery, hundreds of thousands of dollars into the suit. If this goes through they'll hopefully have the ammunition to get the suit dismissed much earlier in the process.
IANAL, but I believe that the difference is one of scope. In the case of the Netherlands' writable media levy, the ECJ directly struck down the national law. The data retention directive, on the other hand, is a EU directive which implemented by local laws in each member state. Since the directive was struck down each state must re-examine their implementations and ensure they comply with the ruling. Until they do so or the laws are struck down directly they remain in force.
But American citizens and entities are bound by them anywhere in the world. A fully independent part of Level 3 operating from a foreign country bound to its American parent only by contract obligations would be (mostly) immune from American court orders. Anything that's legally part of the American company is within the jurisdiction of the American court system regardless of where in the world they operate.
The browser vendors are relevant here because they exert strong market pressure on the CAs in their root store to have reasonable revocation policies. Since the majority of their customers are using their certificates to operate HTTPS web sites even one major browser removing their root certificate is a business-ending event for a CA.
The certificate holder doesn't even have to say they're in breach of contract. They just need to push a CRL entry with reasonCode=keyCompromise. Most CAs are more than happy to revoke keys that have been compromised; especially since they'll often get to charge the customer to re-issue them.
This. A thousand times this. Indirection and the various derived objects it creates is something many, many people have trouble following.
I have one gripe with your explanation, though. You set out to explain that the creative work itself is not and cannot be owned, but then you describe it using the terminology of property (including the word "own"). The copyright in a work does not grant ownership of the work. Rather, it grants a temporary, exclusive right to exploit some aspects of the work. Inasmuch as we have collectively agreed that such a right exists, its exclusivity makes it rivalrous and thus it can reasonably be owned and transferred as property. Even allowing for the existence of the exclusive right, however, the work itself remains non-rivalrous and thus cannot be property.
I couldn't figure out a way to create a direct link. It seems to POST the case number to one page which then redirects you to the display page without passing along the case number. I guess it stores it in your session or a cookie or something.