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]/
