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

[Jay R. Ashworth]

On Fri, Jun 22, 2007 at 06:57:03PM -0400, Sam Varshavchik wrote:
> Jay R. Ashworth writes:
> >On Fri, Jun 22, 2007 at 07:06:07AM -0400, Sam Varshavchik wrote:
> >>That's just a form of keyword-based search, which can be done without 
> >>revealing entire guide data. What you need to do, in addition to 
> >>encrypting program details using a symmetric cipher, with a per-program 
> >>key, is to have a second copy of the program guide where each individual 
> >>word W is replaced by H(w+secret). H is a hash function, 
> >>MD5/SHA1/SHA256/whatever. "secret" is a secret known only to the server. 
> >>To effect the search, you'll need to ping the server with w, the server 
> >>returns H(w+secret), and that's what you run your search with. I've left 
> >>out some minor details, but that's the general idea. 
> >>
> >>I admit that, without some crafty hacking, you'll lose the ability to run 
> >>arbitrary SQL searches, but this'll work for most searches that people 
> >>use. Once your search finds individual programs, you'll then ping the 
> >>server to get it's cipher, and obtain the program details.
> >
> >So, if I understand you right, you want some centralized DBMS server
> >somewhere *to participate in every scheduling event ever on all 200K
> >mythboxes in the US*?
> 
> Oy-vey.  No database is required, of any kind. There's only one "secret", 
> see above, that's needed on the server's side, to return hashes, upon 
> request. If you want to use different per-subscriber hashes to vary the 
> salt, just add the subscriber ID as an input into the hash function. The 
> server does not care if the subscriber ID is valid or not, it's just goes 
> into the hash.
> 
> This is easily distributable.  The hash servers have no dependencies 
> whatsoever. Plus, unless you want the ability to rotate secrets, the mythtv 
> client need to obtain the hash only once, when you initially set up a new 
> search key, and cache the hash code in perpetuity. And if you want the 
> ability to expire hashes, an intelligent expiration mechanism can easily be 
> grafted.

I'm going to have to look in more depth into what you're suggesting...
but it sounds as if it's trying to fix a problem I decline to
contemplate: the idea that schedule data *should* be proprietary, to
anyone. 

There are lots and *lots* of examples in the last 10 years or more of
situations where an organization makes more money on it's mainstream
business by *ceasing* to try to monetize ancillary things they're not
in business to so; if we can't make that sale to stations, we're in the
wrong business.

Cheers,
-- jra


> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


-- 
Jay R. Ashworth                   Baylink                      jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com                     '87 e24
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274