[mythtv-users] Be vewy, vewy quiet! We'a huntin' pirates! hehehehehehe!
Jay R. Ashworth
jra at baylink.com
Sat Jun 23 19:57:03 UTC 2007
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
More information about the mythtv-users
mailing list