New Feature: Scripted Agent Estate Access Discussion

[Love Zhaoying]

4 minutes ago, Skyler Pancake said:

So LL made it extremely clear they have NO interest

That's reading a lot into it.

[M Peccable]

1 minute ago, Scylla Rhiadra said:

 What LL can do, and I'd argue will do if the seriousness of the issue warrants it, is stop the data collection in-world.

Which is, in a broader sense, what they are doing with the new estate tool, and the restrictions applied to Belli.

It would have to be pretty serious, because LL hates breaking content. Stopping all data collection in world would break a great many more things than most people realize.

[Scylla Rhiadra]

1 minute ago, M Peccable said:

It would have to be pretty serious, because LL hates breaking content. Stopping all data collection in world would break a great many more things than most people realize.

Yes.

And that should be how it works.

[Rowan Amore]

1 hour ago, Silent Mistwalker said:

Please show me the documentation that states there is no per parcel whitelisting of bots. I haven't seen anything to indicate a bot can't be added to either an allowed or a banned list on a parcel unless it's a mainland parcel.

You should be able to enter the bot name the same as an account name... since the account name is the bot name. Again, I've seen nothing that says a bot can't be added to a parcel whitelist. 

Seriously, please show me where it says bots can't ever be added to an allowed or banned list.

From the FAQ page...Scripted Agent Estate Access FAQ - deny_bots setting : Linden Lab (freshdesk.com)

Can I use this setting to block scripted agents from my parcel?  

Because the Scripted Agents Access flag (deny_bots) is an estate-level setting, it can only be enabled at the estate level, affecting all of the regions inside that estate. At this time, there is no parcel-level setting for controlling scripted agent access. Parcel owners can currently restrict access to their land through the World > About Land > Access tab, which includes access controls like 'Must have payment info on file' or 'Must be 18+' as options.  

I operate my own scripted agents in my private estate, but would like to deny access to other people's scripted agents by default. How can I exclude specific scripted agents from being blocked?

As an estate owner or estate manager, you have two options to permit specific scripted agents access to your region while denying other scripted agents automatically:

First, you can add the scripted agent to the estate's Always Allowed access list in the World > Region/Estate > Access tab.

Alternatively, if appropriate, any scripted agent that has estate manager powers in the estate will bypass the scripted agent access controls automatically. Granting estate manager rights can also be done on the World > Region/Estate > Access menu.

 

The bolded part...no parcel-level setting for controlling scripted agents...would also mean whitelisting would NOT override estate access.   Meaning, if the estate owner does not want them, they can't be there, period.

Edited March 31, 2023 by Rowan Amore

[Love Zhaoying]

I keep forgetting the PIOF option, thanks @Rowan Amore!

[Sid Nagy]

24 minutes ago, Rowan Amore said:

   Meaning, if the estate owner does not want them, they can't be there, period.

Estate owners can or can't allow a lot on their estate regions.
Whether or not it is allowed to run a business, a club, breed animals, use ban lines, the used ground texture... you name it they can enforce and control things. Most of that they control through the covenants, other things by checking the right boxes as estate holder.
So I can totally see that estate owners in the near future will have regions were bots are allowed and regions where they are not welcome. Customers can chose on what kind of region they rent land on.
What they offer is mainly demand controlled. Longstanding estate barons tend to listen to their user base very carefully.

Edited March 31, 2023 by Sid Nagy
It is my Saturday hobby to edit my texts. :S Also available on Fridays.

[Istelathis]

27 minutes ago, Love Zhaoying said:

I may be reading too much into your statement, but: Removing the motivation for "bad actors" to scrape and sell information would definitely have a chilling effect on whatever their motive is (whether profit, shenanigans, or "because we can").

Imagine if it were all a conspiracy from LL, to actively push people's views from desiring anonymous accounts to demanding we remove anonymous accounts entirely.  They are using our own paranoia against us!!

It was all a conspiracy I tells ya all 😂 

/kidding around I doubt that is their intention... or is it?!?

Yes I am joking around.

[Innula Zenovka]

29 minutes ago, Scylla Rhiadra said:

@Innula Zenovka

Here are the relevant bits of the new personal information policy:

"Personally Identifiable Information, often abbreviated as PII, is information that is capable of identifying an individual user, account, computer, or household. Note that PII need not include the actual name of an individual. That the information can refer to any of the above alone or in conjunction with other data elements linkable with that information suffices to make it PII.

Examples: A username, an agent ID, an IP address, or a tracking cookie are all examples of PII.

Personal Data includes all PII. Any additional information that one links to this PII also becomes Personal Data.

Examples: When one of the above examples of PII is combined with the contents of a Resident’s profile page, their online status, their chat, or their in-world travel behaviors, the PII and the linked data all become Personal Data."

[...]

"After Residents consent to the Second Life Terms of Service and connected Privacy Policy, Second Life presents select information about Residents to each other within the Second Life environment. This presentation is for the sole purpose of facilitating interaction within Second Life. Without a separate agreement in place (for e.g. as a sub-processor or vendor), there is no default right that any third party has to collect, store, process, or transmit a Second Life Resident’s Personal Data outside of Second Life."

The argument, as I understand it, is that the inclusion of account names and UUIDs in the category of PII renders any use of llHTTPRequest() to send agent name and location information to an external server a de facto violation of these rules because there is no "opt in" that would constitute a "separate agreement" between scriptor and resident. Or, as another person has put it, the rules make it impossible to comply because the llHTTPRequest function includes the name of of the owner of an object, and the UUID of the owner, in the outgoing headers of the request.

Thanks.    But I don't see how what that has to do with using llHTTPRequest.   

Without a separate agreement in place (for e.g. as a sub-processor or vendor), there is no default right that any third party has to collect, store, process, or transmit a Second Life Resident’s Personal Data outside of Second Life."

That's concerned with what the third party does with the data about the object owner's UUID and legacy name after they've received it, and stipulates that, whatever they're doing, they do without LL's consent.

And if the receiving site does, despite this, store or process the uuid and legacy name contained  in the x-headers, then it's up the resident whose data has been stored or processed to take the matter up with whoever is storing or processing it:

Linden Lab cannot govern activities that happen outside of the Second Life platform. Where Residents determine violations happen outside of Second Life, such as when Personal Data is presented on third-party websites without their consent, multiple options are available.

Every Resident is encouraged to begin by contacting the individual operating the site in order to achieve a peaceful resolution. This can take the form of a personal request using an email address they provide for this purpose, or by submitting a form (usually called a Data Subject Access Request) on their website to request your information to be removed.

Other options may include contacting regulators to file complaints against third-party websites, their hosting providers, or their content delivery networks where the site operator or hosting provider cannot be determined.

Residents of California can learn about their options here: [1]

Residents of the European Union and the UK can learn about their options here: [2]

https://wiki.secondlife.com/wiki/Linden_Lab_Official:Using_Personal_Data?_gl=1*1bxxpyb*_ga*MjAyMjYxOTM5Ny4xNjc1NTk1Mzk4*_ga_T7G7P6DCEC*MTY4MDI4MzI5MC40MjAuMS4xNjgwMjg2NjE4LjU5LjAuMA..*_fplc*bXQ3QlNNMXFVMFJsSnYlMkJ1RkxDS2c0MFlhSTM0bTBsQWJxN3ZGZk9NZlJLMGl0YW5MTDIxUEclMkZPbjh4Zm9OUXhLVGNyY2N4N1VLRE1uNnZTZVEydCUyQlk5Z3FVNmtwTzJOeUhmYXFJeVVnRGZ2TVBLT0E1S1BodWFYMHVNcHlRJTNEJTNE#Objecting_to_the_Use_of_Personal_Data

Fair enough.  How does this affect me as a scripter, so long as I'm not sending the data to my own website and, on receiving it, storing or otherwise processing it?   

[xDancingStarx]

38 minutes ago, EliseAnne85 said:

Each bot should be paid for and registered with LL.

It was stated several times in this thread that there is no reasonable way to enforce this. It's fine to have demands. I'd like to demand that *every* resident gets free 500L$ per week. It's kinda wishful thinking though.

This is a WoW thread from 2021, it says "blizzard fails to do anything about this bot problem". Do you know how old WoW is? https://us.forums.blizzard.com/en/wow/t/bots-in-wow/832361 and yet they can't kill the bots. Do you think that LL is more capable than Blizzard, where bots really impact the economy? Do you know how much money Blizzard is spending on that issue?

How do you wanna solve this issue? How much money do you want to spend? Do you want to enforce payment info on file when you register an account? Do you want to enforce the Linden Lab viewer and have some kind of anti cheat software in the background that may detect bot usage?

At some point of time I really think that this whole issue is blown out of proportion. People don't even only complain that bots enter their houses, but that they TP onto public land next to them. People complain about their radar "spam" of people entering and leaving the sim. Without any evidence by the way, no numbers given (which would of course be impossible since they can't know who's a bot.)

I'm online a lot, and looking at my radar I see a lot of people entering and leaving the regions within a minute. So what. I KNOW that not all of these are bots. Do I know how many of them are bots? Of course not, nobody does.

It's time to take a breath and reconsider how big of a problem we're talking about. If you ask 100 people inworld about what the current issues of SL are, I'd like to see how bots are ranking. And sorry, I just don't believe that this topic has any significant importance to the average SL user.

What are the current issues that SL has to focus on? Bots? Really? It's fine if there's a functionality easily implemented that calms down a few users who feel very agitated by this topic, but let's focus on SL's real issues.

Edited March 31, 2023 by xDancingStarx

[Love Zhaoying]

2 minutes ago, Innula Zenovka said:

Thanks.    But I don't see how what that has to do with using llHTTPRequest.   

Yeah, in general we're off the "Scripted Agent" topic, and only tangentially related due to privacy concerns. 

IMHO: Any data that can be "sent or received" via HTTP Request, can be "scraped or injected" from / into the viewer (or via API calls) using other methods. The threat of denying HTTP access to certain sites doesn't change much.

[Scylla Rhiadra]

5 minutes ago, Innula Zenovka said:

That's concerned with what the third party does with the data about the object owner's UUID and legacy name after they've received it, and stipulates that, whatever they're doing, they do without LL's consent.

Yes, thank you. I don't have expertise to be able to respond to this myself, but I see the concern from the two scriptors I've seen talk about this on Twitter as a somewhat panicked overreaction. Or maybe just resistance to anything that seems to restrict their ability to do whatever they want with code? I'm not sure, but I also find it hard to believe that LL would put this in place without considering these sorts of implications.

[Rowan Amore]

34 minutes ago, Love Zhaoying said:

That's reading a lot into it.

There really is nothing they can do about it as I mentioned earlier in the thread.  By putting that statement in there, they're only lulling people into a false sense of security.    If I had a website with lots of user info on it, using a different computer in a different location, how the heck is LL going to ban Rowan?   She runs her bots elsewhere.  Her website isn't connected to her in any way.  They may ban the bots but the privacy policy has no teeth.  The info is already out there.  They can't shut down the website.  It's up to YOU to do something about YOUR information being on that website.   So, it might not be that they have no interest, they just have no ability.

[Love Zhaoying]

2 minutes ago, Rowan Amore said:

So, it might not be that they have no interest, they just have no ability.

Yes, that's how I read "cannot", vs. the person I quoted who said "LL has no interest". 

[EliseAnne85]

25 minutes ago, Istelathis said:

Imagine if it were all a conspiracy from LL, to actively push people's views from desiring anonymous accounts to demanding we remove anonymous accounts entirely.  They are using our own paranoia against us!!

It was all a conspiracy I tells ya all 😂 

The only paranoia I have is in regards to bot armies and that it could have the potential to drive up server space which could drive up user cost were this to happen now or into the future.  My profiles are less exciting than watching paint dry.  However, invasion of privacy and disturbing the peace in one's SL home was not paranoia, it was invasion of privacy and disturbing the peace in one's own paid for SL home.  PIOF was the only tool to stop it, which also has impact to disallow other's visit one's SL home if they also have no PIOF.  

SL could also have a set up where all avi's have to go home upon log off or restart or both.  Just have new accounts where one gets a cheap junk starter box-like home with a few minimal pieces of furniture and a ChatGPT bot to ask 'how to' questions from.   Existing or new registered bots could be added to people's 'allow to set here home' and abandoned avi's could be sent to a centralized abandoned homeless resident location.  Something like that but my suggestion allows for adjustment, of course, as it's just a basic suggestion not a fully thought out plan.  My suggestion's premise of all avi's have a home is to cut down on traffic bots, so only a very small amount of avi's could be added to one's 'allow to set home here', like maybe 1 or 2 extra allowed.    

Edited March 31, 2023 by EliseAnne85

[Scylla Rhiadra]

3 minutes ago, Rowan Amore said:

There really is nothing they can do about it as I mentioned earlier in the thread.  By putting that statement in there, they're only lulling people into a false sense of security.    If I had a website with lots of user info on it, using a different computer in a different location, how the heck is LL going to ban Rowan?   She runs her bots elsewhere.  Her website isn't connected to her in any way.  They may ban the bots but the privacy policy has no teeth.  The info is already out there.  They can't shut down the website.  It's up to YOU to do something about YOUR information being on that website.   So, it might not be that they have no interest, they just have no ability.

Rowan, in effect, they already HAVE done something.

Have you looked at the website-that-cannot-be-named recently? Pretty much everything that people were objecting to is now gone, and a few things that people weren't.

It already has worked.

[Rowan Amore]

1 minute ago, Love Zhaoying said:

Yes, that's how I read "cannot", vs. the person I quoted who said "LL has no interest". 

Personally, I think they only rewrote the privacy policy in conjuction with the new scripted agent policy to make people believe they had control of the "situation".   

There is no way to stop collection of avatar (not personal) data.  Period.  All they've managed to do with all this is create yet another controversy.  Well done!

[Rowan Amore]

3 minutes ago, Scylla Rhiadra said:

Rowan, in effect, they already HAVE done something.

Have you looked at the website-that-cannot-be-named recently? Pretty much everything that people were objecting to is now gone, and a few things that people weren't.

It already has worked.

On one website that we all know about.  How many other websites are out there with our collected data?  2?  50?  Who knows?

The ONLY reason that particular website was even known about was because of the forums and a handful of people inworld.  It's the devil we don't know that neither you nor I nor LL can do anything about.

[Soft Linden]

37 minutes ago, Scylla Rhiadra said:

@Innula Zenovka

The argument, as I understand it, is that the inclusion of account names and UUIDs in the category of PII renders any use of llHTTPRequest() to send agent name and location information to an external server a de facto violation of these rules because there is no "opt in" that would constitute a "separate agreement" between scriptor and resident. Or, as another person has put it, the rules make it impossible to comply because the llHTTPRequest function includes the name of of the owner of an object, and the UUID of the owner, in the outgoing headers of the request.

Your best practices: Be transparent, and establish consent. For scripted objects that need to communicate with external servers in order to perform a function for the user, it's a good practice to have scripted objects disclose this fact to the resident in a notecard or in a dialog before using the device. If scripters are transparent about activities that could impact resident privacy and the resident then continues to use the script, then there is consent.

A good example: A mesh body might include a notecard saying "Wearing this HUD will communicate with a web service that tracks who purchased this body. I do this so I can advise about updates and sales. I don't share this data with anyone else. If you wish to opt out, send me a notecard." It says what data will be shared through what action, what that data might be used for, and gives users a way to revoke consent.

Hopefully that doesn't seem like too much of a burden.

A bad example: A mesh body quietly adds the resident name, a slurl for where the resident unpacked the item, and a list of nearby people to a list without even telling the resident. The scripter doesn't disclose this fact. This means there was no transparency or consent. The resident has no idea that their home location or nearby friends are now in a list somewhere.

That's kind of gross, isn't it? Yet there are scripts that do that today.

There may be clarifications or updates to the policy and Using Personal Data explainer as we see what some of the common questions are. And obviously, Linden Lab isn't going to rush through and retroactively police every last legacy script. But do report egregious cases where you learn about them. See the Scripted Agent Policy for what to report and how.

[Scylla Rhiadra]

1 minute ago, Soft Linden said:

A good example: A mesh body might include a notecard saying "Wearing this HUD will communicate with a web service that tracks who purchased this body. I do this so I can advise about updates and sales. I don't share this data with anyone else. If you wish to opt out, send me a notecard." It says what data will be shared through what action, what that data might be used for, and gives users a way to revoke consent.

Now, there's a case -- an important one -- that hadn't even occurred to me.

I really am just liking this more and more. Thank you, Soft.

[Love Zhaoying]

15 minutes ago, Scylla Rhiadra said:

Have you looked at the website-that-cannot-be-named recently? Pretty much everything that people were objecting to is now gone, and a few things that people weren't.

It already has worked.

I suspect some of the changes on "that" website were due to negotiations between LL and "that" company - as we were told there were meetings between the two. That does not necessarily reflect how other companies - less "friendly" companies - will respond to any changes or threats to their existance.

That being said, the steps taken are positive - for some people.  Help as many as you can / the majority (except mainland / parcel holders), hurt the minority (those who market / sell / USE bots but are impacted / etc.) Seems the way to go, and of course here, on this thread, the "minority" is very vocal...as expected. 

There really have not been any surprises about all this, except for me, that LL started with Belliseria. It makes a big statement.

[Love Zhaoying]

13 minutes ago, Soft Linden said:

A good example: A mesh body might include a notecard saying "Wearing this HUD will communicate with a web service that tracks who purchased this body. I do this so I can advise about updates and sales. I don't share this data with anyone else. If you wish to opt out, send me a notecard." It says what data will be shared through what action, what that data might be used for, and gives users a way to revoke consent.

Hopefully that doesn't seem like too much of a burden.

A bad example: A mesh body quietly adds the resident name, a slurl for where the resident unpacked the item, and a list of nearby people to a list without even telling the resident. The scripter doesn't disclose this fact. This means there was no transparency or consent. The resident has no idea that their home location or nearby friends are now in a list somewhere.

That's kind of gross, isn't it? Yet there are scripts that do that today.

Awesome, thanks Soft! 

Plus for our consideration, those products that communicate with external servers / services - gee, when their server stops working and all their products break - that sure is a hassle!  

[Scylla Rhiadra]

Just now, Love Zhaoying said:

That does not necessarily reflect how other companies - less "friendly" companies - will respond to any changes or threats to their existance.

No, that is terra incognita. But what the new policies do is, as I say, give LL the justification in their own ToS to move against data scraping operations (remember that "scripted agent" is a term that no longer only applies to bots!) in-world that are misusing the information. Throttle their supply of data, and most operations that are not merely one-off attempts to wreak havoc will die.

[belindacarson]

I LOVE the GDPR

 

now to file a GDPR ticket.

[Soft Linden]

2 hours ago, Scylla Rhiadra said:

I think that this is very much to the point, Elise. Most bad-faith or non-allowed use of personal information ("PII" in LL's formulation) will be manifested visibly somewhere, probably online, or perhaps in a region or in a product on the Marketplace (which is why I find it interesting that they have redefined "scripted agent" to include non-bot applications as well). LL has now empowered themselves to act against the operations in-world that are collecting the PII used for such visible articulations of a given project.

 

Of note: The "PII" definition in the Using Personal Data guidance isn't our own formulation. It's a superset of the concepts from multiple regulations. For example, "capable of identifying an individual or household" is a qualifier in California regulations, while other aspects are from European Union regulations. We've attempted to provide some safe guidance for people who want to do very basic things when dealing with a global user base. But as the guide emphasizes, it's no replacement for reading all applicable regulations and/or seeking guidance from a privacy attorney.

The "Using Personal Data" guide points to global privacy regulations that exist outside of Second Life. This is an important distinction, which is why we opted to carve out that guide and put it outside any Policy document.

But yes, the goal of a policy update is to give Linden Lab the ability to act based on documented standards. And we want to give well-intentioned creators some guidance on supporting privacy and safety for everybody!

[bunboxmomo]

37 minutes ago, Soft Linden said:

Your best practices: Be transparent, and establish consent. For scripted objects that need to communicate with external servers in order to perform a function for the user, it's a good practice to have scripted objects disclose this fact to the resident in a notecard or in a dialog before using the device. If scripters are transparent about activities that could impact resident privacy and the resident then continues to use the script, then there is consent.

A good example: A mesh body might include a notecard saying "Wearing this HUD will communicate with a web service that tracks who purchased this body. I do this so I can advise about updates and sales. I don't share this data with anyone else. If you wish to opt out, send me a notecard." It says what data will be shared through what action, what that data might be used for, and gives users a way to revoke consent.

Hopefully that doesn't seem like too much of a burden.

A bad example: A mesh body quietly adds the resident name, a slurl for where the resident unpacked the item, and a list of nearby people to a list without even telling the resident. The scripter doesn't disclose this fact. This means there was no transparency or consent. The resident has no idea that their home location or nearby friends are now in a list somewhere.

That's kind of gross, isn't it? Yet there are scripts that do that today.

There may be clarifications or updates to the policy and Using Personal Data explainer as we see what some of the common questions are. And obviously, Linden Lab isn't going to rush through and retroactively police every last legacy script. But do report egregious cases where you learn about them. See the Scripted Agent Policy for what to report and how.

Soft, what you're saying makes sense for the first half of it. I think thats pretty reasonable and I hope other scripters choose to do that too. I don't "phone home" in secret in any of mine, and never intend to, I like the way you phrased the disclaimer, thats pretty good and I'll make use of that in any future scripts of mine if they do need to phone home for whatever purpose.

 

However, regarding the second half your comment, it doesn't really address the concern.

Included below, is an image showing several (but not all) of the default headers included in any outgoing request made by llHTTPRequest(). This is how the function is today, as written by Linden Labs.

As it currently is, any outgoing request, by default unless explicitly *removed*, not added, by the user from the default LL headers (if that's even possible), will include

• The username of the owner of the object (This is considered PII information as of today.)
• The UUID of the owner of the object (This is considered PII information as of today.)
• The name and key of the object itself (I feel this is something some residents might find concerning)
• XYZ position data, Rotation data and even velocity of movement (which includes direction of movement for non scripters) (This is far more information than BonnieBots ever collected from my understanding)

The problem and concern being raised, is a LL function, by default, as it is implemented in the LSL library, is giving out information with every request, regardless of if a scripter is employing good practices or not, because this information is in the header, not the body.

As a result, since these are in the headers, this means any httprequest, no matter how benign and regardless of good faith efforts to comply with the PII policy, will still contain data that is considered protected *and* data ontop of that which was the basis of resident's concerns with bonniebots.

Due to this it makes it functionally impossible to comply with the PII good practices/suggestions document and is raising significant concerns about the use of HTTPRequests in their current form and if the PII policy as written is even viable containing username and UUID data for this reason, including basic operation within SL as it is in terms of UUIDs.

We need clarification on this, either in the policy being edited, or the function being edited, becauase as this is currently is, this is not possible to comply with due to this blocking issue on the implementation of llHTTPRequest in LSL.

This also affects over a decade worth of code it should be mentioned.

Edited March 31, 2023 by bunboxmomo