[opensource-dev] Third party viewer policy

k\o\w kow at sapinski.com
Thu Feb 25 09:45:48 PST 2010

The hashed MAC and id0 sent upon login is just a bonus. Linden collect 
much more sensitive data from your PC using the viewerstats cap, which 
includes unhashed MAC, id0, CPU serial, and a pretty thorough breakdown 
of all your PC specs. I can confirm that this has been used to track 
griefers and custom clients that spoof the login hashes to circumvent bans.

I think everyones approach to the new policy is a bit hostile.... have 
you folks even read the original policies you agreed to? You've all 
given up more rights than the new policies try to take away :)

The simple act of logging into SL can and has been classified as 
"Disturbing the peace" and is grounds for account closure.

These new policies are nothing new, do not represent how 99% of the Lab 
will act when dealing with "abuse", and were probably written by lawyers 
who were tasked with making existing policies more legally binding 
because of all those lawsuits LL has lost.

In any case, I'm going to go with Carlo Wood here and continue using my 
own common sense. The default behaviour of my viewer will loosely follow 
LLs guidelines, and will have plenty of options for spoofing, disabling, 
and circumventing "features" that get in my way. Meerkat already 
obfuscates a lot of sensitive info like mac and id0, allows the export 
of full perm content, and so far I haven't had any complaints, just 
praise. *crosses fingers*.

Linden haven't banned cryolife, vlife, neillife, and the majority of the 
copybot viewers out there that DO identify uniquely upon login. You'll 
probably have to burn a pretty big bridge for them to take action 
against your client.

On 2/25/2010 12:31 PM, Argent wrote:
> Sorry for not editing this in detail, Opera is SLOW as hell in a 
> thread this long in gmail.
> I understand why they're asking for a MAC address. I'm pointing out 
> that a viewer may be running on a device that HAS NO MAC ADDRESS.
> On Wed, Feb 24, 2010 at 8:28 AM, Scott McCulley <smcculley at gmail.com 
> <mailto:smcculley at gmail.com>> wrote:
>     Argent,
>     >From a network standpoint, the mac address is a layer two address
>     that is not seen when crossing a router to a new network. So,
>     therer is no way to see your mac address from the network packets.
>     LL is using the mac address as a unique identifier of your
>     computer. When you use the SL viewer, it can read your mac address
>     locally, then send it along to LL to be used to identify you on
>     the grid. So if you have multiple accounts that you use from the
>     same computer, they know it is you, no matter what your IP
>     address, proxy server, or other network layer protection is used.
>     In the case of known griefers, LL could simply disable access from
>     that mac address that is reported by the viewer, and the person
>     cannot get back in to the grid, regardless of IP or SL account.
>     The only way is to use a completely new computer with a different
>     mac address.
>     That being said, if the developers mask the ability to read and
>     report the mac address to the LL grid, they lose the abilit to
>     block the bad guys.
>     -Scott
>     Sent from my iPhone
>     On Feb 24, 2010, at 5:49 AM, Argent Stonecutter
>     <secret.argent at gmail.com <mailto:secret.argent at gmail.com>> wrote:
>         Admittedly this is not likely to be a common scenario, but the
>         whole
>         idea that a MAC address is a unique identifier for a device is
>         based
>         on a deep-seated confusion about the network stack.
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100225/906f3699/attachment.htm 

More information about the opensource-dev mailing list