Jump to content

New Feature: Scripted Agent Estate Access Discussion


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

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

Recommended Posts

  • Lindens
7 minutes ago, belindacarson said:

I LOVE the GDPR xD

 

With no irony whatsoever, GDPR is a wonderful tool... even if we all have to see silly cookie consent banners.

It has done much good work in increasing transparency and consent across most of the online tech space. If a website collects, stores, transmits, or processes Personal Data, you can look at the Privacy Policy to see how they justify it and how to opt-out.

If you don't find those detailed in a site's Privacy Policy (or if they don't have a Privacy Policy at all!) and you're a European or UK citizen, you have some recourse. And not only that, it has teeth! Regulators have issued fines against giants like Google, and against individual actors alike.

While most of those pertain to website activity or data broker activity, that's because those are the most common avenues for data collection, storage, processing, and transmission. But the GDPR applies to all contexts where UK and EU Data Subjects are involved.

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

8 hours ago, Soft Linden said:

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!

Let us be clear on ONE thing: Soft Linden is a TRUE and FAIR advocate of a user's right to privacy.  Soft was practically the only Linden who helped out over the RedZone fiasco years ago.

Edited by belindacarson
  • Like 3
  • Haha 1
Link to comment
Share on other sites

3 hours ago, Silent Mistwalker said:

This is the Access Tab under About Land for a parcel. Note the section for Allowed Residents. Here you can enter your botalts so that the estate bot ban doesn't affect YOUR bots on YOUR land.

🤔

V1.23_About_Land-Access.jpg

 

Edit: Mainlanders may or may not have access to use that list. Not having access to such features on mainland is one of the many, many reasons I haven't lived on mainland since 2006.

 

 

That is a Parcel Access panel, not an Estate panel, it has exactly NO effect on estate level bot-bans, none.

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

19 minutes ago, Zalificent Corvinus said:

That is the potential problem here, a massive increase in fraudulent AR's, resulting in a massive reduction in handling quality, because there are not enough hours in the day.

There's already a potential enhancement to this potential problem. It seems the bot problem has suddenly become even worse on mainland, because they are now banned from a massive number of regions. With less regions to do, each bot's new cycle begins over again that much sooner. So, this is likely to heighten botphobia even more than it already is among mainland dwellers.

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

1 hour ago, Rowan Amore said:

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.

I'm sorry Rowan that you went to all that trouble only to find out that I still am not taking about using the new feature in any shape or form. I am taking about using a tool that has been in About Land for more than 15 years.

Of course, it can only happen on those regions the new feature has NOT be enabled on. 

The only reason I am posting again is so that you might understand that I am not referring to the new bot estate tool at all when I say it is possible to add bots to a parcel's Allowed list the same as they can be added to a parcel's ban list. It is no different than adding a regular account, but people seem to be completely ignoring that.

*switches back to read only mode

Link to comment
Share on other sites

  • Lindens
9 minutes ago, bunboxmomo said:

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.
de6681d720a3b230cc34a9c8764e73a4.png

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.

 
 

As a best practice, err on the side of transparency and disclose which of the data fields you store and use. We'll discuss this internally and add guidance to the Policy and Using Personal Data page if there's agreement on a need to clarify, or a need to alter how the web and email functions work. We're always cautious about breaking old content, of course, and so the default behaviors wouldn't change without discussion and a lot of advance notice.

If you're really anxious and don't want anyone to claim you don't comply down to the letter, you can disclose that you use llHTTPRequest and link to the LSL guide with the table above that shows what's transmitted. But simply disclosing that you make web requests is reasonable if you're not consuming the extra fields.

 

9 minutes ago, bunboxmomo said:

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.

 
 

For cases where somebody's using the only functions that exist, Linden Lab isn't going to rush through and retroactively police every legacy script. Assume we're building a bridge toward enabling better privacy and safety practices, but also trust that we're being pragmatic and taking measured steps in order to minimize disruption for well-intentioned scripters.

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

29 minutes ago, Zalificent Corvinus said:

Actually my "bs" does fly, and better than most, because you basically missed the whole damn point.

 

You are quite correct that the case  of a friend being threatened with an AR for asking some asshat to sod off, would not have gotten her banned, but, it would have taken up time for a Governance Linden, to pull up the chat logs and say "what a worthless bs AR, filed in the trashcan...".

Every fraudulent "worthless trash" AR takes up time, now the point here is, imagine you are a Governance Linden, you average 5 mins per AR, some are mere 60 second jobs, some take a lot longer, but average handling time, 5 mins, 12 AR's an hour, 8 hours a day, and you asnd the team are already a couple of days behind.

Then as a useless placebo appeasment gesture to some bunch of pathetic whiners, some clueless admin type puts in a NEW rule, that increases your workload 900%.

Thern your line manager tells you that you have to get creative and cut handling time from 5 mins to 3 mins, to reduce the massive backlog, and no they won't take on extra staff, because staff cost money and this was supposed to be a NO-Cost useless  placebo, with the sole intention of getting the whiners to STFU.

That is the potential problem here, a massive increase in fraudulent AR's, resulting in a massive reduction in handling quality, because there are not enough hours in the day.

 

And yet the Lindens themselves have been telling the residents when in doubt AR it and let the LINDENS DECIDE for nearly 20 years. Imagine that.

  • Like 2
Link to comment
Share on other sites

20 minutes ago, M Peccable said:

There's already a potential enhancement to this potential problem. It seems the bot problem has suddenly become even worse on mainland, because they are now banned from a massive number of regions. With less regions to do, each bot's new cycle begins over again that much sooner. So, this is likely to heighten botphobia even more than it already is among mainland dwellers.

"Problem"? They are mostly just annoying. 

Link to comment
Share on other sites

7 minutes ago, Soft Linden said:

For cases where somebody's using the only functions that exist, Linden Lab isn't going to rush through and retroactively police every legacy script. Assume we're building a bridge toward enabling better privacy and safety practices, but also trust that we're being pragmatic and taking measured steps in order to minimize disruption for well-intentioned scripters.

I've seen this concern articulated on Twitter a few times now, and have assumed that LL isn't about to start breaking content or throwing people into the cornfield unless there is a pretty egregious violation.

This is an instance where articulating broader principles rather than listing specific cases is useful: it makes the spirit of the new policy clear, while providing freedom of action to LL, and enough room to exercise judgement.

  • Like 1
Link to comment
Share on other sites

6 minutes ago, Silent Mistwalker said:

I'm sorry Rowan that you went to all that trouble only to find out that I still am not taking about using the new feature in any shape or form. I am taking about using a tool that has been in About Land for more than 15 years.

Of course, it can only happen on those regions the new feature has NOT be enabled on. 

The only reason I am posting again is so that you might understand that I am not referring to the new bot estate tool at all when I say it is possible to add bots to a parcel's Allowed list the same as they can be added to a parcel's ban list. It is no different than adding a regular account, but people seem to be completely ignoring that.

 

But that's not what you replied to...

 

4 hours ago, Rowan Amore said:

If you're renting on a private estate, the owner needs to add your bots to the estate whitelist.   There is no per parcel whitelisting of bots.  That's what part of the debate is about.   The only people who have control per the new anti bot setting are private estate owners.

 

3 hours 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.

 

3 hours ago, Silent Mistwalker said:

My point is you do not have to have access to the estate tools when you have access to your parcel tools to whitelist any account be it registered agent or not. If that were the case, you'd have to ask your landlord to add someone to the estate ban list so it could be added to your parcel ban list every time you want to add or remove someone from your parcel list. It doesn't work that way.

I don't think I'm getting what I'm seeing across to people so I'm just going to bow out.

We ALL know you could add people/bots to your parcel access/ban list.  This debate/thread is specifically about Private estates that have enabled the Anti Bot settings.

 

  • Like 1
Link to comment
Share on other sites

3 minutes ago, Silent Mistwalker said:

And yet the Lindens themselves have been telling the residents when in doubt AR it and let the LINDENS DECIDE for nearly 20 years. Imagine that.

Looking at the forum's land section we see proof of objectively valid ARs taking ages. I personally experienced this issue as well. I know that LL promotes the behaviour to send an AR if in doubt, but that doesn't change the fact that there already is an issue with an overload of ARs at this present time.

  • Thanks 1
Link to comment
Share on other sites

16 minutes ago, Soft Linden said:

As a best practice, err on the side of transparency and disclose which of the data fields you store and use. We'll discuss this internally and add guidance to the Policy and Using Personal Data page if there's agreement on a need to clarify, or a need to alter how the web and email functions work. We're always cautious about breaking old content, of course, and so the default behaviors wouldn't change without discussion and a lot of advance notice.

Yeah that'ts the paradox I'm potentially seeing here, because on one hand you're telling us we should get informed consent, and I agree when it comes to the body of the request, yeah 100% agreed. It'll be a cultural change, but seems a good enough one honestly.

But with headers, that's a little different and like you said changing those functions can do a whole lot of damage to the grid, given how integral llHTTPRequest is and how long it's had those headers for. Changing that can break a lot of functionality real fast. So it's a bit of a catch 22 here as far as I can tell.

The only real solution seems to be to just, ignore the PII advice due to the constraints when it comes to the existence of that data in headers, or just dont use HTTPRequests, until either the function is changed or the policy is changed/clarified for an exception perhaps on header transmission and isntead onus put on the context of the use case on the remote side?

The other thing though is, those headers also contain snapshots of data on XYZ positions, rotations and velocity, which as far as I can tell conflicts with the spirit of the intent behind the recent changes with regards to scritped agents, even if not the letter of things.

I'm not sure how that one could be worked around, without risking significant damage to existing scripts built over the decade by residents, but good luck with that, genuinely. I'm sure you'll work something out over at LL.

 

Quote

If you're really anxious and don't want anyone to claim you don't comply down to the letter, you can disclose that you use llHTTPRequest and link to the LSL guide with the table above that shows what's transmitted. But simply disclosing that you make web requests is reasonable if you're not consuming the extra fields.

I wouldn't say I'm anxious about it, I just want to be able to be a responsible scripter with my scripting, but I can't help but see a conflict here in the way the policy functions vs the way the function...functions? So thats my point of concern.
I am a bit concerned if this was an oversight in the drafting of the policy, or if this was known about but just not included in the wording?

Since llHTTPRequest is such an important function for web integration, which is a big part of the modern web and SL's ability to integrate with it, contradictions concerning that function and it's future status is naturally concerning from a LSL developer side of things and if this might mean future difficulties with interfacing with APIs readily in the grid as part of the modern internet. I've been encouraged by the discussion on recent labgabs, but part of me feels this change presents what feels like clash with the stated vision in SL's future, given how much of a core function this is to the ability for SL to fit into an increasingly microservice driven web, if SL is to grow into the modern internet like it currently is.

Essentially, given the importance of that function in that context, it's future status given today's communications is something I was concerned about and as much as I appreciate you taking the time to reply, do hope for some clarification regarding the status of llHTTPRequest in the future going forwards, though I know you probably aren't able to give that right now just on a whim without that being discussed as you mentioned.

 

Quote

trust that we're being pragmatic and taking measured steps in order to minimize disruption for well-intentioned scripters.

Appreciated thank you!

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

8 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?

67cfc6190296ed5e3bd5a07294f5d581.png

https://wiki.secondlife.com/wiki/Linden_Lab_Official:Using_Personal_Data

"Agents" in LSL, refers to users, so this would be the UUID36.

Under the PII policy as written, we cannot transmit your UUID36 or your legacy name (username) out of SL, or send any transmission that includes this information embedded in it (such as headers), without explicitly informed consent on the transmission being there as part of the script.

The context of the above conversation is that both your UUID36 and your username are in the headers of llHTTPRequest by default (and not sure if they can even be removed by the scripter), so presents a sort of blocking issue here. (Also some additional information that such as position data, which while not in the PII category, is related to the spirit of the concerns from some residents that informed the fear around bots and the recent changes)

As soft has said, consent needs to be obtained, which means explicitly asking for consent for any script sending any HTTP Request.

Soft has said they are going to internally discuss this at LL and we will learn of the outcome, if any, at a later point.

Theres the summary of the above conversation and why those SL identifiers are coming up in PII discussion.

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

3 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?

Patch said in another post they were taking advice from a GDPR specialist.

  • Like 1
Link to comment
Share on other sites

37 minutes ago, M Peccable said:

There's already a potential enhancement to this potential problem. It seems the bot problem has suddenly become even worse on mainland, because they are now banned from a massive number of regions. With less regions to do, each bot's new cycle begins over again that much sooner. So, this is likely to heighten botphobia even more than it already is among mainland dwellers.

I should think that any sudden increase in the number of bots on Mainland is likely to be temporary, while bot operations recalibrate to account for the new situation. No one is going to waste resources by continuing to send the same number of bots out to cover a much smaller field available to them. That situation will rectify itself -- although, again, I'd like to see a parcel level tool that permits landowners on the Mainland make this choice themselves as well.

Nor, honestly, can I imagine a sudden flurry of ARs against bots. For one thing, the prohibition against unregistered bots is not new: that was in existing policy. Secondly, I just don't think people are going to see a sufficient number of "maybe unregistered bots" to create a storm of ARs.

And thirdly, most residents will remain blissfully unaware of these new policies anyway. And many of those who do know of them won't care, or won't care enough to issue ARs.

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

5 minutes ago, Scylla Rhiadra said:

I should think that any sudden increase in the number of bots on Mainland is likely to be temporary, while bot operations recalibrate to account for the new situation. No one is going to waste resources by continuing to send the same number of bots out to cover a much smaller field available to them.

Some of the abusers boast about how many regions they can do a day. I doubt those folks will be doing any adjustments, unless it is tweaks to make the bots even faster.

Link to comment
Share on other sites

5 minutes ago, Scylla Rhiadra said:

most residents will remain blissfully unaware of

..and many of us..ME..will remain blissfully unaware of any increase in Mainland bots! My own Second Life pattern use makes it extremely unlikely that I will encounter bots, even though I live on a mainland parcel. I must assume (by extension) that this really applies to most Second Life users. The affected users are, by deduction, in the minority.

Link to comment
Share on other sites

8 minutes ago, Scylla Rhiadra said:

And thirdly, most residents will remain blissfully unaware of these new policies anyway.

I don't think that's a fair assessment.
There are many services that residents take for granted that are now impacted as a result of this change.
While residents are unlikely to see the direct cause of this change, they are likely to see degradation of service over the coming weeks as data that many scripters rely on for various widely used products in SL will now have an inceasingly unreliable ability to provide their function.
This is an aspect residents will notice, and I do think it's important to, even if this is something you feel is fine, consider this is an impact of this change.

With the HTTPRequest aspect, depending on how that plays out that could have a much larger impact in the time ahead, but the lindens are going to discuss this ahead as stated by Soft in our above conversation.

When it comes to serious topics like this, its best to consider things for all their impacts, rather than just the ones we're directly concerned about.

  • Like 2
Link to comment
Share on other sites

1 minute ago, bunboxmomo said:

I don't think that's a fair assessment.
There are many services that residents take for granted that are now impacted as a result of this change.
While residents are unlikely to see the direct cause of this change, they are likely to see degradation of service over the coming weeks as data that many scripters rely on for various widely used products in SL will now have an inceasingly unreliable ability to provide their function.
This is an aspect residents will notice, and I do think it's important to, even if this is something you feel is fine, consider this is an impact of this change.

With the HTTPRequest aspect, depending on how that plays out that could have a much larger impact in the time ahead, but the lindens are going to discuss this ahead as stated by Soft in our above conversation.

When it comes to serious topics like this, its best to consider things for all their impacts, rather than just the ones we're directly concerned about.

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.

  • Like 1
Link to comment
Share on other sites

26 minutes ago, Rowan Amore said:

But that's not what you replied to...

 

 

 

We ALL know you could add people/bots to your parcel access/ban list.  This debate/thread is specifically about Private estates that have enabled the Anti Bot settings.

 

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).

Link to comment
Share on other sites

36 minutes ago, xDancingStarx said:

Looking at the forum's land section we see proof of objectively valid ARs taking ages. I personally experienced this issue as well. I know that LL promotes the behaviour to send an AR if in doubt, but that doesn't change the fact that there already is an issue with an overload of ARs at this present time.

I never said it did. I've been in SL since 2004 and I am very familiar with how LL does and doesn't do things. There will always be an overload of ARs simply because LL no longer staffs as many employees as they once did. There was a time when LL did pay people to do just ARs. It's no longer financially feasible for LL to continue and hasn't been for more than a decade.

Edited by Silent Mistwalker
Link to comment
Share on other sites

18 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.

You can thank RedZone and zFire Xue for that. 😉

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 442 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...