[mythtv-users] Be vewy, vewy quiet! We'a huntin' pirates! hehehehehehe!
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
> 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
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
Size: 189 bytes
Desc: not available
Url : http://mythtv.org/pipermail/mythtv-users/attachments/20070622/ae6bef74/attachment.pgp
More information about the mythtv-users