Soft Linden

For a while premium-only destinations there were open to all. Reverting to the current state was intentional and a part of testing, but it's not indicative of a broader trend on the beta grid. If anything, we'd like more users testing and filing bug reports on aditi. Closing access would hurt that cause. If anyone else wants to get on aditi and doesn't already know how, you can find more details here: http://wiki.secondlife.com/wiki/Aditi

May I steal that for my first-life profile?

Thank you! I saw the tweet. While I'm not part of marketing, I'll make sure they get a link to this discussion. In the mean time, are there examples of other companies' marketing which you think our team should look to for inspiration or positive examples? Have you seen Second Life user-generated materials where you thought to yourself, "the Linden Lab marketing team should have been the ones doing this?" Those aren't just questions for Luca. I'm sure they'd value any useful examples or inspiration.

So far I’m not able to get this to come up. I’ll keep trying, but if any of you still see it would you help by reporting it here? https://about.ads.microsoft.com/en-us/resources/policies/report-spam-form

Okay, these are getting fun ❤️

No disagreement on anything you've said. And yes, Google warns about putting their tag manager in an iframe: But between you and me, sometimes that's a feature. Even where there is a business need for these tags to be present (we don't add them on this particular page ourselves), it can be helpful to minimize the granularity of information provided.

Hey, Animats. This is a good area for us to investigate. As a rule, we tightly control which partners are in a position to access personal information. I can count those vendors without running out of fingers, and none of them are marketers. You may have seen that we make liberal use of iframes to limit the scope of DOM access on any page where PII, payment data, email addresses, etc are presented. This means that even if a request shows up in the network log, it doesn't mean the third party was in a position to access the contents of the page. A hypothetical bad actor who gained control of those services could not access the personal information presented on a page with appropriate isolation. I'm going to open up a conversation with our identity verification vendor to review their form page. I see that they have a similar approach for some of those script inclusions, such as the Google Tag Manager sandboxed in an iframe. But I want them to detail what kind of controls are in place for the A/B testing script they include from a third party, and for the additional inclusions that stem from that. I'll also push for them to add additional isolation unless they can demonstrate appropriate compensating controls.

This is an interesting request/proposal. I suspect payment info on file isn't a terribly strong indicator of the quality of messages coming from an account. But there's value in letting individuals have the tools to make their own choices. For example, the more heavily griefed sandboxes have had good success with requiring manual invites for people without payment info on file. If you had the ability to restrict IMs from users without PIOF, how would you want that to work if you had sent an IM to the non-PIOF person first? Or if you had sent them L$ or inventory? Would that exempt them? How would you want this to work with ad-hoc chats? (For example, chats created by selecting a group of contact cards) Presumably you would also want anyone on your friend list to be exempt as well. Are there other users who should be exempt? Also, how big of a problem is this really solving? How many of you are frequently approached by a series of fresh anonymous accounts, and how big of a deal is it for you to block them?

I didn't want to guess wrong on your tweed jacket size. But no, we're in a category of business that extends well beyond the IRS. It would be wonderful if it were still that simple! I'll ask our own beloved tweed team if they'd ever consider blogging about the fun they have.

I laughed. But this is largely true. In the short term, Tilia is merely us formalizing an internal segmentation that already existed. The additional paperwork around cashouts is stuff that was coming whether we put a new name on the group or not. We can't control what regulators require of us. In the long term, we want to undertake some significant projects in the payments and security space which will be expensive to implement. Income from SL alone wouldn't pay for these projects without our absorbing some big losses. To address this, we aim to offer Tilia services to additional companies. This will help us distribute many of the costs of projects and services across more companies. In turn, these additional projects will benefit all Tilia customers, including SL. Beyond that, the separate business entity also saves a lot of hair pulling for the legal and finance teams. Take a little trip with me... Imagine sitting down with a team of external regulatory representatives. They're used to talking to a category of businesses that all look nearly identical. Dollars in, dollars out. They like it that way. It's simple. They do yearly audits, make sure everything the business does follows the most boring format possible. Again, boring and predictable makes them happy. You've never seen so much tweed. You'll never see so many flip phones used unironically. One guy on the external team just got Angry Birds. That's Bill. Bill is the cool guy, but the rest of the team is a little skeptical about Bill. Bill's phone doesn't even flip, and that seems kind of edgy. This whole group gets paid by the hour, and in many cases you get to foot the cost of both sides of these engagements. Multiply this by a bunch of states and countries. The way the world is changing, soon it will be nearly all 50 states with different groups of tweed people, and half again as many for countries overseas. Never bet against bureaucracy. You get the picture. This is expensive, frustrating, and time consuming, right? It's worse than you think. Because now imagine that you aren't just explaining the US$ pages. Imagine that you have to take a detour through explaining all of Second Life, Sansar, and Blocksworld. Bill's got all kinds of questions about furries, and it's making the rest of his team anxious. Nobody's sure which checkbox applies to what anymore. Questions about flexi hair have people confused even though the audit has nothing to do with how that half of the company works. Every time. Multiply that by all those states and countries. You can probably imagine that these teams were more than a little happy when we wanted to spin off Tilia for the business customer reason. They'll never again have to explain Ruthing, or why you've still got that emotional attachment to your prim hair.

This is a lot less exciting than some of you are making it out to be. This is not related to yesterday's grid problems. There are cases where, by design, an account may be deleted and a generic template is inserted in its place. It's mostly filled with all-zero values or some other defaults that make the server happy. For example, if an EU resident requested that personal information were deleted from his or her account, this would be one of the many changes made. That said... it's sorely tempting to change the generic "Redacted" surname to "Magellan" now.

One other quick note: Please understand that my warning above is about the program that alters users' email addresses and passwords. This was not a warning about Marine Kelley's viewer or RLV in general. I have been impressed at the care that the RLV and RLVa developers have taken to balance role play and user safety. These viewer developers have also been attentive when we've had specific concerns in the past. There is a good reason that they can operate in the open and that they don't have to distribute their programs on anonymous file sharing sites. If you're ever in doubt about whether something is safe or allowed, their in-world groups may be a great place for discussions. Just don't ask Alyona. She seems mean. ?

Second Life never ceases to be a fascinating place. Half the users want god access. Half want handcuffs they can never take off. Unfortunately, we can't always give people what they want. I have to be a wet blanket again: If a user runs a program that changes the user's email address to something the user does not control, the user has violated the Terms of Service. Full stop. There is a good chance that user will lose the account if the user doesn't have other identifying information on file. The account will be held, and the recovery process would be the same one used for other forms of account compromise. The previous mass rollback of email addresses for these users was a one-time courtesy that consumed a lot of internal resources. As we communicated to these users, it will not be repeated. Depending on the country where you live, you may violate local laws by falsifying or removing contact information on an account that is capable of monetary transactions. I can't provide specific legal guidance. Please consult an attorney if you wish to know more about your obligations, or the obligations of US and European based businesses. Encouraging users to run programs that falsify or remove email addresses is incitement to violate the ToS. Using or encouraging the use of such programs can be reported via "Abuse Report" under the "Help" menu. Please include the words "RLV" and "email" in your Abuse Report to better enable us to search for related reports. People's desire to role play or experience power exchanges is not something we've discouraged. But as a business operating in the US and Europe, we are subject to some incompatible obligations with regard to this particular account change. I would love to be able to say otherwise. Scripters should focus on mechanisms for better detecting RLV cheating. Falsifying or removing contact information such as a user's email address is a dead end. Edit: Added some details on abuse reporting

I'm not a part of the governance or legal team, so I can't give guidance on what unconventional means may be allowed. I can tell you some things that caused a problem with XtremRLV, however. A user must not share SL login credentials with a third party. XtremRLV had users send a "key" to the XtremRLV owner to end lockout, and this revealed the user's cleartext password to the XtremRLV operator. The user and the operator both violated the ToS here. A user's email address has to be up to date and under the sole control of the SL account owner. XtremRLV changed the user's email address in order to thwart password resets. This rendered the user unreachable. This placed users in violation of the ToS. A user must be able to log into our support and billing sites with the use of a standard web browser. XtremRLV's obfuscated password caused a problem here, making use of the XtremRLV tool a violation of the ToS. A user must not be prevented from using the regular SL viewer without any external dependencies. This is often necessary for troubleshooting, such as inventory recovery issues. Again here, use of the XtremRLV tool violated the ToS. I fully appreciate some users' desire to experiment with the experience of a deep power exchange in Second Life. But there are very real legal and business obstacles that simply prevent us from allowing users to be partially locked out of their accounts without fundamental changes to the Second Life service. I don't believe that you can do what you intend without some or all of the above being a problem once again. I would instead encourage you to focus on ways of detecting the breach of RLV limitations. Scripts in in-world objects can detect when users are online. Scripts in attachments can detect whether they are attached to an avatar with RLV enabled. Script these in-world objects to expect "check-in" communication from the attached objects whenever a user is online. If attachments fail to check in or check in with a warning about RLV being disabled then you will have a clear signal that cheating has occurred. This should be enough to help with enforcement. You could probably even standardize this and build a market around the in-world objects and the collar plugins that work with them. You would be able to build on this with no viewer changes whatsoever.

Your post is based on a wrong premise. The use of a private CA is very common for back end services for financial institutions or for other services that deal in sensitive information. This is not at all limited to enterprise. It's not a less mature approach either. The general trend is one of moving away from public CAs for non-browser web APIs. Some background basics: Browsers use common CAs as a matter of convenience; it's a trade off at the expense of increasing users' vulnerability to fraudulent certificates. This is part of the reason why all major browser developers do work to offset that additional exposure. HPKP, certificate class downgrade checks, DNSChain, revocation lists, and Perspectives Project all exist or are under development toward that end. It's trivial to get an SSL certificate issued without controlling a domain. This isn't the 90s, when even the most basic certificate cost hundreds of dollars and extensive checking was the norm. Standards slipped as certificate sellers began to compete on cost and speed. Smash cut to today, and you can go to many different registrars to have your own certificate issued for just about any uncommon domain within an hour. It doesn't even cost anything anymore. If a domain isn't in Alexa's top rankings, there's often no human checking whatsoever. So the answer is not (a) or (b) above. It's ©: Given the number of SL services that use external servers to authorize L$ movement or transmit personal information, it's appropriate to treat LSL based services as highly sensitive. Asking SL scripters to implement various fraudulent certificate checks sets a higher bar than does asking devs to rely on a separate CA in order to establish trust.

Freya Mokusei wrote: Sounds like miscommunication or misunderstanding the problem. Pretty much. But it's more productive when people are loud and paranoid about security than when they're quiet and trust blindly. Questions are good. The reporter has now figured out that they're only encountering a problem when they upgrade their own PHP server to a newer version. Their old code accepted the cert without complaint. I added a comment to the issue that explains some fundamentals on how to extract the Linden Lab CA certificate and add it to trusted certs in order to properly validate certificates. Hopefully that will get them up and going again regardless of which scripting engine they use. And yes, a proper SSL certificate has been in place for as long as llRequestSecureURL has existed. We do operate our own CA rather than using a public CA, as generic web browsers aren't the intended consumers for back end LSL APIs.

Nothing nefarious is going on here. An engineer grabbed a random placeholder image and put it in place while trying to clear up some warnings. Unfortunately he didn't look at what the image actually was for the group he borrowed the image from. He's being asked to put something better in place until the old behavior is restored.

Search for "Surface Pro 3 Second Life" on YouTube. There are a handful of reviews showing complex scenes at 10fps or so. This is with maximized windows and the native 2160x1440 screen resolution. It should be faster if the window size were reduced, or if it were run at a lower screen resolution. It appears usable, but it might not be the best choice for one's primary computer.

I asked the blog team to post this: http://community.secondlife.com/t5/Tools-and-Technology/Account-Safety-and-the-Heartbleed-OpenSSL-Bug/ba-p/2619322 The short of it is your password is fine unless you were reusing your password on another non-SL site. If you were, please change your password to something unique to SL. Yes, the reason the authentication sites were not vulnerable is because they were on old versions of software. Only security fixes were backported, while new features like Heartbeat were not added without a chance to mature. Jumping to the newest version of server software isn't always the best practice. In fact, that practice is the very reason why so many sites were vulnerable. You can read more about this security philosophy here: https://www.debian.org/security/faq#version https://www.debian.org/security/faq#oldversion Thank you for your interest in keeping SL safe. In the future, don't hesitate to file a security JIRA if you worry we've missed anything critical. We watch those 24/7.

No Linden ever said that there would never be 64-bit. Sounds like someone's sourcing an old quote. In 2007, I advised that it was too soon to divide resources. Back then, the 64-bit user base was well under one percent. In 2008, I suggested that we should probably do 64-bit Linux at the least, given the shoddy shape of 32-bit compatibility libraries in most 64-bit Linux distributions. An official build hasn't come from Linden, but I did write, solicit and import a lot of 64-bit changes. Those are in use in the third party 64-bit viewers you can download today. I don't know when official 64-bit viewer builds will come, but it would make a lot more sense today than it did four years ago.