How can that be a source of correlation, unless you are using a viewer
that has a userbase of one (yourself and your alts)?
Even so, the suggestion is on the floor that the transmitted useragent
string be readily spoofable across all methods of gathering the info.
In this way we can allow legit us
On 2010-05-05, at 18:39, Tigro Spottystripes wrote:
> How so?
The SL client is not a browser, and currently provides a stronger
privacy firewall than a browser. This is important, because unlike a
browser connection when you are logged in to SL you're broadcasting a
strong non-repudiable ide
-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.
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
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
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
cleari
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 a
-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.
>
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 poli
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
-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
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
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
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
I have been able to build and run using VC++ Express 2008 w/boost 1-39 from
Robin but, the media_plugin_webkit fails at run time.
There are a lot like the following in the build log.
I guess it is set for 3 tries.
56>Getting recursive dependencies for file:
C:/SL_SVN/trunk/indra/build-VC90/win_c
On Wed, May 5, 2010 at 11:02 AM, Tigro Spottystripes
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 htm
-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?
On 5/5/2010 05:42, Harold Brown wrote:
> This question is someone being overly obtuse on purpose.
>
> The Internal Web Br
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 sol
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
19 matches
Mail list logo
