I'd like to remark that the information you found is just the data of the
ModularSystems website, and all of the other viewer directory listings look
about the same as Emerald's. The actual real-life name(s) of people involved
aren't required to be publicly viewable, but Linden Lab does have them.
Also, consider the possibility that .sl was chosen as a domain because it
could be an abbreviation for SecondLife. Cute, eh?

I seriously doubt anyone with malicious intent is going to bother trying to
register their viewer in the directory.

On Thu, Apr 29, 2010 at 8:38 PM, Boy Lane <boy.l...@yahoo.com> wrote:

> We certainly should follow the bright example of Emerald / Modularsystems,
> where you Discrete are a member of. A pseudo company set up and owned
> by known banned griefer JCool aka who revived his banned account(s) under
> the names of Fractured Crystal/Fractured Modularsystems.
>
> Back to their registration. JCool set up Modularsystems. A mailbox company
> with the following contact details:
>
> http://modularsystems.sl/
> P.O. Box 5702
> West Columbia, South Carolina 29171-5702
> United States
> administra...@modularsystems.sl
>
> That is an untraceable anonymized entity without any name attached to it
> and
> unknown legal status, registered with a domain name in Sierra Leone, a
> country
> that does not even have a WHOIS.
>
> This information was used to register and self-certify Emerald in the
> Viewer
> Directory.
>
> As I as a legally uniformed hobby programmer without commercial interest
> can
> evaluate this situation and validity of the Emerald listing, it is meant to
> circumvent
> any means of the viewer directory to hold a developer accountable for their
> viewers. It is also meant to avoid any possible litigation from LL in case
> indeed
> some malicious code may be found in their viewer(s). Besides Emerald,
> Modularsystems
> also develops and uses a malicious viewer named "Onyx" that is in clear
> violation of
> ToS/TPV.
>
> So no, Discrete, all these things completely contradict your argument. As
> shown a
> listing in Lindens viewer directory doesn't add a single piece of safety or
> security. To
> look for a legitimate viewer the Alternate Viewer list in the community
> edited SL Wiki
> is a better place to, for the simple reason malicious clients may not
> easily
> slip in as
> this is possible with self-certification. A blacklist is a good thing and
> could at least
> complement Viewer Directory and Alternate Viewers list. But of course it
> would
> include most of the malicious viewer from the key developers behind
> Modularsystems
> which obviously you try to avoid.
>
> Additional question to Linden Lab: How can for repeated ToS violations
> permanently
> banned people just circumvent that ban by creating new accounts as many of
> the
> Emerald developers did? Is it money spent for SL that counts rather than
> ToS?
>
> Boy
>
> ----- Original Message ----- > Date: Thu, 29 Apr 2010 16:39:16 -0400
> > From: Discrete Dreamscape <discrete.dreamsc...@gmail.com>
> > Subject: Re: [opensource-dev] Viewer blacklist to replace the TPV
> > directory ?
> > To: Tigro Spottystripes <tigrospottystri...@gmail.com>
> > Cc: opensource-dev@lists.secondlife.com
> > Message-ID:
> > <g2nc38195a91004291339p41f404edgfe05a593c813c...@mail.gmail.com>
> > Content-Type: text/plain; charset="utf-8"
> >
> > This discussion seems to have been created with misleading intentions.
> >
> > Because some TPV creators don't want to reveal any personal information
> > about themselves, they can't be posted on the TPV directory, and because
> > of
> > this, it's understandable they might view the directory as unfair. But,
> > this
> > doesn't strike me as a valid reason to criticize the list.
> >
> > It's certainly valid to say that the viewers on the list are not
> > absolutely
> > trustworthy unless a full code audit is done, but even then, do you
> really
> > know that what's in the code is the same as what's in the binary? Isn't
> > there a limit to what LL can do, given a lack of resources to perform
> such
> > audits, especially when what you download requires trust that it's the
> > same
> > as what they've audited?
> >
> > But really, trust is supposed to be provided by the fact that the viewer
> > has
> > indeed registered using real-life contact information, because who would
> > give such a thing knowing they could be held liable if they indeed
> decided
> > to include malicious code? In general, there is no way to certify purity
> > here, you can only provide a level of trust as a guideline. You can't
> rely
> > on babysitting the users, because LL isn't going to compile every third
> > party's code and release the binaries themselves.
> >
> > In this regard, you may begin to argue that indeed, a blacklist would
> > better
> > serve users. I argue that this is exactly the opposite. You may be able
> to
> > pick out which viewers are explicitly untrusted, but you make no
> > statements
> > about the trustworthiness of any others. In this situation, a user is
> left
> > to choose between either a viewer which is in the grey about its status,
> > or
> > an official Linden viewer. This point is key, as far less warranty is
> > provided for users that they won't be banned for using a third party
> > viewer.
> > I suspect that in this case, many would simply give up and use the
> > official
> > client rather than risk their business, etc.
> >
> > If you want to provide a system where users can trust the clients they
> > use,
> > it seems like our current one is decent enough. In any case, a blacklist
> > doesn't appear to be any safer.
> >
> > Discrete
> >
>
>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Reply via email to