Jump to content

Soft Linden

Lindens
  • Content Count

    29
  • Joined

Community Reputation

66 Excellent

4 Followers

About Soft Linden

  • Rank
    Member

Recent Profile Visitors

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

  1. 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?
  2. 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.
  3. 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.
  4. 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.
  5. 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. ?
  6. 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
  7. 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.
  8. It's possible I'm missing something in my knowledge of RLV. But can't that be thwarted by logging into a region where scripts are disabled at the region level? That would halt even the scripts that use the llTakeControls() exception left in place for vehicles and AOs.
  9. By the by, if a scripter wanted to accomplish similar aims without a special client download or interference in account ownership, I think that's possible. Make a script that resides in an attachment and uses an llHTTPRequest() to check in with an object rezzed in world. The check-in request would include a shared secret, RLV detection status, and confirmation that the object is attached The in-world object would periodically check whether an agent is logged in using llRequestAgentData. If it finds an agent logged in without receiving confirmation of the expected secret and status, it can notify appropriate parties. If a user ultimately opts out, they don't lose the account but they wouldn't be able to escape detection either. Permanent records of "cheat" counts or other social measures could be used as further incentive, rather than account loss. p.s. Is this the first time a Linden has weighed in on making adult toys, or did Cube beat me to the punch back in the day?
  10. Don't worry. We've not turned into prudes overnight. Yes, there were account security issues involved. Problems included account sharing ToS violations, insecure password handling, and interference with Linden-to-customer communications. The intention of the developer was fine, but what he wanted to accomplish isn't really compatible with the ToS and Second Life. We understand and respect that many of you explore very personal interests on Second Life, including kinks. We don't want to discourage personal exploration or expression, so I asked the support team to attempt to handle these cases discretely. That meant reverting email addresses and sending password reset requests rather than requiring phone contact wherever possible. This is at variance with how cases might normally be handled. If the email address rollback didn't work for you and you would like to avoid phone support for an account that was associated with this tool, please file a ticket with support indicating another email address that was recently associated with your account. Ask Support to use that for the password reset request. Again, this is only for accounts previously associated with this tool.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
×
×
  • Create New...