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. Ahab Schmo 12:31, 30 September 2007 (PDT)

Nicholaz's Summary to SLDev

I think (and would be surprised otherwise) there currently consensus among those who replied here on the list that ...

1) the new auth mechanism does nothing to significantly increase security in terms of protecting user assets from malicious viewers (once the viewer is logged in, you're at the mercy of the viewer, no matter how> you logged in)

2) the new auth mechanism makes login to SL cumbersome and breaks many ways in which people are currently using SL (alts, switching between viewers, etc.)

3) the new auth mechanism will make it impossible for some environment to log in from at all (proxies, firewalls, security software, ...) or prevent specific forms of viewers (lean viewers, mobile systems, viewer on a memory stick, ...)

4) the new auth mechanism will break existing applications (bots, libsl, etc.) and these will have to work around these.

5) Allowing these (4) to work around it, means that 3rd party viewers can also work around it, meaning that you'll end up with 3rd party viewers which are a lot more convenient than the official viewer, essentially> driving people away from the official viewer.

6) other mechanisms exist, which a) actually increase security and which b) do not break existing use and c) are less cumbersome

7) (this is my personal addition but I'd be amazed if anyone disagreed) people are losing a lot more assets and value through Linden malfunctions (lost inventory, search & classifieds being not seen because of outages, etc.) than have ever been lost through spoofing or malicious viewers.

8) __whatever mechanism is implemented, should be a *choice* with the__ __existing mechanisms remaining in place__

9) (see (8) )

10) (see (9) )

Bottom line is that the new auth mechanism is something that offers neglectible improvement in security and will cause countless problems or developer hours on both sides.