Jump to content

New Feature: Scripted Agent Estate Access Discussion


You are about to reply to a thread that has been inactive for 318 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

  • Lindens
3 minutes ago, M Peccable said:

So in other words LL, on its own, is extending the "legal" RL PII to include SL information. An abundance of caution I suppose.

But usernames (and to some extent UUIDs too) are everywhere on the Internet and multimedia. YouTube is a good example. That indeed does seem to pose a contradiction.

 

No, it's not our own formulation. See here.

There's a common misconception that something isn't PII if it doesn't tell you a real-life name. In some jurisdictions, for example California, even tracking cookies or usernames can be PII. It's sufficient that the PII identifies an individual even if you haven't yet learned the real-life identity of that individual. Think of it like pointing at a person, even if you don't know the person's name. You've "identified" one individual in a crowd.

As a simple rule of thumb: If you're reasonably sure that the same user or machine returned a minute or a month later, whatever information helped make that connection is PII.

There's another common misconception that every last interaction is governed by the strictures of each privacy regulation. There are explicit carve-outs for non-automated human activity. For example, GDPR Article 2(2)(c) carves out an exception for processing Personal Data (which includes PII) by a natural person in the course of a purely personal or household activity.

In the YouTube example, if one made a script that scraped YouTube and performed the automated collection of information about various YouTube users and tied it to their usernames, one would do well to consult a privacy attorney first.

It's not surprising that there's some confusion. There's a lot to take in here. And sadly, there haven't been enough campaigns introducing people to their privacy rights. So I'm really happy to see people take an interest!

  • Like 3
  • Thanks 6
Link to comment
Share on other sites

2 minutes ago, Silent Mistwalker said:

You misunderstood my reply.

I'm not so sure it's possible to have a discussion about estate settings without also discussing the parcels those settings affect. Most regions aren't just one large parcel. They're broken up into smaller parcels, except maybe homesteads. 

I'm wondering why it's so hard for people to understand that I am simply putting forth an idea an already existing tool that just might be useful... if only they (general you, not Rowan specifically) would listen instead of hearing what they want to hear. But they're too angry and are taking that anger out on me. I'm not the one they should be angry with, if they should be angry at anyone (or thing).

With all due respect, you're talking about something completely different than what this thread is about.  It's about the NEW anti bot setting available to Private Estate owners only.  If they have set their estate to not allow bots, each parcel is included and cannot use their own parcel access list to allow their own bots.  The estate owner would need to add them to the estate access list individually.  Some will, some won't.

As Bellisseria is all owned by LL (estate owner) and has enabled the anti bot setting, no one can add them to their Belli parcel.  That is what @Paul Hexemis upset about.

We're talking registered scripted agents.

 

  • Like 2
Link to comment
Share on other sites

Just now, Rowan Amore said:

 

We're talking registered scripted agents.

 

Which is what I am talking about. Registered scripted agents allowed or disallowed on the Access Tab for a parcel when it has NOT been activated on the region/estate level. 

It may not be relevant in your opinion but that doesn't make it irrelevant.

  • Haha 1
Link to comment
Share on other sites

3 minutes ago, Soft Linden said:

Think of it like pointing at a person, even if you don't know the person's name. You've "identified" one individual in a crowd.

Wow. I never thought I would live in a world, RL or SL, where pointing at someone was breaking the rules. 😕

Link to comment
Share on other sites

  • Lindens
2 minutes ago, M Peccable said:

Wow. I never thought I would live in a world, RL or SL, where pointing at someone was breaking the rules. 😕

 

I think you're joking. But for the benefit of people skimming since this is a fast-moving thread, see the rest of the quoted post regarding carve-outs.

  • Like 3
Link to comment
Share on other sites

17 minutes ago, Soft Linden said:

carves-out an exception for processing Personal Data (which includes PII) by a natural person in the course of a purely personal or household activity.

Well, only half joking :)To me the carve-outs just makes the water more murky. At what point does SL activity cross the line of not being purely personal activity?

Edited by M Peccable
Clarity, hopefully
Link to comment
Share on other sites

30 minutes ago, Scylla Rhiadra said:

Fair enough, although the context of my remarks was specifically with regard to unregistered bots.

My sense of what Soft said is that no one is expecting creators to turn 180 deg. on a dime here. I don't think there should be any immediate reason why services and products that are not particularly dependent upon data collection from bots will be immediately affected.

Well if your primary concern is seeing bots, yes, deny_bots will mean you see less of them, but that will come with a cost.

graph-bot-activity-cohorts.png

This is a list of all the "known" roaming bot networks as of Feburary 2023.
As you can see there are far more on here than the BonnieBots, which I believe were the bots that created resident cocnern due to fears regarding how may have operated, rather than concerns about how they did operate.

That aside, BB isn't the point here.
The point is there are many other networks that are now unable to provide reliable information for the purpose.

Perhaps one of the mist interesting ones here in my opinion would be that of SurveyTeam, which is a bot network that operates on behalf of GridSurvey which is a long long long time pillar of the community in the valuable information they provide about SL and generously provides API that countless scripts make use of over the past decade and a half, if not more.

This dataset can no longer be relied upon for production and mission crtiical standards of code, due to the patchyness of the dataset.
That means algorithms needs to be changed to account for that, if they can be at all.

This is true for not just that bot network, but multiple ones. I'm not saying "dont add deny_bot" personally, I think it's a good thing, but it should be parcel level with region override on negative parcel permissions, and the invisible setting on parcels should also hide residents and objects from the viewer, and scripts in my opinion. Personally, I think it didn't go far enough, but it could have been a bit less of a blunt hammer approach to the situation in my opinion.

My support of that position, is not informed by a fear of bots or a spookyness of them. I'm a scripter myself, I'm not the least bit concerned when I see a bot come and go, because I know they really dont do anything spooky. I support the policy change because I believe users have a right to decide for themselves how to manage their own land without having to justify their choices about their own land.  Code is unfortunately a black box to many users, and by the nature of our own human psychology we conjure imagined threats and fears about things we don't know exactly what they do, and bots become the boogeyman under the bed. So while I do think for a lot of users, this "botphobia" as I've seen it described as by others in this thread, is informed by a misunderstanding of what these bots even do, that has just blown out of control, I still think people should have the right to decide for themselves on their own land.

However, despite being in support of that, I'm also not going to pretend that this won't have a significant impact on the grid, thats the nature of what I'm getting at here. This is a major policy change that will fundamentally alter much about the grid as we know it, even if that is not immediately obvious yet, and it will do so in ways far beyond how many bots you see every day.

While LL I'm sure is fully aware of this, and will have considered this, on the resident side of things where many of us are people who just come to hang out and may not know these things as in depth when it comes to our thoughts on things should be ready for that and keepm that in consideration, rather than from a hopeful utopia where the bots are gone but everything else stays the same, otherwise we run the risk of cheering on potentially devastating changes that can take a while for things to re-adjust from, asuming project maintainers are even still active in SL. The sudden workload, may even push a number to decide SL aint worth it for them, and I'm not just talking about bot operators.

With regards to degradation to service, first part of what I said about that was with regards to the deny_bot flag. This means that datasets are now unreliable, so code that acceses this data via APIs, and not just BonnieBots, but any of them, can now not be safely relied on, which means algorithms have to be changed. This takes time, and there is no guarentee equal functionality will be viable. This has to be an accepcted cost of such a change, and people who were pushing for this, I hope they were aware of that.

In terms of the HTTPRequest aspect again, soft's statement is a good one and it is good to hear that, however, this still does not change the fact that as it currently stands the nature of llHTTPRequest, and any handling of UUID36 for that matter (Which is one of the most important data types in LSL) is in the realm of uncertainty for the forseeable future, pending future statements from LL.

While, as soft said, we will not see action taken or enforcement against existing scripts and services. This does mean that developers, myself included, will be a lot more hesitant for now to continue development of anything using these functions (Which again, are some of the most important ones in LSL), until this uncertainty is cleared. In addition, projects that may have been started, likely now never will given the unknown status of the function and use of UUIDs in the future.

This will have an impact on the grid, even with the pending status of enforcement by LL, due to a slowdown in development out of caution, to avoid wasted workhours into algorithms we'd have to redo.

Again, I am in favour of these changes (a bit spicy on some aspects of httprequest though), but I wouldn't say its a good idea to pretend to ourselves the only impact this will have is, how many bots we see popping in and out over the course of a day, and we should be prepared to accept the consequences of this change as a result of the policy change that has been asked for, by who I can hope knew what would that entail with it.

 

Just my two cents on the whole "Yeah this is great!"
 

Edited by bunboxmomo
  • Like 6
  • Thanks 2
Link to comment
Share on other sites

1 minute ago, bunboxmomo said:

Well if your primary concern is seeing bots, yes, deny_bots will mean you see less of them, but that will come with a cost.

graph-bot-activity-cohorts.png

This is a list of all the "known" roaming bot networks as of Feburary 2023.
As you can see there are far more on here than the BonnieBots, which I believe were the bots that created resident cocnern due to fears regarding how may have operated, rather than concerns about how they did operate.

That aside, BB isn't the point here.
The point is there are many other networks that are now unable to provide reliable information for the purpose.

Perhaps one of the mist interesting ones here in my opinion would be that of SurveyTeam, which is a bot network that operates on behalf of GridSurvey which is a long long long time pillar of the community in the valuable information they provide about SL and generously provides API that countless scripts make use of over the past decade and a half, if not more.

This dataset can no longer be relied upon for production and mission crtiical standards of code, due to the patchyness of the dataset.
That means algorithms needs to be changed to account for that, if they can be at all.

This is true for not just that bot network, but multiple ones. I'm not saying "dont add deny_bot" personally, I think it's a good thing, but it should be parcel level with region override on negative parcel permissions, and the invisible setting on parcels should also hide residents and objects from the viewer, and scripts in my opinion. Personally, I think it didn't go far enough, but it could have been a bit less of a blunt hammer approach to the situation in my opinion.

My support of that position, is not informed by a fear of bots or a spookyness of them. I'm a scripter myself, I'm not the least bit concerned when I see a bot come and go, because I know they really dont do anything spooky. I support the policy change because I believe users have a right to decide for themselves how to manage their own land without having to justify their choices about their own land.  Code is unfortunately a black box to many users, and by the nature of our own human psychology we conjure imagined threats and fears about things we don't know exactly what they do, and bots become the boogeyman under the bed. So while I do think for a lot of users, this "botphobia" as I've seen it described as by others in this thread, is informed by a misunderstanding of what these bots even do, that has just blown out of control, I still think people should have the right to decide for themselves on their own land.

However, despite being in support of that, I'm also not going to pretend that this won't have a significant impact on the grid, thats the nature of what I'm getting at here. This is a major policy change that will fundamentally alter much about the grid as we know it, even if that is not immediately obvious yet, and it will do so in ways far beyond how many bots you see every day.

These decisions should be made with this in consideration, rather than from a hopeful utopia where the bots are gone but everything else stays the same, otherwise we run the risk of cheering on potentially devastating changes that can take a while for things to re-adjust from, asuming project maintainers are even still active in SL. The sudden workload, may even push a number to decide SL aint worth it for them, and I'm not just talking about bot operators.

With regards to degradation to service, first part of what I said about that was with regards to the deny_bot flag. This means that datasets are now unreliable, so code that acceses this data via APIs, and not just BonnieBots, but any of them, can now not be safely relied on, which means algorithms have to be changed. This takes time, and there is no guarentee equal functionality will be viable. This has to be an accepcted cost of such a change, and people who were pushing for this, I hope they were aware of that.

In terms of the HTTPRequest aspect again, soft's statement is a good one and it is good to hear that, however, this still does not change the fact that as it currently stands the nature of llHTTPRequest, and any handling of UUID36 for that matter (Which is one of the most important data types in LSL) is in the realm of uncertainty for the forseeable future, pending future statements from LL.

While, as soft said, we will not see action taken or enforcement against existing scripts and services. This does mean that developers, myself included, will be a lot more hesitant for now to continue development of anything using these functions (Which again, are some of the most important ones in LSL), until this uncertainty is cleared. In addition, projects that may have been started, likely now never will given the unknown status of the function and use of UUIDs in the future.

This will have an impact on the grid, even with the pending status of enforcement by LL, due to a slowdown in development out of caution, to avoid wasted workhours into algorithms we'd have to redo.

Again, I am in favour of these changes (a bit spicy on some aspects of httprequest though), but I wouldn't say its a good idea to pretend to ourselves the only impact this will have is, how many bots we see popping in and out over the course of a day, and we should be prepared to accept the consequences of this change as a result of the policy change that has been asked for, by who I can hope knew what would that entail with it.

 

Just my two cents on the whole "Yeah this is great!"
 

Bots have NEVER been the "pillar of the community".  Aty least now, something has finally been done about the plague of anonymous bots plaguing landowners.  At least the bots whom we daren't name, actually chose to identify themselves, and what they were up to.

 

for me, my land has the new setting in place (thanks landlord ^^) and I'll continue to AR the suspected (my word) undeclared bots.

  • Like 1
  • Haha 1
Link to comment
Share on other sites

Just now, belindacarson said:

Bots have NEVER been the "pillar of the community".  Aty least now, something has finally been done about the plague of anonymous bots plaguing landowners.

People who run bots are residents just like your self, and create things with the best of intentions just like anyone else.
With regards to something like GridSurvey, many of the things you use everyday in SL will be making use of their ongoing survey of the grid and it's regions.

I'm not saying worship bot owners, but the vilification, is a bit much.

  • Like 2
Link to comment
Share on other sites

57 minutes ago, M Peccable said:

I guess I missed something somewhere. All the PII regulation quotations I have seen refer to RL personal info. How did avatar UUIDs and user names get connected to RL personal info?

That's how PII works.

Your "user name" is a piece of PII because it identifies "you" ("your account"). It is a unique piece of information that is associated with noone's account but yours. Kind of like your email address, if that example is easier to understand.

Your UUID is the same way: Only 1 "user name" and 1 UUID identify "you".

If someone were to hack the SL database, or find the "connecting dots", they would only need your user name and/or UUID to identify YOU as a "user". Plus, the "user name" can be used to try to hack into the account, etc. etc. etc.

We've been doing the same type of "personal data protection" in my IT field for many years before the GDPR.

Edited by Love Zhaoying
Me explain bad, but me make points anyway because I has teh dum.
  • Like 2
Link to comment
Share on other sites

13 minutes ago, Love Zhaoying said:

That's how PII works.

Your "user name" is a piece of PII because it identifies "you" ("your account"). It is a unique piece of information that is associated with noone's account but yours. Kind of like your email address, if that example is easier to understand.

Your UUID is the same way: Only 1 "user name" and 1 UUID identify "you".

If someone were to hack the SL database, or find the "connecting dots", they would only need your user name and/or UUID to identify YOU as a "user". Plus, the "user name" can be used to try to hack into the account, etc. etc. etc.

We've been doing the same type of "personal data protection" in my IT field for many years before the GDPR.

If that's the case, it shouldn't be easily accessed from your profile.nor.should your PIOF status.  And while we're at it, take off that 1st life tab because that's just asking for trouble.  🙄

  • Like 2
Link to comment
Share on other sites

2 minutes ago, Rowan Amore said:

And while we're at it, take off that 1st life tab because that's just asking for trouble.

I would agree, but of course that's one that we already have 100% control over.  We can decide to put true RL information there or to post a bogus photo, as I have since Day One.  That's an opt-in spot.  

  • Like 2
Link to comment
Share on other sites

30 minutes ago, bunboxmomo said:

People who run bots are residents just like your self, and create things with the best of intentions just like anyone else.
With regards to something like GridSurvey, many of the things you use everyday in SL will be making use of their ongoing survey of the grid and it's regions.

I'm not saying worship bot owners, but the vilification, is a bit much.

I've said this before and likely will say it again. Tyche (creator/owner of GridSurvey) would take the necessary steps to prevent her bots from entering [y]our region/estate/homestead if you ask her to do so. All she needs is the name of the region and you won't see her land survey bots on that region ever again unless you ask to be included again or that region changes ownership/goes away. 

I know Tyche would do this because she did for me, a complete stranger that IMed her out of the blue asking if there was some way she could stop her bots because at the time (over a decade ago) my homestead was being bombarded with bots. That happened well over 10 years ago. This is how long the bot issue has been ongoing.

Edited by Silent Mistwalker
  • Like 3
Link to comment
Share on other sites

4 minutes ago, Silent Mistwalker said:

I've said this before and likely will say it again. Tyche (creator/owner of GridSurvey) would take the necessary steps to prevent her bots from entering [y]our region/estate/homestead if you ask her to do so. All she needs is the name of the region and you won't see her land survey bots on that region ever again unless you ask to be included again or that region changes ownership/goes away. 

I know Tyche would do this because she did for me, a complete stranger that IMed her out of the blue asking if there was some way she could stop her bots because at the time (over a decade ago) my homestead was being bombarded with bots. That happened well over 10 years ago. This is how long the bot issue has been ongoing.

Exactly, these are people too, kind ones at that for the most part that run free services at their own cost, that enable us to do things in SL we otherwise would not be able to.
These aren't villains to be vilified or reviled, they are residents who genuinely care about SL and love SL.

  • Like 2
Link to comment
Share on other sites

  • Lindens
7 minutes ago, Rolig Loon said:

I would agree, but of course that's one that we already have 100% control over.  We can decide to put true RL information there or to post a bogus photo, as I have since Day One.  That's an opt-in spot.  

Sure! And that's what online privacy boils down to: Revocable consent to have one's information used by specific parties in a specific context for a specific purpose.

After seeing the Terms of Service and SL Privacy Policy, a resident consents and opts in by adding information to their profile.

The context is within Second Life, and the specific parties are Second Life users.

The purpose is for other Second Life users to learn about the resident.

And the resident can revoke consent at any point by erasing the information from the profile.

That model applies to all online Personal Data sharing in a perfect world.

That profile tabs pass the test, so long as nobody violates the resident's privacy rights by scraping it for other uses.

  • Like 5
  • Thanks 2
Link to comment
Share on other sites

1 minute ago, bunboxmomo said:

Exactly, these are people too, kind ones at that for the most part that run free services at their own cost, that enable us to do things in SL we otherwise would not be able to.
These aren't villains to be vilified or reviled, they are residents who genuinely care about SL and love SL.

I agree. This is why I think the new scripted agent feature needs to be implemented at the parcel level but not be able to override the estate/region settings. As I said earlier in the thread I can also see where doing so would be even more of a nightmare for LL. But that isn't for us to determine, and it looks like LL is taking it in steps. If all goes well enough function wise it may come about that we one day have the same settings at the parcel level (without being able to override region settings), if we hold our faces right. 😁

  • Like 1
Link to comment
Share on other sites

6 minutes ago, Silent Mistwalker said:

I've said this before and likely will say it again. Tyche (creator/owner of GridSurvey) would take the necessary steps to prevent her bots from entering [y]our region/estate/homestead if you ask her to do so. All she needs is the name of the region and you won't see her land survey bots on that region ever again unless you ask to be included again or that region changes ownership/goes away. 

I know Tyche would do this because she did for me, a complete stranger that IMed her out of the blue asking if there was some way she could stop her bots because at the time (over a decade ago) my homestead was being bombarded with bots. That happened well over 10 years ago. This is how long the bot issue has been ongoing.

I have done the same thing over a similar time period. However, that is irrelevant. Her bots, along with mine and all the other responsible bot owners, are getting swept away by all the botphobia. No exceptions, regardless of the owner's reputation or the purpose of the bots.

  • Like 2
Link to comment
Share on other sites

"User names" and "UUID's" are a special cases, hard to connect with other users by avatar or script without them. 

I think one small improvement would be, if the "login user ID" was something different than the "user name", and definitely not your email address. That way, no one could hack your account - they wouldn't know your "login".

ETA: At my own company, they do exactly that for new users- they get a "lifetime ID" for their login which is neutral, and unfortunately a string of numbers. 

Edited by Love Zhaoying
Link to comment
Share on other sites

Just now, Love Zhaoying said:

Like what? Not counting "shopping-related" or "flying", "boating", or "driving", please. I'm curious.

Well to pluck an example out of the ether, gridsurvey provides us with information about the grid that a lot of random sim teleporters would function on as far back as as 2012 or so.
It allowed us for example to be able to make decisions based on various different region statistics, about if it was likely to be a dead teleport, and if so "reroll".
It also allowed us to retrieve UUIDs for textures relating to maps, which I'm pretty sure a lot of people have used.

But this is me just plucking one out of the ether, therers far far more.

But it's important to remember, this is an API, it's not about complete solutions. APIs are RESTful services that can be called via outgoing llHTTPRequests and the data used in LSL.

Theres a lot of things you use, that probably on some level uses data from an external API in part populated by data from bots, you just don't see it as the end user because this is all backend in script functionality.

  • Like 2
Link to comment
Share on other sites

1 minute ago, M Peccable said:

I have done the same thing over a similar time period. However, that is irrelevant. Her bots, along with mine and all the other responsible bot owners, are getting swept away by all the botphobia. No exceptions, regardless of the owner's reputation or the purpose of the bots.

I also said earlier in the thread that as unfortunate as it is, this is one of the risks you take when doing business in online. Specifically, in SL. Over the past 19 years I have seen this happen more than once in SL and yet SL is still here, and we still support it even though my prim builds were ancient history before I ever got my business off the ground.

I do empathize with those who may lose part or all of their business in SL but they knew that was a risk when they started. If they didn't, well, I'm sorry, they didn't do the research. 

  • Like 2
Link to comment
Share on other sites

1 minute ago, Love Zhaoying said:
5 minutes ago, bunboxmomo said:

that enable us to do things in SL we otherwise would not be able to

Like what? Not counting "shopping-related" or "flying", "boating", or "driving", please. I'm curious.

I use Tyche Shepard's gridsurvey when I'm curious about why I can't TP to a spot that I have a SLURL or a LM for.  The standard error message that pops up is not very helpful.  It only tells me what I already know: that the destination is unavailable.  If I look on gridsurvey.com I can see that it was abandoned in June 2022, so I shouldn't waste my time waiting for the servers to let me in.

That's a trivial example. Here's another .... If I wanted to name a new region, I would probably want to poke around and see whether someone else had already used the name I was thinking of or, perhaps more importantly, whether there's some other region with a name that is very close to it. I'd like to avoid naming a region Rolig Home if there's an RP region somewhere named Rolling Home, so I don't get any of their visitors dropping in to my region by mistake.

Those are fairly simple things that any resident might like to be able to do, but which would be much harder or even impossible without gridsurvey.

  • Like 3
  • Thanks 2
Link to comment
Share on other sites

This PII thing seems full of inconsistencies. For example, it seems to me many visitor trackers SL are in violation. Even if the owner "opted-in" to allowing their user name and UUID to be stored in a list, all of the visitors being recorded didn't opt-in. So if the visitor counter is storing its list outside of SL, which many do, it's a potential PII violation.

Edited by M Peccable
  • Like 1
Link to comment
Share on other sites

7 minutes ago, bunboxmomo said:

Well to pluck an example out of the ether, gridsurvey provides us with information about the grid that a lot of random sim teleporters would function on as far back as as 2012 or so.

Another form of travel. Not sure I've ever personally used grid-based teleporters (needed to, for "fun", except when forced to) in my 16 years in SL. But, it's an example and I didn't exclude it. There ya go!

An edge case is still a use case.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 318 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...