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.

Anti-fraud measures!

It appears there is a greater desire to find anti-fraud measures than to just stop phishing attack by malicious code. Of course, both are of interest, but it appears the anti-fraud bit was stated weakly when in fact it the stronger point. I suspect a major miscommunication occurred here. The viewer itself was addressed by LL rather than augmented security for anti-fraud. I'm under the assumption that LL is not able to release some details to the public at this time, so we get bits and pieces of more minor points rather than the major points with priority.

The article mentions anti-fraud as an objective, but the criticisms are mainly focused on anti-phishing.

In fact, there is mention that anti-fraud is the priority! [1]

Also, we can see the light of this from Robin Linden as pasted below.

I believe the critique needs to address the issue of anti-fraud more significantly. That is to allow such measures even if the anti-phishing has been addressed more (actually too much).

We need to help LL solve fraud in the many forms it appears besides just the login!

http://slrecord.typepad.com/the_second_life_record/2007/10/vat-attack.html

[11:16]  Jessica Holyoke: I have a question, when you stated that the ebay sellers of lindens were engaged in fraud,were they reported to law enforcement?
[11:16]  Robin Linden: Not all eBay sellers of Lindens are engaged in fraud.
[11:18]  Jessica Holyoke: but the one's that you said were engaged in fraud and took action against their accounts(sorry about the lag)
[11:19]  Robin Linden: For the most part jessica people who engage in fraud have been tough to catch. We rarely know who they are in RL.

---

There's really not a lot that software design can do to prevent social-engineering frauds, and it's not really the software's responsibility. The best you can do is inform and educate those who stay alert to communication, and hope word of mouth ripples out...even if that's in the form of urban legend hysteria, people will be more careful about what they exchange and who they exchange with.

Prodigal Maeterlinck 13:07, 6 December 2007 (PST)