I think I replied from an address which isn't registered with the list earlier, so here's what I said again:
The fact that this is all presumably going to be sent in the clear as opposed to encrypted means this would be technically very easy to reverse engineer. Aside from that, the key really is the resource, which you'd somehow need to protect in order to stop invalid user agents just spoofing all this info. In that respect it's very similar to swf verify, which doesn't work. Whether this can be claimed to be a copyright mechanism is a legal rather than technical issue IMO. On Tue, Mar 9, 2010 at 12:14 AM, Mo McRoberts <[email protected]> wrote: > > On 8-Mar-2010, at 22:55, Mo McRoberts wrote: > >> Learned Backstage types, > > [snip] > >> I’ve written it up here: >> http://nevali.net/post/435363058/user-agent-referrer-verification > > It’s been pointed out to me that the write-up would be better in the e-mail, > so here it is: > > This is a snippet of code which verifies access to a given resource based > upon a combination of access to a referring resource and a user-agent string. > The client generates an sha256-hmac based on the contents of the referring > resource (which the client must have access to) and its user-agent string. > This HMAC is sent along with the request for a resource. > > Thus, given a list of referring resources and valid user agents, the server > can generate a list of valid keys by performing the same sha256-hmac process > on each combination. If a client sends a request which does not appear in > this list of keys, the request is denied. > > I would be interested on an expert opinion as to whether this is considered > an “effective” technological copyright-protection mechanism according to the > Copyright, Designs and Patents Act 1988 (as amended by The Copyright and > Related Rights Regulation 2003), and whether implementing a third-party > client which implements this protocol (for the purposes of interoperability) > constitutes “any device, product or component which is primarily designed, > produced, or adapted for the purpose of enabling or facilitating the > circumvention of effective technological measures” as specified by section > 296ZB of the Act. > > Cheers! > > M. > > -- > mo mcroberts > http://nevali.net > iChat: [email protected] Jabber/GTalk: [email protected] Twitter: @nevali > > Run Leopard or Snow Leopard? Set Quick Look free with DropLook - > http://labs.jazzio.com/DropLook/ > > > > > > > > > > - > Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please > visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. > Unofficial list archive: > http://www.mail-archive.com/[email protected]/ > - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/[email protected]/
