Re: [backstage] Re: User Agent/Referrer Verification
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. I should say: I deliberately didn’t ask for a cryptographic critique. this isn’t code I’m planning on deploying anywhere. however, some folk may (as you have) recognise it as being similar to something else, although my code is obviously pretty generic (it’s built on HTTP, but could just as easily be RTSP, or something else). For what it’s worth, SWF Verification _does_ work, if what you want to do is “prevent access to the media from people who don’t have access the SWF”. Assuming they can’t get it any other way. Which is, of course, a massive assumption to work. SWF Verification doesn’t work for anything else, of course, but it’s not really designed for it, either (the clue is in the name!). It's the access to the referrer part that I don't understand. Why is it any harder for an invalid client to access it than a valid one? This is locking the door and then putting the key under the mat. Once everyone realises where the key is it's all a bit trivial. You'd have to put completely different protection on the referrer file itself. On an _utterly_ unrelated note, isn’t it weird how Red5 can happily implement SWF Verification on the server side, but XBMC apparently can’t on the client? Quite. Padlocks are legal but lock picks are going equipped in British law, but only if you wander around with them. - 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/backstage@lists.bbc.co.uk/
Re: [backstage] Re: User Agent/Referrer Verification
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 p...@dabdig.com 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 ikwall...@gmail.com To: backstage@lists.bbc.co.uk 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 m...@nevali.net 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: mo.mcrobe...@me.com Jabber/GTalk: m...@ilaven.net 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/backstage@lists.bbc.co.uk/ - 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/backstage@lists.bbc.co.uk/ - 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/backstage@lists.bbc.co.uk/ - 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:
[backstage] Free films in 1080p?
We're going to be committing Blu-Ray compatible encoding in x264 soon, which will be the first open-source Blu-Ray compatible encoder, and we plan to release a free downloadable Blu-Ray image to coincide with this. We really don't want to release something like Big Buck Bunny or Elephants Dream for the umpteenth time so we're looking for something else (length doesn't matter much) The conditions are: Must be free Must look good in 1080p Must have a high-quality master available to us Are there any good suggestions for what we could use? The only two which are contenders so far are Bergensbanen from NRK, a 7.5 hour train journey (!), or Fairytale from the SVT HD test set (though we haven't yet been able to track down anyone who has a full copy) (For the H.264 nerds out there, another developer added multiple slice support a few months ago and I wrote a large part of NAL-HRD which were the missing pieces we didn't have that Blu-Ray requires) - 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/backstage@lists.bbc.co.uk/
Re: [backstage] Re: User Agent/Referrer Verification
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 ikwall...@gmail.com To: backstage@lists.bbc.co.uk 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 m...@nevali.net 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: mo.mcrobe...@me.com Jabber/GTalk: m...@ilaven.net 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/backstage@lists.bbc.co.uk/ - 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/backstage@lists.bbc.co.uk/ - 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/backstage@lists.bbc.co.uk/
Re: [backstage] Free films in 1080p?
On Tue, Mar 9, 2010 at 13:00, Kieran Kunhya kie...@kunhya.com wrote: We're going to be committing Blu-Ray compatible encoding in x264 soon, which will be the first open-source Blu-Ray compatible encoder, and we plan to release a free downloadable Blu-Ray image to coincide with this. We really don't want to release something like Big Buck Bunny or Elephants Dream for the umpteenth time so we're looking for something else (length doesn't matter much) …nor Sita Sings The Blues, presumably ;) The conditions are: Must be free Must look good in 1080p Must have a high-quality master available to us Are there any good suggestions for what we could use? NASA have a whole heap of stuff, especially Hubblecast and I think the ISS on-board programmes. Browsing Vimeo HD will likely turn up some decent showreels which the creators are generally happy to release if you ask them. Also speak to the guy behind VODO (Jamie King), ISTR he mentioned he had some 1080p stuff. i...@vodo.net is the place for enquiries. You’ll probably have to ask for the masters—most folks don’t tend to bother uploading them anywhere, for relatively obvious reasons! Most of the people I’ve dealt with related to this kind of stuff are pretty amenable to trailblazing projects and the like if you ask nicely :) (For the H.264 nerds out there, another developer added multiple slice support a few months ago and I wrote a large part of NAL-HRD which were the missing pieces we didn't have that Blu-Ray requires) Awesome work — congratulations to you and the rest of the x264 team! M. - 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/backstage@lists.bbc.co.uk/
Re: [backstage] Re: User Agent/Referrer Verification
On Tue, Mar 9, 2010 at 14:23, Paul Webster p...@dabdig.com wrote: And for practical purposes ... the UserAgent field changes with version updates. You would think, wouldn’t you… 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) That’s certainly the case in HTTP. Less so in other protocols. As far as I know, there’s only one single UA in RMTP (and only one “Server”-equivalent response). Indeed, one could contend that the fact there’s only one suitable value in each direction relegates it to a protocol-level constant which couldn’t possibly be used as the basis for any legal protection. 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. Yup. Or, a rogue user just distributes the media by hand. Or obtains it through some other means… 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. You’re assuming there was some. I’m not at all convinced there was any, and I suspect that’s part of why it was just quietly switched on. I do think the BBC is (collectively) genuine when it says that it’s unfortunate that XBMC has stopped working. This raises more questions than it answers. There are plenty of people on this list alone who could have trivially pointed out the various unintended consequences of doing it, and it’s certainly not won many prizes in the old PR stakes. With the current consultation on iPlayer running and the threat of political turmoil, it seems to me to be the _worst_ possible time to attempt to quietly flip the switch. It really is Freeview HD all over again: quietly do it, hope that nobody notices. The difference in the Freeview HD case is that there was actually straightforward logical reasoning for not telling anybody; the engineers _knew_ the measures would do nothing at all with respect to piracy, but if the rightsholders knew that the public knew it was worthless (even though we’d all find out in a matter of days anyway, especially given that Freesat has it), then they’d walk away. Get them to sign on the dotted line first. Questions persist about BBC HD on Freesat, of course, but they can mostly be put down to everything being sorted out at the last minute rather than any real screw-ups (I’m not convinced the Culture, Media Sport Select Committee would necessarily view the debacle quite so generously, though). I do wonder how much of the TV budget adjustments in the strategy review were driven by the difficulties in getting content from third parties; if the BBC is making more programmes itself, or at least commissioning them into a known landscape (rather than buying them in from the US), there are limits to who can quibble about it broadcasting FTA, HD or otherwise. My gut feeling is that in this case, nobody with any real involvement in the change actually stopped to consider what negative impact it might have (rather than knowing full well what it was and crossing fingers). The PR geniuses need to be taken out and shot, though. Ian Hunter’s blog post was an utter disaster. Given the technically-minded audience of the BBC Internet Blog, wheeling out the Managing Editor of Online to blind everyone with some technical terms was an ill-thought-out move, at best. This situation is one where honesty really would be the best policy: “Sorry about this. We hadn’t actually considered that things like XBMC would break. In all honesty, we didn’t perform a proper analysis of pros and cons in making this change, and promise to consider the implications of things like this more carefully in the future. Just so that everybody’s clear, though, using an unsupported client means that it can break altogether at _any_ time, even if the reason for the breakage seems utterly unfathomable from a logical point of view.” M. M. - 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/backstage@lists.bbc.co.uk/
Re: [backstage] Re: User Agent/Referrer Verification
On Tue, Mar 9, 2010 at 14:23, Iain Wallace ikwall...@gmail.com wrote: It's the access to the referrer part that I don't understand. Why is it any harder for an invalid client to access it than a valid one? This is locking the door and then putting the key under the mat. Once everyone realises where the key is it's all a bit trivial. You'd have to put completely different protection on the referrer file itself. Not really. Think of the situation where the media is served from a CDN but the player SWF (i.e., the referrer) is behind a paywall. SWF Verification allows the CDN to have a list of keys which are known-good, and so be (slightly) confident that only those successfully hitting the media have authenticated themselves properly to access the SWF, without needing to build some sort of federated auth system on the CDN. This is, obviously, contingent on nobody with legitimate access to either the SWF or the content redistributing it, but that’s not the problem it’s intended to solve. Also, it all rather depends upon what you define as an “invalid” client: is something which properly implements the protocol and whose user has legitimate access to the SWF a valid or an invalid client? If the answer isn’t “valid”, SWF Verification isn’t the solution you’re looking for. I’m not actually defending SWF Verification, incidentally. But, from what I can gather from various people “in the industry” (plus, of course, Adobe’s legal threats), there’s a huge amount of misunderstanding as to what it actually _is_, which means it gets deployed in ridiculous situations. (Simple example: if the “authentication” layer for your SWF is GeoIP-driven restrictions, and those same restrictions exist on the CDN, implementing SWF Verification is pointless, because those denied from accessing the SWF are *already* defined from accessing the media). On an _utterly_ unrelated note, isn’t it weird how Red5 can happily implement SWF Verification on the server side, but XBMC apparently can’t on the client? Quite. Padlocks are legal but lock picks are going equipped in British law, but only if you wander around with them. Except that implementing SWF Verification in XBMC wouldn’t be anything like having a lock pick. It’s more like having fingers which can grasp a key—you still need the key (the SWF, in this now slightly tortuous analogy!). M. - 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/backstage@lists.bbc.co.uk/
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 m...@nevali.net 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: mo.mcrobe...@me.com Jabber/GTalk: m...@ilaven.net 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/backstage@lists.bbc.co.uk/ - 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/backstage@lists.bbc.co.uk/
Re: [backstage] Re: User Agent/Referrer Verification
On Tue, Mar 9, 2010 at 13:50, Iain Wallace ikwall...@gmail.com wrote: 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. Fair point, and indeed I’d probably want some kind of session key involved (be it HTTPS, or whatever) were I _actually_ to propose this as an implementation for something :) 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. I should say: I deliberately didn’t ask for a cryptographic critique. this isn’t code I’m planning on deploying anywhere. however, some folk may (as you have) recognise it as being similar to something else, although my code is obviously pretty generic (it’s built on HTTP, but could just as easily be RTSP, or something else). For what it’s worth, SWF Verification _does_ work, if what you want to do is “prevent access to the media from people who don’t have access the SWF”. Assuming they can’t get it any other way. Which is, of course, a massive assumption to work. SWF Verification doesn’t work for anything else, of course, but it’s not really designed for it, either (the clue is in the name!). (I tweaked my code last night after posting this to better explain what it does/doesn’t do or protect against to avoid any misconceptions about what it might achieve were somebody to implement it). Whether this can be claimed to be a copyright mechanism is a legal rather than technical issue IMO. …but does rather depend upon the technical aspects of it, to *some* extent. but yes, it’s the legal aspect I’m really interested in. if somebody else were to implement the same algorithm (no spoofing of resource hashes required) as appears in client.php, would they fall afoul of the CDPA (or, indeed, the DMCA)? On an _utterly_ unrelated note, isn’t it weird how Red5 can happily implement SWF Verification on the server side, but XBMC apparently can’t on the client? M. - 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/backstage@lists.bbc.co.uk/
Sita was: [backstage] Free films in 1080p?
I had tried to get Sita released in SVG format. unfortunately Nina wasn't happy with SVG output from Adobe source files, in particular some transparencies are lost in the conversion, and there doesn't appear to be a work around. . regards Jonathan On 9 Mar 2010, at 13:21, Mo McRoberts wrote: …nor Sita Sings The Blues, presumably ;)
