The second issue is purely technical. Although my suggestion (as Jacek somehow implies) did not require a manual review of the code (which, indeed, would take months given the amount of code in the SL viewer), but a more simple certification process of the developers, tied to a key exchange between LL, the developer, and the user with a “certified client” (which would have a certification issued based on a checksum of the binary; this can be done online and would take an amount of time equal to uploading a 50 or 60 MByte file — which takes several minutes or an hour, depending on the developers’ upstreaming bandwidth — but not more than that: the key idea was an automatic process).

This three-party method can, however, be reasonably easily forged or intercepted assuming one has the source code for the bits doing the validation. My assumptions were the following:

- the developer gets certified by Linden Lab. This means that there is a special relationship between LL and that particular developer. That’s not an extraordinary requirement. For instance, testing the Open Grid Protocol with LL was limited to a number of people who had to provide minimal data to LL; being part of the Registration API network requires a bit of effort (and LL manually activating certain capabilities on your avatar), but it’s also not very hard to do; whereas enrolling for the Risk API is, indeed, not easy. Age validation can go from purely automatic to manual faxing of documents to LL. So, overall, LL is already used to deal with “enrollment procedures” for special kinds of developers — this would be just a new one. Residents eager to join “special services” are also reasonably used to a few extra procedures.

“Certification” in this context meant mostly access to a LL-hosted site that accepts, in a trusted form, the avatar login from a certified developer, and gives an upload option (of the SL client binary), emitting a digitally-signed certificate for it, which is tied to that specific client’s checksum

- developer now distributes the certified binary with the digital certificate

- user downloads both, and logs in to SL. At this point, the SL client presents its credentials (the signed certificate) and is checked for validity. If it’s valid, SL will display only content that is flagged as “anybody can view it”; the rest will be invisible (either per parcel, or universally, etc. as per my many suggestions)

So where are the major flaws of this method?

The first problem is how the client sends its checksum (so that on LL’s side, they can check if it’s the same as in the certificate presented to it). As Jacek and others pointed out, there is no way to avoid that a malicious client doesn’t present a fake checksum with a valid certificate. Granted, once LL finds out about that particular certificate, it could revoke it immediately, but Jacek is right: revoking the certificates for LL’s own clients (which would be the prime candidates) would be a mess.

The alternative would, of course, be a release of a closed-source application running on your computer (effectively, a DRM agent) that validates the checksum for the client. This is basically what many applications out there (including Windows, but also almost everything from Adobe or Autodesk) do. Naturally, this would mean that LL would have to develop a DRM agent for all platforms and operating systems, existing and future ones (i.e. if someone ports the SL client for the iPhone, LL would have to develop a DRM agent for the iPhone too). It’s unmanageable. Also, like everybody knows, it can be compromised, too.

I was stumped to find a solution for this issue, and that was the technical argument for not pursuing my idea any further. Granted, you could place the burden on the side of the developer: each developer would create their own DRM mechanism, and hold out “license keys” for each connection. This would work the following way: when logging in, the SL client would contact a developers’ web service and get a license key, signed with a certificate emitted by LL to the developer. Then it would present that license key to LL’s grid servers, who would accept it if they could validate the developers’ signature.

The way how each developer emits licenses would be up to them. They could use a checksum thingy embedded in part of the code that would not be open source, but it would be up to them. LL would simply accept signed license keys, and that would be all. It would be up to the developer to make sure that their license keys were not abused. So it’s really pushing the blame elsewhere. The advantage? Each binary would not be required to be uploaded for validation by LL (they would simply trust the signed license key) and development would never be “stifled” that way. Naturally enough, LL would provide, with their own SL clients, the appropriate DRM agent.

The weak spot would then be on the developers’ side — figuring out a way to prevent their system to be hacked or compromised by a malicious user; because on LL’s side, once a developer starts handing out licenses for malicious use, they’d simply revoke that developer’s certificate, and none of those malicious clients would work.

Pushing the DRM issue on top of open source developers is, however, a hard strain on them :) For the libertarians among them, this would be swallowing a very bitter pill :) And, yes, I also don’t see a way how you could release open sourced code including the DRM code without having it easily subverted by a third party.

The second problem (interception) is, however, impossible to deal with. Due to the Analogue Hole with all digital content, tools like GL Interceptor will always work (even if the cache & stream contents were encrypted, which they’re not). At the very least, textures will always be easy to copy (although once you just have mesh data on the VRAM, I don’t see how you could extract “prim data” from it, meaning that at least objects would be safe).

There are no “technical flaws” with a DRM system (assuming that nobody’s claiming that it’s 100% safe, because it will never be); there is, however, an ideological flaw for some developers, and while I’m fine in discussing technical issues, I’m not interesting to discuss the merits of a proposal that gets a part of the development community itchy because of their ideology, principles, and moral stance regarding DRM. It would be not only unwise, but even unfair, to stubbornly push an issue because of that — it would be like “demanding” that Richard Stallman endorses DRM on the FSF projects because some of them are being used for illegitimate or even illegal purposes. It would be completely worthless — a fight not worth fighting, or rather, not even worth thinking about it. DRM is a dirty word in the open source community, and thus any proposal that mentions it would ultimately fail. That might be the best reason why LL has never ever suggested it in public.

So, I’ll take Jacek’s advice and focus on content theft detection and effective social enforcement instead of “magic tools” to make content theft very hard but ultimately never impossible. And like McCabe so well put it, fortunately, the number of CopyBot sellers and related sites are small, mostly due to the ethical conscience of most developers, who want nothing to do with content theft.

BTW, Dale, my apologies if your comment was deleted by mistake on my blog. Sometimes they go into the spam queue for no particular reason and I press the “delete” button too quickly before realising that there were a valid comments there :( I’m sorry! It doesn’t happen often, but sometimes it does.

Generally it’s reasonable to base a protection scheme on someone not being able to break a strong cipher. But it’s much less reasonable to assume that people won’t be able to reverse-engineer an executable. Happens all the time. :)

(I vaguely recall having posted some wise insightful comment to her “withdrawl” post myself, and never seeing it show up; maybe I pushed the wrong button. As I recall I gestured at the long and pretty unsuccessful battle that Blizzard has waged against WoW bots, and argued that given that they have an easier problem to solve and still haven’t succeeded, it’s not too surprising that it’s hard to come up with a working scheme for SL.)

Prokofy Neva’s done the same kind of thing: proposing a means of content protection that is not in fact technically possible, and then when people point out that it’s not possible declaring (profanely) that he’s being persecuted by people who don’t want any copy protection at all. Not helpful!

I think part of the problem here is that, unless you’ve looked into the problem in some depth, it doesn’t look an harder than technical problems that get solved all the time. We can make avatars fly, surely we can keep people from getting into SL with unauthorized clients! It just turns out, for relatively complicated reasons, that the latter problem is much (much (much)) harder than the former…

unfortunetly, McCabe, there’s no easy answer except:

“That’s a lot of hard bullshit.”

I totally agree with you, LL’s strategy of keeping things on the down-low is detrimental to everyone. They don’t fix anything until it’s publicly known as an exploit, and that’s a shame, it’s akin to releasing a car with faulty brakes, but nobody who’s crashed has lived to tell about it, so its no big deal.

Back in _this_ universe, though: neither did I find any sort of broad-based response — much less an antagonistic groundswell at the level even Gwyneth implied in her retraction spot. Between the two locations, there was a grand total of ten (10!) responses, of which perhaps two could be construed as dismissive or impolite. More to the point, virtually all of the comments (including the impolite ones) raised at least reasonable technical difficulties with the proposal — and not a one of them even alluded to the notion that “information, including _your_ digital content, must be free!”

It’s unfortunate, and a little mystifying, that she drew the conclusions that she did from these comments. In any case, I have to disagree with the assertion that it’s a good thing the proposal was withdrawn. Establishment of security (and specifically, strength of encryption) schemes ultimately benefit from the give-and-take of protracted, detailed exchanges. It’s not impossible that something useful can be made of this proposal, or one that serendipitously arises from its discussion. Taking your ball and going home is not the way to that end.

(And contrary to what some have said, it’s OS developers’ consciences that keep these tools out of the mainstream, not our lack thereof).

Wish there were an easy answer for this.