Rather..good idea, but (I think) cryptographic part needs to be little more complex than usual certificate chain.

it could even evolve to option on account page ‘you logged in with in last month. do you want to allow logins only with ‘?

p.s.and this doesn’t NOT require distribution of signing key with viewer source

Two: As you already mentioned in a follow-up comment, there is still no practical way to address interception at the local memory level with tools like OGLE. So you went to all the trouble to encrypt and verify people with proper clients (slowing down their performance tremendously in the process) and now they can still pluck all the decrypted shapes and textures right out of the memory on their own machine. If your proposed system is implemented then all piracy efforts would just shift towards make GL interception easier to use. The pirates still have a way to pirate and all the legitimate users are now burdened with a low-performance client with several more points of failure to boot.
I admire that you are trying to protect content creators and are proposing solutions instead of just whining, but really there is no winning this war. If you implement a scheme like this, everyone loses.
Personally, I think the key to creating a content creation market in the metaverse is not to base your business model on singular objects, gadgets and textures. The analog hole has existed for a long, long time now and a lot of smart people have failed to plug it. The key is to specialize in creating whole experiences. Websites, like metaverse content, are easy to copy and mirror and emulate. It’s the constant interaction and updating of content on a website that keeps a user community coming back and generating revenue. This is what people should be focusing on if they intend to make money in the future metaverse. Those who base their business on skins and objects are bound for extinction in my opinion. There will always be a way to pirate simple content (analog hole) and there will always be those who choose to make and offer similar content for free. Experiences and communities are a much harder thing to steal.

Persig Phaeton

They already do offer both.

The idea that it is “just another DRM” isn’t something to discredit this plan whatsoever. Because what do need is in fact a DRM because people do in fact have rights and in fact do expect that a virtual world helps keep them, and not merely with a note to “call your lawyer” which is all the OS gang wants.

I’m very disturbed to hear that you’re “withdrawing” this proposal, Gwyn, being beat up by OS thugs in the process.

It doesn’t matter if someone can copy it — they’d have to get access first, and it’s enough of a complex regime that the average opportunist won’t bother.

LL could very well get into the certificate business and help guard content. It is the only hope of the Metaverse having any viability of commerce, frankly. Don’t listen to Adam, he’s a Bolshevik on these matters.

LL can and should offer closed-source clients, and end this hysterical fascination of open source. There is no reason they couldn’t offer both? One will be chosen by those who want to protect content, and the other will be chosen by those who don’t, and the market will decide.

The key to Gwyn’s brilliant plan is the check box on the sim. The sim owner gets to decide. He can be overwhelmed by a fake stealer of a signature, but then he has evidence of a crime, when the resale is discovered — evidence of a break-in.

I totally agree that you objective here is to make it HARDER, and you don’t defeat the project merely by saying it is not 100 percent perfect.

Quoth:
>>Jacek, obviously the viewer “string” is not enough We all
>>agree with that… that was the whole point of not relying on
>>it at all, but use LL-signed digital certificates which are
>>tied to a specific build of a client. The checksum would be
>>part of the certificate, or, to be more precise, it would be
>>encoded as part of the certificate — like website
>>certificates these days simply use the website’s URL as part
>>of the encoded data.

Website certificates are a whole different ball game – in SSL’s case, you are verifying a outside identity (DNS) *and* an outside authority (Verisign/etc), to verify who you are speaking to. If DNS was corrupted, then someone could in theory start forging webservers too.

On a local viewer case you have no outside identity who can vouch for you running an official viewer – hence the scheme falls apart. If it was possible to verify who is/isnt in an official client – Blizzard wouldnt need software like their ‘Warden’ to try prevent bots from logging in (and people just corrupted the warden to act as a verifier – leading to the recent copyright case with Blizzard and WoW Gilder.)

You’re failing to understand that the client is open-source so it doesn’t matter what sort of encryption is going on – the key is there. You can just get a key from a “legitimate” client (without the need of the author’s consent) and use it on your “illegal” client.

Encryption isn’t meant to prevent communications from being intercepted and read by unwanted parties. It does no good if the client or the server are compromised (and, thus, their keys are known).

The only way your proposal is achievable would be with a closed source client. And even on that case, the key still needs to be there somewhere and, sooner or later, someone would find out.

If you fail to understand this, please, try studying encryption or network security overall. You’re missing a fairly basic thing.

So you’d get a more restricted system for legitimate users with a closed source client which still allowed illegal copies.

Do you work for the RIAA or MPAA by any chance?

But my text was not very clear, I admit that I had Symbian Signed in mind: submit the client to LL’s website, which will embed the signature in the compiled executable, and return a version with the signature embedded into it. I agree that’s a bit tough to do and by far the largest drawback of this solution — it’s something like 50 MBytes each time, after all, for the regular SL client. Granted, you would need to do this only once per released version.

To be more precise, even that could be forged — say, authenticating with one trusted client, and then using another one to receive the incoming packets. Switching sessions in SL happens naturally when changing regions via teleport, so this might work). So I agree this might not be so easy to implement But… see below.

Packet sniffers work wonderfully well (and the libopenmv package even comes with a pre-compiled “proxy” to aid in decoding streams of data between the server and the client — you connect your SL client to the proxy, the proxy connects to SL, but logs all traffic exchanged between both. It’s insanely easy to use.), but — the answer, of course, is encrypting the data streams. Positioning information, which is more sensitive, could continue to go through the usual, unencrypted UDP channels as normal. A few suggestions by the Architecture Working Group has been to continue to keep positioning information in UDP packets, but move streaming data transfer to HTTP instead. Move it to HTTPS, and the packet sniffing will be pretty useless (and you can do two-way certificate handshaking, since both LL’s grid and your client will have certificates for the SSL connection at both ends).

It’s obviously impossible to prevent the copy of textures (that’s why avoided to put the focus on them). Although there are far better solutions to deal with the cache without making it so childishly simple to copy, nothing can prevent GL Interceptor or any memory-reading application to get at the textures (and very likely sounds as well). It would only be harder. And believe me, while everybody is able to figure out what a skin or a piece of clothing looks like merely by looking at it (those would continue to be prime targets for memory interception techniques), patiently wading through cryptic images for sculpties and their UV maps, and figure out where it goes on a complex object (when you don’t have the prim relations anyway), is far from an easy task.

Quoting myself, Nothing in the world is 100% safe. The idea is to make content theft very hard instead of insanely simple like it is today. I hardly understand how that stifles legitimate use and open source development; every day I use digital certificates to log in to VPNs and that certainly doesn’t “stifle” my use of remote services or my ability to do development (an encrypted remote call with libCURL just adds an extra line of code… provided you’ve got a legitimate certificate in your disk first, which was my whole point). It just makes it way more harder for potential crackers to enter my network.

As you say, the viewer’s simple string signature can be forged. I could, in theory, make a viewer filled with all sorts of nasty things, and make it report itself as “Second Life Release 1.21.6″. Currently, LL’s servers would be fooled.

But I don’t see how that issue could be corrected with certificates. If the certificate is a file on the computer, it could be copied from a legitimate installation (even an installation of LL’s own viewer!) and used to “verify” another viewer. Even if the certificate is embedded in the viewer executable (either as part of the source code, or as a separate file that is linked in), it could still be decompiled or extracted.

And of course, if it were part of the source code, LL would have to withold that part of the source from its open source releases, as would any open source viewer that applied and got a legitimate certificate from LL. Compile-your-own viewers would be crippled, and open source development drastically stifled.

As for using a checksum of the binary, I doubt that would work. Unless you’re going to send all 50MB or so of the program over the internet at every login so that LL could do the checksum in a clean environment,the checksum can be forged, too. One could simply design the evil viewer to report a checksum generated from the good viewer instead of its own. (In fact, even sending the binary over the internet wouldn’t work; the evil viewer could just send the good viewer instead, like a creepy old man saying “Here’s a picture of a sexy 18-year-old girl. Yes, this is really me!”)

And further: even if all these things actually worked, the analogue hole is still open. Content thieves could still decode textures from the cache, or use OGLE to extract the textures directly from memory, or simply press the “Print Screen” button. Prim parameters, avatar shapes, and more could still be intercepted with a packet sniffer on their way between LL’s server and LL’s “trusted” viewer.

So, I’m sorry to say, all the thought and time you put into this idea, but it seems like just another flawed DRM idea that would not stop actual content theft, and would instead only stifle legitimate use and open source development. I certainly won’t be voting for that JIRA issue.

Combine it with TC features of new OS-es and processors and you have got an all-round secure package.

But – would anyone use it? I know I wouldn’t..