Day: May 9, 2013

ToS changes, FinCEN and speculation

Posted on by Inara Pey

secondlife

Update, May 10th: Alex Kadochnikov has posted a further piece on the recent FInCEN interpretive guidelines on virtual currencies.

The recent change in the ToS affecting the use of third-party exchanges for L$ transactions was apparently accompanied by an e-mail from the Lab to such exchanges asking them to cease trading / cease trading in Linden Dollars.

So far, and as reported on Hypergrid Business, around eight exchanges have suspended trading in Linden Dollars while seeking clarification from the Lab as to whether / how they can continue to provide a service to users. Whether the suspension turn into an outright cessation of trading / operation obviously depends on the response obtained from the Lab.

Additionally, Oz Linden contacted TPV developers via the Opensource Development mailing list, stating:

Linden Lab has made a change to the Terms of Service – see the blog post at

http://community.secondlife.com/t5/Featured-News/Updated-Second-Life-Terms-of-Service/ba-p/1996185

If you are a viewer developer, and your viewer includes use of a third-party exchange for functions like ‘buy L$,’ it will need to be changed to use the LindeX instead. 

Some are speculating that the move is as a result of the FinCEN issuing a set of interpretive guidelines on virtual currency (which I commented about in April), possibly related to limiting the Lab’s exposure where other exchanges are concerned. As I’ve stated in comments following-up on the news piece on the change – and while, inevitably, IANAL), I’m not altogether convinced by those arguments per se, because there is nothing in the FinCEN guidelines which appears to fundamentally impact LL’s exposure in this regard – rather, they and third-party exchanges appear to be in the same boat where FinCEN’s guidelines are concerned.

US Treasury's FinCEN: examining virtual currencies
US Treasury’s FinCEN: examining virtual currencies

However, this is not to say that I think LL’s move is entirely unrelated to the FinCEN guidelines being published in March. Again, as I’ve commented both in this blog and elsewhere:

I would add that where there is a potential overlap between the two (the FinCEN guidelines and the SL ToS change), inasmuch as by attempting to limit any exposure of L$ to third-party exchanges and confine trading to LL’s own mechanism (the LindeX), the Lab might be trying to strengthen their position that the L$ is a “gaming token” rather than a “virtual currency” – which cuts to the heart of the core difference in their interpretation of the Linden Dollar’s status, and how FinCEN might regard it.

Of course, even in doing this, the Lab doesn’t escape FinCEN’s view that they are effectively a Money Service Business (MSB) and as such, are required to register as such with the US Treasury and meet regulatory requirements and adhere to anti-money laundering and other periodic reports. Some have suggested that the Lab may as a result face escalating costs in attempting to meet these requirements which may render the Linden Dollar, as we know it today, unviable to the company. However, as I stated back in April:

… there would appear to be questions as to how justified concerns over compliance (and the cost thereto faced by the Lab) actually are.

When it comes to money laundering in particular, Linden Lab already has a number of safeguards in place. Whether these are compliant with any requirements specified by the US Treasury is open to debate … However, it would seem unlikely that such safeguards would be without reference to any legal / regulatory compliance, even  if they only meet the bare minimum required.

Thus, how much additional work and expense would be required on LL’s part should they have to become a registered MSB isn’t that easy to ascertain; so dismissing them as being unable to comply, or that cost of compliance would be something the company would be unable to bear would appear to be perhaps premature.

However, it is reasonable to suggest that if this move is related to FinCEN, then quite possibly it is just an initial step, one which may well be followed-up in the coming months by further changes as the Linden Dollar’s overall status is further clarified as a result of dialogue between LL and FinCEN. Whether such additional result in the Linden Dollar becoming a closed currency without “real” value is entirely open to debate and beyond the considerations of this piece.

There is another question to be asked here as well. Which is this: while it might be unwise to totally dismiss FinCEN as having nothing to do with LL’s change in policy, are there other reasons why LL would make this move?

Well, yes there are. Here’s a couple:

  • It could actually have arisen as a result of the discovery of a fraudulent activity or situation which simply could not be ignored, and the Lab had to take drastic steps in order to ensure the door was firmly slammed shut on the matter
  • It might simply be an attempt to ring-fence the buying and selling of L$ for direct revenue gain. As WolfBaginski Bearsfoot points out, LL are potentially missing out on around $500,000 in transaction commissions going through VirWoX alone. While this may sound trivial, it could go some way to offsetting declining revenue from tier (which in 2012 amounted to approximately $762,000).

Then there is the way in which the change has been announced. If the reason behind it is purely a response to FinCEN setting out its stall in relation to virtual currencies, why couldn’t the Lab have indicated this to be the case? At the very least, and with more considered up-front communication blog-wise, it would have avoided the current levels of confusion, angst and speculation. And why the need to act in such an abrupt manner? It seems odd that if this course of action has arisen from the moves by FinCEN, the Lab explain the situation to users and third-party exchanges alike and give both X number of days to prepare for the changes to come into effect. Were they perhaps afraid that doing so would lead to a run on demand for L$ through third-party exchanges?

It is possible that whatever prompted the change to the ToS may never be known – particularly if it was, as mentioned above, related to a specific fraud-related situation or activity which the Lab could not afford to ignore.As such, this one change –  allowing for the current confusion and speculation it has created – is liable to be the end of things,

However, if it is as a result of the rumblings coming out of FinCEN as they cast their eyes across virtual currencies, then this might just be a foretaste of further changes to come.

Related Links

SL projects update week 19 (2): Interest list, missing prims, griefing

Posted on by Inara Pey

Interest List Update

As noted in week 18, Andrew Linden has been working on fixing a bug related to Meeroos (but which I’ve seen affecting other animals as well).

If you turn your camera away from a crowd of Meeroos, wait several seconds, then turn back around… the Meeroos will be updated, but not quite in the right order. So sometimes you’ll see a head move to the new position, then a fraction of a second later the rest of the body.  So I have a theoretical fix that doesn’t crash the simulator (anymore)

Reporting on the situation at the Simulator User Group meeting on Tuesday May 7th, he said, “Right before this meeting I was rounding up some meeroos to do some testing on the beta grid. The bug is theoretically fixed, but I’ve yet to actually see it work. We’ll be testing this week.” If all goes well, the fix may well be progressing towards an RC release in the near future.

“Missing Prims”

Still no major news on this issue in terms of a lasting fix becoming available. Commenting on it again during the Simulator User Group Meeting, Andrew Linden said:

We were having trouble reproducing it on one of our more recent viewers; the viewer that will eventually go along with the recent interest list fixes, is currently stalled for a mysterious crash bug.

We think the “right click to make the object show up” bug is related to loading of object cache in the viewer and that loading code has had an overhaul in this recent viewer project. So we think the bug is fixed there, but we have yet to test it a lot. Because there is a crash bug we’re still trying to track down.

"Missing" prims - viewer-side fix stalled; code might be made available to TPVs anyway?
“Missing” prims – viewer-side fix stalled; code might be made available to TPVs anyway?

The question was asked if the code could be made available to TPVs as it is, even if prone to crashing. Doing so might provide extra eyes on the problem which may both help to resolve the issue and fix the crash issue. Andrew replied to the question by saying, “Oz asked us to put that code out on a public repo, but that was before we realized we had a crash problem.” However, he agreed to take the request back to the office and see what the reaction might be.

Other Bits – Griefing Issues

There has been a long-standing issue with objects sitting on the region borders being very hard to return to their owners, and which has become something of an exploit where mainland griefing is concerned. It had been hoped that the fix for the issue would be deployed to the grid this week, However, in reviewing matters, Andrew linden regretfully reported that “It appears that ‘return of objects at region border’ bug fix is not deployed at the moment, as far as I can tell.”  There is currently no date as to when this will be deployed,

Similarly, there is still no news as to when the particle muting capability (right-click on a particle to stop your viewer generating the particle stream in your world-view) might make a viewer-side appearance.

There are reports of a new form of particularly malicious griefing involving spinning / flashing objects which appear deliberately designed to trigger epilepsy or migraine.  At the Simulator UG meeting, Simon Linden indicated that the Lab is at least aware of this form of attack.

Blocking Banned Users’ Objects from Rendering

A suggestion has been put forward at several Simulator UG meetings where griefing has been discussed that all objects on a parcel belonging to a user banned from that parcel for griefing should no longer be rendered for other users within that parcel.

This is seen as a particularly useful option at events, etc., where time would otherwise be taken up in trying to locate and return objects which may have been left behind when banning the user, and / or in telling other people in the parcel how to mute offending objects from their view.

Commenting on this as a possible server-side capability, Andrew Linden said, “More fidelity of visibility on a per-parcel level would further complicate things that are already fairly complicated. I’m not saying it can’t be done, but it would be tricky and I would worry about lag issues… server lag as it picks up more work.”

However, after a discussion on the viability of viewer-side blocking and server-side blocking, he commented, “I’m hip… if visibility of banned owners’ objects were to be done… it would probably be easiest to do it at the server.” Even so, there would still be a range of issues to deal with, were such a capability to be put into place. As it stands, it appears to be more a case of food-for-thought than a definite step to be taken.

Forced Object Return

Another griefing attack is one which sees an object deposited in a region but which doesn’t actually trigger until after the region is restarted. This means it gets included in the region back-up – and any subsequent region restart, leaving it free to annoy.

A suggestion was put forward at the Server Beta meeting on Thursday May, 2nd to force a return of all objects in a region which are not set to the required Group as a part of the region restart process. This idea gained some support at the meeting and might have resulted in a feature request being filed. However, it is not without issues of its own – such as with regions where Group object rezzing isn’t a requirement, where it could result in a lot of items which might otherwise have been “safe” returned to their owners.