>> 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/[email protected]/
