Jump to content

Soft Linden

Lindens
  • Posts

    66
  • Joined

Posts posted by Soft Linden

  1. On 3/25/2024 at 11:17 PM, Bubblesort Triskaidekaphobia said:

    My first reaction to this was... isn't WebRTC a security liability?  I have a plugin for my browser that blocks WebRTC, unless I want to run it, because it can expose your IP address, even through a VPN tunnel (similar to how Shoutcast exposes it).  This is not a bug that WebRTC intends to patch.  They say it is foundational to the technology.

    When I read that LL is working on preventing that kind of leakage with a firewall, though, I was relieved.  I have no problem running their WebRTC, if the security concerns are addressed.

    For Second Life's use of WebRTC voice, all connections will be made between the viewer and Second Life servers, even for single-user direct voice calls. The only party that voice services WebRTC shares your IP with is Linden Lab.

    This is different from the existing voice solution, which uses peer-to-peer connections for single-user direct voice calls, enabling IP discovery if a user accepts a single-user voice call.

    • Like 2
    • Thanks 5
  2. 29 minutes ago, WereBeast Alpha said:

    For anyone who has it enabled this is my current traffic on my RP sim. Whereas before I was getting over 200 a day. Since enabling the bot traffic ban my traffic level has dropped. 

     

    Screenshot 2023-04-01 121107.png

     

    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?

    • Like 5
  3. 11 minutes ago, Love Zhaoying said:

    I think the question has come up: does doing this hash, and saving it externally, comply with the GDPR? I assume "yes",

     
     

    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.

    • Like 2
    • Thanks 1
  4. 1 hour ago, xDancingStarx said:

    This is not true according to my knowledge and information, though.

    "In comparison, in the context of the European GDPR, the Article 29 Working Party[6] considered hashing to be a technique for pseudonymization that “reduces the linkability of a dataset with the original identity of a data subject” and thus “is a useful security measure,” but is “not a method of anonymisation.”[7] In other words, from the perspective of the Article 29 Working Party, while hashing might be a useful security technique, it is not sufficient to convert personal data into deidentified data."

    https://www.gtlaw-dataprivacydish.com/2021/03/what-is-hashing-and-does-it-help-avoid-the-obligations-imposed-by-the-new-privacy-regulations/

     

    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.

    • Like 6
    • Thanks 3
  5. 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
  6. On 3/29/2023 at 1:20 AM, Milissa Rossini said:

    I was always thinking if there has any prim has function that enable any thing or avatar within it becoming invisible from outside, but any avatar within the prim can see outside. If we have such prim, we can really make a house, vehicle, room with real privacy like in real world.

     

    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.

    • Like 3
  7. 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
  8. 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
  9. 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
  10. 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!

    • Like 2
    • Thanks 8
  11. 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.

    • Thanks 15
  12. 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.

    • Like 4
    • Thanks 8
  13. 6 minutes ago, RowanMinx said:

    You may be correct about it being a booty clapper yet I do know people who have their physics turned up to almost this level of whack.

    It's probably a ton of fun for them when the camera's following behind, so I'm not one to judge. More power to them if they want to pin those sliders to MAX.

    Just pray they stay out of the narrow aisles at the antique shop. 😜

    • Like 1
    • Haha 8
  14. 12 hours ago, RowanMinx said:

    Why they even added an option for belly jiggle is beyond me.

    There was an expectation that people would be more comfortable with the addition of a general body physics system than a Baywatch-only mode.

    I was skeptical myself, but a number of people reacted positively. The combination of that and putting the physics options under the wearer’s control probably saved us from the upset that the Emerald version caused. The Emerald version was a great innovation from a feature standpoint, but the reactions to that version were also incredibly strong. Half the users demanded that we add the same option immediately, and half expressed hurt or concern.

    • Thanks 2
  15. On 1/5/2021 at 3:33 PM, Desiree Moonwinder said:

    Do you think its coincidental that the number of groups (i.e., 42) just happens to be the same as "The Answer to the Ultimate Question of Life, The Universe, and Everything," as told in The Hitchhiker's Guide to the Galaxy by Douglas Adams?

    It is not a coincidence. ❤️

    • Like 1
    • Thanks 1
    • Haha 1
  16. 1 hour ago, Ardy Lay said:

    I keep myself calm by telling myself that investors that know and like Second Life bought out investors that were no longer interested in what Second Life has become.

    Long-term investments work differently than what's in many of the previous investors' portfolios. Often it's not a case of whether investors like the companies they own; it's about maintaining a portfolio of companies that benefit from an investor's particular expertise.

    At this point, Second Life is appropriate for an owner who has expertise in long-term sustainability. It's not a flashy startup anymore. My perception is that an owner with long-term expertise is where we've ended up. I don't see Second Life as having passed into the hands of somebody who wants it to be something other than Second Life. If nobody told you about the sale, I'd be surprised if many of us even noticed it for a long time.

    You'll hear more when everybody is ready, but this was a long process of mutual selection. This isn't one of those stories where the company went to the first person willing to write a big check.

    • Like 2
    • Thanks 12
  17. On 3/15/2020 at 11:34 PM, Axelfoxthefoxyfluff said:

    I mean like toxic people who don't seem to know or care that when they are acting mean, that they are hurting real people with how they act.

    The initial question here was really smart. Many people don't understand that some people are oblivious to how they act. Or they don't understand the ways that others are likely to perceive their actions. Combine someone who's oblivious to how they are perceived with somebody who's certain every slight is deliberate? That's where the really dramatic clashes begin.

    • Like 10
×
×
  • Create New...