Re: [opensource-dev] [POLICY] Configurable HTTP user-agent string
This question is someone being overly obtuse on purpose. The Internal Web Browser is 1. Not a Third Party Viewer, 2. Nor is it connecting to the Second Life Grid, negating the whole Spoof clause question At the most it might connect to an HTTP-Server on a prim. If the Internal Web Browser is used to connect to a website with a web interface to SL, it is still NOT a Third Party Viewer. The web interface is and that interface must be responsible for following the TPVp. On Tue, May 4, 2010 at 10:06 PM, Rob Nelson nexisentertainm...@gmail.com wrote: On Tue, 2010-05-04 at 20:48 -0300, Tigro Spottystripes wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Is the internal browser considered the viewer itself or can it have it's own identifier? From what I remember, it uses something like Second Life Viewer/VERSION (Mozilla 4.0...) And is the user agent string of the internal browser *the* unique viewer identifier mentioned in the TPVp? No, the TPV speaks of the viewer login channel. By default, it uses Second Life Development. Emerald uses Emerald Viewer, Luna uses Luna Viewer (I think, it's been a while since I dug around in the code). The login channel was originally intended to keep OSS viewers from receiving official viewer updates. Are we gonna have to hire a lawyer to get these questions answered? If past history of trying to get similar questions answered counts, then yes. On 4/5/2010 20:41, Boroondas Gupte wrote: On 05/04/2010 10:57 PM, Ricky wrote: [...] we could easily add some functions into our various viewers to change the string into whatever we choose it to be. Again, just like browser useragents. Would that be allowed under TPVp section 2. http://secondlife.com/corporate/tpv.php#priv2c.ii? You must not spoof the viewer identifier or the identity of a Third-Party Viewer connecting to Second Life. Each version of a Third-Party Viewer must have a unique viewer identifier and must not use the same viewer identifier as a Linden Lab viewer or another Third-Party Viewer. Boroondas ___ 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 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEAREKAAYFAkvgslkACgkQ8ZFfSrFHsmWX1QCcDVH2V6fdAWj+cGFXhxCvqOSx 8c0An2/dWHyCSSGH/s/ouq5FtSueM6dq =6mbF -END PGP SIGNATURE- ___ 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 ___ 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
Re: [opensource-dev] [POLICY] Configurable HTTP user-agent string
On 05/05/2010 10:42 AM, Harold Brown wrote: This question is someone being overly obtuse Sorry about that. on purpose. I can assure you that not. While I was aware my question was a bit nitpick-ish, I didn't consider to look at the internal browser as separate entity (which makes sense and solves this issue) instead of as part of the viewer. cheers Boroondas ___ 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
Re: [opensource-dev] [POLICY] Configurable HTTP user-agent string
On Wed, May 5, 2010 at 11:02 AM, Tigro Spottystripes tigrospottystri...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 can the the client loading HTML on a prim be considered the same as the internal web browser or the rules change in that case? Techinaly there is no internal webbrowser, all html pages are generated from a seperate process to the viewer using the webkit rendering engine and passed to the viewer as a texture via a shared memory buffer. Using seperate processes is enough to isolate from GPL issues and other licence issues in other cases so i can't see what the html engine user agent string has to do with the TVP and the unique identifier which is used by LL on the xmlrpc login processin this case either. I often have to change user agent on my browser to fix broken websites, I can't see how this is any different. Plus if this really is an issue LL can request that you unfix your code, i believe that was part of the TVP conditions for connecting to SL but again the webbrowser is not specificly connecting to secondlife and its the age old story of anyone who wants to do bad things can and will fake idents regardless, its only leigit viewers that need to fake idents to avoid broken content in this case and not allowing a viewer to fake this only hurts and would make a mocery of the entire 3rd party viewer system. Robin ___ 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
Re: [opensource-dev] [POLICY] Configurable HTTP user-agent string
Can't we just get an additional AGENT_VIEWER flag via llGetAgentInfo? Even if not foolproof, it's useful as a factor for legitimate security or warning tools, as well as for stats gathering for 99% of residents. It seems like a logical solution to me, instead of having to go the http agent route or other hackish solutions. If I don't get any feasibility objections here, I'll open a Jira issue. I haven't' seen any such proposal on there yet... On 5/5/10 4:18 AM, Robin Cornelius robin.cornel...@gmail.com wrote: On Wed, May 5, 2010 at 11:02 AM, Tigro Spottystripes tigrospottystri...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 can the the client loading HTML on a prim be considered the same as the internal web browser or the rules change in that case? Techinaly there is no internal webbrowser, all html pages are generated from a seperate process to the viewer using the webkit rendering engine and passed to the viewer as a texture via a shared memory buffer. Using seperate processes is enough to isolate from GPL issues and other licence issues in other cases so i can't see what the html engine user agent string has to do with the TVP and the unique identifier which is used by LL on the xmlrpc login processin this case either. I often have to change user agent on my browser to fix broken websites, I can't see how this is any different. Plus if this really is an issue LL can request that you unfix your code, i believe that was part of the TVP conditions for connecting to SL but again the webbrowser is not specificly connecting to secondlife and its the age old story of anyone who wants to do bad things can and will fake idents regardless, its only leigit viewers that need to fake idents to avoid broken content in this case and not allowing a viewer to fake this only hurts and would make a mocery of the entire 3rd party viewer system. Robin ___ 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
Re: [opensource-dev] [POLICY] Configurable HTTP user-agent string
Am 05.05.2010 21:57, schrieb Bryon Ruxton: Can't we just get an additional AGENT_VIEWER flag via llGetAgentInfo? Even if not foolproof, it's useful as a factor for legitimate security or warning tools, as well as for stats gathering for 99% of residents. It seems like a logical solution to me, instead of having to go the http agent route or other hackish solutions. If I don't get any feasibility objections here, I'll open a Jira issue. I haven't' seen any such proposal on there yet... and why should any illegal viewer send (in future) his real viewer agent? ___ 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
Re: [opensource-dev] [POLICY] Configurable HTTP user-agent string
Bryon Ruxton schrieb: Can't we just get an additional AGENT_VIEWER flag via llGetAgentInfo? Even if not foolproof, it's useful as a factor for legitimate security or warning tools, as well as for stats gathering for 99% of residents. It seems like a logical solution to me, instead of having to go the http agent route or other hackish solutions. Making the http trick obsolete is a good step forward in ensuring privacy and maybe a step forward to some LSL policy. Like TPV policy was a start to stop copybot development/distribution. When will LSL being policed about what can be done? LSL can also be used to replicate prim parameters and export/import. And newer tools abusing the llParcelMedia commands can be used to get the IP address of the users and they allow planting cookies into the viewers, that are shared between all accounts. Don't get me wrong on here. The hypothetical scenery I'm thinking about is a stalker being friends with a land owner, tracking down the alts of myself to grief me. I am not against banning on the viewer identity. Though alt account information is no one's business until LL makes that information available. ___ 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
Re: [opensource-dev] [POLICY] Configurable HTTP user-agent string
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I thought cookies weren't shared between accounts even in the same machine...are you sure they are? On 5/5/2010 17:28, Thomas Shikami wrote: Bryon Ruxton schrieb: Can't we just get an additional AGENT_VIEWER flag via llGetAgentInfo? Even if not foolproof, it's useful as a factor for legitimate security or warning tools, as well as for stats gathering for 99% of residents. It seems like a logical solution to me, instead of having to go the http agent route or other hackish solutions. Making the http trick obsolete is a good step forward in ensuring privacy and maybe a step forward to some LSL policy. Like TPV policy was a start to stop copybot development/distribution. When will LSL being policed about what can be done? LSL can also be used to replicate prim parameters and export/import. And newer tools abusing the llParcelMedia commands can be used to get the IP address of the users and they allow planting cookies into the viewers, that are shared between all accounts. Don't get me wrong on here. The hypothetical scenery I'm thinking about is a stalker being friends with a land owner, tracking down the alts of myself to grief me. I am not against banning on the viewer identity. Though alt account information is no one's business until LL makes that information available. ___ 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 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEAREKAAYFAkvh2wcACgkQ8ZFfSrFHsmUlZQCdHADCp5TnG3YSvbyPl1AE3HNu kT4AnRP5d5Le/TaKmpyi8HT6FU0A4/cu =+xGt -END PGP SIGNATURE- ___ 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
Re: [opensource-dev] [POLICY] Configurable HTTP user-agent string
HTTP cookies were shared across all accounts using a viewer installation - until recently. It's my understanding that the latest crop of viewer2 viewers keep cookies separate per-account. However unless you're using one of those newest ones, it's possible to track down alt-accounts or hotseat users using parcel media streams, shared-media prims or HTTP links by introducing tracking cookies. On 6/05/2010 6:54 AM, Tigro Spottystripes wrote: I thought cookies weren't shared between accounts even in the same machine...are you sure they are? On 5/5/2010 17:28, Thomas Shikami wrote: Bryon Ruxton schrieb: Can't we just get an additional AGENT_VIEWER flag via llGetAgentInfo? Even if not foolproof, it's useful as a factor for legitimate security or warning tools, as well as for stats gathering for 99% of residents. It seems like a logical solution to me, instead of having to go the http agent route or other hackish solutions. Making the http trick obsolete is a good step forward in ensuring privacy and maybe a step forward to some LSL policy. Like TPV policy was a start to stop copybot development/distribution. When will LSL being policed about what can be done? LSL can also be used to replicate prim parameters and export/import. And newer tools abusing the llParcelMedia commands can be used to get the IP address of the users and they allow planting cookies into the viewers, that are shared between all accounts. Don't get me wrong on here. The hypothetical scenery I'm thinking about is a stalker being friends with a land owner, tracking down the alts of myself to grief me. I am not against banning on the viewer identity. Though alt account information is no one's business until LL makes that information available. ___ 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 -- Tateru Nino Contributing Editor http://massively.com/ -- Tateru Nino http://dwellonit.taterunino.net/ ___ 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
Re: [opensource-dev] [POLICY] Configurable HTTP user-agent string
On 2010-05-05, at 14:57, Bryon Ruxton wrote: Can't we just get an additional AGENT_VIEWER flag via llGetAgentInfo? Let's not. ___ 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
Re: [opensource-dev] [POLICY] Configurable HTTP user-agent string
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 That would open lots of possibilities On 5/5/2010 18:32, Argent Stonecutter wrote: On 2010-05-05, at 14:57, Bryon Ruxton wrote: Can't we just get an additional AGENT_VIEWER flag via llGetAgentInfo? Let's not. ___ 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 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEAREKAAYFAkvh5H8ACgkQ8ZFfSrFHsmWdPQCdHwH8SvkaPRp/0CVhuL0jVrfD rikAnj23Hz0BtcRuVUUVYEgTEyPhR0x/ =V9gp -END PGP SIGNATURE- ___ 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
Re: [opensource-dev] Possible glitch in TPV identification procedure
Channel name is a persistent saved setting. Meaning if you log in under a viewer that sets its channel in the saved settings file, but does not use one of its own(settings file), the normal viewer will continue to identify itself as that viewer. Until you remove the entry yourself, by either clearing your settings files, or by hand, this will always happen. I've notified LL about this problem once or twice before, but nothing appears to have been done about it. Marking the channel entry as non persistent would be enough to mitigate the problem caused here, in the app_settings/settings.xml file. The reason this does not occur for the normal viewer, and spread to TPV clients is because only settings that have been changed from their defaults are written into the users settings. On Wed, May 5, 2010 at 18:01, Jay Reynolds Freeman jay_reynolds_free...@mac.com wrote: Now this is weird: I have a TPV that I have developed for my own occasional use -- not for distribution. I have identified it according to the procedures outlined in http://wiki.secondlife.com/wiki/Channel_and_Version_Requirements and they seem to work. So far, well and good. I also have an executable binary of a standard LL viewer -- 1.23.5 -- that I use most of the time. This is a straight download of the executable, direct from LL, unmodified by me in any way, and so verified by inspecting the dates on the actual executable. Yet when I run my unmodified 1.23.5 and use the menu item Help-About Second Life ... , what is displayed is the version string that I have created for my modified TPV. Taken at face value, this observation suggests that my unmodified 1.23.5 binary is somehow identifying itself as my personal TPV when I launch it, and that sounds like a glitch somewhere -- I just don't know where. Further information: I am running on a Macintosh, under MacOS 10.6.3 ... I run the two viewers -- 1.23.5 and my personal one -- using the same Macintosh account (Unix account) and also using the same SL accounts (avatar names). When I create a different Macintosh/Unix account, and run the 1.23.5 binary while logged in as that different account (but using one of my usual SL accounts), the misidentification does NOT occur; that is, it looks like the incorrect identification of 1.23.5 only happens in the Unix account in which I have also used my personal TPV. I reiterate, all the mods to identify my personal TPV were made in the source directory I use to build it, and the version of 1.23.5 that I am running was compiled by Linden Laboratories -- all I did was download it. My guess is that there is something like a cookie, somewhere associated with my everyday Macintosh/Unix account, that is not getting cleared when it ought to be. Does anyone have any idea what is going on, or what I ought to do to fix the problem systematically? Remembering to clear cookies every time I log in, or something like that, does not sound like a very robust fix. Unanticipated regular misidentification of viewers could cause great confusion. I will be happy to file a bug report about this, but it might help if I knew what was going on ... -- Jay Reynolds Freeman / CeeJay Tigerpaw - jay_reynolds_free...@mac.com http://web.mac.com/jay_reynolds_freeman (personal web site) ___ 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
Re: [opensource-dev] Possible glitch in TPV identification procedure
Zabb65 schrieb: Channel name is a persistent saved setting. Meaning if you log in under a viewer that sets its channel in the saved settings file, but does not use one of its own(settings file), the normal viewer will continue to identify itself as that viewer. Until you remove the entry yourself, by either clearing your settings files, or by hand, this will always happen. I've notified LL about this problem once or twice before, but nothing appears to have been done about it. Marking the channel entry as non persistent would be enough to mitigate the problem caused here, in the app_settings/settings.xml file. The reason this does not occur for the normal viewer, and spread to TPV clients is because only settings that have been changed from their defaults are written into the users settings. So, the solution is on hand... modify app_settings/settings.xml in your TPV to match the LL_CHANNEL define, that makes the different channel name the default and then it won't be saved into user_settings. ___ 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
Re: [opensource-dev] [POLICY] Configurable HTTP user-agent string
On 2010-05-05, at 16:34, Tigro Spottystripes wrote: That would open lots of possibilities It would open up all kinds of cans of worms. ___ 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
Re: [opensource-dev] [POLICY] Configurable HTTP user-agent string
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 How so? On 5/5/2010 20:36, Argent Stonecutter wrote: On 2010-05-05, at 16:34, Tigro Spottystripes wrote: That would open lots of possibilities It would open up all kinds of cans of worms. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEAREKAAYFAkviAbIACgkQ8ZFfSrFHsmWQHQCeOGj+Ra4uidYat6bepkltiCfQ fj8AnA2ZmVOhKQd1+EzCWJYEathu9Flb =zxFC -END PGP SIGNATURE- ___ 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
