This needs to be done NOW. Everything else should be put on hold until there is some kind of security for us.

ETA ~ the above comment is in response to destiny niles.

TOmake it clear the minute LL desided to send the info over the internet to something in a computer that an end user have control over they lost the possibility to control this. Thats how any computer security works. Sorry thats life, nothing to be done about. Can we focus on making SL better for all now?

The sim cloning tool has existed for a long time in a secondlife client, it just wasn't advertised on a blog in the past, this is nothing new, nothing has changed.

A plugin authentication model isn't feasible at this point, it would mean the hard work of every open source developer, every third party client up until now would have been in vain.

As for your worries about user information being stolen...chances are if you download one of these "Hack clients" that allow you to steal content, you will have your information stolen, and I'd say you deserve it.

As for the true open source clients, if you don't trust them, you're free to download the source code and compile your own copy, nobody is forcing you to use a binary provided by someone else.

In closing: Please do not re-open this issue, the jira is not a place for it. The jira deals with BUGS, not OPINIONS ON OPENSOURCE SOFTWARE, this is a tool for developers, not a forum to voice your concerns over content theft, try the secondlife forums.

Not even remotely true. It would simply be a matter of linden lab writing an authentication module and releasing that as a dll to those who are willing to enter a legally binding agreement that they will not include malicious code. The end developer would then simply recompile their code to include the dll that, among other things, identifies them as a distributor and allows their client to connect to the grid.

Furthermore, that this is an old issue does not make it a non-issue. So please quit trying to obfuscate the problem with faux claims that this model is not feasable. Thanks!

If you think it is, then you obviously do not understand the open source community surrounding and supporting secondlife.

Closed again, this isn't misfiled, it does not belong ANYWHERE on the JIRA.

The JIRA is a developer tool to deal with bugs, this is not a bug, it isn't even related to the software itself.

Please repost this on the SecondLife forum, and check the JIRA guidelines before posting another issue here.

"A closed source DLL that would need to be included with the software is not feasible given the licensing terms.

If you think it is, then you obviously do not understand the open source community surrounding and supporting secondlife."

I have no idea who you are, nor do I care, but the above comment is inane. Or did you forget about the voice dlls that must be released for 3rd party viewers to use voice?

Oh and. Stop closing my issue. If linden lab wishes to ignore it, they will anyway. Leaving it open allows people to vote and let LL know that this BUG is a huge concern.

May I also remind you of the posting guidelines of Pjira - https://wiki.secondlife.com/wiki/PJIRA#Be_courteous

Be courteous

Note: The Second Life Community Standards apply to all areas of Second Life, including the Second Life Public Issue Tracker. Any Resident who disregards these guidelines may be banned from future use of the issue tracker. Pjira is neither a Forum nor a blog. It is Also not the place for Policy discussion. It is a system used primarily by Linden Lab's Engineers and Developers.

Examples of specific behavior or actions which may result in removal from the Issue Tracker:

• Using the Issue Tracker to promote a business, cause, blog, website or anything not directly related to the issue at hand.
• Personal Attacks
• Flaming, Trolling - Flaming (posting a comment that is intended to incite anger or directly attack a person or persons) and Trolling (a post with an intentionally contrary opinion written with the intent of inciting or getting argumentative opinions) are not appropriate for the Issue Tracker. Please keep to the facts of the issue at hand. Posts that disregard this may be deleted.
• Private Discussions - Blogging your personal opinions or off-topic rants. The issue tracker is about finding solutions to bugs and problems. We love productive feedback. Please stick to the technical details of the matter at hand.
• Editing Wars - Repeated changes to a resolution, priority or classification of an issue within the issue tracker.

Right. No more than locking your car or home irl will prevent life theft if someone wants your stuff.

In other words, if we are to go by your model, we may as well leave our cars unlocked with the keys in the ignition and our house doors open. Bc after all, someone is going to steal them anyway.

If linden lab considers copybotting a violation of their TOS (which they do), then it most certainly would behoove them to fix this particular BUG which is more like a gaping hole in their (non)security model.

Thanks Alexa

Neither the copybots, or this code have anything to do with the open source viewer. Closing the viewer have NO effect what so ever on the possibility or operation of these tools.

Their security model work fine, what you aren't allowed to see you can't see, what you are allowed to see , you can (and de facto copy because that's at the base of any computers since how far i can remember)

trying to impose a drm system is not only unfeasible at this state (the client sourcecode is opensource) but is also like trying to plug a water source with a rubber stopper.

It's always been possible to pretty much copy anything off the web and put it on your own website. Has this made the web nonviable as a business platform? Indeed not, for what self respecting business does not have a web presence these days.

The cold hard truth of the fact is, the tools that drive the web, and even the internet itself are, by and large, open source. The fact that said software is open source is what allowed the internet and the web that runs on top of it become so ubiquitous, because it lets everyone take a stab at it, instead of one single entity.

If you close everything up, Second Life will stagnate and die, there will be no innovation, nothing new, everyone will move on to something better, and you'll have nobody to sell your stuff to. So you lose.

If you let it open up and flourish, a few people that wouldn't have bought your stuff anyway will steal it, and many more people who will pay money for it will join up and buy it. So you win.

The BUG fix I am asking for is a simple plugin authentication model that will hold open source developers accountable for injecting malicious code into their programs. While most open source developers are responsible, there are those who will irresponsibly use open source code. Responsible developers should not have a problem including an authentication module. After all, their goal is to provide a wide variety of features to the SL community that are not otherwise included in LL's SL viewer.

It's a pointless waste of jira space honestly, but at least it'snot encumbering the REAL problems, like peoples who experience crashes and the like.

Not with a bang but a whimper.

Before dealing with them, it is perhaps worth making a small point. Most systems die because of some combination of irrelevance, bloat and obsolescence, not because somebody killed them. The best way we have identified to date to avoid the above is to have a motivated group of open source enthusiasts working on the system, preferably with commercial contributions to structure and the code base. Any move in the opposite direction, particularly when attempting to cure a perceived social problem with a technical approach is likely to be harmful. Particularly when both commercial and open source alternatives already exist and are attracting legions of very competent participants. Awareness of the above should enliven any discussions about the future of SL.

That said, the issues I think are being confused in this JIRA are viewer validation and authentication and then more general issues of IP, DRM and fair use (including fair use of your own creations).

Function Then form.

As far as viewer validation and authentication are concerned, it doesn't matter what PAM is used unless you have decided what it does. Given that viewers work across many server providers, only one of which is managed by LL, the question is moot until providers agree on a protocol that can operate across providers. Even more critical, and probably more challenging to attain agreement, will be the decision on what to validate, how to validate it and how validation will be assured. In the security community, it is widely agreed that ensuring that a piece of software functions to specifications and does not include hijacking code is a task best undertaken by an open source community evaluating relatively stable, widely used, open source code in an environement where discussion is open and encouraged. Far away in concept from the proposals made in this JIRA.

Screwdrivers are more evil than Copybots

As far as IP is concerned, these are social issues and the solutions need to be social too. The appeal of SL is that "ordinary" users can do a lot. The greater the restrictions placed on such users the less appealing it will be. Just because a software tool e.g. copybot, can be used to rip-off the work of others does not mean that the tool is evil and should be banned any more than the fact that you could break into a house with a screwdriver, or worse, you could stab and kill somebody with a screwdriver (which can't be achieved with a copybot) means that screwdrivers are evil and should be banned, even if there not being a 4th Amendment right to bear screwdrivers, not even the NRA would be likely to protest. Screwdrivers - and copybots - serve useful purposes as well as being potentially able to be used for evil. When people expropriate protected intellectual property the proper response is to reassert the protection with the correct tool, a take-down notice. Fortunately, to date, LL has recognized this.

Caveat Avatar

In conclusion, perhaps the most effective protection for SL, for users worried about its future viability and the protection of their virtual assets, is for them not to beg LL to slam the door on its best hope for long-term relevance, but for those users to operate viewers from sources they trust!. This might mean that people imagining that they have much to lose should use only the unreliable and clumsy viewers from LL. For myself, I cherish the freedom to enjoy the stability and flexibility of having multiple client platforms (even those from Linden Labs, after all, I do need benchmarks with which to compare the efforts of others) to visit Second Life and potentially other virtual worlds; and actively dislike hearing people suggest that their interests in bolting the doors of empty stables ought to outweigh my interests when the answers to their problems lie so clearly in their own hands.

PS Given that this JIRA already contains everything and the kitchen sink, maybe we could use it to propose the addition of negative voting to the JIRA to be able to say, "I think this suggestion really sucks" without having to write an essay.

Hmmm, that's interesting. But anyway, I happen to not only use a 3rd party viewer but have also developed my cs bots using openlibmv. In other words, I am not even remotely against having open source viewer code. What I am against however is the lack of checks and balances that allow people to inject malicious code in their viewers. And, as I have repeatedly stated, this bug could be easily addressed by simply implementing a plugin authentication model. Not that hard to do. Really.

You can't, it's not your computer down there, there is only so much the LL servers can "see" from the client.

This Jira boils down to something like: "I have based my business on a delusion about how objects are distributed in SL, and I am losing money because of my mistake. Please fix."

I don't think that's going to achieve anything.

We understand that you work hard on your creations in Second Life, and rely on our system to ensure you have a means of being paid for your creations. We've worked hard to make a robust system for keeping honest people honest, while at the same time ensuring that we have a system open and vibrant enough that people will still keep using it years from now. Our system may not prevent someone determined to infringe your copyright from doing so, but we feel it does a pretty good job of making your intentions as a copyright holder clear.

We rely on copyright law to secure our living at Linden Lab, so we understand your plight. As imperfect and inconvenient as it is to rely on the court system in the more egregious cases of copyright infringement, it's really the best mechanism that we have to ensure that we can maintain the right balance between the interests of content creators and the interests of everyone using Second Life (including content creators who are also content consumers).

I'd like to refer everyone to a couple of pages for more on this topic:

Laurap Linden's post from last year:
https://blogs.secondlife.com/community/features/blog/2008/04/11/protecting-your-copyrighted-content

Our open source FAQ ("Content Creators" section):
http://secondlifegrid.net/technology-programs/virtual-world-open-source/faq#contentcreators

Please take the time to read both of the items above.

Thanks
Rob

Whining about the protocol is neither of those.

I think it is possible to develop a protocol for legal distribution of items to other grids

SVC-4181 was my suggestion, via a ratings system, and probably would entail extending the protocol. What we really need is a way to sell items to Opensim and LL based grids that are not part of the main grid, while preserving the permissions system.

I believe deeply that LL needs to concentrate more on what is far more scalable, and content sales is far more scalable than land sales. There's a lot of business they could be skimming the transactions on, that's not happening and people are making things like this copybot instead.

So... we need a better way, is all.

Create a blank grid with a few empty sims for open source developers to test in. State clearly nothing in that grid is copyrighted so don't upload copyrighted content. Must have a grid to connect to for testing.

Establish a policy that says all open source contributions are brought in via the Snowglobe project.

Install non open source code in Snowglobe deployment compiles that identify the compile as LL certified.

Install code in the regions and login system to deny access to any compile not certified by LL.

Problem sorted. There is still open source contributions with all it's bug fixing advantages. But it all has to be certified before being allowed to connect to the grid.

Note this would also end the use of bot software for traffic falsification unless it is a special bot system compile certified by LL that does the thing labeling the bots and does not include them in traffic or on any mapping system.,

Sadly it will mean we all have to leave SL and no one will make good stuff in SL any more. I have told you many times there is no technical solutions on this. Now finally even the big record companies understood that can't make a technical DRM solution, they have to look at other working models of getting payed for there work. I think that's is a bad timing for LL to head down that road. DRM solutions, rights management as it is, only make life hard for legitimate users, it makes no trouble for the illegal users.

What needed is a good safe process of finding people that make money from faking objects. A good way to keep them form selling stuff, hopefully one that gives that money back to the creator and not hurts the fooled customers. If it hurts customers they will get more hesitant to spend money, you know that even if you try to make it right LL might take the money and items, you get more reluctant to spend the money. You need to be sure you can spend money safe to be a customer. It also have to make sure the creator, original creator gete the money it needs, Some issues with how SL works, escially with groups, make all creators or almost all need an alt to sell.

Who cares if the rippers go around the open source felon grids using software to commit felonies by bypassing DRM in grids created by and for felons? They can have a ball stealing from one another.

Why would any corporation or educational institution or non profit want to deal with Linden Lab if Linden Lab supports (by proxy of taking no serious position and no action on) felony theft operations? Seems to me LL might want to deal with this issue once and for all. Either eliminate the SL economy (and close SL down) or get serious and supply a technical solution that controls access to trusted applications.

I think it will become necessary to have the US Government become involved in the running and management of Second Life.

1. Many opensource developers are more or less allergic to adding such 'non-open source' DRM components to their viewers, so they would probably not work on SL/Snowglobe anymore for religious reasons, do you really want to loose all those contributions?

2. Snowglobe is just one of the viewers around. Any of the other forks of the viewer would be dead at once. And i really doubt SL would adopt the features of some widely used 3rd party viewers into the snowglobe codebase.

3. LL does not have the manpower to do enough security auditing to make it anywhere near to safe. (Neither did Microsoft when building the XBox nor Apple with the IPhone, both been jailbreaked).

4. If you have a 'certified viewer' you just need to hop through a few more holes to get your evil code hooked up. There are a ton of options from proxying the UDP/TCP streams and injecting your stuff to writing something like writing a debugger and hooking up to the process. The only way to prevent that even remotely is the 'big brother' style approach done with World of Warcraft and similar games where you the client constantly scans all of your system for suspicious activity (and even that won't help you if running on Linux with self build kernel).

So, waste of time, brains and money. If it had a remote chance of success maybe, but it has none.

LL Can't put any code into the viewer that would prevent an third party viewer to connect to SL. Even if they liked it's impossible. This is because that can control what runs on the other end of what ever is out there on the net.

They can try, they can makes something that makes it "not" allowed, it will not stop the illegal uses it will only hinder the good legal uses as better viewers. Why should someone using copybot today, care about if it's illegal?

It been proved in libomv, former libsl, it was written and worked when the viewer was closed source.

Instead of complaining about the way digital technology works and trying to sweep back the tide, the astute business person will find a business plan that takes advantage of the situation. The rest are unlikely to find success. Don't be one of the rest.

The only way to get the results you want would be to only allow approved and licensed creators to upload or build. That would be hugely disruptive, but even so it would be less disruptive than this proposal.

I have read many of the posts, and all the links provided. Clearly, this is not a simple issue that can be resolved with a simple mouse-cick. I do think, however, there is at least an element of "sweeping it under the rug."

I've worked in Corporate America long enough to recognize when a company is defaulting to "passing the buck", and that's what it looks to me is happening when LL is asking us to default to the court systems of our various countries when dealing with copyright issues.

It would make content creators – aka those of us who spend time making SL what it is, spend many dollars to keep the economy going – feel MUCH beetter if we saw that LL was taking a much more ACTIVE stance against copybotters. By active, I don't necessarily mean technology-wise, I do mean policy-wise. I did read that LL will take action if a creator documents who, what, when, where and why, through the proper channels. Clearly, however, this is a process that is not always realistic. A creator does not always know WHO is copybotting their creations, where or when. From the first-hand accounts I've heard, the process that LL has in place for creators to submit complaints is FAR from perfect.

Here's my example: I checked out a mall I was invited to open up a vendor spot in. While looking around, I saw there was a vendor there who sold hair that had been CLEARLY copied from several very well-known hair designers, two of whom I instantly recognized. I contacted the two designers by notecard, took pics of what I saw. The response I got from one of the designers was so shocking to me ... simply put, she thanked me for my interest and said that she would not pursue the issue, as her previous attempts to report copybotters all, ALL, had failed and had not been responded to by LL. The other designer never responded. I've heard other anecdotal evidence that supports what the one hair designer also responded. I think most creators can think of a few people who have all run into this issue and have similar stories.

If a technological response/action is not possible or is too unrealistic to come by, if it will hinder our SL experience too much to implement, ok, I can understand. THEN, what must happen to make up for this is for LL to have an ACTIVE, EFFECTIVE, and SATISFACTORY corporate/legal response to copyright infringement. IT IS NOT ENOUGH to say "go to your own government," or to say "here's a system we have," but leave that system so unsatisfactory that most creators don't feel the desire to use it.

Put your money where your mouth is. Why? Because I put my money in to your product with the belief that you will give me what you say you will, and I have the right to expect to GET what you say you will give me.

Again, my perspective is not based strongly in technology simply because I don't know the coding that goes into my being able to link prims together. Hopefully, however, it's legitimate enough to be seriously considered here.

Thanks.

Although the copybot problem has been a long standing issue, rezzable's recent proposal to release a SIM export tool that ignores second life's DRM raises serious concerns among and wthin the merchant community with regard to protecting their IP. Linden Lab implemented a DRM that allows content providers to define how their content is used. Can the purchaser make copies? Can they resell it? Can they modify it? While the permission system provides a means to not only make these choices, it is also designed to retain the original creator's signature. Both copybots and tools such as rezzable's new SIM export tool however circumvent this system, allowing people to not only export content but import the exported content as their own creation. Therein lies the concern. Why? Because the content creation signature has been changed to reflect the new person as the creator. Copying of the extent proposed by "companies" such as rezzable, make it time and cost prohibitive for Linden Lab to follow up and address IP issues.

Copybotting is but a portion of this longstanding problem. Enter malicious code injection. Let's consider a case of this that occurred in the not so distant past. The recent misuse of greenlife viewer source code prompted them to change the way they release their code, so that they now include a digital signature along with a statement that the only authorized greenlife viewers are those downloaded directly from their site. The malicious code collected user login information. The result, while addressed, created unnecessary issues for the original developer, and some people are still perpetuating the rumor that the LordGregGreg's greenlife viewer has embedded malicious code. In a sense, he and his developers were lucky. Someone could have easily incurred far more damage than stealing usernames and passwords. Does the word "Trojan" ring a bell?

There is, of course, the fact that Second Life is, among other things, an ecommerce platform. Linden Lab has long capitalized on the fact that it is possible to make real world money. Their purchase of XStreetSL indicates they continue to hold this belief. With this in mind, they should be more than concerned what connects to their servers. Furthermore, since 3rd party developers take pride in their work, it only goes to follow that implementing a means to validate their viewers through some form of Linden Lab validation mechanism would increase customer utilization while also providing latitude for creating content backup systems that follow Linden Lab DRM rules. In fact, 3rd party viewer (and bot) developers should be demanding that Linden Lab implement a means for authenticating their software, as such would, in turn, increase customer confidence.

That being said, some of you proffer that implementing a viewer validation system is an surmountable task. Wrong. You add upon this already faulty premise that releasing an authentication dll would render the SL viewer closed. Portions of LL's viewer includes dll's. Your point is therefore moot. You further suggest that crime hardening the SL viewer will do not a thing to deter IP theft. Wrong again. Crime hardening is a well-known and utilized practice within the software industry. While IP theft most certainly occurs, people who choose to, say, download ripped software do so at their own peril (i.e., keygens and cracked software carry with them the inherent risk of containing trojans). Otherwise put, anyone who truly understands software architecture, design, and implementation would quickly recognize the problem that unchecked open source slated to connect to ecommerce servers present.

It's impossible to do any of this 100% reliably, but that's not a problem in itself (less than 100% reliability is often okay in the real world). But I'm rather dubious as to whether it can be done, in this case, with any significant reliability at all.

(As other posters have pointed out, even systems like WoW, which have no provision for third-party viewers of any kind, are forced into complex and draconian schemes to prevent unauthorized client programs from connecting, and they are only partially effective.)

If LL wrote a "simple" DLL and gave that DLL to authorized viewer developers to distribute with their applications, someone would quickly analyze that DLL and figure out what it did, and produce a functional equivalent. Or, for that matter, anyone wanting to use their own unauthorized viewer would just get a copy of the DLL from an authorized distribution, write their own code to call it in the same way an authorized viewer calls it, and they'd be in. So a simple DLL would be completely ineffective.

Slightly more effective would be creating a statically-linked library (one per platform that SL should be accessible from), and having authorized developers link it into their distributed binaries. But again someone wanting to make an unauthorized viewer could simply extract the library from an authorized executable (not hard to do), call it from their code in the same way the authorized viewer calls it, and statically link the library into their own binary, and again they're in. So still not every effective.

If LL had lots of resources to devote to this, they could offer a program whereby anyone wanting to develop a viewer would essentially send LL their source code, LL would do some proprietary alterations to it (adding a protocol-obfuscation library linked to the viewer code in a hard-to-tease-apart way, say), and return a binary that could then be used to connected to SL. It seems very unlikely that LL has the resources to do that, and even if they did someone halfway clever would probably quickly figure out whatever protocol obfuscation was being added in the alteration step and publish that information (as documentation, or source code, or a DLL or whatever), and it would essentially all be for naught again.

There are all sorts of defensible positions on the political and business questions about open source vs. closed source, about how much effort to put into DRM given that it can't be 100% effective, about how the Lab's DMCA and other IP-related policies and procedures should be set up, and so on. I'm not taking a position on any of that here.

But for the purposes of this JIRA I think the most essential point is that, unless the OP can point to a convincing alternative that everyone else has overlooked, no plugin authentication system like the one here proposed would actually work, even imperfectly. So regardless of what anyone thinks about the political and business questions, this particular technical suggestion seems probably infeasible. This may be annoying or unfortunate; but it does seem to be true.

(Unless, again, someone can provide convincing evidence to the contrary.)

There are 2 parts to the story, the content creators and those that develop the software around it. None of them can exist without the other and for that matter people should start finding a common denominator on which level they want to work together. Maybe it is time to make some sacrifices because this is no playground this is real business and it can't be happening that some company with major debts is gonna hurt hard working people over their desperate attempt to cut losses.

Linden Labs is making the rules, believing in the court system is not good enough, we invest real money in Second Life, protect our investments or see us leave! I'd love to see an approval system that we can be sure it is worth to invest more money into your projects. Without that happening and this issue becoming public i see no future whatsoever for this kind of system. Why would people invest money into Second life when all their work can be ripped, reproduced and sold within 2 minutes. When that happens the open source code becomes irrelevant because nobody will use it no more.

From memory the web is still flourishing as ever.

It's up to us, the content creators to adapt, the technology isn't going to wait for us because we refuse to evolve. the DVD signed the death of the VCR and the printing press made the copy monks disappear, if you do not want to disappear you have to adapt, the world isn't static thing, it evolve and change. If you're not walking ahead from it you're going to be left behind.

And it's someone who live from content creation in SL who is speaking.

I agree that if we had some plausible way of enabling an SL viewer to prove to the server that it was really a particular program, that would let us do various potentially useful things (including, as you suggest, excluding certain viewers from traffic counts). But I have pretty extensive experience in this area, and I'm not aware of any technology that would actually give us that for the SL use-case. (I don't know enough about the XNA use-case to say anything there.)

(Executable fingerprinting by itself is trivial to forge, for instance: if the server asks the evil viewer some question about itself ("give me the MDC fingerprint of your executable from bytes NNNN to KKKK", say), the evil viewer can just look at its own captive copy of a good viewer executable, and answer the question based on that.)

Which is to say, I'm not at all arguing that it would be a bad idea if we could do it. I'm just saying that I don't think we can do it; it is not, as far as I know, technically possible to do in a way that meets the requirements of the SL case.

I had made myself a very cool independant chatlog (so i could put the chatlog on my second display in it's own independant window)

So yeah sure fingerprinting is such a "long way" to harden the SL platform by providing... whatever.
Of course then we can demand from client sto connect to sl through a crypted tunnel (a "man in the middle" attack can still snatch the keys unless it's one key per "official nice developper" ro some bull like this.)

However each step in this direction is a step in the way of (making it harder to develop-valuable-tools-where-so-far-everything-is-quite-simple-and-doesn't-work-that-bad"
If Linden labs still want SL to become a standard of the internet, well you do not create a standard by making it clunky, and last time i checked, HTML still has no DRMs in it.

But more seriously, any attempt at "locking down" what can and cannot access the sl grid is going to be seen by the opensource community as a big middlefinger and risk to trigger unforeseen consequences.
Like focusing their contribution on projects that treat the help they get from the opensource community with more respect for example.
(edit for clarity because apparently some peoples will try to use anything you write to diabolize you.)

Soo how do we close a jira issue?

You are making threats on behalf of the open source community. How professional.

Side A: LL needs to do something to prevent unauthorized 3rd party clients from connecting to the grid and doing evil things, like copybotting. It's possible to this while still allowing good 3rd party clients to connect by using an authentication scheme, like Microsoft's XNA on the Xbox.

Side B: Not only is it technically infeasible to do that, but even if you did, it wouldn't work anyway.

I'm obviously on side B here, which is well represented, but I want to point out a few things...

Angela Talamasca:

Let's consider a case of this that occurred in the not so distant past. The recent misuse of greenlife viewer source code prompted them to change the way they release their code, so that they now include a digital signature along with a statement that the only authorized greenlife viewers are those downloaded directly from their site. The malicious code collected user login information. The result, while addressed, created unnecessary issues for the original developer, and some people are still perpetuating the rumor that the LordGregGreg's greenlife viewer has embedded malicious code. In a sense, he and his developers were lucky. Someone could have easily incurred far more damage than stealing usernames and passwords. Does the word "Trojan" ring a bell?

Using hashes and code signatures has been a common practice to verify downloads for over a decade. While important and useful for an end user to verify the integrity of a downloaded app, this approach is less than useless for LL to verify a connecting client. Setting up some sort of system where LL would verify and issue hashes for 3rd party clients might be interesting, but would only help honest people avoid tools for thievery. I thought the issue here was allowing thieves to operate unfettered....

That being said, some of you proffer that implementing a viewer validation system is an surmountable task. Wrong. You add upon this already faulty premise that releasing an authentication dll would render the SL viewer closed. Portions of LL's viewer includes dll's. Your point is therefore moot. You further suggest that crime hardening the SL viewer will do not a thing to deter IP theft. Wrong again. Crime hardening is a well-known and utilized practice within the software industry. While IP theft most certainly occurs, people who choose to, say, download ripped software do so at their own peril (i.e., keygens and cracked software carry with them the inherent risk of containing trojans). Otherwise put, anyone who truly understands software architecture, design, and implementation would quickly recognize the problem that unchecked open source slated to connect to ecommerce servers present.

There's a couple of things wrong here. Let's go point-by-point.

You add upon this already faulty premise that releasing an authentication dll would render the SL viewer closed. Portions of LL's viewer includes dll's. Your point is therefore moot.

Um. no it isn't? I'm assuming here that you're referring to the curse that is voice? Open source clients have in the past and do still now run on platforms voice does not support. You're advocating a change to the system that would place the onus on LL to write an authentication infrastructure for every platform SL can run on, rather than letting the community take the viewer where it's wanted.

Crime hardening is a well-known and utilized practice within the software industry.

Um... no?

While IP theft most certainly occurs, people who choose to, say, download ripped software do so at their own peril (i.e., keygens and cracked software carry with them the inherent risk of containing trojans).

Off topic, but I agree...

Otherwise put, anyone who truly understands software architecture, design, and implementation would quickly recognize the problem that unchecked open source slated to connect to ecommerce servers present.

Dangerous open source software like Apache, Firefox, Safari, BIND, OpenSSL, and cURL? I would humbly submit that anyone who understands "software architecture, design, and implementation" would also understand that the only reason authentication mechanisms like XNA use only work because the provider has complete control of the platform from the hardware up. LL is never going to have the kind of control over platforms SL runs on.

More importantly, mechanisms like the ones in XNA don't work. Don't believe me? Try googling "wii homebrew", "ps3 homebrew", or "xbox 360 homebrew". I'll wait.

Since I evidently can't resist flogging a dead horse, how about a few more examples?

• Talked to the RIAA lately about how well DRM systems work? How about that iTunes?
  • Bonus points: The palm Pre at launch did pretend to be an iPOD to get around iTunes DRM. Apple released an update to disable it, but do you really think Palm'll leave it there?
• How about the MPAA and DVDCA's attempt to protect DVD's with the CSS encryption system?
• How about those new Blu-ray discs with DRM that can be updated after release? They use licensed and certified players just like some here want LL to license and certify clients? How's that working out?

I very much doubt that because this is becoming Internet 3.0, this is way to prestigious for a real coder as to threaten consequences. This is the next big thing on the internet and being a part of it's development is gonna open doors. Whoever want's to work against it will probably have to fear a stronger reaction from the open source community as SL has to expect from the coders.
Someone who is close to to write a break through code and being a consistent contributor to Internet 3.0 will not back off that easily. Besides that I couldn't care less if I hurt some coders feelings because with tools like Sim Bot there won't be a crowd left they can code for. It is an open source code that is threatening ALL contents creators businesses and for that matter we can stubbornly act open minded to threatening tools or we find ways to minimize their use.

Well, you thought wrong. The issue here is deterring thievery and malicious code injection. If you read up, you will see that bit in my very first post. And yes, we are definitely talking about helping to keep honest people honest. Furthermore, providing software that allows people to indiscriminately copy content is most certainly inviting thievery from not only "thieves" and "so-called honest people" alike but also those who may be too lazy or not have the technical wherewithal to crack the system themselves. If you do not understand this salient point then I am at a loss to explain it to you.

I wrote in part: "Crime hardening is a well-known and utilized practice within the software industry."

@Pliny wrote: "Um... no?"

Um... yes? My apologies that you are unfamiliar with the term. "Crime hardening" is a term that originated in the criminal justice system that has since become commonly used in the software security sector. Btw, and as an fyi, google is your friend.

Hardening the TCP/IP stack to SYN attacks
http://www.securityfocus.com/infocus/1729

Hardening HTAccess, Part One
http://www.securityfocus.com/infocus/1368

Hardened-PHP Project
http://www.hardened-php.net/

Hardening Linux (Paperback)
http://www.amazon.com/Hardening-Linux-James-Turnbull/dp/1590594444

Securing and Hardening Red Hat Linux Production Systems
http://www.puschitz.com/SecuringLinux.shtml

You were saying?

I wrote: "While IP theft most certainly occurs, people who choose to, say, download ripped software do so at their own peril (i.e., keygens and cracked software carry with them the inherent risk of containing trojans)."

@Pliny wrote: Off topic, but I agree...

While I recognize and respect that you do not have even a rudimentary grasp of crime hardening... you know... since, as you note above, you apparently never heard of it? I urge you to acquaint yourself with what it entails and why designers make the security choices they make. I could try to explain it to you but I am simply not in the mood to write a novella. Though, here is a teeny tiny hint. The comment you so readily dismissed plays a relevant role in that decision making process.

As for your RIAA & MPAA snidery? Please. I have long been involved in that discussion within the security sector. So, yeah, I think I might know a thing or two or ten about that bit too. Bc, unlike you, apparently, we actually do consider the wide range of pros and cons that go beyond coding when architecting and designing software solutions.

That being said, the way you and others continue to repeat the mantras, "there is no fool proof way to prevent theft so why bother doing anything at all?" Iow, are you bots? Seriously, though. There is a latin term for this type of fallacious argument. Its called argument absurdem (you can look that up too). The less extreme, though, no less absurd response is, "there might be a way but it's too hard so why bother doing anything at all?" And you refer to my raising this issue as a whine? laughs

Furthermore, while you are welcome to hold the belief that, "releasing a dll turns the client into a closed source" it no more makes it so than does the belief the moon is made of cheese, make the moon edible.

And finally, since you and others insist on turning this into an open source issue....

While I have long supported open source, I am also a proponent of responsible software architecture, design, and implementation practices (of which crime hardening, btw, indeed plays a role). And the only reason I can see that Linden Lab has chosen to continue engaging in the appalling software practices that they are engaging in, and are so intent on supporting people who apparently would not know how to code their way out of a paper sack (ala the "it's too hard!" whine), is for free labor. Or otherwise put, greed.

Well, you get what you pay for, I suppose. If you do not understand what I am speaking of here, do feel free to explain why the client code is full of redundant code and circular function calls. And while you are at it, you are also welcome to champion their non-code review process.

"That being said, the way you and others continue to repeat the mantras, "there is no fool proof way to prevent theft so why bother doing anything at all?" Iow, are you bots?"

That is in fact not a very good argument. It's a mathematical fact that there's no foolproof way to detect viruses, for instance, but we get quite a bit of benefit from imperfect but good-enough measures.

The important technical question here is whether it's possible to do even a good-enough job of detecting, at the server, what client a user is using to attempt to access SL. My impression so far is that it is not possible to do even a good-enough job. Again, this is not a political statement, and has little or nothing to do with the whole open-source thing; it's a purely technical opinion, and I would be glad to be proven wrong.

Techniques for verifying that the right program is running are sometimes called "attestation" technologies. The specific one that's needed in this use-case, being able to tell at the server what the client is running, is "remote attestation". A Web search on those terms will find quite a bit of relevant stuff. Remote attestation is particularly hard, and as far as I'm aware the existing techniques depend on a special piece of hardware at the client side (something we don't have in the SL use-case).

It used to be, and to a great extent still is, a truism that a server should never have make any security-related assumptions about what the client is running. My bank's website has to be secure even if I'm not running the browser that they designed it for; my stockbroker's server has to be secure against any pattern of bits that might come down the wire, generated by any client program. The recent Adult content restrictions in SL are server-side; you can't get to an Adult area without veifying age no matter what client-side code you use or write (the age-verification database and the control over where your AV can go are both server cide).

Over the decades the field has experimented with some exceptions to this, the most obvious examples being in online games (where a rogue client might let a player cheat) and in DRM (where a rogue client might let a user violate a usage agreement or some content). But we haven't made a huge around of progress because the problem is so hard. XNA (as far as I've been able to determine) depends on having control of the client-side hardware (the xbox). WoW allows only a single client, and installs various proprietary weird things down into the OS to try to keep the user from running cheat addons. iTunes used to rely on a single authorized client program and various secrets hidden in the code, but recently they've given it up as a bad job, and switched to distributing music in an any-client format, and relying on copyright law to keep users honest.

The problem of doing remote attestation while still making it easy for third parties to write new innovative clients is, as far as I know, something that no one's even attempted before, and (as I indicated above) I know of no technology capable of doing it even imperfectly. Every method that I know of becomes really trivially easy to bypass in this use-case. I think we ought to stop calling each other names (on both sides of the issue!) and concentrate on whether or not there's actually some way this could be made to work. My current impression is that there isn't.

The problem i've seen with most of the copy protection schemes used by game companies is summarized in 3 points:
-They annoy the honest consumer
-They cost a lot of money (their developpers must be happy to be able to sell stuffs that keep needing replacement)
-They are broken in a matter of days because they rely on trying to hide something from the person who has full rights on the machine they run on.

You cite PHP Hardened, Apache Hardneed, etc, we can draw easily a parallele between the SL servers and an apache server, one provide webpages, the other one provide 3D 'pages' in a way.

Even in the most hardened version of apache, never you will find one that actually reject browsers it doesn't recognise.

If SL is supposed to be the web 3.0 it's a scope that goes beyon Linden Labs or OpenGrid whatever, because in this case, linden labs is just one service provider from many.

As i said before the classic web survive quite well with supporting any clients that can "talk" in http and there are many of them who do not remotely look like browsers, from RSS agregators to Web aspirators. But on the world wide web i see nobody complain and throw a tantrum that peoples can copy their website layout, their images, videos and flash files from a simple click.

So what is different that makes it acceptable on the WWW and inacceptable on it's wannabe 3D counterpart?

Indeed! It gets rather tedious being contacted inworld by those who think they can strong arm their pov by sending uninvited IMs demanding people stop discussing this issue. Then again, since you appear to have no compunctions engaging in such intrusive behavior, I do not expect you to get it.

Yes, the "alleged" most secure implementation does involve hardware, though that generally falls under the larger umbrella of trusted computing, which is still up for debate.

However, afaics, a TC model is simply not required to implement what I have in mind. For example, here is a potential scenario utilizing the model I've been toying with.

Joe Developer wants to create a variant SL client. He requests a developer key via a process that involves entering into a legally binding agreement that he will abide by SL's DRM and that he will not embed malicious code in his program. The process would include identifying the type of SL client (or clients) he plans to deploy (i.e., an SL Viewer, a Bot Program, etc). Upon receiving acceptance into the developer program, he downloads the developer key which is a dll plugin that must be included in his final product.

Once he is ready to deploy his product, he submits the final executable, which is vetted to ensure it meets minimal contractual requirements. This would involve some form of automated sandboxing and your usual virus/trojan scanning, etcetera. Upon meeting these requirements, the executable fingerprint is stored in the client authentication database, and the executable is added to an SL variant clients download area for deployment.

Joe User hears about the neat new features in Joe Developer's viewer, so they download the exectuable, which is really an install shell. Upon launching the installer and agreeing to the terms of service, an encrypted executable fingerprint and mac addy are sent to the authentication gatekeeper. When the user launches the viewer and prior to login, the encrypted executable fingerprint and mac addy are sent to the authentication gatekeeper for verification. At which point, Joe User can now log into the production grid with his neat new viewer.

Some pros/cons wrt the aforementioned scenario:

Pros:

• This model is quite simple to implement, can be designed to be somewhat seamless, and introduces no overhead to the final execution of the client, as viewer authentication occurs prior to client login.

• Being a member in good standing in the variant client development community provides concrete evidence of coding acumen for placing on one's resume for potential future contracts and/or employment.

• If it turned out that Joe Developer hid an undetectable easter egg, then his variant client could be neutralized quite quickly, as it would be a matter of disabling his authenticatin server developer key, which in turn disables all deployed executables tied to that key.

• Linden Lab is now positioned to file criminal charges, should they so choose, if Joe Developer violated the developer TOS.

Cons:

• This model would require developers submit their executable for review which would in turn increase overall time to market.

• This model would only allow them to connect their client to the test grid for testing purposes. The obvious problem here is the vacuum problem. Or otherwise put, you can only go so far on the test grid.

Imo, both of the above cons can be addressed in a step-wise fashion. Call it levels of trustability if you will. For example, as developer's variant clients prove to be trustworthy, their status is graduated to varying degrees of trust, which in turn, say, allows them to hook in to the production grid for testing and reduces the review process for deployment.

Please clarify the following you said:

Joe User hears about the neat new features in Joe Developer's viewer, so they download the exectuable, which is really an install shell. Upon launching the installer and agreeing to the terms of service, an encrypted executable fingerprint and mac addy are sent to the authentication gatekeeper. When the user launches the viewer and prior to login, the encrypted executable fingerprint and mac addy are sent to the authentication gatekeeper for verification. At which point, Joe User can now log into the production grid with his neat new viewer.

What is that install shell. How is the encrypted executable fingerprint created? What mechanisms are used to prevent Eva Developer to have her client just send Joe Developers client's executable fingerprint. BTW, if crackers want to steal content, they will use rootkits specifically crafted to trick that dll to read Joe Developers executable but execute Eva Developers executable, to make Eva's executable connect to production grid with Joe's signature.

Please add references to real life implementations that work on a normal PC and Mac on every OS, not just a single platform like Xbox360. Link to websites that discuss this matter. Ideally they are backed by research from universities or renowned firms.

Since you said in the description:

If you do not understand what a plugin authentication model is, then you need to hire someone who does.

Who knows about the plugin authentication model? References, weblinks or names. Ideally working at a renowned firm or university.

Upon downloading a legitic application stealing it's auth key or impersonating it, is trivial.

The hardware solution present the advantage that you have a physical medium to bury your secret keys in, but the software solution doesn't give you this opportunity.

Google search keywords: ActiveX, Authenticode

Please do some research before posting. Thanks.

I have some other commitments I need to attend to. However, you can start with this.

http://portal.acm.org/citation.cfm?id=302176

The model I have proposed is quite similar, minus the trusted hardware component. Which I hold is unnecessary for a trusted SL variant client.

The Fallacy of Trusted Client Software: http://www.schneier.com/essay-063.html

@Angela: I think that something like what you outline is about the best we could do without trusted hardware at the client end. My technical opinion is that it's not a tenable model for this use-case because:

(A) it's high cost: Linden Lab would have to accept, vet, and register (and identify and enter into a legal agreement with the author of) every version of every viewer that anyone wanted to use to connect to the main grid, or to any other Linden grid (including the current beta grid) that contained protected content (assuming that this solution is intended to address rogue clients violating content protections). The Lab's legal team would probably also have nightmares about giving the appearance that the Lab was implicitly certifying that the registered clients were virus free etc. At the margin, it would probably have some effect in reducing the amount of benign client experimentation and innovation that goes on, discourage some people from getting involved at all, make quick patches impossible (at least as far as connection to real grids is concerned), and so on.

(B) it's low-benefit, providing only a small amount of security against DRM-violating or otherwise nasty clients, because without trusted hardware on the client side it's easy to bypass: as Kyrah suggests, the attacker can just install Joe Developer's authorized viewer, watch its startup sequence in tcpdump, and have his own unauthorized viewer do the same thing at startup (provide the same encrypted executable fingerprint and mac address that Joe's would have). The code to do this can be freely circulated among the unauthorized-viewer-writer community. We can try to make this harder by obfuscating the key in the code that Joe links in, and using nonces and challenge-response between the server and the client, and so on; but since the attacker has and can run a copy of Joe's authorized code, we really can't make it very hard. At the margin, it would probably have some effect in reducing the frequency of use and/or development of malicious SL clients, although it's hard to predict by how much.

Different people can of course have honest differences of opinion about just how high the cost in (A) is, and how small the benefit in (B) is. My assessment is that the cost would considerably outweigh the benefit. But I'm open to convincing counterarguments.

@Kyrah: Bruce is a really sharp security guy, and a good writer. I do think he overstates his case sometimes, but he's 'way more famous than me, so who I am to correct him?

You can lock your doors, install anti-theft devices in your cars, install security cameras at work, and firewalls and anti-virus software on your computer. You can password protect your accounts and encrypt your data communications. All these do is to make it tougher to steal from you or to access your computer. Not a single one of them guarantees that you will not be a victim of crime.... that you have any sort of guarantee whatsoever against someone who is intent on breaking into your car, home, and/or computer. What they do accomplish however is that the average thief is more likely than not to steal cars that are unlocked and stores that are unattended. What they do accomplish however is that the average script kiddy scanning your ports is more likely than not to move on to a target that has no protection whatsoever. What they do accomplish is to increase the potential that the average virus will be identified and fingerprinted before it ever reaches your computer. Otherwise put. This is about statistics and odds within a time, risk, benefit analysis model. Where time, risk, and benefit is purely subjective and defined by the actor.

That being said, statistically speaking, the majority of SL users are not script kiddies, hackers, or otherwise (time). SL history indicates that some people do have not a problem using widely available IP theft tools (benefit). Ripped software has the very real potential of containing viruses and/or trojans (risk). Which is why I hold that an authentication scheme will mitigate the benefit while increasing the risk, such that the risk now outweighs the benefit, which in turn deters wholesale IP theft. Simply bc the presence of a plugin authentication scheme places the onus for creating an IP theft tool squarely on the shoulders of the hacker who would now have to provide ripped software to average Joe User. Furthermore, I hold that the implementation of such will also go a long way increasing customer confidence in Linden Lab's promise to address IP theft as well as increase customer confidence in legitimate 3rd party variant clients. And this is exactly why I consider the solution to be quite simple.

In other words, we do not need to get into quantum computing, complex algorithms and protocols, cryptography, steganography, and trusted hardware to discuss potential solutions to this problem. And I, personally, see all attempts to try to turn this into a discussion about fool proof methods against hackers to be nothing more than an exercise in specious obfuscation as opposed to honest inquiry.

Agreed. I hold that Linden Lab has a monetary stake in protecting virtual IP as a portion of their profit comes from not only content provider sales but tier paid by content providers as well. Furthermore, how much are they presently spending in support to deal with claims of IP theft? Conversely, how much of that cost can be mitigated through the implementation of some sort of software deterrent? I would proffer that the initial implementation cost of a software deterrent would definitely outweigh their support cost. At this juncture. I further hold that present benefit for implementing such a system would seem minimal. So, in this sense we agree.... to a point.

I also think that there is a very real potential for a long-term ROI. This obviously boils down to trend analysis and predictive validity.

My contention is based upon the opinion that customer dissatisfaction wrt Linden Lab's non-response to virtual IP theft will eventually reach critical mass. And when this occurs, implementing a software deterrent will be much more costly while at the same time having little to no impact on stemming the tide. Why? Simply bc, at that point, customer confidence has already been eroded to near nil while software solution requirements will be much more stringent and even possibly, unattainable. In other words, the key here is demonstrating that they are proactive in deterring IP theft. Pointing to a link is not proactive. Responding to IP theft with a form letter is not proactive. Implementing a software deterrent is proactive.

That being said, consider this abstract from a semi-recent ACM research paper (Cheat-prevention and anlysis in online virtual worlds):

"Virtual environments and online games are becoming a major market force. At the same time, the virtual property contained in these environments is being traded for real money and thus attains a real value. Although the legal issues involved with this virtual property have not yet been decided, they will have to be soon. To protect virtual property, virtual environment systems will have to conform to certain requirements. We analyze what these requirements are in order to either prevent cheating or at least prove a digital offense has transpired. Along with greater security, this will also reduce the cost of support, which is one of the major cost factors for online games." (emphasis added, mine)

Link: http://portal.acm.org/citation.cfm?id=1363217.1363235&coll=ACM&dl=ACM&CFID=45031338&CFTOKEN=95258023

In other words, we do not need to get into quantum computing, complex algorithms and protocols, cryptography, steganography, and trusted hardware to discuss potential solutions to this problem. And I, personally, see all attempts to try to turn this into a discussion about fool proof methods against hackers to be nothing more than an exercise in specious obfuscation as opposed to honest inquiry.

Specious obfuscation? Would that be like linking to papers locked behind the ACM membership wall to prove a point? For anyone interested, you can read that paper about cheating here: http://eprints.physik.tu-berlin.de/204/01/Final_Paper.pdf.

A few quick things to note about that paper.

• It mentions the SL economy in passing as an example.
• It then proceeds to say nothing else about SL or it's architecture.
• It has nothing to say about user-generated content.
• It addresses gold farming in WOW and EQ2 quite nicely.

Now if this issue was opened to demand that LL beef up it's ability to log and track object creation/renames and transactions so that ripped items can be traced, we wouldn't be having this discussion.

Instead, were discussing a bolt-on authentication scheme. One that it has been cogently argued (or not so cogently in my case) would not work.

You know what though? Let's just forget about that. For the sake of argument, let's assume LL can wave Starax's magic wand and deliver us into a world where only the official client exists.

It wouldn't make a real difference.

Angela is right about one thing. Thieves take the path of least resistance. Sometimes it possible to make things "hard enough" that they'll go off and bother some one else. This isn't one of those times.

As that ACM paper talks about, anything sent down the wire to a client is subject to manipulation. It's ludicrously easy these days to throw together man-in-the-middle-attack proxies in your favorite programming language. And all it takes is one person to release that code for everybody to get in on the game. Locking down the client doesn't change that. All it does is burn resources in a never ending game of cat-and-mouse that could be better used addressing real bugs.

Then it's back to square one at developping a new protection scheme.

The issue at hand is that the content creators feel the laws is not adapted to help them fast enough. Yes it's a serious problem and it looks like it will only get worse , wich might, at some point, make us reconsider if IP laws aren't fighting against windmills.

So, I rephrase a bit. Please show something that is even remotely successful against content theft and can be applied to open source.

Now, for something different. I thought about this plugin authentication model and it inspired me to have a concept about authenticated viewer distributions. It'll protect against injection of malicious code and it gives protection by reputation and trust. It won't protect against using libomv or just using an open sourced viewer to connect to the grid to just take what you want.

The concept is about developing a launcher for open sourced viewers. It'll be distributed exclusively on a website. That launcher can install special distribution archives that are digitally signed. When that launcher executes one of the distributed viewers it'll also check the embedded signatures on the executables and all included files.

This project can give end users confidence, that the viewer they start is really compiled by that specific SL account. As digital signatures will be able to be negotiated inside SL and that site could securely store RL information about the person (just like domains-by-proxy) that is not shared to the public, but yet that signature would be tagged as having verified RL information available for law enforcment, should that viewer cause any malicious actions like hidden L$ transfers or identity theft. Alternatively the signatures could be code-signing certificates issued by any of the already established CAs.

The launcher can be released as open source, so it'd be compatible with open sourced viewers as well. It can not however guarantee anything to server software about that it is being used. It can only ensure the end-user of launching a client that hasn't been tampered with since release and they know who compiled the viewer for them.

@Angela: general agreement. My feeling on the notion that LL should do this primarily in order to show that they are serious about preventing IP theft is that it might well do more harm than good: it's so easy to bypass that it would quickly be bypassed, and we'd see the usual suspects posting angry rants about how LL was being dishonest by putting up such a weak scheme and pretending to have solved the problem, how they ought to be sued or regulated by the FDA, that would get picked up by the Reg who would link to Schneier's essay and make sarcastic comments, and so on. But since public relations is definitely not my field, my feelings on that part of the issue are not necessarily a good guideline.

A couple of small technical points:

"Ripped software has the very real potential of containing viruses and/or trojans": that's sort of a different question, really; people who don't want to run viewers from untrusted providers can already avoid that by only using viewers from trusted providers. The current proposal would prevent someone who somehow accidentally runs an unauthorized viewer from connecting to a live grid with it, but that doesn't seem like a significant use-case to me.

"the presence of a plugin authentication scheme places the onus for creating an IP theft tool squarely on the shoulders of the hacker who would now have to provide ripped software to average Joe User." I think we're already at that point, even without a scheme like that proposed here. The average user, using the supplied LL viewer, already can't get around the SL content protections. For the average user to get around content protections, he has to get his hands on some non-official client, like Copybot or Builderbot. If an attestation scheme like that proposed in this JIRA were implemented, it would still be the case that the average user wouldn't be able to get around content protections unless he got his hands on a non-officiai client that enabled that. The main difference would be that such a non-official client would be slightly harder to create, and that creating it would probably involve explicitly pretending to be some authorized client.

(While the latter would not be technically too difficult, one interesting consequences at least in the US is that it might be easier to make the case that such a non-authorized client was intentionally bypassing content protection, and therefore more of a DMCA violation.

"'...or at least prove a digital offense has transpired...' (emphasis added, mine)"

Yeah, watermarking or fingerprinting content, or otherwise making it easier to prove after the fact that a copyright or other IP violation has occurred, is an interesting idea, as you and Pliny both say above. I think that would have to be a different JIRA, though; the current proposal would as far as I can tell have no direct impact on that area.

If I were the Lab, I would be considering addressing this problem by beefing up the responsiveness and visibility of my DMCA processes, by firmly stating (and meaning) that it is a ToS violation to use any client (Copybot, Builderbot, clever manipulations of the standard viewer, whatever) to copy stuff that you don't have c/m/t rights to copy, and putting out some sort of guidelines to third-party client developers about what kinds of content restrictions are expected in a non-ToS-violating client. My judgement is that all of those things would be more cost-effective than technical measures around remote attestation. But then I'm not the Lab...

Interesting proposal. However, I am really uncertain why, within the context of your model, since the client is being launched from a special SL distribution archives website, it cannot be pre-verfied that it does not contain code that violates DRM.

Furthermore, since your model, like mine, involves digital signatures (i.e., SSL certs registered with a CA) you would obviously be communicating over a secure pipe (which, if configured properly, renders your MTM argument wrt my proposal, moot). In other words, you could just as easily send the launched client a runtime authentication code that it would then use in combination with Joe User's login to negotiate via a likewise secure pipe with an authentication gatekeeper for connection to the production grid.

And finally, since these distribution archives are identifiably related to, say, Bob, Ted, Carol and Alice Developer, it would go to follow that the distribution classification (i.e., snow globe, shadow viewer, emerald viewer, bot-o-matic) is important, in that it allows users to determine what particular "bells and whistles" they want when traversing the SL landscape. Therefore, said information would naturally be stored with the informational data relating to the distribution.

While server distribution classification knowledge is irrelevant when it comes to the viewers (i.e., the user can always pull down the help/about to see what distribution they are using for bug reporting), it does become relevant when considering bots, that the server can now easily identify and omit from traffic numbers.

In all, it seems to me that you've basically reiterated a model that is quite close to what I proposed (albeit, far more elegantly), minus the server side check and shell installation. I do like your idea of launching the client from a special SL distribution archives website, as opposed to my suggestion of launching the client installation from a special SL distribution archives website, as your suggestion adds an additional layer of protection, that my proposal did not contain.

As for citations? ACM and IEEE are my primary source as I tend toward peer reviewed research.

For one, while I have stated that my model is not 100% fool proof, contrary to various protestations, I do not consider the model to be necessarily weak. Or even easily and quickly bypassed, for that matter. If I did, I would not have posted it, much less indicated the need for Joe Hacker when Jane Wannabe Coder could just as easily accomplish the job. Which, in turn, would render the risk-to-benefit argument of my model, moot.

I am not talking about PR either. I am considering this more from within a socio-legal context. For example, as I am sure you are aware, there are a couple of probative terms within the legal community that I hold directly relate to what we are presently discussing: best efforts and commercially reasonable efforts.

These are obviously subjective and in the final analysis, require the test of law. The premise here is fairly simple.

If it can be shown that a company reasonably endeavored to protect its client's fiduciary interests (i.e., financial institution's customer savings or in this case resident's virtual IP), a company can be said to have met its contractual obligation.

Conversely, if a company engaged in the equivalent of software lip service, knowing that such would instill a false sense of security, which would in turn increase the risk of harm, that would be not only unprofessionally deceptive and unethical but likely actionable. And, if proven, would severely damage their technical credibility, ethical standing, and even potentially run them out of business.

So yes, in that sense, I do agree with your contention that if LL were to implement a weak something just to show they're doing something about IP theft, it would be an extremely poor and unethical business decision on their part.

I highly doubt they're that stupid.

Or the case of clients that are autobuilt from an svn repository? ( as in every night for example )

I agree. And this could be a huge hindrance to 3rd party developers. However the hope is that the majority of debugging would occur on a test grid, so "repeated and often" production submissions should be unnecessary. Furthermore, I would want to find a way to "reward" developers who are consistently producing reasonably bug free code. In order to do this, I would envision levels of trustablity such that, once established, the submission path would be much more streamlined and not a whole lot different than ftp'ing them to a personal web server.

ETA ~ or in the case of snowglobe which is by default trusted due to Linden involvement and the fact that it already resides on Linden servers, updated via SVN, and therefore unimpacted by the extra layer of security proposed in this model.

"For one, while I have stated that my model is not 100% fool proof, contrary to various protestations, I do not consider the model to be necessarily weak. Or even easily and quickly bypassed, for that matter."

Fair enough. Can you say why you don't consider it to be weak or easily and quickly bypassed? People have described above what seem to be quick and easy ways of bypassing it (which, if they're feasible, would pretty much directly render it weak). Do you see some flaws in those methods of bypass, or plausible ways to counter them? Basically you just slap on tcpdump, watch the exchange between the client and server, and make your own unauthorized client do the same thing. Or, if the interaction is more complex, you look at how the authorized code (either open-source or decompiled) calls the LL libraries to satisfy the server as to who it is, and you make your unauthorized client call the same library in the same way.

LL can do various kinds of code-obfuscation to try to make it harder, but the amount they can do is limited (since it's certainly going to be too expensive to do a full obfuscating rewrite of every registered client), and in general even full-program code obfuscation hasn't been very successful for the reasons Schneier lays out in his essay (lots of skilled people with lots of time and interest attacking vs. a few skilled people on a tight schedule defending).

The discussion always progresses in exactly the same way, essentially a slow process of remedial education to bring the proponents up to speed on how the technology works and eventually, with luck, providing them with the realization that their apparently brilliant suggestions are actually unworkable. This is a lot of effort by all concerned for nil reward.

Kudos to everyone involved in the process, particularly the many open source contributors who do so much to help LL improve the viewer. You sure have stamina, and a lot of spare time.

I vote against this proposal.

Voted in Favor.

Edit: Okay it was a little longer back than I remembered, 1.18.6 viewer RC

Edit:

"Edit: Okay it was a little longer back than I remembered, 1.18.6 viewer RC"

Ah, right, that. That was in fact about changing the way the user authenticated to SL (proved that it was really him logging in), not about proving that any particular client was being used to log in. The basic idea, as I recall, was to redirect the user through a web-page to log in on, rather than having the viewer log you in directly, in an attempt to reduce some of the risks of using an untrusted client. But (as the discussion around it pointed out) it didn't actually accomplish that, and it introduced a bunch of new risks, so it was backed out, I think before the actual release.

But in any case, the "authentication" tried out in that 1.18.6 RC is a completely different kind of authentication than the attestation proposed in this JIRA.

Program launch and negotiation with the authentication gatekeeper occurs over a secure communication channel. In addition to digitally signed executable and components, is a time sensitive authorization code which is generated at run-time, encrypted, and sent along with user and password data over the secure communication channel to be validated by the gatekeeper. Thomas' suggestion of the program launcher removes the only and primary weakness of my model (i.e., a dll that can be decompiled).

That said, the strength or weakness of this, or any other security proposal, for that matter, is dependent upon underlying assumptions that are based within the area of what is presently understood about human behavior, generally, and criminal behavior within the electronic data protection domain, specifically. In very general terms, the analysis of criminal behavior indicates that there are two primary taxons: opportunistic and targeted.

Opportunistic can be defined by the "opportunity" (and, in some cases, invitation) to engage in criminal behavior that promises low risk of legal retaliation along with some degree of rationalization and subjectively assigned benefits. Crime statistics indicate that opportunistic criminal behavior of this sort falls within one standard deviation of the norm.

Targeted can be defined as intentionally targeting and circumventing electronic data protection. While this taxon is by far the smallest percentage of this particular criminal population, most security research focuses upon this taxon based upon the underlying presumption that exploits originate from this group and will be widely and freely distributed to the primary taxon: the opportunistic criminal.

While this assumption may very well hold true in areas such as banking, and even the record, music, and general online gaming industry, I proffer that, in the case of SL the risk of using a cracked viewer that could potentially contain malicious code, in addition to the risk of being caught and potentially prosecuted, will outweigh the benefit of stealing some unquantifiable and subjectively valuated virtual IP for the majority of those who fall into the opportunistic taxon.

Which is "why" I hold that the model I am proposing meets the "good enough" criteria for protecting user information and content provider ip.

The final result is two fold. One, Linden Lab puts their money where their mouth is wrt protecting user information and content provider ip. Thereby increasing customer confidence. And two, any attempts to circumvent this concrete implementation can be used in a court of law as proof of criminal intent.

Oh and. That I think of it, there is a third unrelated positive. Additional crime hardening of their behind the firewall product, and preparedness for the influx of the health care community.

@Angela: There can be no secure communication channel if the hardware at one end of the channel is under the control of an untrusted party. There can be an encrypted communication channel, but the attacker has the keys, so it's not secure. Digitally signing the executable and its components doesn't help, because the attacker controls the hardware on which the signature-checking code will run, and can simply bypass it or lie to it. The attacker also has a copy of the algorithm used to produce the time-sensitive authorization code, and can disassemble it, watch it run, and so on, and therefore duplicate its operation at any desired time. But you know all this. So what we disagree on is essentially a subjective judgment of whether the effort required for the attacker to make use of the information that he has to produce a working but unauthorized viewer is minor or major. So there's probably not much more to say there.

But let's stipulate that it would be possible to create a system that would take conscious and non-trivial effort to circumvent, even though such circumvention would be possible. I think we can agree that what would happen is that at least one attacker in the "targeted" class would produce a circumvention, and make that circumvention available through the usual shady collection of websites and newsgroups and so on. The remaining question is how widely it would be used. Your feeling is that it would be used rarely if at all, because of the fear of being caught, or distrust of the code (seeing as how it comes from shady sources). I tend to doubt that, myself; I would speculate it would be used roughly as widely as Copybot currently is, and as a result we would have roughly the same amount of IP rights violation as we do now. These feelings are probably again pretty subjective so we may have reached the end of this particular discussion. I hope we've at least helped tease out the various considerations involved, so the Lindens reading this (and I hope there are some!) can make a better decision.

(Oh, one final note: I would not call the virtual IP in SL "unquantifiable and subjectively valued". People put prices on it and pay money for it all the time! Seems to me it's at least as quantifiable and objectively valued as your average iTunes track, at the very least.)

Edit: wow all those smiley faces look stupid. Habits are hard to break...

Less than wholesale and unfettered copybotting software in use today.

@Dale who wrote in part: "I would not call the virtual IP in SL "unquantifiable and subjectively valued".

The value of virtual IP is still being tested in various courts of law. I stand by my statement.

http://tr.im/NYPostVIPOpinion
http://tr.im/ItsAVideoGame
http://tr.im/BraggVLindenResearch

Also see: http://law360.com. If you aren't a subscriber, they provide a free 7 day trial.

That said, there is an important key element in all of this.

Linden Lab extended a promise as part of their campaign to entice people to use their system (http://tr.im/LLPromise) and in the not so distant past, Mark Kingdon has perpetuated that promise (http://tr.im/LLPerpsPromise). And yet, they are apparently unwilling to back it up. That is, outside of major pressure. (http://tr.im/LLForced2Act) In other words, afaics, unless they make a reasonable effort to protect content IP from leaving the grid via means that involve circumventing their very own TOS (i.e. rogue clients), their words are nothing more than fluff and present attempt to fix the bulk permissions system is a complete waste of time. Esp considering that, from their very own TOS (http://tr.im/LLFinePrint) they have a provision that provides legal support for some form of trusted software model.

"Notwithstanding the foregoing, you may use and create software that provides access to the Servers for substantially similar function (or subset thereof) as the Viewer; provided that such software is not used for and does not enable any violation of these Terms of Service." (emphasis added, mine)

Finally, and again, does crime hardening guarantee against IP theft? A resounding, no. The big however is, it provides some degree of deterrence against wholesale IP theft as well as providing concrete proof of criminal intent. Otherwise put, a software trust model in conjunction with the above TOS (http://tr.im/LLFinePrint) provision positions Linden Lab to bring criminal charges under the "Computer Fraud and Abuse Act" (http://tr.im/USC18SS1030) in the event of just such a breach via a rogue client.

Our intuitions differ on how widely unauthorized-but-hacked-to-look-authorized viewers would be used. You think it'd be less than current copybotting software, I think it'd be at least as much. Not sure how to get any evidence as to who's right.

"The value of virtual IP is still being tested in various courts of law."

Well, yeah. On the other hand the value of virtual IP is on obvious display every day; look up the US$ to L$ conversion ratio, look at the L$ prices people are paying for virtual shoes in SL, and you've got the very real and very objective value of virtual IP. To some extent that's a tangent; on the other hand I think to the extent that you're arguing that people won't bother to crack breakable protection schemes because the virtual goods that they'll get access to aren't really worth much, your argument also suggests that LL shouldn't put much effort into protecting them, since they aren't really worth much. Can't have it both ways. I tend to disagree with both of those statements.

"Finally, and again, does crime hardening guarantee against IP theft? A resounding, no. The big however is, it provides some degree of deterrence against wholesale IP theft as well as providing concrete proof of criminal intent."

This last bit strikes me as very interesting. I wonder what kind of system we'd come up with if we focused on the "proving criminal intent" part rather than on the "preventing unauthorized viewers from connecting" part? I think the former is likely to be more doable than the latter; maybe something more cost-effective can be done on that side. And to reiterate something I said above:

If I were the Lab, I would be considering addressing this problem by beefing up the responsiveness and visibility of my DMCA processes, by firmly stating (and meaning) that it is a ToS violation to use any client (Copybot, Builderbot, clever manipulations of the standard viewer, whatever) to copy stuff that you don't have c/m/t rights to copy, and putting out some sort of guidelines to third-party client developers about what kinds of content restrictions are expected in a non-ToS-violating client. My judgement is that all of those things would be more cost-effective than technical measures around remote attestation. But then I'm not the Lab...

(I will also point out here, because of recent statements in a well-known weblog, that all of the opinions that I express in this or any other JIRA are completely my own, and do not represent the opinions of my employer, IBM, Linden Lab, or anyone else at all.)

Dale, please stop disassembling.

The amount of damage caused by a computer virus can be in the hundreds to get corrected. Furthermore, if the code contains a trojan, you're talking about the potential for identity theft which could be in the thousands, if not hundreds of thousands. And that's not to mention the time it would take to correct. Now add potential criminal justice system involvement ala criminal charges? Which means the individual is now risking having a criminal record?

Surely you understand that this type of risk does not negate the value of virtual IP? Esp considering that this is in the context of moving the ability to steal content into the hacker realm. Oh and. Lest we forget the threat from the yapping peanut gallery that Linden Lab would "face severe consequences!!!1!" if they locked down client access to the grid. Just sayin...

@Dale who wrote in part: "This last bit strikes me as very interesting. I wonder what kind of system we'd come up with if we focused on the "proving criminal intent" part rather than on the "preventing unauthorized viewers from connecting" part?"

Hmmm... just off the top of my head?

One idea that I have been toying with is some sort of heuristic analysis model. People tend to be creatures of habit (and so do bots, for that matter). So... you attempt to identify patterns that deviate from user activity norm. And those that deviate become flagged as potential parasites for further investigation. Btw, I have no idea where the heck I'm going with this as I haven't really fleshed it out! And I can already see lots of holes, though... they could arguably be plugged. But anyway...

On proving criminal intent, I was thinking of something much simpler, as we discussed in IM the other day. What if, say, the Lab put up a website where anyone, on entering some sort of identifying information (messy questions there TBD), could get a "viewer developer UUID", and agree not to release any viewers that had certain disallowed behaviors (details TBD). The ToS would include a prohibition on creating or distributing any viewer that uses someone else's viewer developer UUID. Then when a viewer first contacts the grid, it has to supply a known viewer developer UUID. It would of course be completely trivial to find out someone else's viewer developer UUID by looking at the viewer they distribute; we wouldn't even pretend that was hard. BUT if someone did distribute a viewer with nasty behaviors (like enabling IP violation), no one could claim that it was innocent, or "just a tool" or anything, because it would perforce constitute a ToS violation.

Is that the kind of thing you meant? It looks to me like this would have about the same benefit as the more complex remote attestation stuff, while having considerably less cost in terms of the Lab having to process and vet people's viewers. Of course this is also pretty much top-of-the-head, so I may have overlooked something key. (In particular it's not clear to me yet that any of this is more effective than would be stronger and more visible enforcement of the current ToS requirement that a third-party viewer "does not enable any violation of these Terms of Service". Have to think about that.)

Edit: didn't mean to say, in the strawman UUID proposal, that it would be forbidden to use a viewer developed by someone else.

Interesting proposal. However, I am really uncertain why, within the context of your model, since the client is being launched from a special SL distribution archives website, it cannot be pre-verfied that it does not contain code that violates DRM.

In no way I said "special SL distribution archives website" in any way. I said, you'd have a launcher. An application installed on the PC that just checks the digital signature of the viewer that is being launched. It can come from any site the user would trust. Crackers would also release a crack of that launcher that'd just behave exactly like the original with the exception of no longer checking the signature of the viewer, but telling the server a fake response that it cannot differentiate from a real response. This is because there is no way to protect any key that is mandatory for authentication and must be accessible by the launcher, which makes it automatically readable to any cracker interested, which shows how rediciulous it is to even attempt this.

Furthermore, since your model, like mine, involves digital signatures (i.e., SSL certs registered with a CA) you would obviously be communicating over a secure pipe (which, if configured properly, renders your MTM argument wrt my proposal, moot). In other words, you could just as easily send the launched client a runtime authentication code that it would then use in combination with Joe User's login to negotiate via a likewise secure pipe with an authentication gatekeeper for connection to the production grid.

You are confusing digital signatures with secure connections in this case. In no way there can be made any secure connection between the launcher and the server in a way that a cracker as end-user couldn't just analyse and fake. The launcher is running on the client and is subject to any modification on the client itself, wether it be rootkits, patches, hardware modifications etc.
It is physically impossible for any server to know, that the launcher is the one that is being called. It is easy to just create a launcher that is calling any viewer no matter what digital signature, but this is not in the proposal. For that, you'd just be able to just run any viewer in the classic method. The launcher has technically no possibility to authenticate itself to the servers in a way, that any other software cannot do. Because the launcher runs on the clients machine. Look at DRM, CSS, BD+, even digitally encrypted TV. They are only hard to crack if keys are stored on a small hardware device that can resist analyzing. Please understand the scopes.

As your other comments are just a followup on a misconception about what was said, they are moot. Please understand, there is not even remotely a way to make cracking an authentication scheme, wether it being copy protection or run-time code authentification (cheat protections for FPS and MMORPG), in software only, where the check is happening at the end-user's machine.

Any attempts to have authentication by LL will just slow down the people who want to do things right, and speed up the people who do it wrong.

because i happen to work on a tos compliant 3rd party viewer, and not on a content theft program, I find this jira a ignorant threat caused by fear of what has been going on for about a year now.

Leave us alone, only good guys go by the laws.

Program launch and negotiation with the authentication gatekeeper occurs over a secure communication channel. In addition to digitally signed executable and components, is a time sensitive authorization code which is generated at run-time, encrypted, and sent along with user and password data over the secure communication channel to be validated by the gatekeeper. Thomas' suggestion of the program launcher removes the only and primary weakness of my model (i.e., a dll that can be decompiled).

The secure channel is an illusion, it doesn't exist if you are one of the parties involved (in this case, the cracker as end-user). The program launcher can as well be decompiled and cracked. The only way to have an uncracked launcher is, if the end-user wants an authentic launcher. If the end-user wants to run unauthenticated viewers, they'll get a cracked launcher or even a viewer that doesn't need a launcher. Since there is no secure communication channel that protects from the end-user itself, all communication can be faked on it's own SSL connection by an emulator that has the same keys, extracted from the launcher and/or signed viewers.

Something to add. Every protection mechanism in software is very expensive to produce, it involves thousands of man hours to develop a protection scheme. But it takes just a day to a week for a single person to crack it. And a protected launcher like this is definitely an attack target.

While this assumption may very well hold true in areas such as banking, and even the record, music, and general online gaming industry, I proffer that, in the case of SL the risk of using a cracked viewer that could potentially contain malicious code, in addition to the risk of being caught and potentially prosecuted, will outweigh the benefit of stealing some unquantifiable and subjectively valuated virtual IP for the majority of those who fall into the opportunistic taxon.

Let's see, when I was interested in creating virtual copies and there's a risk to be banned... I'd definitely use an alt account with a fake ID. Scam some L$, buy the products and export them... if I'm banned, only the alt account is gone, low calculated risk... once exported I can make as many alt accounts as I like to import products and selling them everywhere... being caught is no issue. Just a disposable alt killed, fake ID used.
About the possibility of malicious code inside... know what? As a cracker I don't care about this. I'd just use two separate machines. One for the malicious clients and another for all serious activity. In case there was a trojan or virus in that client, it'd only affect those criminal activities that are done on disposable accounts anyways... again a very very low risk or just no risk at all.

btw. things seem to be no crime for those people, they do not play in that scheme.

"The evul hax0r god (hereinafter known as EHG) will crack the system within minutes of when it is launched and bring a reign of terror and destruction down upon Second Life... the likes of which you have never seen. Ramen."

In other words, in your worlds, apparently, everyone who steals is an EHG. And since we cannot stop EHG from hacking into a system, why bother? The phrase "thou dost protest too much" comes to mind.

But let's get back to reality, shall we?

Realistically, EHG is but a minority, whereas mere mortal opportunistic criminal (hereinafter known as MMOC) commits the majority of criminal acts. Which is why crime hardening works in most cases. Furthermore, while crime most certainly occurs (Otherwise, why the need for the CJS? Or for that matter, security companies?), our society manages to function in a reasonably cohesive manner.

You know... for example, we, as a society engage in agreed upon social rituals, which include everything from recognizing and respecting personal property to entering into fiduciary contracts, meeting fiduciary obligations, and paying for goods and services with agreed upon valuation of any particular culture's currency. And well... a whole range of things that define us as social animals.

While it takes but one action to wreak all sorts of havoc (remember the S&L scandal? and more recently, Enron?), we, as a society, do not shrink back with child like fear and defeatest attitudes that all is lost. That we can do nothing about it, bc crime is inevitable. So why bother doing anything at all? That is, most of us don't. Our system, would of course, break down, if we chose to take such a passive and cowardly stance and forgo crime hardening.

And yet you persist.

Dale's argues that it would be cost-prohibitive to implement a "good enough" crime hardening model while at the same time arguing that virtual IP (hereinafter known as VIP) does have value... but apparently not enough value worth protecting.

For one, I never claimed that VIP does not have value. I would not otherwise be involved in this particular discussion. My contention is, within the context of individual users VIP value is distributed such that a "good enough" crime hardening scheme would most certainly deter most MMOC's. Importantly, at least Linden Lab would now have a means to identify those MMOCs who it did not deter along with supporting concrete evidence of criminal intent.

As for Linden Lab? One would think they have a stake in protecting their user's content. One need only consider Linden Lab's monthly transaction report (http://tr.im/LLJulyTrans). If we take an extremely conservative approach, and say the linden dollar is valued at 300 Lindens per USD, and base calcuations at the bottom of each reported range (i.e., 2 for 2-19, 20 for 20-49, etcetera), the results indicate there is, at minimum, USD$18.9M in transactions from June 25th through July 25th. While this obviously does not reflect "converted" Lindens, we can surmise that some portion of these transactions reflect converted to real world dollars, at the very least, in the form of tier paid directly to Linden Lab.

That said, while there are different potential ways to approach this, as long as lindens can be traded for real world money, this problem will not go away. Nor will it get smaller.

Then again, Linden Lab could simply end this debate by discontinuing the ability to convert Lindens to real world money. Though, such a drastic move would abrogate the marketing model they have used for the last several years to entice people to the grid... Still, it would reduce the headaches and legal quagmire they stepped into when they decided to try to set up a micro economy. It goes without saying, of course, that such a move would have a deleterious effect wrt to their user base. Then again, considering their present trajectory (http://tr.im/LLBlog)? Perhaps that is what they really want.

Look, it's simple, if i was a hacker and a thief i wouldn't even care about this, it's nothing I couldn't get around. And although EHG is a minority, it only takes one to give it to all the script kiddies.

This whole idea isn't going to do anything but cripple the people who make sl better. You are going to limit access to the sl service only to thoes who break the rules.

I mean.. for goodness sakes, i don't need a special client to copy bot stuff, you can do it plain by monitoring data sent and received without ever making a connection. I really hate to break it to you, but this isn't going to work. Please.. i know what it is like to have your stuff stolen, trust me, it angers me to no end. If there was truly a solution to this I would be screaming at people to implement it.

But there problem is that there isn't, and although it may help you sleep better at night thinking only LL approved people log into sl, it will never be more than a dream, and you are going to hurt honest people in the process.

So please, put the gun down.

Am not saying agree with me or you're a terrorist. Am simply noting the inanity of repeating the EHG mantra and threats made (if you don't get this latter bit, read up to see Abattoir's "risk to trigger unforeseen consequences" comment) as a means to prop up one's pov.

That said, feel free to challenge whatever argument I am putting forth. I can, after all, be just as wrong as the next guy. Alas, repeatedly chanting the worn-out EHG mantra and/or putting forth baseless threats does not a thing to convince me that the contention I am putting forth is wrong. All it does is to indicate that is all you have to prop up your side of the argument. And frankly speaking, I do not find that to be even remotely substantial in supporting the "do-nothing" stance.

Then you can try and find a way to stop that, and untill you do you end this argument.

I'm not making threats here, i know it feels better to just think we are talking off the tops of our heads, and that this is really possible. but its not. I have control of all data LL sends to my computer, and that is all that is needed to copy any object. Sure, it's allot easier to build it into a program that already handles the packets, but it's not at all necessary.

Lets cover it like this,
1. LL sends a packet "new object that looks like this",
2. have a program that monitors data (you cant stop that, its on my own computer)
3. That program writes down "how this object looks"
4. and then turns it into a lsl scripts
5. The offical viewer can copy and paste the lsl script, item remade, (with any creator name) and they sell it. game over.

If you can come up with any way to stop any of that, let me know. Because any plugin authentication method doesnt even effect any of that unless you close off all source to the viewer, and encrypt everything, (which will only buy you time, the program is distributed, and there is enough money involved to get EHG interested)

It's nearly impossible, with all the money in the world, to fix this. Look at microsoft, have you found a version that isnt cracked yet?

And keep in mind that the infamous EHG only needs to make that once.

I hate being devils advocate, but its absolutly necessary that you understand that you can not fix this.

Let me refine my point so you don't get confused and think this is a threat.

You are shooting, and you aren't going to do any good, you are going to hit me, and the productive people. No one else.

And I always thought they were Lawful Neutral...

Cripple? Really? Seriously. I've been toiling away on my AI Bots (you know, those proggies that lots of people have come to equate with evul). So I certainly know that this model would impede that particular development. However, I am more than happy to deal with the inconvenient overhead. Bc I do get a payback in the form of legitimizing the stuff I've been working on. With the end goal (intelligent agents that can be potentially used within the education, research, and CJS sectors) that I consider the hoped-for final result substantial, thereby making the additional inconvenience moot. But that's just for me. Cannot speak for everyone else. Obviously.

Nonetheless, let's get to the meat of this matter...

LordGregGreg wrote in part: "although EHG is a minority, it only takes one to give it to all the script kiddies."

This really is the key element, isn't it? After all we certainly know (if we don't by now, we should) that EHGs can take what they want. So, it really boils down to percentages of the remaining criminal population. Which can be broken out as follows:

What percentage of IP theft involves MMOC? Crime analysis research indicates ~82% of all IP theft occurs within this taxon. So, a crime hardening model, while certainly focusing upon the EHG, is basically targeting this ~82%. Of course even with this, we know that we will not get 100% coverage of this group either. After all, as you so note, this group can be further divided into sub-taxons, if you may.

Script Kiddies: these are people who may have rudimentary programming knowledge and may even aspire to one day become as good as their EHG brothers. At this point, however, they do not really have the wherewithal to crack the programs themselves. A crime hardening model would not likely deter these people.

Gimmes: these are people who do not have any programming knowledge whatsoever but to are willing to use whatever IP theft tool is available. A crime hardening model would deter some of these people, in that risk-to-benefit model has changed.

Incidentals: these are people who will weigh risk to benefit along with engaging in some degree of rationalization when considering engaging in criminal behavior. In most instances, they do not see the behavior as criminal, even if they realize at a very basic level that it is. This is esp so, if the behavior is approved via silence (ala Linden Lab doing/saying nothing). A crime hardening model would deter this group bc Linden Lab would be drawing a line in the sand that explicitly says, "do not cross."

Otherwise put, the "good-enough" answer really lies in the determination of statistical distribution among the above, along with the answer to the question, what percentage theft deterrence is considered to be "good-enough"?

I contend that the above would follow your standard distribution and that Incidentals would make up ~82% of the MMOC population. The remaining distribution would be divided btwn gimmes and script kiddies. And of the gimmes, I'll be liberal and give them ~50% (even though crime statistics indicate otherwise). Resulting in an overall predicted deterrence at ~71%. Otherwise put, ~29% of the potential criminal pool would continue on undeterred. While this is still far from perfect, I hold that it is far better than today's 100% open door, take what you want, non-policy.

Pssst. Please to tell them they spelled "evul" and "Hax0r" wrong. LOLOL

Easy to use will make sure both the gimme and script kiddies are involved.

Open source would make it so people can download a binary from someone they trust to look at the code and stop password stealers

And the risk involved would be identical to that of copy bot..

infact... if we look at this.. it would be the same as copybot, just done in a way that completely waltzes around any plugin authentication pain.

So that means that w/e percent copybots, would still copybot, perhaps even more as this model would be completely undetectable by anyone until they import it.

And cripple, yes. I make changes, lots of them, 90% of them don't work.
"Day Oh added a comment - 23/Jul/09 04:32 PM
I'm imagining not being able to debug and make changes to an application while connected... gotta submit every change for a review first xD "
seriously.

It's hard enough getting about 5 people to coordinate and make a release, it would be absolute hell to have to drag LL into the process, they have better things to do than read 2000 lines of changes every week.

Then you can try and find a way to stop that, and untill you do you end this argument."

Quick answer. No and no.

If you want to solve this issue, you are going to have to take a different approach.

Raise the risks, make it harder to get an account, make punishments more severe (legal, inescapable, perhaps require real identification to be on the rlmoney grid), make ways to catch theifs easier. Stuff like that for starters.

Stuff that only targets the bad people.

And let the productive people be on your side.

I'm NOT suggesting that anybody in this discussion is trying to make a buck by the way, just noticing a behavior i see emerge quite often.

"So that means that w/e percent copybots, would still copybot, perhaps even more as this model would be completely undetectable by anyone until they import it."

It would just take one person in the skilled-attacker class to make and distribute an unauthorized client (or client-construction toolkit) to enable everyone else in the entire attacker class to bypass the protection. The only increased deterence I can imagine would come from either:

(A) people who are afraid the unauthorized client might contain malicious (against the user) code; but I don't see any reason that people would worry any more about that in this case than they do with copybot today (since copybot has a "bad-guy tool" reputation already), or

(B) people who would feel guiltier about using the unauthorized client, and/or more likely to get caught; but again I don't see any reason that the situation there would be any different than the current copybot.

Note that I'm not saying that approximate (i.e. imperfect) remote attestation is impossible (it's definitely possible), nor am I saying that we shouldn't try any countermeasures that aren't perfect (all sorts of countermeasures can be cost-effective without being perfect). I'm just saying that this particular countermeasure, putting some kind of remote-attestation library into the viewers, seems to be unlikely to be cost-effective. Other people may of course disagree.

And I do think that we should take only cost-effective measure.

(I think it'd also be good if we could stop calling each other names and accusing each other of being criminals and so on. It contributes nothing to the conversation.)

I don't understand how you are even asking these questions.. the answers seem very obvious to me.. so let me run through them.

[She doesn't say that it has to be100% fool-proof.]
If it is not 100% fool proof, than it is 0% fool proof after someone breaks through.

[If they are indeed so good it wouldn't matter what LL does. It will be just a minor inconvenience.]
The good people will not be able to circumvent these things, as doing so would obviously be illegal, not something you want to do if your working on a public client. It's a complete road block for anyone who wants to do things right.

[If you are so good I truly believe it is a disgrace to come and steal. I find it very hard to believe that those that are indeed good programmers would sink so low.]
We know its a disgrace to steal, but it is completely naive to think that good programs won't make something like this. Just look at what you are already up against. Copybot is GOOD code, and it was built from scratch in c#. The other permissions hacks are also good creative code. Sorry, but you are up against people who know what they are doing.

[Come on, if everybody is so good why do they even come to sl? Shouldn't they have already made their own VR without needing to first reverse-engineer what LL has done]
Because there are people and money here. These is no reason to reinvent the wheel. SL attracts the good and the bad, i don't need to prove it, look around you, how are you questioning that?

[Lets say some might do it a few times(to prove that he/she can do it), but after the third time it will become a chore.]
Obviously not. I can give you a list of permission exploits that have been exploited, and then fixed. It's more than i have fingers on my hands. The simple prim copybot as we know it has been redone about 6 different times, its clear they aren't getting bored. You can ponder their phsycology all you want, but the proof is that it happens.

[if the communication between sl and the viewer is encrypted your monitoring program is good for nothing because it needs a key to decrypt the data To get the key you need to mod the viewer The moded viewer won't work unless you get a dll from LL To get that dll you will need to enter into a contract with ll (if you were to program for IPhone it wouldn't be that much different) Ok, you are right, it will be cumbersome but it will at least deter some. It might be even be possible to track down those that "share" their dll]
First off, suggesting that LL encrypt their data is absolutely outrageous. Now you have gone from making it a pain in the ass to be productive, to making it impossible. Also, I don't need a license with LL, i just need a viewer. I can watch the data and decrypt from there, or even decompile enough of the viewer. I refer to my microsoft example, you can not do enough to cause any good, and all you are going to do is hurt the people who play by the rules. SWITCH YOUR TARGET WE ARE ON YOUR SIDE.

watermarking, detecting copyied builds, stuff like that is good and productive, and we can help with that. Do stuff that only hurts the bad people so you can stop raging the open source community. You are fighting with people who hate copybot just as much as you do, we just happen to know a little bit more on how it works and what can, and can not stop it.

No one's suggested that virtual goods have no value. The closest anyone's come to saying that was Angela, saying that their value is "uncertain and subjective".

Watermarking content and some of the other things you mention might be fine ideas; but they aren't what this particular JIRA is about. The people expressing doubts about the cost-effectiveness of this particular JIRA aren't thereby saying "we shouldn't try to do anything to protect content". They're just expressing doubts about this particular idea.

Hope that helps.

Currently anyone can grab the code, build it (if they can figure out how) and connect to the grid and while the person has to either have certain knowledge or have the will to look up and interpret how to build the viewer there are otherwise very few hoops to jump through. Although there were a few exceptions that would allow this, many of the proposed solutions here also prevent people from even downloading and compiling the UNCHANGED code and connecting to the grid which is just ridiculous.

One of the main reasons I have been somewhat tempered in my criticism of my proposal is that I'm pretty sure LL knows this and that Rob and Phillip Linden would never allow it since this would destroy all the work they've done with the open source effort as well as being a gigantic Fsk you to every resident who has contributed to the effort. Which I believe comes to hundreds of us "open source freaks" to quote Prok.

If residents suddenly learn that engaging in or receiving stolen property burns then most will stop sticking their hand in that fire and will be more careful about where they spend money.

I.e.; if ripping off content becomes a waste of time the frequency will drop to a more manageable level.

Let us see Linden lab take a first step to prove they are serious about it. And let's see them enforce the rules on everyone including their alts, family members, charter members, and friends.

I will not hold my breath. If Linden Lab will not get tough on this matter then why would they remotely be interested in technical means of verification?

@Ann: I agree it seems from our viewpoint that the low-hanging fruit in content protection would be non-technical stuff like a clearer DMCA process, more visible enforcement of the ToS terms on not distributing clients that enable rights violation, some clear guidelines on what makes for an acceptable third-party viewer, and so on. The wheels of the Lab grind slow; I hope it will turn out that they also grind exceeding fine.

In regards to an automated testing system, there are ways to automatically code check and there are services that you can pay to do that but they are simplistic at best and it would be a stretch to use such a system to even check for malicious code to steal people's passwords. I don't see using an automated solution to check for a list of "malicious" functions as feasible, especially since there is no agreed upon list of what qualifies as "malicious" and all but a far right fringe agree that it's how the functions are used more than the functions themselves that are the problem

One problem with making getting a developer code automated is that at that point is that it would be good for authentication (who made this code) but not verification (what is in this code). I'd actually be in favor of having an authentication only system like this on a voluntary basis but that should probably be a another feature request.

http://secondthoughts.typepad.com/second_thoughts/2009/07/open-source-shakedown-why-i-do-not-believe-it-is-technically-impossible-to-secure-digital-ip.html

This jira has gone too far. People are using it targeting the open source people who want to help you, and publicly defaming people to a serious degree.

I think there is a serious misjudging what is going on. The target is on the open source community, who are very much on your side on this issue. This comes from the utter discust at programs like copybot, etc, and I can understand that, especially the drive to want to go to any means to get this shut down.

But the key point that is missed, is that locking out the open source people won't lock out copybot. I know on the surface, it looks simple like this, and if it really was a feasable option, I would throw down my hat, sacrifice my work, and get it shut down with you just to protect second life and its content creators.

Please, anyone is free to talk to me in world if you want to bounce ideas off with me before posting here.

I think allot has been learned in this jira, unfortunately, most of it is also pretty discomforting, but It is time to refocus efforts to stop copybot, using this new information.

I strongly encourage you, Angela Talamasca, to close this jira yourself, and let me help you make another one which will put everyone behind you and hopefully cause a serious dent in thoes who take permissions they dont have.

That said, the original model is based upon two key components: implied and contractual trust that is enforced via some form of gatekeeping.

There are presently a number of 3rd party variant SL viewers. The link to the viewer download along with its related feature enumerations can be found on the SL Wiki. (http://tr.im/LL3rdPartyViewers) In addition, Linden Lab includes the obligatory legal disclaimer:

"Third-party, hybrid, and homebrew viewers are not associated with Linden Lab, are governed by their own respective licenses. LindenLab is not responsible for any desired or undesired results in association with those viewers."

In my model, the aforementioned disclaimer would remain intact. The big however is, that in my model, there would be some form of gatekeeping (as opposed to an anyone can add their link, wiki) for identifying these 3rd party viewers to prospective users.

This would be similar to present the opensource project process (i.e., while you can download and view the source code, you cannot commit changes unless you have signed and submitted a contribution agreement (http://tr.im/LLContributionAgreement) with linden lab).

In this case, the process would occur as follows:

• Joe Developer enters into a legally binding contract with LL that his viewer does not contain malicious code or violate LL ToS, and that he will exercise due diligence by releasing signed executables for public use.

• Upon being accepted into the 3rd party developer program, he is then directed to a secure developer account management page where he can include links to his site and describe his product, should he so choose.

• In addition, he also requests and receives a grid access key from via this account.

• Upon receiving the key (which occurs within seconds of the clicking request key button), he adds his newly assigned key to the appropriate field in the server authentication protocol, that has already been pre-determined and published by Linden Lab. At which point, he is ready to connect to the grid.

It goes without saying, but I'll say it anyway, the login negotiation process should occur over a secure communications channel as opposed to today's weak md5 encryption over an open communcations channel.

• After various debug iterations, he simply signs the version he plans to deploy, and uploads that along with its related digital signature to the same program download area that he uses today.

• At various points after the initial release Joe Developer wishes to release updates to his program. Joe Developer can choose to a) continue using the existing key or b) request a new key, which would render his existing key inactive.

It should be noted, this model does not require Linden Lab review or otherwise vet Joe Developer or his code. Furthermore, with this model, Joe Developer can test and release updated viewers to his hearts content, since he has a grid access key that is only invalidated when he requests and receives a new key.

The only extra overhead Joe Developer should see is the one time, initial contractual registration process, the time it takes to write and/or update the description of his viewer listing (he may choose to provide a link only to his download site), and the time it takes request/receive new keys, and then add those new key to his code. This latter bit is click, cut and paste, process, folks.

The only extra overhead on the part of Linden Lab is to provide the contractual document, file submitted documents along with other contractual documents, provide a simple, yet secure area where Joe Developer, once approved, can access his developer area to request/receive new keys and/or update his product description as he sees fit. And, importantly, log connections to the grid that include but are not limited to usernames (already being sent), the client grid access key (can be the agent field), originating ip addy (already being sent) and mac addy (already being sent), and time and date of access for later heuristic analysis. The logging bit is a one day effort at most. While the creation of a 3rd party developer area would be one week, tops. The primary effort would be the heuristic analysis. However even that should not be a major hurdle as viewer usage over time.

All well and fine, so exactly how does such this seemingly over-simplistic model prevent copybotting?

First and formost, this model will, at most, deter copybotting. Secondly, but no less importantly, we will assume the executable can be easily hacked, and the grid access key extracted and distributed to script kiddies to incorporate in their copybot programs, and said proggies will then be distributed to gimmes.

Even so, by implementing such a model Linden Lab has drawn a very public line in the sand, saying do not cross or face appropriate legal action. Furthermore, grid access key lifetime is arbitrary in that Joe Developer determines when to update that key. So heuristic analysis of access logs can be used to flag potential breaches of the system. The end result provides a concrete path of criminal intent. Which is what is needed to be actionable in a court of law. Or otherwise put, if you really want to stop crime punish the criminal.

Excuse me? That isn't my site. rolls eyes

Although this will still not really do much to stop copybot, it does take me out of the cross hair.

I have no problem with this implimentation.
(sorry about above, edited)

@Angela, it's your proposal of course but the way I'd invision it would be pretty much your solution but since this wouldn't work well with 3rd party viewers that are released open source I think another way to do this with more of a carrot and less of a stick approach and at the same time automate the whole listing of 3rd party viewers (the wiki page is a pain in the ass to keep updated and accurate) is to have this be optional to be used on compiled viewers so that people could distribute their custom source without one and that could still be used.

The carrot is tricky since LL would have to give a certain amount of approval to viewers that went through the process while still maintaining their distance for legal reasons. My idea is that by going through the process you could get your developer key which you could encode into your binaries and part of the application process would be the option to get a listing on a visible page somewhere on the sl top domain (www.secondlife.com/resident_viewers or something like that) and if not a seal of approval than at least being one step up the level than anyone else as well as free advertising. Here's how I see how this could work.

3 levels of viewers
------------
1) LL official viewers
2) confirmed resident viewers (per my process above)
3) everything else

Here's what I think the published information could be
------------------------------------
Info about the viewer itself:
Creator(s): [who coded the viewer]
download url:
source code url:
date of last update:
license terms:

I do wonder how much benefit there would be to this, over LL just announcing "it is a ToS violation to distribute a viewer that enables content theft, or to use any viewer to steal content, and we log IP and MAC addresses and will use those to track down culprits", and then actually doing that once or twice to prove they meant it.

(And also defining in some more detail what "enables content theft" means.)

Certainly worth thinking about in any case.

It is not against the TOS to build any tool however using such a tool on the grid for malicious purposes is a TOS offense and can result in up to and including a ban

LL has never explained their logic behind this but I'm guessing it's partially so they can claim deniability and also so that they don't get into a situation where they police one application and then are required to start policing everything because they've set a precedent. It sucks for us the residents but it is an entirely logical position on their end.

Apparently we enable content theft Dale because we don't support these unrealistic, and in the case of the people who have hijacked this issue and taken it too far, draconian restrictions that would kill open source development on Second Life and destroy SL as we know it.... ok that may be a little melodramatic but I really wish that it was a more ridiculous statement than it was since the effect would be huge.

Because otherwise i can see from a mile a code branch of the viewer with an easy to use "preference" input box where you can paste the developper key of your choice (yours or ... not).

If the developer key thing is put in place by LL they will have to do a code segment in the style:

const string DEVELOPPER_KEY = "FFFFFF"; //paste your developer key here, otherwise your client will only be able to connect to the beta grid.

(of course a developer can decide to be clever and obfuscate his dev. key but most "modded", viewers usually move around only a minimal amount of code to keep .patch files readable and divert as little as possible from the code trunk, especially if the source is ment to be read by someone else, it also makes updating your code to the latest viewer version easier.

@Angela -

First and formost, this model will, at most, deter copybotting. Secondly, but no less importantly, we will assume the executable can be easily hacked, and the grid access key extracted and distributed to script kiddies to incorporate in their copybot programs, and said proggies will then be distributed to gimmes.

I'm heartened that we seem to be making progress here. We seem to have reached a consensus that this proposal would not affect the availability of theft tools.

What we still seem to be disagreeing on is how effective this proposal would be at discouraging the act of theft. It seems to have been argued here that stopping "casual copybotters" would be good enough.

I question whether there is such a thing as a "casual copybotter" in SL. Last I checked, using copybot and any of it's ilk is a PITA. I have heard rumors of clients (cyrobot, vlife, flex-life) that make copying point-and-click simple, but those clients appear to be hard to get one's hands upon.

Any way you slice it, copying items in SL today is a process that in most cases involves managing alts, bots, and esoteric client features. Maybe I'm just cynical, but I think this is outside the skill set of most residents. We're talking about people who can't even find the Advanced menu without a YouTube tutorial.

Even so, by implementing such a model Linden Lab has drawn a very public line in the sand, saying do not cross or face appropriate legal action. Furthermore, grid access key lifetime is arbitrary in that Joe Developer determines when to update that key. So heuristic analysis of access logs can be used to flag potential breaches of the system. The end result provides a concrete path of criminal intent. Which is what is needed to be actionable in a court of law. Or otherwise put, if you really want to stop crime punish the criminal.

And now I'm a sad panda again.

If the Lab were to invest serious time and energy developing what we all agree now is an easily exploited attestation system - just for the symbolic value... I would be livid. As in screw-you-guys-I'm-switching-to-Cobalt pissed.

For all it's faults (and they are leigon), the DMCA is the way to deal with this problem. You want a "concrete path of criminal intent"? People don't accidentally trip and copybot things. Lobby LL to beef up it's ability to log and track people who import and sell copied objects.

In another JIRA ticket.

Properly filed.

Perhaps under MISC?

Can I get a close up in here?

Social solutions. This mostly stems from there being no technical possibility to stop this. Many of the technical changes proposed in this JIRA would, as has been stated, be for naught, as there is no way to keep the data to be copied from the hardware and software that is out of the control of Linden Labs.

Of course one of the repeated reasons for technical solutions is, 'Technical change X Y would make copying much harder for those without technical skills and knowledge'
However: How many copybot users know about the technical details? I dare say almost none. So the argument that it would stop the non-tech savvy is flawed, if not broken by the very application that caused this JIRA in the first place.

In the extreme case, as was stated, the object data can simply be captured, and reconstructed.
Read: It would literally take a day or so to circumvent any done proposals for technical changes in the future, right now.
All of them. Less to wrap it into an application and distribute it. It was hard to write copybot. it is simple to get and to use it. History will simply repeat itself in case of any technical changes.

No, the solution, as stated, is social. To make copying content for profit more risky. The goal is to make the danger outweight the desire to sell what is not yours. The steps to that are various, and each has its own set of problems and advantages.

1) Only allow access to SL after having verified through RL data.
This was the case before LL opened up SL to the masses, removing the requirement for credit card info in account creation. I see how this would help tremendously. At the same time, I know I would not be here right now if this opening up would not have happened. I did not have any credit card at the time I joined up, and I joined up in 2007 and not earlier because of the credit card requirements. I cannot morally take a positive stance towards this solution, as I believe it would also keep alot of good people out of SL. Far more than bad.

2) Simplify the DMCA process
This is, in a way, not doable to my knowledge. The DMCA process itself has its base in the law, along with what LL may and may not do and react to. I also have heard of lots of successful DMCAs in SL already, so this seems to already work as intended. However.

3) Have, along with the DMCA, more effective and thorough checks and punishments for copying content that is not yours.
I think this is where the solution lies, and where some Problems still reside. The actual punishments and consequences for IP theft and reselling do not outweight the profit. However, the more severe the punishments and consequences are, the more there needs to be strict controls to prevent innocents from being framed.
The actual desired consequences, I'm sure, differ from person to person. Some would like all stolen content to be instawiped off the grid. Others would like $L fines. Seizing of land and holdings? Removal of the ability to sell anything? Permanent banning on first strike?

I'm not here to propose any of those, but I hope I have made my point.

The only diff btwn my most recent and previous proposals is that there are less technical hoops to jump through. Furthermore I have long felt this discussion was unraveling into overly-complex and unnecessary b.s. Esp since the goal has always been about determining a means to identify and track overt criminal behavior. Which, I hold presents a "good enough" deterrent effect for the "Honest Joes," thereby leaving intentional criminals. Otherwise put, not only do I assume the system will be cracked, I am depending upon it. How else do you think I plan to determine if someone has engaged in overtly illegal behavior? Osmosis?

No matter. Here's some interesting food for thought. http://tr.im/LLMetaAnalysis Enjoy!

Esp since the goal has always been about determining a means to identify and track overt criminal behavior. Which, I hold presents a "good enough" deterrent effect for the "Honest Joes," thereby leaving intentional criminals.

Okay. I must be missing something here. I've sat down and gone back through this entire tortured conversation. Who are these "Honest Joes" that you seek to deter from copying? No where in this ticket has there been any reference to how many of these people there are. How can you be sure they even represent a significant portion of theft in SL?

I can't find any guesses on this, let alone any real numbers.

To reiterate: How can detering "Honest Joes" be good enough when nobody knows how many of them there are?

Infact.. how about ONLY the people who use copybot illegally.

It simple, you make the risk higher for everyone. I could, (Or perhaps the lindens with all the money) make a little way to record one of your creations, and passively scan and alert you of any build within a certain percentage of similarity.

The easier it is to catch, the less people wil use it, honest joes, and EHG alike.

And how about making the punishments much higher. There are many ways to do this, like perhaps only letting people with credit card information be able to sell stuff. Or as extreeme as you want to go.

But this probably belongs in a diferent jira, as this one is all about something else.

Wait-a-minute.

A system that could auto-monitor for similar builds would be impractical. However, a system that lets residents give the Lindens copies of their creations for registration (think virtual copyright/patenting) might be doable. I daresay it'd even be practical. If all the Lindens had to do to verify that something was ripped is compare it with something they already have on file... I'd bet they could be a lot more responsive.

Of course, you'd have to trust the Lindens with full mod copies of your items, and there have been accusations in the past...

But still, there might be something useful here.

A resident could set up a service for people to register builds. A bot could tp around the grid each week scanning for any of them, and IMing notices if it find anything.

(Sorry, i know it would be tons more powerfull if LL did this, i just have a habbit of trying to find way to not to have to rely on them taking action)

@Pliny wrote in part: "A system that could auto-monitor for similar builds would be impractical. However, a system that lets residents give the Lindens copies of their creations for registration (think virtual copyright/patenting) might be doable."

Except that... you've just turned Linden Lab into a copyright/patent office. No offense but that prolly won't go over very well with Linden Lab. You know... from a legal perspective?

@LordGregGreg wrote in part: "A resident could set up a service for people to register builds. A bot could tp around the grid each week scanning for any of them, and IMing notices if it find anything."

Alas, already tried and failed due to lack of international legal standing. The url has since been taken over by someone advertising "how to survive a credit crash", though you can read about the SLPTO 2007 grand opening here. (http://tr.im/SLPTO)

But anyway... My proposal says let's require said thieves to commit the more serious and tangible crime of unauthorized grid access thereby providing a means to potentially prosecute them under the "Computer Fraud and Abuse Act" (http://tr.im/USC18SS1030) Esp considering that this type of thing has already been tested in a court of law. Just sayin...

I am afraid that is the only way to detect it is a method similar to the one I mentioned.

Anything else can be gotten around, and as mentioned before, it only has to happen once for everyone to have it and do it. There would be no discouragement of using the new copybot, because it would be impossible to detect. even if you could go to jail if you were, if the chance of being caught is 0.. not a big deal.

That seems like a bit of an arrogant statement, and completely bogus at that. libsecondlife was 90% complete and the CopyBot excitement all happened before the viewer was ever open sourced. Making a new authentication method that is closed source won't change the state of open source clients at all.

Those familiar with the opens source culture, its origination, and trajectory, understand why, for the most part, open source works. They also understand the underlying goal of GPL and how that is enforced, not through technical schemes, or for that matter even the courts, rather by the open source community. An example of this can be easily demonstrated when KirstenLee quit distributing the shadow viewer (http://tr.im/GPLenforcement) due to pressure from the SL open source community. (http://tr.im/WhereIsTheSource) It should be noted that she eventually complied, setting up a SourceForge account.

There is a lesson to be learned in the above example. And that is, compliance through social pressure still works. Even so, there is, no doubt, a difference between my proposal and the above cited case. And that difference is what differentiates true hackers (those who love technical challenges) from crackers (those whose goal is to exploit allegedly secure systems), for example. We (being those of us involved in this discussion) also certainly understand that true security, when it comes to computers, is not defined by just the communication channel but the end points as well. Or, to cite one of my favorite old-time quotes:

"Using encryption on the Internet is the equivalent of arranging an armored car to deliver credit-card information from someone living in a cardboard box to someone living on a park bench." - Gene Spafford

Arguably, and where the anecdotal tale of KristenLee's woes are applicable wrt this topic, are the fact that, in order for open source to work, there must be a means to hold those involved accountable. After all, to do otherwise, erodes confidence in the open source model. And this adherence is largely accomplished through social pressure as opposed to legal means. I hold that, similarly, those involved in creating 3rd party client variants, will not only accept but want to register/update developer keys, should Linden Lab implement such a model. The primary driving force being, that they are then recognized as a legitimate source. Furthermore, they will be most interested in protecting said legitimacy. Thus distributing the oversight within and among the development community.

Nonetheless, this will only work, assuming Linden Lab is able to implement a means for identifying and addressing illegitimate uses. I hold that heuristic analysis is that means. While such won't immediately bear fruit, so to speak... over time, a sound implementation will reveal patterns that can then be used to identify potential breaches (i.e, that which sharply deviates from said patterns).

As previously noted, the outcome is multifaceted. I suggest that in addition to identifying potential breaches in the system (whether for DMCA violations or even attempts to steal personal data), it has the potential for the additional following benefits.

• provide a concrete means for legitimizing 3rd party variant clients

• provide a means for identifying bots and therefore excluding them from traffic counts

• provide a non-intrusive avenue for metrics gathering and analysis

And the solutions provided are ridiculously convoluted.
I do hope that LL has better things to do with their time than devote any resource to this.

The developer_key or better, viewer identification key, is already in and used. Every legit third party viewer is using it already. It's called the Channel and Version. Even libomv is using it's own method to send the application name and author's identification to LL's servers. OpenLifeGrid is using these informations to only allow authorized viewers to connect. This works more or less very well, because OLG is more a closed group of some individuals and there is less to gain by making a viewer fake the OpenLife viewer login procedure.

The illegal viewers I've seen so far either completely imitate the official channel and version number of Second Life viewer or they have a channel/version that is recognizable in some way and has been banned from usage on SL already. One of these banned viewers was a leaked version of CryoLife. I guess the original Copybots have been banned by these IDs as well, though the criminal forces just hack what they can and thus just inventing new identifiers.

The only difference between what's deployed today and what was proposed in here is the difference between "allow all but" and "allow only known"

For some historic information. Older viewers have sent the MD5 signature of their own executables for an identifiation, if an official viewer was used. This has been abandoned since viewers like ShoopedLife just sent any arbitrary MD5 signature to LL, imitating an official viewer very well.

In recent viewers there has been something implemented which gives another form of signature about which viewer is used. It's a clothing layer protection. The first illegal viewer that employed this method so far was VLife and since then it has been given to other viewer developers. Then the author and distributor of VLife decided to make a public viewer called GreenLife Emerald Viewer that is hosted on his own domain names modularsystems.sl and lawlinter.net, and created the project greenlifeemeraldviewer on google code. The clothing layer protection feature was deployed in that viewer as well and then found its way into many other viewers, hacked or legit. It even came with code to read these tags and make them visible, so you can see who uses what viewer.

So, you can see many of these client detection features are already implemented, logged and even some abandoned. And who knows what sourcecode changes are between the official viewer and the open sourced version, that LL can detect.

So the usage of an illegal viewer can very well be detected and proven in most of the cases. But nothing of this is used proactively. Someone needs to abuse the viewers and someone else needs to report that person. If no one reports that illegal activity then what's left is for the IP owner to file a valid DMCA. Every valid DMCA will be acted upon. That this process isn't working is just a myth, that I can only explain in the way, that the DMCA filed wasn't sent as a letter, not signed, no real life address and/or no proof of IP ownership inside.

VLife was rumored to have a trojan by some or key logger by others. It was also rumored to allow people to copy on double-click, etc. And of course, it was allegedly being sold for L$50K on XStreet. Whatever the case, that viewer, from my understanding def contained malicious code and violated the open source GPL. What I was admittedly unaware of, as per your comment (quoted above), is that the VLife creator and the GreenLife Emerald Viewer creator are one and the same. And that the Emerald Viewer is VLife by any other name. What a shame. No matter. Thanks for sharing that bit of viewer history. Sadly, it puts into perspective why some people are having such a fit about this thread.

edit: FYI, anyone who thinks "Emerald Viewer is VLife by any other name" has obviously never logged into emerald.

The solution is obvious, simple, but perhaps not practical. Don't put Bob's content on Alice's computer.

Make Bob's computer render Bob's content for Alice. This imaginary protocol would have the proposed client sending information about Alice's camera (and other render settings) to Bob's computer. Bob's computer would generate an image and deliver it to Alice's computer for the proposed client to assemble along with content from other creators.

I've left lots of technical details out of both my problem description and proposed solution, not cause I don't understand them, but because this topic bores me. In a digital world, any attempt to control what others do with information you give them is doomed, get over it.

OIC. So, are you saying he got religion? Furthermore, is the sock puppet really necessary?

This is supposed to be a JIRA about the way assets are shared. NOT about what can and cannot clients can do. The flaw in this system is not open source, but human greed and human curiosity.

Open source has given Second Life bug fixes and other such advances, even if most are not heard. The Snowglobe Viewer is making advances faster then any viewer I have watch progress on.

If you are going to reply negatively about anything, I have just said please keep in mind that it can be considered flaming and unnecessary commenting. As Alexa Linden has said (shortened) Keep JIRA chatting civil and sane.

If server-side rendering actually worked (e.g. if all that OnLive / OTOY stuff was realer), then Bob's content could at least stay on the Linden's computers, and Alice's computers would get only rendered images containing pieces of it. That would help more for some kinds of content than others...

Nobody wants to help an industry that wants to send us back to the stone age of computing and wants to put filter gates at every corners of the network because progress is threatening their business model.

Emerald was jcool410's idea and the first thing that was done was stripping VLife off all features that were the illegal client leaving it as a base for Emerald development (Actually, took the same codebase and copied code from VLife over to Emerald). VLife and Emerald are highly sharing most of the same modifications and yes, even the login screen between VLife and Emerald looks about the same. About GPLv2, it was violated and GreenLife can't be legally distributed. As well if you analyse the package that you can download from their site at http://modularsystems.sl/index.php?option=com_phocadownload&view=category&id=1:installer-win&Itemid=5 called GreenLife_Propriatary_YOU_NEED_THIS_FOR_SPEED_v7.exe with the MD5 of e3e1cb4e08c97d3056464a31a8e55d4a contains llkdu.dll, a non-redistributable component. It also contains SLVoice and fmod.dll. And if I understand the GPL licensing correctly, that if you break the licensing (by distributing VLife and protecting it and intending to never giving out the sourcecode) you loose the license to the base work and can never re-aquire licensing by just downloading the source again and starting over.

There is no possibility to verify wat is running on the end computer you can only verify what data you think ity have been sending you. There is NO suggestions still here HOW this Magic box, and yes it have to be magic should work.

The problem is for the user to connect and get in you have to give hin the key. Once he have the key he can go in. Once he is in you can control, what he does. The most common used tools today are not the modified open source clients, it's modified drivers, well actually developer debugging drivers. It's programs looking on the harddrive. It's tools using libsl, even it that change name by now.

I suggest you tale the time to think out a teoretict possible model to implement instead of just adding a magic box to the JIRA. Perferable make an test implemantaion to prove the consept idea. All suggestede ideas here are not working and are moved form one security area into an other. In the suggested area the envirment is totally differnt and none of the suggested ideas are even remotely likely to make any difference.

Sorry the idea here is not implementable as suggested and shuld be closed as sorry we have discovered the word was round, we can't pretend that's it's still flat.

But oh they try and they try, and at such length.

If you want to change the law then lobby your elected representatives. If the law doesn't suit you and makes you angry then go move to a country that fits your ideology better. In the meantime you can see how Second Life is evolving away from a place where people can openly flaunt stolen works and to a place people are accountable for IP theft. These policy changes to a law abiding configuration must have the communists broiling mad.

But this is a technical discussion and there is no place for pointless ideology here.

In the meantime ripping tools that can be detected, and yes some can, are being dealt with by residents who choose to participate in the exposure of residents using such ripping clients.

By the way, this issue is a duplicate of a resolved issue...