[sldev] Viewer Auth Postponed

[Argent Stonecutter]

On 2008-01-11, at 15:51, Kelly Linden wrote:
> Argent Stonecutter wrote:
>> First, let me note that I'm not talking about maintaining the  
>> network-level login code indefinitely, just the XUI login page.

>> On 2008-01-11, at 13:04, Kelly Linden wrote:
>>> Just because you can doesn't mean you should.  Maintaining this  
>>> indefinitely would mean more code to maintain which is a Bad Thing.
>>

>> True, but on the other hand the new login path requires a lot more  
>> code than the old login path, because it puts gecko in the  
>> critical path for login. Maintaining the XUI login page makes  
>> gecko optional. This has a number of advantages.

>> * It reduces the amount of code in the critical path.

> No, it "doubles" it (give or take).

How do you figure?

For the XUI page: XUI is already in the critical path anyway, so the  
only code this adds to the critical path is the XUI form itself.
For the HTML page: gecko is a lot bigger chunk of code than XUI, and  
the HTML login page is a lot bigger chunk of code than an XUI form...  
and a lot more complex.

Most of the login-specific code will be common to both.

On one side you've got gecko doing a fetch of the page, displaying  
it, doing a form submission, and getting a redirect to either another  
web page (for an error) or a secondlife: URL for success, which gets  
passed back to the client via the bindings for secondlife: URLs, and  
then you go through the common login code.

On the other you've got the XUI page being used to generate a form  
submission, and getting back a redirect to a web page (for an error)  
or a secondlife: URL for success, and that takes you to the common  
login code.

>   The next time there is a bug or new feature or any change that  
> effects the login process it will need to be made in two places  
> instead of one.

Possibly, depends on the bug or feature.

>> * It reduces the impact of problems in the very large amount of  
>> code associated with gecko. Customers who can't login at all tend  
>> to be a lot more upset than customers who can't use search and  
>> help and web tabs in profiles.

> I did say it should be one path that *works*.  It it might not work  
> then we should not use it.

I made that argument already, about the HTML code. :)

Supporting both is a second-best position.

So I'll grant your arguments against supporting both, and cut to the  
chase. The big argument against the HTML page is security. Web  
browsers are inherently exposed to whole classes of attacks that the  
SL client can be made immune to. At the moment there are components  
in the SL client that hurt its security, and the two biggest ones are  
the HTML rendering engine and streaming video... simply because both  
are huge chunks of code *and* they (plus streaming audio) are the  
only parts of the client directly exposed to third-party content. I  
do not normally enable any streaming media, let alone streaming  
video, and I don't use the HTML rendering engine for anything but  
Linden-provided content... and I encourage other people to do the  
same thing.

And there's already been one threatened exploit using the HTML login  
page... and that *is* supposed to be Linden-provided content.

So...

>> If anything, I strongly believe the XUI login page should be  
>> retained and the HTML login page eliminated. It's obviously your  
>> call and not mine, but I would like you to consider it.

> I don't necessarily disagree with this, but the HTML login does  
> have its advantages and if it can be made to just work then it  
> could be a viable solution.


Even if it can, it shouldn't be, simply from a security perspective.