Jump to content

Soft Linden

Lindens
  • Posts

    65
  • Joined

Reputation

361 Excellent

7 Followers

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. You're sure it's not a coincidence? Scripted agents aren't supposed to contribute to traffic. Or are people not TPing in because they don't see someone on the map, where they saw a bot or two as green dots before?
  2. Since we're talking about global privacy laws and not Linden ToS, you'd need to consult with a privacy attorney to get a definitive yes. Sadly, that's the nature of most laws. It's easy to find out if you're in violation, but hard to get certainty about being in the clear. The people who spend a decade learning every edge case and caveat want compensation for that. Certainly, nobody at Linden Lab would flag it as a poor practice, though. That level of attention to user privacy is commendable.
  3. There's a trick that some sites use if they want to determine whether a given IP address is seen for the first time in a given sample period, but where they also want to preserve user anonymity: 1. Hash the IP address (could also be an agent ID in this case) 2. Keep only the last 3-4 hex digits of the hash for 4,096 or 65,536 possible values If the truncated hash matches a previously stored hash, the site knows that the user *probably* visited, but they don't know for certain. There's the tiny possibility of a collision; a collision is when two different input values produce the same output value. However, if a bad actor got a hold of the list of hashes, 3-4 hex digits doesn't begin to tell them the actual IP addresses. If we assume IPv4 with 4 billion values, even the 4-digit truncated hash points to an average of 65,536 possible IPs per truncated hash result. If you apply this to something like a script that tallies unique visitors each day, if you hash the agent IDs and kept only 3 hex digits, the chances of collision would be very low for even a busy region, and each hash result would point to over 17,000 possible accounts. 4 hex digits would have a near zero error rate, and each hash result would still point to over 1,000 possible accounts.
  4. They can pry the 8 megs of resizing and retexturing scripts out of my cold, dead 250-prim hands…
  5. 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.
  6. Remind me to come back tomorrow to explain how to apply soundproof textures to Linden homes.
  7. Some related background: Parcels have an option that makes users invisible to people who aren't on the parcel. I made a deliberate choice to have this option work in both directions: if users opt to be invisible to neighbors, the neighbors aren't visible to them. The other devs agreed. We wanted to provide a disincentive to using the feature when unnecessary. People have a natural tendency to want privacy for themselves while being curious about the affairs of others. The worry was that if people could enjoy the advantage of becoming invisible spies, most every parcel would end up with the invisibility flag set and it would ruin the connected experience of adjoining parcels. I expect we would opt against a one-way privacy prim for the very same reason.
  8. 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.
  9. 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!
  10. 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. 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.
  11. 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.
  12. 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!
  13. 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.
  14. I pointed it out, but you'll find a link in the Scripted Agent Policy that was blogged today. See the "Using Personal Data" link within that policy. Of note, the Scripted Agent Policy was previously named the Bot Policy. "Scripted Agent" is a term that's inclusive of what people often call a "Bot."
  15. Linden Lab does not sell customer information, not even non-identifying information like friend lists. We have never done so in the past either. We're aware of other companies that do this, and most of us find that practice to be creepy and an abuse of customer trust. If you ever came to suspect that we changed our minds on this, you could look at our Privacy Policy. We would be required by law to disclose the practice there. Making companies disclose this practice is one of the great benefits of new privacy regulations.
×
×
  • Create New...