Sorry that you believe "it must be possible". It isn't.

The point is - we are all trying to improve SL, by jumping on these Jira's with negativity and posting things "are impossible" without knowing better, you slow it all down - Linden Labs read that and think the community doesn't want this.

If you're not sure of something or have no experience doing it, stick to something you are. In general, if you have nothing good to say, don't say it. Here's a small lesson for you : there are very few things that are impossible - so use the term sparingly, otherwise if you really need to - write something is impossible for yourself.
_________________________________________________________________________________

For the others now thinking its 'impossible' : a possibility is having an additional (not required) parameter on the login. Should anyone login without it, the client is 'Unknown'.

Should a valid and well-intentioned 3rd party 'client' be written they can apply for a license key from LL.

Depending on how it should be managed by LL the parameter would be populated either by an encrypted API returning a 'hopping' key ( which would need a decoder on the server-side - only runs once on login and can run asynchronous ), or a simpler method is a unique 'key' (like uuid) would be sent to a registrant by LL, to only be used when the registrant compiles the final binary of their client (ie. they are certifying their client is 'clean') - they are not to publish the keys to others. The key would match the registered client name on a LL lookup table, eg 'abc viewer'.

Should the 3-rd party's key be compromised, LL would just disable it, so clients would again be 'unknown' on login till the 3rd party recompiles with a fresh key : this will deter registrants spreading their key.

An API could be more intelligent and imbed info such as checksums of the compiled code into the parameter which would prevent even leaked API's working - so that may be more secure.

The above would still keep the client opensource - as nobody NEEDS to register to compile and use their opensource code. Those messing about with the client code can still use their clients on most of the grid, except those regions who have chosen to prevent unregistered or certain clients. This would be EXTREMELY useful to corporate customers.

That's really fair considering those estate owners are paying loads of USD each month to host their content. Those building legitimate clients can still do so, and for them the added benefit is they would be distancing themselves from the negativity associates with 3rd party clients.

I'm not saying this is the solution, only one idea I thought up in 5 minutes to negate Maggie's 'impossible' comment, there must be some really good ideas out there.

I think it's not even desirable to deliberately create a way for scripts to discriminate against viewer versions they "don't like". Further, I think it's misguided to try to use a program running on someone's own equipment as a weapon against them, which is what you're proposing.

So far SLV is relatively free of half-baked DRM crap. Let's keep it that way. The only sensible place for DRM is the server. Not in the viewer, and not in LSL scripts.

It happens I have perfectly adequate credentials in software engineering, so I do hope you can comment without personal attacks in the future.

Corporate customers are perfectly free to register avatars rather than viewers, as they do today.

1) IT IS possible ... i just gave an example of how.

2) If you 'think' its not desirable to have scripts discriminate then just don't use the scripts. On MY regions I can do as I like, you do as you like on yours. Please don't dictate to myself and others who want to rid SL of all the rubbish what we can and cannot do.

3) BTW : Exactly why is that not desirable? Do you have a vested interest in 'illegal' (out of TOS) clients? ... because that's the only reason someone would not like a feature like this.

4) If you think its "misguided" to use software with built in security to protect its datastore, you better log off right now, as most apps you use will be doing just that. In fact this website is - so maybe you should not post here.

5) A 'weapon' ... is it necessary to be so melodramatic? Will it explode and kill people?

6) Why a 'weapon' anyway? Those compiling their own clients can still do so and run them on their regions as well as thousands that remain open. If they are doing a decent job of it they can register and distance themselves from the 'criminal' elements ... thats a massive plus for them too - so its not a 'weapon' ... maybe more a 'rocket-engine' for their product.

7) What do you mean by 'half-baked' DRM crap? And why is the only sensible place for DRM the server? Again, thats just because you are not thinking outside the box. But please stop trying to convince others to not think any further.

8) Congratulations on your credentials , however I never questioned nor have any interest in them.

9) Well your first post was a personal attack, and I do understand its a good way of introducing negativity and taking the focus off the suggestion being made, but its not going to work here, so you can drop it. My response was just to tell you that I don't appreciate your negativity on posts, such as this is.

To recap :

This is a small non-obtrusive change that really will only be 'negative' to trouble-makers - why's that a problem to anyone other than said trouble-makers (and their alts) ?

At the same time it will rebuild the faith in SL content, and bring a much higher level of confidence to corporate clients. I will mention that I consult to one of the top 10 IT companies in the world, and they are not in SL because of these issues ... perhaps that will change with something like this.

http://wiki.secondlife.com/wiki/PJIRA#Be_courteous

"Thinking outside the box" will tell you any code in the users hands is ripe for exploitation.

Telling me to "stick to things you really know something about" is surely a personal attack on my professional credentials. You asserted a belief that it was possible to do this securely, and I stated my position is that it is not. That neither constitutes an attack on you, nor excuses your own attack.

Issuing a binary-dependant UUID would be a nightmare as the viewer goes through versions, which I'm sure you can see it does quite frequently.

"Non-obtrusive" this proposal is not. And it will "be negative" any time the process is hacked or breaks down.

I suggest you take your "top 10 IT company" client who told you they want a viewer lockdown to OpenSim, where you are free to implement both ends of this yourself and demonstrate how "non-obtrusive" it is.

1) "Your 'example' is not secure. The source for it will be distributed, and by definition the end-user can easily eavesdrop the session."
a. Of course it's secure, thats what it's about.
b. Again: No-one gets the source, just a compiled API to link into their project, or a key to use as a param.
c. Eavesdropping is useless unless they can decifer the rules built into the API generating the key, which can be pretty secure. When (if) its eventually cracked, simply generate a new one.There's encryption methods too btw.

2) "Thinking outside the box" will tell you any code in the users hands is ripe for exploitation.
Again - please read what i suggested : "Thinking outside the box" means they don't have the source-code - i thought that's pretty obvious.

3) "Telling me to 'stick to things you really know something about' is surely a personal attack on my professional credentials."
Not at all, I never did (and still don't) know your credentials, and it's irrelevant. Although I am confused as you still don't seem to be understanding what I suggested. But that's what I meant ... first try understand the proposal and once you do, then make the comments. You are still mis-understanding it and posting nonsense - so please go carefully re-read it. At the moment you are posting negative comments about what you 'assume' i suggested.
Also, as I wrote previously, get off riding the "personal attack" pony.

4) "Issuing a binary-dependant UUID would be a nightmare as the viewer goes through versions, which I'm sure you can see it does quite frequently."
Again, please re-read and understand all.
This is not true at all : the same key (not a UUID) would be applicable across versions - until it's compromised. So it's quite likely never to change for a 'licensee'.

5) " 'Non-obtrusive' this proposal is not."
It most certainly is.
a. Nothing here is "needed" by users experimenting with open-source code, or even by trouble-seekers, so totally non-obtrusive to all of them them.
b. A 'licensed' builder simply applies once, gets the key (or preferably API) and builds their viewer application with it ... it adds maybe 15 minutes of additional effort on their part, so that's also non-obtrusive to them, plus gives them a happier client-base and even more users.
c. More corporations feel more secure about content in SL, and invest more USD in SL, which improves the grid for all, and SL bottomline.
d. Because of the added security, more content creators will create more better content for SL.
None of the above is obtrusive.

6) "And it will 'be negative' any time the process is hacked or breaks down."
a. LOL .. thats a REALLY good excuse for not adding features to aide protecting customers IP .... "we cannot add feature X because 'if' it ever fails people will be negative"!!!
b. In that case we should undo all features and close the Jira, as they all have the ability to "break down". Forget about 'improving' SL as any code-changes are risk. What's the point?
c. (If) there is a security compromise, its already designed to handle that - just revoke the key so licensee needs another. (Pls try understand that as you're pretty stuck on that).
d. But yes, it's bound to be VERY negative for CERTAIN people - those using SL against TOS - and we can fully expect to see unhappy posts from them on this Jira.

7) "... client who told you they want a viewer lockdown .."
Who said anyone asked me for a viewer lock-down? Surely they would have asked LL. All I mentioned was the reason they are not in SL or using it as a corporate tool. Again, you are not reading my posts ... pls go back and read them all carefully to understand what its about before replying.

As for me or anyone else taking a client to OpenSim, I don't think i need to even reply to that silly suggestion.

Your replies are 100% negative, and off-target. You might as well complain about world economy, as most of what you are posting is not what I suggested.

I'm not sure on what criteria you decided that, but I don't agree with that, and have reset it.

IP theft and griefing is a very serious concern for the majority of SL users, and I don't see why more focus and effort is not put into finding ways to reduce it. It seems as soon as this topic is raised, it is down-played. This is a very good way to deal with that. Something like this should have been implemented years ago.

Please consider leaving it critical so it can be properly investigated and soon, and not lie around like Jira SVC-676 for 2 years bouncing about. To the many content creators in SL this is critical, and to many it's already been a show-stopper.

Everyone who who downloaded the code for a third party viewer would have to get their own key to build the viewer and connect it to the grid since distributing your own builder key with the code for your build would defeat the whole purpose since people could jsut change the code and impersonate you. Like VWR-14778, which depending on how you read the issues either relates to this or is duplicated by this, this idea would not work and would do great harm to the open source community. As I stated with that one though, there is almost no point in making more than one comment to oppose this since there is pretty much zero chance of LL doing something like this especially since it's founder has been one of the people pushing to get more people into working with the viewer source.

This kind of authentication you're suggesting is actually an active topic in computer science research. Smart people have been thinking up on this kind of problem for years. Here's a link to one of the more popular papers on how to identify modified runtimes.

http://sparrow.ece.cmu.edu/~adrian/projects/pioneer.pdf
http://portal.acm.org/citation.cfm?id=1095809.1095812

The idea is to entangle the binary in such a way as to make it difficult to return a dynamically computed checksum within a certain amount of time. It's a neat idea, but I don't believe it will be robust in an environment such as the Internet with a potentially highly variable RTT.

What I'm really trying to say is that it's a really hard problem, and the only way people have been finding any kind of solution is to come up with these wonky ideas that have these highly machine dependent solutions that I don't think are particularly reliable.

Even in the case of your proposed approach, I think it would be possible to "steal" the salted key from either analysis of the executable or monitoring of network traffic.

At any rate, I am certain you would earn a PhD in computer science if you could find an unbeatable solution to this problem.

On top of all this, I'm not sure what value it is even if you could identify if a viewer was a standard or non-standard release. I don't think LL has any interest in disabling any kind of non-standard viewers.

I sympathize with your problem, I really do, but I think DRM on an open platform (such as a PC) is a lost cause. When you're talking about IP theft, you can't really hope to contain all possible avenues of attack, and you only need one avenue to work once before all technological solutions become moot in preventing unauthorized duplication.

It's not a new problem, and it's not one that hasn't been solved due to lack of attention. I think what you need to do is to propose a plan that is technically sound before people will consider it seriously. I'm afraid that until then, it's just a lot of wishful thinking

IAm, your claim was "This is a small non-obtrusive change that really will only be 'negative' to trouble-makers". I don't think that's even close to true, and explained why. Now you seem to have backed off that claim.

Again, if your unnamed Huge Client With Lots Of Money To Spend wants a tightly controlled environment with the ability to lock out non-preferred viewers, OpenSim is a much better tool. Now you claim your intent is not to lock-out non-preferred viewers. Could you please set forward a use case for this proposed feature that does not involve doing that?

Personally, I think you have a highly exaggerated notion of exactly what content any viewer is capable of copying, and consequently also the benefits of any proposal like this. You certainly are minimizing the costs that others commenting seem aware of.

But, since you feel this is all so easy to implement, you should feel free to build your own proof-of-concept implementation against the OpenSim platform and the released viewer source...should you be sucessful in doing that and convincing LL and the viewer development community that it is desirable, backporting it to the LL server should be quite easy.

a. Those using the binary with API embedded would login as usual, and the client would be identifed as eg. 'abc Viewer'.

b. Those that want to 'fiddle' with their source code can do so and login to SL without the API, so their client would register as 'Unknown', not a big deal. They can access their regions, and most of SL except those who chose to exclude 'Unknown' clients - which after all is only fair considering those region owners are paying a pretty penny for their regions.

Thanks for the link to VWR-14778 ... i never saw that, and it is certainly very similar - I'm happy to see so many others have the same concerns.

What did concern me is the Linden responses to these proposals : sort-of you have the DMCA process so use that.

While its true that is the process, it doesn't mean we should not be building additional functions to deter IP theft. Specially considering how inadequate and unrealistic the DMCA procedure is for SL (considering RL USD legal costs vs SL Linden business profits). We need to be making SL better for the users, not more difficult.

____________________________________________________________________________________
@ Francis :
Thanks for the info, from a quick scan of the attached docs I would say the idea is similar but they are obviously going for the ultimate. I think something similar but a lot simpler can be safely implemented with excellent results, and it can grow too over time.

And you are right that the published solutions are not suitable for internet due to RTT etc. I've got minimal checksum experience as to what's possible, but perhaps instead of using time, the time element can be left out and a few checksums calculated based on fixed ranges / targets in the linked code and then combined (as opposed to one checksum) ... that would make it pretty difficult to 'patch' the open source code to return similar values - as they'd not know where to patch. Also those separate ranges can be 'weighted', etc ... so in general a pretty strong API can be built without going overboard.

As you are rightly pointing out, there will be times when the API is compromised, and that should be (and is) expected. This means :
1) The compromiser has had to work really hard to achieve this - that will automatically exclude 95% of the current mischief-makers
2) The model is working and what is currently out-of-control in SL would be under control
3) LL would generate a new key, and the compromiser will be back to zero, and possibly give up
4) LL will prove to content creators they are working at assisting with the problem, so the confidence can rebuild.
5) Theft and griefing statistics would literally hit the deck. (Yes there will be a few getting through - but really a few!)

I don't think LL would want to disable a viewer grid-wide and no reason too. But owners of regions would like to (and should) have that ability. Additionally (as per VWR-14778) LL could get important statistics from that info about logins (bots etc), and have the ability to shut down some connections from users abusing the grid with bots etc. This is EXACTLY what we need every weekend when valid users cannot login, but possibly 20 000 bots are connected making traffic.

You are right one cannot stop everything, but unless one starts addressing the issues nothing is going to happen. One should never give up.

Re a sound technical proposal : I believe this is a sound proposal. Maybe the extreme mechanisms you mentioned (and thought i was referring too) are not as yet, but something simpler most certainly is. And yes, we know it would stop 100%, but its certainly going to have a very significant impact (perhaps 95%+), and make it really difficult from then on.

____________________________________________________________________________________
@Maggie
Thanks the comment re priority was for Alexa to consider, but as you mention it the "Critical" lists "content loss" .. that sounds appropriate. Note, this is not a bug, its an enhancement request. In the scope of enhancement requests, it is critical.

"This is a small non-obtrusive change that really will only be 'negative' to trouble-makers" is right, I don't see why you think i have backed off it, but i haven't. There's nothing obtrusive about it. When i say "negative" I mean have a negative effect, not just be negative to change. There will always be hoards of ppl opposing any suggestion, good or bad. Case in hand.

You seem to be obsessed with my client, and have now added the "With Lots Of Money To Spend" all by yourself. Did you not understand what i wrote about first reading my words and replying to them ... ie do not reply to your made-up versions of my posts, its really very silly and a waste of time.
Again : Forget them. I only mentioned them to illustrate this is the reason they are not in SL.

You mention Opensim a lot. If you like it, enjoy it, I prefer SL thx.

The intent IS to allow sim owners and corporate clients to lock out rogue viewers from their estates, as is their right ... as they pay the bill. Kind-of similar to locking out everyone from their estate via estate options, only this way they can allow viewers they consider "safe" to explore - ie 99, 8% (or whatever) of SL.

Which 'costs' do others forsee? There is nothing "lost". Simply some registration of 'approved' viewers. And not registering is also a non-issue, as you'll still be able to access most of the grid.

Thx for giving up the "personal attack" line, and moving onto a "you go do it strategy". That's progress, whats next?

"Content loss" means you had something in inventory or rezzed in -world, and now it's gone. It does not refer to copying prim structure. Copying is not loss.

You ask what's next after my "you go do it strategy"? Why, that's simple! What's next is you go do it. Heavy emphasis on "you".

Seriously, you've told everybody how easy and wonderful this project would be. If that was a credible argument, people should be falling over themselves volunteering to to the work. I interpret the lack of a cheering throng of volunteers to be an expression of skepticism that this is feasible, that it is desirable, or both.

Obviously my position is the third alternative, but YMMV.

You may prefer SL to OpenSim...I do too. But OpenSim is useful for implementing projects where someone other than LL needs to control both the viewer and the server. This is one of those projects.

To prove that it's feasible, instead of waving your hands and telling us all how simple it would be, kindly demonstrate. Once you can show that it works, is easy to manage, and is secure-- all claims you have made here--you can try to get folks to implement your proof-of-concept back here on the main grid.

My thought is: since in fact it's not at all that easy, either you will go away grumbling about how negative everybody is (the condition you arrived in), or actually try to back your words with actions, and discover it is in fact not doable. At that point, the second discussion as to whether it would be desirable --a value judgement at best-will be moot.

I'm still waiting for your use case for this that isn't a viewer lockout, by the way. I don;t think there is one. The only way this misfeature could protect content is to prevent a viewer from downloading textures or the prim structure of objects, and the only way I can think of to do that is to eject the avatar from the sim. And it would have to be an island sim...because a lot of content is still viewer-visible from adjacent sims.

Lastly, surely "one of the top 10 IT companies in the world" who is "not in SL because of these issues" has lots of money to spend. Your own words...but if they don't have lots of money to spend...why exactly should we care what they want?

Almost NOTHING you have posted in your last post is relevant here, most of it is you AGAIN protesting about your own "version" of what you "assume" I mean. Is it really so difficult to read the posts and stick to commenting on MY posts?

Your interpretation of "Content loss" is different to mine and others - thats life, get over it.

"Seriously, you've told everybody how easy ... this project would be" ... you keep doing this. Where did I say its easy. Pls revise the link Alexa gave re flaming and trolling.

Thanks for the offer, but trying to manipulate me to do LL's work won't work, unless they contract us which is unlikely. Pls revise the link Alexa gave.

I've discussed the use case - please revise my posts.

Ooops.

Your assertion that it would be easy: "This is a small non-obtrusive change". It is neither small nor non-obtrusive. I've offered you a viable strategy to move toward your stated goal. You can either do something to support your claims, or continue futile ranting here. It's up to you.

I see it different : The reason Jira's are not taken seriously is because of the flaming wars and drama, which "certain ppl" try incite to play down / confuse an idea they don't like. But its fine we don't agree.

"This is a small non-obtrusive change" does not mean it's easy to code. Since when is Small = easy? Small change in that context (refering to how obtrusive it is or not) means its not going to be a big thing to roll out or be a big change for opensource clients. I'm not saying it IS complex to code, neither am I saying it's not, as obviously that depend on the details of the design and how secure one makes it vs the trade-off of a little admin regenerating keys when its compromised.

Again pls read Alexa's post on being courteous : The only "futile ranting" here is you ranting on about your idea of what I am proposing - which seems entirely different from what i do post.

Anyway, look, if anybody copies your darned Porche sculpties, just file a DMCA like everybody else, OK?

That car is a pretty thing. That must have been a lot of work, since of course you didn't use somebody else's meshes without permission.

What is "critical" to one group of people is not always to another. To hard-working content creators, some progress in this regards is "critical", and years overdue. Just because its not a bug causing blue screens doesn't mean it can't be critical - as an enhancement request it is.

The right way to read priority would be : Type + Priority

Like everyone else, I've been raising a ridiculous amount of DMCA's, sometimes multiple per week for the last 2 years ... how does that make content creation in SL viable or even fun? And why shouldn't we progress with some options to negate that?

"Like everyone else, I've been raising a ridiculous amount of DMCA's, sometimes multiple per week for the last 2 years ... how does that make content creation in SL viable or even fun? And why shouldn't we progress with some options to negate that?"

Raising DMCAs? Your lawyer has been filing that many take-down notices with the legal department of Linden Labs? And they haven't passed on any responses from the other parties?

As for having a login parameter...

Admitted, Linden Labs could have their build system automatically insert codes for the hundreds of test builds they do each week - they couldn't do that for the external client builders. In the mean time, the one key they could NOT afford to revoke would be the ones in the current release clients - and a VERY simple packet sniff would give that one.

No, as soon as you have a requirement for a client to verify itself, it won't work. Seriously, look at the fun the online first-person shooters have trying to keep out bots. It just doesn't WORK.

Until the compute power for the server to render each scene for each client, AND the bandwidth to send it as a simple bitmap (at an acceptable framerate!) comes along, the data has to be sent to the client - and that data is vulnerable to snooping and decrypting.

As for the clients - just remember Dr. House's advice - EVERYONE lies. I've no idea how you're going to get your hypothetical binary API blob to verify the actual code being run - on a Linux system, it's CERTAINLY not going to get access to the memory space to verify it. Or at least, not for long. The Linux community is going to rightly consider that a HUGE security risk, and it'll give up SecondLife before it gives up SSH.

Re DMCA's : The point is they are a pain in the **** to deal with, and the experience is destroying content creators in SL ... there are thousands of really good creators that have just given up creating in SL due to that.

Re Login:
The reason things like this never get added to systems is because people (rightly) say it'll not solve everything. But its not designed to solve everything, and there will always be those that can 'crack' it. Its designed to make it more difficult, so that 95% of the current attacks are stopped. ATM anyone that can click the build icon and have some basic coding skills can prob find an exploit, you want to stop those. Once it's cracked some people will get through and slowly spread the knowledge to those with less, so then a change is made and back to square 1, and the cycle starts again.

That just how security is. It doesn't mean because a few talented ppl work out how to get through that its "not working" ... it is working, on the 95% its stopping.

A challenge / response would make it a lot more difficult to break. But again, it's not always necessary to design something totally inpenetratable (and as you say and we all know thats just not going to be totally inpenetratable), its more about stopping the majority, and moving forward and adapting with time.

Same as virus protection. Every week a new threat comes out, so they patch it before the masses with basic coding knowledge can use the exploit. The anti-virus teams try write algorithms to stay ahead, but realistically that just doesn't happen.

Throwing hands up in the air and saying it can't solve all the issues is just silly. Work at solving the majority.

If the library is linked into the application when its built, it'll have access to the memory space. No need to give the source out.

One should however remember that this JIRA does nothing to archive the content theft goal of reducing and i think the goals should be rewritten to state this.

Yes, besides of preventing content theft I don't see any purpose for knowing other people's clients (other than curiosity). Which client one uses should be subject of privacy (if no illegal actions are done by this person).

For the topic "content theft" this thread already duplicates VWR-14778, so if we substract "content theft", why should we know other people's clients?

All the other descriptions have for Priority are to do with bugs. This is an enhancement request, and a critical one.

Priority should be read Type+Priority, in that context its not an issue.

I know this is already happening, but really. Its still discrimination

Also about your plan to have it update each week and such. It's not realistic to release a new client each week with a new key, that can easily be cracked, sniffed, stolen, obtained, given out, modified and other such things. Bandwidth costs money. As a developer for a third party client, I'm not going to pay out hundred of dollars for bandwidth for a failed DRM solution.

Even if LL decided to close the source, it wouldn't solve the problem, challenge response relies on somebody having the right keys. So as long as your handing the keys to somebody, they can use them. I don't know how to simplify it any more.

Keeping the "majority" out doesn't work either. The ones with talent often want to share the bounty of their talent and offer to everyone the compromised keys for inclusion in third party clients. It only takes one person to comprise a solution before its worthless.

The key distribution problem has already been blown off by IAm,and apparently he considers that the priority usage guidelines don't apply to him, because his cause is just and his heart is pure. And because there's no type code for "unimplementable fantasy".

Also he gets to use his own definition of "content loss"...not the one everybody else here uses: namely that something you had in inventory or rezzed in-world was actually lost. As in gone and can't be found. Not copied.

It sure is a lot of fuss over one set of sculpties that could be reproduced by feeding a $2US 3D mesh model into Blender.

Alexa registered her opinion as to the priority, and I would agree except that now that the issue has been identified as a duplicate it would seem to be eligible for closure.

"I don't like you meerkat open source theifs, this lsl-multi-gadget is disabled, no refunds, relog back in with my own personal client with a keylogger to activate it"

https://www.xstreetsl.com/modules.php?name=Marketplace&file=item&ItemID=659850

Branding Guidelines

Branded items may be listed or sold only by the brand or intellectual property owner or its authorized agents. A "branded item" is an item that: contains or uses a brand name or logo; replicates or closely imitates the appearance of a real-world physical product of a brand owner (for example, items that replicate the appearance of brands of cars, jewelry, or shoes that are available in the real world);

Zwagoth :
1) Surely a region owner should have the right to refuse access if they feel their content is at risk?
Regarding 'discrimination' : it would be a silly scripter that carelessly refuses visitors ... imagine what that would do to his traffic.

2) There's no 'weekly' update suggestion.

3) Challenge/Response could do away with sniffing issue - the algorithm in the API would return a different (matching) response for a differnt (random) challenge. The only way to get keys is if the registrar gave them out : in that case as soon as the compromise is detected a new key will be needed. Yes the registrar will need to rebuild and redistribute - but they won't be giving keys away again.

4) A compromised system will be disabled.

_____________________________________________

Maggie Darwin:

(Post revised)

Again : Try stick to the Jira - note the rules on personal attacks.

There is no 'distribution problem'. Register the viewer, link in the API to your source, build the binary. Distribute.

_____________________________________________

lordgreggreg back :

1) No-ones suggesting to close off viewer source. There is no reason to have source of a security API.

2) Lets assume for a minute that i wanted to stop "meerkat browser" on my region ... how is that a bad thing - its my region isn't it? I pay the bill every month. Surely i should have the right to decide? If there's a damaging browser in use, why should I allow it? ... just because no-one else cares about my IP? Why can I not have the right to care about it? I'm sure we are all intelligent enough to know estate owners wouldn't randomly block viewers ... else I wouldn't have traffic, right. A real-world example is my home and property - I have the right to decide who comes to visit, and what they carry onto my property - it would be a really messed up world if visitors had the right to walk into anyones homes carrying anythign and doing anything.

With regards functionality in SL to assist with IP theft, it's the same story over and over for years already - nothing gets done, and every suggestion gets shot down. Well not true ... actually the reverse gets done : "progress" means the viewer goes open-source with absolutely no regard for what will/can be written.

ATM its theft and some griefing activity, what will it be next year? Some of us invest months and years building estates and content in SL and it gets copied and griefed almost freely now.

Challenge response only works if there is a shared secret. When you distribute the client, you are handing out that shared secret, meaning anyone can use it, extract it, etc.

What keeps me from copying the algorithm that is distributed with the client? I know how to use a debugger/disassembler, it would take me maybe 5-10 minute to isolate it, pull it apart, and then maybe 40 minutes to rewrite it from scratch.

You are placing third party developers in position where they are at the mercy of any asshole who wants to compromise their key, and punishing them when it does happen. That is completely backwards to me.

The whole fundamental is flawed, and has been proven not to work on hundreds of occasions. Every networked game in existence has proven this is flawed by being pulled apart and hacks written for them..

SL is not special.

As for your vehicle, it is modeled after a real life product whose IP rights you do not own. The model may be your IP rights, yes, but you are not authorized to sell it because it is modeled after the IP of somebody else. You may contact Porsche and ask if you may sell the vehicle and only with proven authorization may you do so.

Additionally, you do not own the land you buy from Linden Labs, it is their property, it is being rented to you. This leaves them in the position to determine who has access to your land, although they have chosen to give some of those rights to you as well.

I'm not Maggie Linden. I'm Maggie Darwin. She's a different person.

And the actual source of your Porche (tm) mesh is moot, because it looks to me like you must take it down anyway until you have an authorization from Porche (tm) to use their marque or design, according to the new IP rules just published by XStreet.

Since you're such a champion of IP rights I'm sure this will happen expeditiously and without "whinging". I would expect to see the same rules applied in-world soon as a part of the new IP protection roadmap.

Congratulations, your campaign is succeeding. I hope you have an off-grid backup of your product because it would appear to be subject to possible deletion by LL. Oh, that's right...you'd never use a viewer that could do that, they are pirate tools.

If you're going to accuse me of making a personal attack, please do so in real time and not retroactively by editing a comment. Also note exactly what I have said that you consider a personal attack.

Especially given the rationale for this enhancement request, I'd say Linden Research's IP rules, guidelines and compliance with them, as well as the capabilities of various viewers in manipulating content (on-grid and off) are very much germane to the discussion.

You're missing the point. Or maybe you are not and that's why you are concerned?: A simple imbedded stringlist used as a challenge response set would be reasonably easy to break yes as it would have a predictable response, but a decent algorithm would not be, no matter how superhuman you think you are.

I'm not saying its impossible to break, just very difficult and take a lot of effort ... taking care of 90 - 95% of compromises.

As for owning land or not, a owner owns virtual rights to their land, that's more than a IP thief or griefer owns.

As for the rest stay on topic pls.

______________________________________

Maggie :

Thx for pointing out my error in confusing you with Maggie Linden - I was busy with her at the earlier thus the confusion. I edited the posts.

Content loss is when items disappear, I see nothing is this JIRA that handles items lost in the inventory or when rezzing them. Jusgt a new feature to make is possible to spy on what viewer a uses uses.

This have nothing with content loss to do. As long so called content creators keep doing actions like this.., I don't personally like to give them any money.

I'm still 100% sure this will not make your dreams come true, as proof i offer WoW and the internet.

As far as I am concerned this should be a Showstopper, but as its obviously not as important to "some people" I have put it at critical.

Can't you please come back to reality? Explain HOW spying on the user would make a sale bost? Explain HOW banning customers would help sales. Explaing how banning customers are critical to any "This is really critical information for any serious investors in SL IP."

Not so sure - a "superhuman" wouldn't winge.

But we can already see the effect this proposed feature is having : some people are already worried that when they or friends attempt to compromise this, they will be seen as "negative" influences in the community, not as "heroes" as they are today.

______________________________________

Balp Allen:
Thanks, I guess I'll have to try survive without your money then.

PS: Talk about Jira-griefing ... do not grief this Jira. Go play with your own Jira priorities. The priority descriptions are unclear as they are for bugs, not New Features. To me personally this is a showstopper, but I'm happy to leave it at Critical Feature Request as others may not see it as a show-stopper. It's certainly not Normal.

But in my view no further action in this JIRA is warranted until the submitter is himself in compliance with all Linden IP rules, including the XStreet branding guidelines as regards trademark/brand name usage and products that closely imitate the appearance of a real-world physical product of a brand owner.

E.g. if you like to fake...

Your have the LL key... Sorry but with out locking the hardware up, and in a safe box with physical untouchable guards, you can't protect it. Trying this over the internet... It's just impossible.

Sorry but thats life.

What can be done is either accept this is a social problem and apply social solutions, e.g. DMCA law suites, telling customers to only buy from the owner, As never get a Porsche form any one that can't be connected to have the rights from "Dr. Ing. h. c. F. Porsche AG"
This is a matter of custumer education not of limiting the potential customers choose of clients. This type of limits will not work anyhow, as your producta need to be taken out of your land by a customer... This customer can then someware else meet a copybot... and you still loose.

The damage of the proposed solutions old hits the wrong people.

If you like to know that I suggest you vote for the Emerald client identification program stuff to be added and scriptable.

I have see way to much abuse of the browser id in webpages to trust this info to not be changeable easy by the user.

Maggie Darwin :
Maggie, unless you are an IP lawyer, stick to things you know about - I've mentioned that to you before. If you are an IP lawyer, then you need to do some revision.

In any case, stick to the subject.

_______________________________________________________
Balp Allen:

Re your previous post :
"... Just pleas compare the levels." I did, and critical seems appropriate.

" And sure you like to spy on the user, figure out what computer he has, that to me is not a showstopper" - to me niether, but thats not what this request is about. This request is about certifying the viewers so that griefing viewers are minimized, nothing to do about PC or OS.

Just last week an open-source viewer ("Neil life") was compromised to phish for passwords and hundreds of users fell into that trap. That's the type of thing this would prevent. For that type of thing alone, this request should be "show-stopper" !

" actually I can't even see ho0w this would help you to reach your goal of protecting your copyrights."
If an estate owner (say a large corporation) invests a lot of money time and effort and builds a really cool estate for respectable users to enjoy, then by only allowing users with "approved" viewers to visit (which should be 99%) they can feel more secure that their hard work and investment will not be compromised and found all over the grid, as well as on other grids.

" Why not just make your sales limited to members of a group?"
Since when does a thief need to buy anything?!

"Explain HOW banning customers would help sales."
Firstly, the viewers kept away would be a very small minority. And will be even less once this is introduced.
Secondly, no thieves ever "buy" anything, so no business would lose any revenue by keeping illegal (copybot) viewers away.

Explaing how banning customers are critical to any "This is really critical information for any serious investors in SL IP."
Explained above.

__________
Newer posts :
"IAm some basic faults in you idea, The client have to know the developers key for your idea to work. "
Thats not neccessary. Please read the thread - just need to skip over all the garbage from people trying to take it off-topic. LL could issue the 'registered' clients with a compiled API which already has the security algorithms built in - that way there is no 'key' to compromise. As an extra level a 'coding' key can also be issued yes - this would make it easier for when/if there is a compromise - just a new key is sent to the registered client maker.

DMCA does not work. Users making copies are creating free alt accounts and cannot be traced. Additionally for most content-makers it would be too expensive.
Also, if you make a new fantastic product and its stolen, the grid is so big you are unlikely to ever see it to file DMCA's.

Further, when someone steals IP, they resell it and make profit. Eventually innocent users are buying the stolen IP without knowledge its stolen, and many even reselling it, as its now often full-perm and devalued.

The problem needs to be stopped at the source, not the destination.

"This type of limits will not work anyhow, as your producta need to be taken out of your land by a customer"
This is not always true - many builds (eg architecture) do not move from their region.

" This doesn't help that. It only makes is possible for EVERYONE to spy on what viewer the user have"
Why does that matter? If the viewer is a good non-griefing viewer its np. Thats only a concern for people making viewers with griefing functions in.

"I suggest you vote for the Emerald client identification program stuff to be added and scriptable"
Anyone can trick that ... superhuman Zwagoth will do it in 5 seconds

I'd close it as duplicate except clearly the submitter would simply open it again, speaking of "JIRA-greifing".

Having asserted that this misfeature is so necessary to protect in-world IP, you can't then rule that IP rule compliance is off topic in the discussion. The rules apply to everybody.

Track the one you prefer.

Your claim is that this crypto CRM feature is necessary to protect in-world IP. In my view IP rules compliance (including your own) is therefore very much on-topic.

By not marking this issue resolved/duplicate and moving to VWR-14778, you're fragmenting the discussion of in-world IP protection. It's a recognized practice in pJIRA to move all discussion relevant to a topic into as few issues as possible. This is linked as duplicate (not by me!) and should be marked resolved.

In any case. so far I see no interest here from anybody capable of implementing this particular misfeature (I certainly don't think you're going to get much help from Zwagoth at this point. ), and you won't offer a proof-of-concept implementation of your own, despite your unsupported assertions that it is feasible, productive and not burdensome. I disagree on all three points, and hear substantial agreement from the other participants in the discussion.

Re your previous post :
>>> "... Just pleas compare the levels." I did, and critical seems appropriate.

It looks like all, or most, others disagree... Well the guys at LL are smart enought to ignore thsi kind of shit anyhow,

>>> " And sure you like to spy on the user, figure out what computer he has, that to me is not a showstopper" - to me niether, but thats not what this request is about. This request is about certifying the viewers so that griefing viewers are minimized, nothing to do about PC or OS.

1) Thats not what you stated...
2) Greifing viewers, this must be a minimal problem i never seen any griefing viewer.
3) It doesn't as suggested say anything about what you like to do, Make sure a copybot can't get into your store, This can't be done this way.

>>> Just last week an open-source viewer ("Neil life") was compromised to phish for passwords and hundreds of users fell into that trap. That's the type of thing this would prevent. For that type of thing alone, this request should be "show-stopper" !

It could not and would not have stopped that, it would not even made it possible for SL to see that this happend. Sadly the only thing that could help this is USER resposibility, USER eduication, As long you can download and install a program... This can happen, With out that possibility a computer would been a tv-game only. I'm not willing to offer my free choosie if i like to install second life at all and have Asus or Dell make that desition for me.

>>> " actually I can't even see ho0w this would help you to reach your goal of protecting your copyrights."
If an estate owner (say a large corporation) invests a lot of money time and effort and builds a really cool estate for respectable users to enjoy, then by only allowing users with "approved" viewers to visit (which should be 99%) they can feel more secure that their hard work and investment will not be compromised and found all over the grid, as well as on other grids.

They maybe can feel more secure, but it's really like pissing in your pants to keep you form freezing, feels good a little until you realize, they you are both colder and now smell as well. The copybot will never compy to the rules, if don't have to and in many, maybe most cases are not part of the viewer. OpenGL drivers have what i seen beeen the biggest copybots. Then comes programs reading the cache. If you feel more secure, fine, but in reality you isn't any safer. Not a small single bit of safer.... I'm sorry but thats a fact, can you get it into your head now please.

>>> " Why not just make your sales limited to members of a group?"
Since when does a thief need to buy anything?!

Most illegal copies are probably made from legal copies, the almost mythical big copy stuff, would not bother to follow the laws to identify them selfs correct anyhow. This is big difference between stealing and copying, and as long one thing and take copying as stealing. You will apply the forces on the wrong problem. This is still no solutions to stop or lower copying, i have seen no suggestions it would help in that, it olny give out more information about the user.

>>> "Explain HOW banning customers would help sales."
Firstly, the viewers kept away would be a very small minority. And will be even less once this is introduced.
Secondly, no thieves ever "buy" anything, so no business would lose any revenue by keeping illegal (copybot) viewers away.

So banning a minoriry helps sales? Banning a minority in RL is called discrimiations and at least where i live is illegal with good reasons. Copybots will not send the correct answer on these questions anyhow. So they not be stopped.

>>> Explaing how banning customers are critical to any "This is really critical information for any serious investors in SL IP."
Explained above.

No, You only explained you are paranoid.... And don't care about trademark laws...

This is not only about IP, its about many things: viewers enhanced for griefing attacks, phishing, identity theft etc

Re VWR-14778 : Thanks, this this request is LINKED to VWR-14778, its not a duplicate, it's similar, not the same. That's the reason there is a link facility - to link similar (related) items. I do appreciate you'd like it closed asap, but as I suggested in the prev post - if you just remove yourself from the watchers list on this and keep watching VWR-14778 then you will be ok.

You've tried to derail this request, it hasn't worked, move on.

I have achieved what I set out to achieve with you anyway - your initial "this is not possible to do" opinion you have changed to it being not "feasible, productive" and "burdensome". Thats fine, and is typical opinion of people opposing some feature. Glad to have helped you along.

Have a nice day.

__________________________________________________
Balp Allen :

"It looks like all, or most, others disagree... Well the guys at LL are smart enought to ignore thsi kind of shit anyhow,"
By others you mean 'opposers'. Naturally they'd all disagree. Did you notice how many people disagreed when LL introduced seperate "adult" sims etc? This is normal.
You may be right about LL ignoring requests on security though.
It is a "critical" Enhancement request. Not sure you should view it as a bug, but you can if you like.

"Greifing viewers, this must be a minimal problem i never seen any griefing viewer."
Thats not true - in the same post you replied about "Neil life" exploited viewer last week - thats a griefing viewer.
Further, just because there is a minimal number of them used, doesn't mean its a "minimal problem" - it a "serious problem" and getting worse each day as coders try write something worse than the guy before.

"It could not and would not have stopped that"
Yes it would ... the reason this viewer spread so easily because there is no control over these viewers and people are naive. As soon as something like this is implemented, 99% of users will only download 'certified' viewers.

"So banning a minoriry helps sales? Banning a minority in RL is called discrimiations and at least where i live is illegal with good reasons. Copybots will not send the correct answer on these questions anyhow. So they not be stopped."
Well i don't know where you live, but in most normal societies thiefs and troublemakers are 'banned' or jailed. For example a good citizen is allowed on my property, but a thief or troublemaker not. I want that same ability in SL. How do I know a person is a troublemaker? Well I don't - but based on some criteria I make a descision that they are 'undesirable' (suspect) people to have on my property, so I can keep them off. So if you want to accuse me of discriminating for keeping suspect people off my property, good luck to you - but I certainly will keep doing it.

"No, You only explained you are paranoid.... "
Paranoid about griefing, phishing, theft in SL - most definitely yes.
This is a personal comment, but as you brought it up, why are you so paranoid about identifying the viewer you use? Why is that such an issue? Its just the type of viewer after all, nothing about your personal details. People that are paranoid about that likely have a reason to be. Most likely even if you use a "non-certified" viewer (identified as a "Unknown" viewer) you will be ok to use that and play with it on your property and probably a large aprt of SL anyway - as many owners won't mind - but the point is, that's their choice.

VWR-14778 Protecting user information and content provider IP"

I said it was not possible to do. That includes feasibilty, with reasonable levels of security, and at a acceptable cost to the SL viewer community and infrastructure, as well as to the general user population.

If you claim otherwise, please provide a proof of concept for further discussion in the framework of the main issue, so the viewer development community can evaluate your proposal.

VWR-14778 Protecting user information and content provider IP

You don't see me posting garbage on your Jira's or closing them do you?

It only move a small peace of volutair information form the client to other client, e.g. People who like to say they have unknown viewer will be know to have unknown viewers.The day this starts to get used to ban anyone, That appenenly is the goal. Pepple will start lieing about this. The first that starts to lie is the once you hope to stop. So it will add discrimiation, against people that are not trusted, like people that like to run 64 bit binaries on 64 bit OS:es. With the goal of... mmmm nothing....

The trouble is this doesn't indentify thiefs and troube makers, Thiefs and trouble makers are banned form Second life using an AR. Yes there is a well defined and at many times working solution. Maybe the process need a little proof of the thief really being a thief, but i think that a pretty good start assume people are innocent until proven guilty. Thats is if you don't mine the other way around fr DCMA where you have to counter the accusation or considers guilty.

No this would not have stopped the fooling rtying to get people download an fake client, The massage wouls have been changed to insteand of a unknown small viewer been targeting an approved viewer. Poeple would stil have downloaded and got there passwords stolen. As long THE USERS don't learn to verify the source of the downlaod THEY will her malware and trojans installed. The keyboards sniffer next time stealing the stuff while you login using a unchanged certified viewer can't even start to be protected against this way. Beliving that IS know nothing about computer security.

But ths will not stop the greifers viewer form connecting.. It wil not stop him from getting to your sim, you stil have to use the tools and ban the griefing avatar... Sorry, your idea with cryptograpic signature even been tried in SL if DIDN'T stop other viewer from identifying as the offical viewer... Sorry even if it sound cool to know what software i run YOU CAN*T EVER KNOW... I can always fake that.... You can't even knw what computer I'm on.... Sorry thats just plain facts...

It will not be possible to lie about the client, and 64 bit clients are no problem, niether are 32 bit or anythng else - thats irrelevant. Makers of clients just need to register their client with LL and noone cares if its 32 bit or 64, or if they don't want to, thats no problem - then they can still do as they like, with a few restrictions on the grid.

"Thiefs and trouble makers are banned form Second life using an AR."
Please think about what you are writing - this is absolutely nonsense. It has never worked, and cannot work.

"keyboards sniffers" have nothing to do with this - not neccessary to discuss them here. This will help to reduce keyboard "phishing" written into a client - which at the moment are very easy to add to the open-source client. You may be right, someone may crack this and release a 'bad' client 'posing' as a certified client, but it'll be a hell of a hard job for them to crack - so only very few will get it right. And when they do it, it will only work for a while - till it is found out and the client can be classified "unknown" - and possibly if wanted a screen-pop can alert the user using it. At the moment there is no way to stop that phishing client or alert people using it.

"Sorry, your idea with cryptograpic signature even been tried in SL if DIDN'T stop other viewer from identifying as the offical viewer."
My idea has never been tried. If you are talking about the Emerald viewer identifier - that is certainly not secure and should be easy to fool. Thats totally different.

"You can't even knw what computer I'm on"
For the last time, I don't want to know what computer you are on, this is not about your PC, or your ID, or your name, or age, or drivers licence, or dogs name. This is ONLY about identifying your client software used to connect to SL. Fullstop.

>>> "Yes it is a critical feature. It was a requirement that should have been dealt with BEFORE the client went open-source."

FYI, The copy bot came BEFORE the viewer was open sourced, if used exact 0 lines of code form the viewer. This proposal can not stop the copybot, the copybot is not based on the viewer code, the copybot HAVE nothing to do with open source. It was created when SL was closed source. Now stop the FUD, please.

>> Please think about what you are writing - this is absolutely nonsense. It has never worked, and cannot work

Sorry, but arresting and using legal actions against criminals is the only think that had any kind of effect, placing a fence as you suggest don't make any security unless there is a law and a juridical system that can put the criminal away. That this not worked is absolutely nonsense, that any kind of technical solutions ever works is absolutely nonsense.

>>> "keyboards sniffers" have nothing to do with this - not neccessary to discuss them here.
It have everything to do as you take up securing the user from what she downloaded and installs on there computer. as defence for this idea. Making a trojan with added keylogger are probability the most common way of installing shit to steal information about a computer. Even with an open source client this still is the EASIEST way for the cyber criminal to attack. Knowing and trusting who you download from IS vital for any computer security. Your poposal have nothing to do with verifying the download, it happens WAY to late when the victims computer already is taken over by the attacker and all you see and hear form the computer already have been faked by the criminal. Sorry trojan have to be stopped before that can execute ANY come on the computer, not when the sent fake info over the internet already.

Also how does this stop the client from reading the Username and password sending that to an other location instead of sending to second life? You like to see trivial attack scenario that are much much easier to make that changing a third party viewer and with your protection still steal the users password with out your protection doing anything, using an unmodified binary from Linden Labs? Sorry but this will in NO way protect the people downloading a trojan, sorry your dreams are just blue dreams and have nothing to do with real life, or second life for that matter.

>>> My idea has never been tried. If you are talking about the Emerald viewer identifier - that is certainly not secure and should be easy to fool. Thats totally different.

It not the emeral in code, that was never intended to do anything like that... Why because the emerald developers know it's impossible and would never try to solve an impossible task. The official viewer used a hidden md5 sum to verify the client. This was cracked and replicated long before the viewer was open sourced.

>>> For the last time, I don't want to know what computer you are on .... This is ONLY about identifying your client software used to connect to SL

The client i use to connect tells what computer i have... As all clients in all version don't exists on all computers. Spo why do you like to known, do you really think it will stop content copying? Do you really thin k it will lower content copying. Do you really think the people breaking TOS to copy your stuff will follow TOS to identify correct? So the only info you get is the few that for some reason can't use the offical viewers, you can single these out and call then thiefs. And yes i care when people point at a minority and call them all thiefs, like been done to gypsies, in rl. I think thats is the LOWEST for of hypnotism, or for that matter calling people terrorist because that believe that a guy called mummed also got messaged form the same strange force, god as Jesus. For god sake Jews, Christians and Muslims all believe in the same fucking god.

But if you really belive this is possible to do, adding the code to the viewer is possible just start hacking... You have the viewer code and opensim. I argue the feature is impossible to archive, and as such i can't see it's critical or even wanted. What you can archive in the browser identification line from http, e.g. the web. That is every user can change it them selfs if they like.

>>> 3) Challenge/Response could do away with sniffing issue - the algorithm in the API would return a different (matching) response for a differnt (random) challenge. The only way to get keys is if the registrar gave them out : in that case as soon as the compromise is detected a new key will be needed. Yes the registrar will need to rebuild and redistribute - but they won't be giving keys away again.

You have not explained this logical super leap and miss form your side.

For the client to be able to answer a random questions it need's the keys....

If the client needs the keys.... It have to be handles out to the user...

So the developer have to give his keys to the user.....

So the user can use these keys to make correct answers for an other client....

So the developer need to get a new key as the user have it....

And i will not give keys out again, e.g. the user can't have the developer keys on there computer.....

The user can't answer the random challenge any more and can't get verified in the new build.....

Didn't we loose something in the process during the way...

How to you both give the key out and keep if? hidden?

You are swamping this thread with nonsense too ... I am happy to answer you but please keep drama and personal comments out of it. Keep to the basics and the topic.

"IAm, Sorry but given form your arguing i can't make any other conclusions you know nothing about computer security."

Comments like this do not belong here. It should not be necessary for me to reveal who or what I am on a Jira to 'defend' my post - you are the one paranoid about people knowing any of your personal details, why do you attack mine? You can be assured I am pretty highly regarded IT consultant, and likely have been for longer than most of younger generation are aged.

Actually, reading through your replies I can see that you do not understand what I have suggested. Every time you post something, you post about something which is irrelevant but "similar" in some regard.

Did you even read what I suggested?

I really suggest that you try clear your mind of whatever personal-eating monsters you have dreamed up, then CAREFULLY re-read all from the top so you get a better understanding of what it is or how it works. I don't want to say that you seem unqualified to understand it (as you have done), because I don't believe that's the case - I believe you are just missing understanding it, and you are assuming too many things - or making them up as you go. Or seeing ghosts that do not exist. And please quit throwing in the kitchen-sink - dramatizing about non related issues .. .this won't stop keylogger or d/l trojan attacks etc ... of course it won't - don't be silly.

I will answer some of your other comments :
"FYI, The copy bot came BEFORE the viewer was open sourced"
I know when copybot came out and am aware what libsl is etc. I only use the term "copybot" as many ppl recognize that term, wheres simple copying technology written into opensource clients has no 'terminology'.

However : libSL was LL's initial attempt at opening up the browser, so it is related to this issue. While it opened some useful avenues (a few useful bots), it opened more unuseful ones (traffic + camping bots - means valid users cannot connect on weekends etc, copybot, etc). One would have thought with that bad experience, they would have thought about these things BEFORE going opensource, instead we sit with another new mess today.

"Sorry, but arresting and using legal actions against criminals is the only think that had any kind of effect, placing a fence as you suggest don't make any security unless there is a law and a juridical system that can put the criminal away. "
As I said, AR's and DMCA's are nonsense and really ARE the fence. Its a fence LL uses to say they have a mechanism for dealing with these issues, but in reality it is pretty useless.

" Even with an open source client this still is the EASIEST way for the cyber criminal to attack"
Nonsense. With an open-source client it is MUCH easier to steal a users data from the compiled open-source client than by writing an external keyboard sniffer and trying to get them to download and use that. Thats pretty obvious.

"Knowing and trusting who you download from IS vital for any computer security."

• Exactly. And at the moment there is NO way for users to know XYZViewer is ok to download. Once there is some registration, there will be some way of knowing, ie. XYZViewer appears on a LL list of 'regsitered viewers', with a link to the correct download page.
• Further, if it is desired (NOTE - I am not saying it must be done so please don't get paranoid again), a messagebox can be built into the API to alert a user when they login that it is a 'Unknown' client, and if the user is worried about security then can change their password right away.

"Also how does this stop the client from reading the Username and password sending that to an other location instead of sending to second life"
Obviously you cannot stop that, but messagebox like above will allow user to change password fast enough in most cases. Today there is zip.

"Sorry but this will in NO way protect the people downloading a trojan"
Well, obviously I am not suggesting a world-wide solution to every trojan and virus on the internet ! Maybe you are mistaking that. Of course there will always be ways of getting users to download trojans etc ... this is life, live with it. But it doesn't mean LL should sit on their butts crying and saying they can do nothing! Get up and do something about it, try. Obviously one cannot solve all - we all know that. So you can stop dramatising that too. And I wrote that from the beginning ... that it can solve the majority, but there always will be those that work hard enough and break it.

Its the same in RL ... if I leave my doors open (this is how opensource is now), anyone can walk into my home. If I close doors, most will not but a few will break windows (these are criminals). I can then put burglar bars on the windows and security system - now most 'common' criminals will not get in, but there is always be the experts - maybe 5% of the criminals, that will still get in. Thats life.

As a matter of interest ... do you close your door at home? Do you lock it? If so why? On the other hand, if you do or don't - thats your business, but please don't expect me to leave mine open, and don't try force me, and when i want to lock my doors don't tell me thats wrong! At least give me the option.

"The official viewer used a hidden md5 sum to verify the client. This was cracked and replicated long before the viewer was open sourced."
The mere fact that you mention this as a similar system to my suggestion shows how little you understand about this proposal. Please go review it all before more drama.

"do you really think it will stop content copying?"
No

" Do you really thin k it will lower content copying."
Yes, dramatically. But more importantly general griefing, phishing attacks, etc

"So the only info you get is the few that for some reason can't use the offical viewers"
Why can they not use official viewers? You think you are the only one using 64 bit, or linux etc?
And no, we should get info from all viewers ... so you are using ABC viewer, Joe is using XYZ viewer etc.

"you can single these out and call then thiefs"
I never called them "thieves" - they are "unknown" viewers.

I suggest you leave religion and RL politics TOTALLY out of your posts here.

Thanks for the offer for me to do it, however I have raised an enhancement request for LL to patch their security flaw on THEIR system. If I was a paid part of their R&D team I would not have raised this Jira request, but would have discussed it internally and worked on the project, but I'm not.

____________________________________________________________
Re (3) :
"You have not explained this logical super leap and miss form your side."

The leap and miss is from your side.
Do you know what a compiled API is?
Why would the developer 'give' his keys to the user? That's silly. Why can he not compile and encrypt it into his build where he calls the API login function? Or alternatively a unique pre-keyed API is sent to the developer when he registers.

If the user should in any answer a random challenge form the server, it need an unique key, you suggested this key identified the build not the user e.g. the developers key. So this key have to reside on the users computer. Else the user can't generate the answer. E.g. The developer need to send his key, or some thing derivide form the key to the user, The developer can then not guarantee that the user not changed the software. That the response given by the is done with his unchanged software.

Public key's schemas can do two things, encrypt a session, or verify that something comes from a know user, signing.
You suggest a scheme where with out the secret key someone verifies that are someone. The suggestions breaks the possibilities in cryptography.

The only thing that is possible to do is to give Each user and viewer a personal signing key and revoke this key when the user breaks the rules of SL.
But this is the same as disabligt the accounts of the offending criminals. So all this crypto stuff doesn't add anything.

Now back to this Jira, it states:

"""I have seen a few similar request, which have been closed and comments are that it cannot be done, etc.
However it must be possible to set a flag upon login to store how the login was made, whether its the SL client, a
licensed client (and which), a no-brand open source client, libSL client, unknown, etc.
This is really critical information for any serious investors in SL IP.
"""

You then come and keep repeting it most be possible, I and most others argue it's NOT possible, we base this on crypto therories. You keep staying it's locking the door, and it's not locking the door, Coputer security are totally different from real world security. The threats and physical limitations are totally different. You say make hader, it's been proved in libsecondlife, or libomv, as it's called now, is a proof of that, it was developed by reverse engineer the protocol. In all big parts with out any help of the lindens.

There are cryptographic only two possible scenarios, The user can identify what software they download and not install anything that they don't trust. Developer keys, these key have to keep secret form the user.

The User identify to second life who they are, user keys, these keys have to keeped secret by the user.

Your argument mixes these two keys schemes. You argue the exat same way as Angela Talamasca, in the duplicate JIRA,

ready this part again, it's your "claim"

"""Depending on how it should be managed by LL the parameter would be populated either by an encrypted API returning a 'hopping' key ( which would need a decoder on the server-side - only runs once on login and can run asynchronous ), or a simpler method is a unique 'key' (like uuid) would be sent to a registrant by LL, to only be used when the registrant compiles the final binary of their client (ie. they are certifying their client is 'clean') - they are not to publish the keys to others. The key would match the registered client name on a LL lookup table, eg 'abc viewer'.

Should the 3-rd party's key be compromised, LL would just disable it, so clients would again be 'unknown' on login till the 3rd party recompiles with a fresh key : this will deter registrants spreading their key."""

Where do you suggest this code runs? At the users computer, then doen't you have to send this key, and code to the user? E.g. you can't secure the key from the user.

When it comes to protecting the user, when LL can do., is something you not suggested here, sign developers keys, and start using there own, so the user can verify that they got something form a registered developer. I'm not sure this politics, e.g. certifying some developer are good people is an way LL will like to go. They can't however verify the software running on the client computer the only think that can do is give the user a choose to see it LL have had complaints about the software. I don't think this will stop the trouble or lower it. Signed applications on Windows have not worked, It's still the most common place for trojans. The evil guy here don't even have to care about what LL says about the viewer, in your suggestion when the message reaches the user it's to late.

You add a cumbersome work process, some big words and content creators feeling falsely secure, for checking something that not will give that anything.

As you like first life comparisons, your suggestions is like taking the wheelchair ramp away, telling if you can check the ramp isn't there you will be protected.

The scheme you suggest with a api and "message" box, are trivial to work around, They why then can't work, they can't do what you dream they should do, it's no locked door, it nothing like this. Siging developer keys giving the user an added level of thrust and verifications is not what you suggested. The key have to be something the user can verify BEFORE starting the application, it have to be cryptographic secure, two exampleare are signed binaries in windows, and gnupg/pgp signatures on the binaries. To have LL sign keys of people that signed a contribute notice, sure great, but it's far form this JIRA and doesn't take you anyware closer to knowing if Joe User, us using Me Developers, or Evil Hackers software. We can only give the user more info about if to choose Me Developers code or Evil Hackers, in having LL say WE know That Is Balp Allen... No one complained about his shit , yet....

Read your comment to LGG again...

Either your memory is bad or you lie...

If you have listings or content that do not comply [with branding guidelines], please modify or remove your listings and content, including content in Second Life associated with the listings, to bring them into compliance by no later than Monday, September 14, 2009. If you remove a featured listing to bring it into compliance on or before September 14, 2009, you will receive a pro-rated refund for the time remaining on the listing. After September 14, Linden Lab may remove listings and content that do not comply with the Xstreet SL Listing Guidelines, and no refunds will be issued...

You're seem to be assuming there is a key passed around that can be stolen, this is not necessary and is not what I suggested as that would not be a good solution.

____________________________________________________________________

Maggie: You can't be tired:
(1) you're still on the watch list
(2) you're still reading and posting

As for interest falling off, that won't happen, no matter what changes do/don't need to be made - I and others create tons of content in SL not just one item. I'm not going to discuss any of my content on this forum though, as it's not relevant , nor is it just about me, nor just about content - security in SL is needed for millions of users, and been asked for years (and promised but not delivered after the mess of copybot). I'd not assume too much if I were you though.

On the other hand anyone who raises and ferociously defends a Jira about posters spelling errors is bound to continually post garbage on this and other requests!!! (MISC-1802 : Nobody on PJIRA knows the difference between affect and effect)

On misc-3134 Phoenix Linden posted :
"We do not, and cannot provide any guarantees of the quality and security of third party viewers. If another party installs third party software, they are implicitly completely trusting that third party - regardless of if it is our viewer or a share-ware image viewer.
If any particular third party client distributor is making false linden trademark claims or violating the GPL we can take direct action."

That does not apply here. This request is not for LL to "provide any guarantees of the quality and security of third party viewers". This request is to add functionality to make available to SL (LSL) information about which viewers are connecting. This request does not make LL responsible for any 3rd party viewer at all, in fact it helps distance LL from that reponsibility by giving some details vs the current total transparency.

It's clear to me that

1) you believe this is feasible

2) you believe it is necessary

3) you believe it is desirable

4) you lack either the background or the motivation to actually implement it yourself as a proof of concept

3) is a value judgement and we clearly have different values.

So, given all that, there's no point in my continuing to address your moving-target arguments to convince you otherwise. But just in case anybody posts here in support of this issue, I'll continue to monitor it, even though I think the chances you'll find somebody to write it for you are negligible.

Life's going to be interesting, especially with the future mesh capabilities rolled out at SLCC 09. Given that I, understand completely why the administrative protections relying on IP law are being strengthened both on XStreet and on the grid, because any crypto-based DRM is bound to be ineffective, and to inflict collateral damage as such things always do.

1) Licensed clients, thats is just what Phoenix write about, it was a JIRA request just to licence clients.

2) Y9ou have many time talked about LL licensing clients, even using crypto keys to secure this, can we agree on this is not possible?

3) Could you then with out jumping over any step explain HOW the users should be able to transfer a proof of using a "licensed" client to the servers.

As you don't seams to be familiar wirth how this works in software, maybe a i should give a RL example.

Locking a door, to keep a place closed, you like someone to come in so you have to give him a key, you say only use when not carrying a camera.
Not the person come in and out as he likes, one day he desides he like a camera and continues to walk in and out. The key have no possibility to check whan the user also have on him self. You said, ok, let the key have a detector in it self, beeping if there is a camera close, the problem is the user can put the camare into a box so the key will not be seen, we can't even guess how the camera looks. The detectors can only operate by the user copnneting a wite fropm the camera to the key.

Your suggestions is that in lsl you can see the channel of the viewer, andin additions you suggested that if the channel is unkown a popup to warn the user. You make some starge assumtions that the suer be protected and this info be "This is really critical information for any serious investors in SL IP."

I say your idea is a bigger stem than quantum cryptography, or maybe it can be solved using that.