I use:
4) Cablebox with Firewire output + firewire port on PC.

It works really quite well.

Cable companies are required to offer cable boxes with firewire (usually the HD ones all come with it). However, depending on your cableco, the firewire output may or may not be encrypted. You can only connect it to your PC if it is not encrypted.

Note that the presence or absence of encryption on the Firewire output is *totally independent* from whether the data is encrypted on the cable line. The cable box decrypts the signal with its cable card, and possibly re-encrypts it for the firewire output, depending on the cableco's settings.

For me (with RCN Boston), I've found that all the extended-basic channels are sent unencrypted over the firewire output, except, paradoxially, *sometimes* the HD OTA channels. I dunno what's up with that, but my solution was to just not go through the cable box for those channels. I don't subscribe to premiums, so I don't know whether they are encrypted or not. Your mileage may of course vary, depending on provider and possibly even region.

The parallels are astounding: Indefinite delays, arbitrary conflicting decisions, and reapproval of already-approved content required when making minor changes!

I'm sure part of the problem with the "unofficial" app store is that it's quite likely that one of these days, Apple will get serious, and make a bootloader without glaring security holes in it. (I mean come ON, Apple, the bootloader isn't that big!...)

When that happens, it may be impossible to "permanently" unlock an iPhone without hardware mods, which will seriously limit the Jailbreak community -- probably into irrelevance.

That's a rather big risk for anyone to take on in their development...

Heck, I'm not even bothering to learn to write for the iPhone as a *hobby*, because it'd be a waste of my time. Pretty much everything I want to write isn't allowed by Apple's rules, and while my phone is Jailbroken, Apple is trying (so far, completely incompetently...) to prevent me from being able to buy a new jailbreakable iPhone ever again. So it seems to me that the iPhone is basically a dead-end platform.

Not true. Unfixed release-critical bugs in unknown and barely used packages result in the package being removed from the release, not the release being delayed.

See here, about crypto CPU usage.

I'll also note that DNSCurve lookups use less network bandwidth than DNSSEC. DNSSEC drastically increases network bandwidth requirements with all those individual record signatures that need to be returned...

Your statistic would be valid for no cache vs a cache.

But that's not the actual question at hand.

The question is:
What's the cache hit rate for a recursive cache serving a group of machines, vs. the cache hit rate for a recursive cache serving just a single machine.

I'm going to place my bet on nowhere near a 10x increase in traffic from having an unshared local cache.

But I haven't done the test. If anyone wants to (or knows of literature that's already explored this)...

A "validating stub resolver" will actually need to be (basically) a recursive resolver itself (it needs to do multiple queries to verify each signature in the delegation chain from the root down to the record it's actually interested in). And thus, if you want it to perform well, it'll need a local cache.

Now it's basically a caching recursive resolver.

So, is your claim that because the caching recursive resolver which you run on localhost can use a second-level remote cache instead of talking to the authoritative servers directly, DNSSEC is superior?

I suppose you can consider that an advantage...but heck, I sure can't see the point of it. If you're going to require a caching recursive resolver on localhost, just have it talk to the authoritative servers and be done with it... It certainly doesn't seem worth all the pain of DNSSEC to allow for an untrusted intermediate cache to be used!

I just don't see it.

Huh?

DNSSec doesn't let you set your laptop's DNS to Starbucks' NS and be safe, because you can't do DNSSec from a stub resolver and have to use TSIG (which protects the client->server data transfer, not the zone data).

DNSCurve doesn't let you set your laptop's DNS to Starbucks' NS and be safe, because DNSCurve protects the client->server data transfer (of each step of the process) not the zone data.

You're screwed either way.

Or, you can decide to either use a different resolver somewhere on the internet you *do* trust (and configure its key so you can be sure you're actually talking to it!), or run a caching recursive resolver on your laptop. Either of those will give you properly secured DNS with both DNSCurve and DNSSEC.

You might be interested in this thread:
https://lists.dns-oarc.net/pipermail/dns-operations/2008-May/002736.html
where Paul Vixie recommends that nobody should ever deploy a stub resolver that supports DNSSEC, but instead use TSIG to talk to the recursive resolver. Which really makes DNSSEC's security characteristics look very much like DNSCurve. The only difference being that DNSSEC is hugely more complex to use and implement.