Yes, it can be stopped

Performance isn't the issue, as you can use sufficient encryption which would have very little impact on performance and be very effective for obscuring data.

The issue is that encryption isn't a solution which attacks the problem. Encryption is good for stopping man-in-the-middle attacks. However, if you have control of either end of the link, encryption is useless.

LibSL is its own client. It doesn't utilize man-in-the-middle attacks to accomplish its ends. Thus, all a malicious attacker would have to do is to Reverse Engineer the encryption on their end and then put the same code (and keys) in their new CopyBot and voila! Back to square one.

okay, so if SL wanted to encourage open SL clients, um, then why don't they just make the client open source?

Good question. You'd have to ask them, though; others already have been begging for it for a while now.

I suspect one reason is because of this issue. They weren't ready to deal with it; now they have to. So, perhaps one of the reasons they have been resisting it will now fall away once they do.

Encryption is only part of the equation. The most important one is peer verification/certification. The goal is not to prevent different clients to connect, but rather to prevent rogue code to connect to the grid.

Allow LibSL or any other client to connect at will to a test grid, but only allow certified applications to connect to the production grid.

Again, there is NO WAY to distinguish between "certified code" on the client, and "rogue code" on the client, as far as the Server's point of view is concerned. The "rogue" app can just as easily mimic the same authentication/encryption scheme as the "certified" one.

Again, the CLIENT is NOT TO BE TRUSTED. It is in the hands of the barbarians; they can make it say whatever is necessary to make the server think it is the "Real McCoy".

This is what I keep thinking. I see industries (movie and music mostly) trying technological means to stop illegal/infringing duplication and distribution, and the tech changes don't last. Someone manages to circumvent it quite quickly.

So, we can't usefully:

1. Add encryption
   
2. Verify the client
   
3. Sign packets to verify source
   

What, if anything, can be done that would be significant resistance to CopyBot like technology?

High Orbit, WELL SAID!!!!!

There are too many people around here that will believe anything if you tell them. I laugh because I can happily walk into a store, and get screenshots of every single item in the store, and use those screenshots to upload textures and copy people's items. Granted this doesn't help much with getting scripts, but I still have what is most important to me.

And now we have all these shops that are closed in protest of copybot, which only hurts EVERYONE.

To those who have closed their shops in protest, I'm highly disappointed

I don't know any other way to explain it other than to just state it bluntly:

There is no technology possible to prevent unauthorized copying. It simply is not a problem which has a technological solution at this time.

If you are asking about the future, there are many initiatives proposed by the content and infotech industries which aim to lock down your computer itself so that the permissions on the use of content (music, movies, games, etc) match the desires of the content producers and distributors.

As an analogy, they effectively want to "weld the hood shut" on your car. If you are (or know) someone who likes to do your own maintenance on your car, you will understand what this means. Basically, you lose control, and potentially rights specifically granted to you under the Law which can not otherwise be adridged. Further, once this technology is "in the door", the content producers can pretty much do whatever they want. If they want to start charging you everytime you want to watch a movie, then they can. Of course, you don't HAVE to pay it, but you don't HAVE to watch their movie, either.

Anyway, that's really not the point of the discussion. The point is that they have been trying for a LONG time to get these kinds of protections in for content industries that have gross sales in the many BILLIONS of dollars, meaning they have a lot of clout, and have utterly failed every time so far. Good news for consumers, but it also illustrates the HUGE problem in securing content in SL, which has a much smaller amount of resources to devote to the problem, and a lot smaller set of interests (monetarily) to protect.

Sure, they could do what they said they were going to NOT do and get into an escalating "arms race" with residents bent on infringing content. They could scrap the LibSL project, locking them out, driving them underground, and start raising the bar for your run of the mill casual violator, and giving the hard-core peeps more incentive to break it. Once broken, copy tools would again filter down, quietly, into the rank and file of residents, with plenty of copying going on, and hardly anyone knowing, until someone blabs about it, then we go through this all over again, then again, then again.......

The real issue, which most of the anti-copybot / anti-LibSL peeps ignore (conveniently) is HOW much copying is really going on? The fact of the matter is that it is (and has been; copybot isn't the first tool of its kind to copy assets) actually very small amounts. I would wager that most content creators' works have never been copied, and the ones that have, all but a tiny few have had more than a handful of instances of infringement. There have been wholesale, large-scale infringements in the past, but by far, they are not in the majority.

As such, is the problem REALLY big enough to justify the significant resources required to (futilely) combat it? Is it worth losing a great project which has helped make the game better (LibSL)? Is it really worth it for the false sense of security it will bring?

One positive aspect of the CopyBot sensationalism and publicity is that people KNOW about it, and can deal with it on their own terms. When it is driven underground, people will learn about it MUCH later, after significant damage has already been done.

Well I don't buy that philosophy one bit.

Consider the Drug Enforcement Administration. They are responsible for getting rid of drugs.

Now, they can't stop people from publishing recipes of how to cook methamphetamine, I don't believe.

But they aren't very likely to publish those recipes themselves.

And they also aren't likely to have people on the payroll whose job it is to discover these recipes (or create them where they don't exist), and then publish that so that everyone will be able to duplicate them.

LL has not only allowed their friends in LibSL - AND the Lindens in LibSL - to concoct the recipes, they've allowed them to publish them, and then said - go ahead and cook them up, everybody. We won't stop you. And patted LibSL on the back for creating and publishing them in the first place.

coco

'Hardware' validation of logins perhaps?

The extreme in the corporate world is known as SecurID; I have one for remote logins to work, they're great. However, for something like SL this is overkill.

How about the GameCard concept? They could be bought at any store (heck, use the existing phonecard network if they're all unique enough). What's important is the unique ID on the card, not any amount of money associated with it (they could probably be distributed worldwide for under US$2 each, given the right distributor). They could even be free, if you're willing to buy the numbers off a 3rd party website.

You may create a set number of accounts per card (say 10, which is reasonable for the average end-user or even large family). Banning is by card, and 120 days is given for recource/appeals before banned accounts are deleted (longer if lawsuits emerge).

Just a suggestion, but its one way to fix several problems at once, relatively cheaply.

--Alan

OK, I can see that helping.

But I can't see many folks buying new hardware to play, either.

I'm really thinking that, at least as things stand, there is truly nothing technological that can be done to prevent CopyBot style technology.

Meaning that - as much as I hate the answer - LL's answer is the only one. Bring on the DMCA.

Of course there are ways. As an extreme you can stream the client itself from the server. Heck, you could stream a virtual machine that executes streamed code that is obfuscated in a per session basis.

Sure, you can attach a debugger to the virtual machine and hack the code at runtime but you’ll have to do it each session. Again, it is just a matter of making economically prohibitive. It is simply too easy right now.

Yes, and we can all see how successful THAT organization is.... :-/ Not to mention they also commit some of the worst violations of due process of any branch of the Justice department.

I don't think an even more inflammatory and bad analogy is going to help advance the debate any.

Drugs are not even in the same ballpark, and LL is playing golf. (How's that for a bad analogy? )



I've seen no evidence that there was any direct Linden involvement specifically in the creation of CopyBot. Further, drugs are controlled substances, illegal to possess, let alone sell or use. CopyBot is a tool, and it is NOT illegal to possess OR, in some cases, use.

I'm sorry, but I can't accept this analogy.

OK, let's take this one point at a time...



Aside from the obvious PERFORMANCE issues, streaming ~20MB (I am allowing for the fact that SOME of the client is on your local HD) of data everytime you load SL would be HUGELY cost-prohibitive in terms of bandwidth, plus making everyone wait 5-15 minutes for a download every time they log in won't make for happy campers.



Streaming a virtual machine that executes streamed code, eh? Again; HUGE performance drop; VMs are notoriously SLOW. Not to mention this solution would be VERY complex for even LL to implement and maintain. However, let's say for the sake of argument that they are Programming Gods and can do it, no sweat. Obfuscated on a per-session basis? I HOPE you don't mean that the code dynamically changes (polymorphs) at run-time.. more massive complexity and performance-sapping. If you mean encrypted, it won't work, because, again, the client is an endpoint, and cannot be trusted.



In general, code doesn't change on a SESSION basis. What are you gonna do? Rearrange all the routines in the memory image? That won't slow anybody down significantly, you STILL have to have a way for them to find each other; a table of entry points, something. You can't randomly change opcodes in the stream, or the thing just won't run. As such, the memory image of the code would probably not be variable outside of a macro level, except when there are updates, and those don't happen all that often now; I'd hate to think about the hell they would go through trying to test and push updates on a monthly schedule with a complex system like you are describing.

OK, let's say they do all that, keep it from becoming a patch nightmare, are able to keep performance from going completely in the toilet, and are marginally able to keep ahead of the CopyBot peeps. How much does it cost and how much energy is expended to make it happen? If you follow the "Good-Fast-Cheap -- Pick any two" rule, you are asking for better than good, and faster than fast, so it is NOT going to be anywhere near anything that could even remotely resemble "Cheap".

Are you willing to pay L$1000 per upload and US$100/month for a basic account because of all the extra people they have to hire to make your magical system work?

Again, is the CURE worse than the DISEASE??

I swear, I'm going to post a classified with this exact quote in it. I don't even sell anything in SL, but what a great way to assure that the economy can go on as normal, but keep a large percentage of the bad population out. I'm disappointed by the stores that have completely closed in protest.

The first two posts in this thread are seriously the best I've seen from anyone in any other thread regarding copybot. Well done.

That's your opinion. Most large corporations think otherwise.

Let's say for my .NET client that connects to a proprietary webservice, I told my manager:

1. Encryption is useless, why should I even program it??? Anyone can break it because they have the client. Nooooo.
2. Authentication with our server, who cares? People are going to mimic our applications no matter what we do! Why???
3. Packets can't be verified, anyone can sniff them, everything is out in the open! Damn our insecure world!

Do you know what would happen to me??? I WOULD BE FIRED!!!

You do what you can. You try to stay ahead of the people who crack software. Sure, if someone is determined you can't stop anything, but that doesn't mean these measures are useless. On the other hand, if you give up, and always have a defeatist attitude, you will always lose.

Uhh, let's stick to the CONTEXT here, k? The CONTEXT is the applications of specific technologies (such as encryption) to the problem.



If you REALLY know what you are talking about, you know that having an encrypted link with an UNSECURED client means that the encryption is useless to stop the client from being compromised. NO ONE said, simply, "encryption is useless". What good is SSL going to do you when someone has a keylogger or spybot program running on their system? Hmm?



Same principle. If authentication from the CLIENT side can't be trusted, then your server BETTER NOT be accepting information and requests from it.



Packets by themselves cannot be verified. That's why you have higher level protocols to add those layers.



Aye, if you presented every issue to me with that level of hyperbole and lack of context, I'd fire you, too.



I think they are committed to "doing what they can". They just aren't going to do what YOU think they should. Instead of playing the ever-increasing "stay ahead of the crackers" game, they are going the route of identification and accountability, or so they claim. Maybe it will work better, maybe it will be worse. How about giving them the benefit of a doubt and letting them try? Or is that just too much to ask anyone nowadays?

@Talarus Luan

You're right, LL has publicly stated they don't want to get into an "arms race" with people who crack software.

I think it's a bad decision, and I have the right to voice my concerns. Other companies take a different approach, even when the user has full access to the client. I'm just letting other people who don't develop software know that not everyone in the industry takes a defeatist attitude when it comes to security.

I've said what I wanted to say in this thread, that's all.

signed

If Second Life can't enforce their DRM, and won't even try to stay ahead of the crackers, then they shouldn't advertise SL as a perfect place to start a business.

I know LL is averse to placing any cash barrier to entry to SL and as Jillian pointed out alot of people will be put off entry if they have to go out and buy a card-reader in order to log into SL. So I bring a suggestion from the world of music: the humble USB dongle. It requires no extra computer hardware.

I've been a user of Cubase for a long time and have seen hacking/cracking of music production software become so rampant that some companies of software that I used and relied on going bankrupt as a result of it. The copy-protection arms race became a neccessary fight for survival. Steinberg (the manufacturers of Cubase) introduced a hardware USB dongle made by Syncrosoft. When it was first introduced, it was bypassed by crackers within a short time. However it has become sufficiently secure so that cracking of the recent versions has all but dried up.

The obvious downsides of such a proposal are: first the costs, not many people are going to be keen to shell out US$25 for a dongle. And secondly the lead time necessary for LL to deliver the dongle to its customers. Even with immediate turnaround at the LL end, you'd still have to contend with the vagaries of the postal service which could mean a wait of anything up to 2 weeks or more for people living outside the US.

As for the card-reader, that one's more likely to fly. I have seen computer keyboards coming on the market with integrated card-readers. If this becomes an industry trend with card-readers being another default interface alongside usb, parallel, serial and firewire ports, then it's quite likely to become the path to take. For the meanwhile some implementation of the https protocol?

No kidding. Really? Not seeing where you get the defeates attitude bull, I'm exploring avenues.

So lets return to encryption for a sec here...

LL wants to avoid an "arms race" - For those who know thier encryption, would it be possible to avoid it being an arms race if something off-the-shelf were installed, and the keys got themselves changed now and again? Or is knowing the sort of encryption enough to get keys cracked too fast for it to be useful?
Which is to say, can enough resistance to this kind of thing be had without causing the "arms race" LL says they want to avoid?

I think some are slightly mistaking my suggestion...

I'm talking more of a 'software key' that can be bought, like a license (think the license keys for things like the paid version of ZoneAlarm).

Until Uru registration used to have this; You'd buy the key from a 3rd party registrar called Kagi, which was emailed to you. The key is entered on the master authentication page for new accounts. Done!

What's different about the suggestion is that we have lots of other sources of unique identifiers out there other than a credit card, in particular the *still* lucrative (and international!) phonecard market.

This should be (relatively) trivial to leverage into the existing SL system once they decide on a method and source.

BTW, I like the USB dongle thing; There's an HDD hardware encryption method that requires a USB-based key inserted during boot; It holds the 128+ bit key. Just wish it came in SATA.

--Alan

You mean "unauthenticated" accounts. There are a lot of unpaid accounts that are authenticated to a real person.

There shouldn't *be* any unauthenticated accounts. And I won't block unauthenticated accounts on my land except as a real last resort - by that I mean "if this doesn't work I'm leaving SL" - on the principle that there shouldn't be "second class citizens" in SL.
Not even that long. The client has to be able to encrypt and decrypt the stream, so code injection in the client will bypass any encryption. And the only way to counter THAT is to make the client effectively spyware - and (as has been demonstrated with all the 'fish mining' bots in MMORPGs) that doesn't even work.

SSL and SSH work because it's end-to-end encryption that both ends have an interest in maintaining. If one end-point is compromised, it's useless, as has been demonstrated again and again with trojanned SSH and Kerberos clients in shared computer labs.

What LL is faced with is a situation where one end-point - the user's computer - is trivially compromised.

It's called a "sting" operation. It's like the post office running ads for kiddy porn, which also happens. And it's one of the things I worried about when this broke.

I'm not defending LL's poor communication here, and I'm not defending the griefers who wrote this bot. But I'll take a naive Linden Labs over a malicious one any day.