[mythtv-users] Be vewy, vewy quiet! We'a huntin' pirates! hehehehehehe!

Sam Varshavchik mrsam at courier-mta.com
Fri Jun 22 22:37:33 UTC 2007


Joseph Caputo writes:

> On 6/22/07, Sam Varshavchik <mrsam at courier-mta.com> wrote:
>
> [ using encryption and hashing to thwart data pirrrrrates ]
> 
> Well, I admit it's an interesting solution, but I personally think
> it's overkill -- and I wouldn't want to give up *any* of Myth's
> scheduling features (though the prospect of getting less complete
> guide data than we have with DataDirect now would effectively remove
> some of the power search capability anyway).  Plus, just think of how
> long it will take the scheduler to run over a slow internet link.

I admit that I have not really dug inside scheduler's code, but I think it 
should be optimizable with a minimum overhead.

You already need to go out and grab guide data, once a day. The scheduler 
already knows the titles of the stuff you want recorded, and what your 
search keys are. The search words can be piggy-backed on the ping to the 
server to get the encrypted guide data, and the hashes come back with the 
resulting guide data.

One cool aspect of this scheme -- IMO -- is that all the extra overhead on 
the server does not require /any/ kind of a database dip. Except, perhaps 
keeping a list of about 700 fixed secrets for salting the hash function (to 
minimize the overhead of retrieving abbreviated guide data for the on-screen 
program guide, abbreviated titles of shows are symmetric-ciphered using a 
different initial vector per each half hour slice, mythtv would fetch 2-3 
hours worth of initial vectors in one ping, then use the IVs to quickly 
decipher abbreviated titles for the on-screen program guide display; someone 
trying to steal this data will have to get all 48 x 14 IVs, and thus easily 
detectable).

> Also, there are a number of people who run Myth without a 24/7
> internet connection, just updating their guide data once every day or
> two over dialup (and in a couple of cases, sneakernet!).  Not to

Intelligent caching should help that. Unless you include rotating keys
as part of the design, the hashes for the search keys never change, so you 
only need to get them once. And even if you do rotate the keys, you can 
design an organized expiration mechanism where mythtv knows when it needs to 
get new hashes (and the server can return both old and new hashes during a 
transitional period)

I never claimed that this is going to be easy. The only thing that I've said 
that it's theoretically doable.

> mention, I'm sure there are more than a few users (and possibly
> developers, too) who would strongly oppose any third party keeping
> track of what they were recording, regardless of whether it could be
> tied to them personally or not.

Yes, yes, of course. But you can't have everything. Ask yourself: if Zap2it 
was willing to go along with this scheme, are you going to decline?

And this does not actually reveal what you're recording, just what your 
search keys are.  And, potential, what times you are recording _something_.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mythtv.org/pipermail/mythtv-users/attachments/20070622/ae6bef74/attachment.pgp 


More information about the mythtv-users mailing list