I'm trying to work out if this thread is a genuine idea being proposed or if it was simply to highlight the futility of SWF Verification. If it was the latter: Well demonstrated! ;)
On Tue, Mar 9, 2010 at 2:23 PM, Paul Webster <[email protected]> wrote: > And for practical purposes ... the UserAgent field changes with version > updates. > So - as software gets updated it would mean that the back-end would also > have to go through the library and re-generate keys for old material (or > recalculate it on the fly on access). > Taking just an invariable sub-string of the UserAgent field ("product" up to > the "/") would remove the issue. > > But is this an attempt to determine if "rogue"-application1 using the > UserAgent string of "legal"-application2 might be the basis of some sort of > legal protection (copyright or DCMA-style infringement)? > > Sounds unlikely to me - given that changing UA field is routinely done and > documented (e.g. Opera includes it in standard UI so that it can get into > sites that include code for specific browsers but don't recognise standard > Opera). > (MS-IE identifying itself as "Mozilla" is an example of hackery in this > area) > > Meanwhile - what happens when someone distributes one of more of the pairs > of user-agent/key - in that case the "rogue" app will not need direct access > to the original file. > > Personal view - I wish that the Flash verification had not been turned on - > and I would like to see the impact analysis that BBC did before doing it. > > Paul > ----- Original Message ----- From: "Iain Wallace" <[email protected]> > To: <[email protected]> > Sent: Tuesday, March 09, 2010 1:50 PM > Subject: Re: [backstage] Re: User Agent/Referrer Verification > > >> 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]/ >> > > - > 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]/
