[sldev] [Upcoming Changes] Website Viewer Authentication -Suggested Reboot

[Nik Radford]

This idea makes me cringe too.

I can see 90% of the SL userbase is going to hate this. I'm going to hate 
this. Most people here seem to hate it.

Many concerns have already been raised so I won't re-list them.

So as Matt says,

this needs a radical re-thinking.

nik

----- Original Message ----- 
From: "Matthew Dowd" <matthew.dowd at hotmail.co.uk>
To: "Donovan Linden" <donovan at lindenlab.com>; "Second Life Developer Mailing 
List" <sldev at lists.secondlife.com>
Sent: Saturday, September 29, 2007 9:48 AM
Subject: RE: [sldev] [Upcoming Changes] Website Viewer 
Authentication -Suggested Reboot



Can we go back to basics and determine what the use case/rationale for this 
change is?

My first gut reaction was that this approach seemed unnecessary clunky and 
seemed to have more issues than it solves.

Working through the posts I can see a lot of issues being raised:

i) ability to run simultaneous clients (a must for content creation, and I'd 
never have been able to test the "Group Invite" pie menu feature in 1.18.3 
without running two accounts simultaneously)
ii) ability to install multiple clients on the same machine (I think people 
here will typically have the main client, the test client, the beta client 
and their own compiled client for example).
iii) breaks use cases in development in the architecture discussion
iv) places too much dependency on a feature often disabled by browsers as a 
security risk (and on particular browser implementations)
v) HTTP proxy issues

The reasons being given at the moment are:

Security:
but as has been pointed out, if you do download and run a malicious client, 
loss of the password will be the least of your issues given what it could 
potentially do. As has been pointed out, promoting this mechanism as more 
secure could lead to a false sense of security with people being less wary 
of third party clients - "the new system means its perfectly safe" - but to 
their detriment (IDV has a similar issue in how it is being promoted). This 
is a laudable objective but not really met by the proposed solution.

Flexibility:
Implementing support for OpenID would give this flexibility and I believe 
could be implemented in a different method. This is a laudable objective but 
could be handled in a different way.

Persistence:
Has anyone asked for this? For those with a single account, you can already 
save you username and password in the viewer, and your 
website/account/forums logon persists through cookies. Those with multiple 
accounts will actually find the persistence a pain. At the moment I can 
remain logged into the forums with my main account, whilst testing something 
via my alt. The last thing I want is to start accidently posting to the 
forums with the wrong account because I've just logged on to test something 
with an alt! (I suspect you'll find as many people who would prefer the 
forum and account logons to be seperate as those who would want the proposed 
persistence).

So to summarise, I think this needs to be radically rethought! As I see it 
the two objectives are

security for third party browsers - possible solution provide server side 
sandboxing (although this has implications further down the line when/if the 
grid opens up)
flexibility - lets start a discussion on ways of implementing OpenID

Matthew
_________________________________________________________________
Celeb spotting – Play CelebMashup and win cool prizes
https://www.celebmashup.com_______________________________________________
Click here to unsubscribe or manage your list subscription:
/index.html