Talk:Viewer Authentication Critique

Process for editing the critique

By virtue of jumping first, I think Matthew Dowd should be the working group chair for editing this document. What I think that means is this:

• Anyone can still make no-brainer edits to the article
• Matthew will be arbiter for dispute resolution, should that be necessary.
• If there are points that Matthew is unclear about, he should delete them from the document, and move them to the talk page.
• If there are points that others are unclear about, they should bring them up on the talk page, and then later delete them from the main page if a question/concern goes unanswered on the talk page (with "see talk page" in the comment of the edit).
• If, for whatever reason, it becomes necessary to fork this document, it's best to move all critiques into the user space of the working group chair. So, for example, Matthew's version would move to User:Matthew Dowd/Viewer Authentication Critique, and other critiques could also be done the same way. This page would become a list of critiques.

Sound like a reasonable process? I think this is lightweight enough that a pretty good document can evolve pretty quickly. -- Rob Linden 12:56, 29 September 2007 (PDT)

Third party viewers/code

What's the substantive difference between these two points?

1. Viewer still involves running trusted code on the computer and could initiate other attacks e.g.
2. Most of these attacks could be performed by any third-party software designed for use with SL

Both have many subpoints. Could they be consolidated into a single point? -- Rob Linden 20:10, 29 September 2007 (PDT)

The first point is that keeping the client from seeing the password doesn't remove the danger of a modified client.

The second point is that *any* ancillary software (such as animation editors, sculpt editors, sculpt texture plugins) could be used in an attack, even if they don't actually connect to SL, since they would be used by SL residents.

-- Argent Stonecutter 21:00, 29 September 2007 (PDT)

Is this better, Rob? -- Argent Stonecutter 21:11, 29 September 2007 (PDT)

Yes, that is. Thanks for the clarification! -- Rob Linden 21:44, 29 September 2007 (PDT)

No balance

This article is pretty awful, its just an attack. For real critique you have to explore the alternatives and discuss the pros and cons for each. Even if this form of log in has these disadvantages it could still be an improvement over what we currently have. We need a common point of reference to discuss if this is an improvement and what alternatives exist.

• I've tried to keep it balanced by seperating it into the three concerns, having Pros and Cons (these are really for the approach rather than the concerns), and a list of alternative options (although this is more of a jumping off point for further discussions of the alternatives than a considered response at this stage). It is somewhat negative, as to be honest, all the responses on the SLDev list were against the proposal. It does need some input now from LL - to check the objectives are correct, and perhaps indicate what they think the pros are! --Matthew Dowd 02:13, 30 September 2007 (PDT)

Having studied the original idea, each time and deeper I'm now convinced there is 0 gain on the security point, I also see many many big security risks with it. I hope this will be the first issue in the last time that actually the Lindens start to listen to criticism about the proposal. I think not there have so far been one mail in favor of the idea on the developer list. All the other issues that just ignores the users, to that extent that i have put off all investment in SL. The day an alternative comes out, Lindens and in really danger for how they handle there users. So far they have a product that is one of a kind. But the completion gain all the time. The company that did everything they could to screw there user base will loose. --Balp Allen 01:44, 30 September 2007 (PDT)

In my humble opinion, this is a mistake. To get rid of bots it is brilliant. Make life a whole lot more complex. But for security of going on a fishing expedition it will be a matter of time before some kindly soul sets up an alternative web page where you can log on to SecondLife sending the correct code to SL's web servers and maybe keeping it. Keep the trust in the client fix the code to being more robust. SecondLife is ment to be leading the way not following. Offer a validation service of 3rd party clients to ensure that we are safe. People are going to want to see the LL Seal of approval.

As also pointed out in your own con's the coders could as easily have key capture and other nastyness running. So this solution makes it harder on those who do not run web and SL client at same time. More hassle on the user end. Start up Web Client Go to page. enter in info. --Jamie David 07:42, 30 September 2007 (PDT)