Scripted objects with undesirable undisclosed functionality?

[Sara Nova]

I recently attached my Empower Magic HUD for the first time in years, and it told me it was an out-of-date version. Not a surprise considering how long it had been. What was a surprise was that it said it was disabling the version I had—what if I don't want to update? I don't see any warning of forced updates on the empowermagick.com website.

Even worse, the landmark it gave me to get the update led to something completely different now, and when I asked in the group about it, they said it's "dead"; the creator is gone and it's no longer available for sale. (Yes, and for some reason the website is still up.) Since the HUD came with modify permissions, I decided to try rezzing a backup (it seemed to have deleted all the scripts) and deleting the updater script. As I hoped, it didn't trigger when rezzed, only when attached, so I was able to delete the script. But then when I attached the HUD, it said this:

Quote

Empower HUD v5: Locking this HUD as it lacks a valid updater.  Please contact [creator's name].

Empower HUD v5: Your HUD has been locked by an Empower Adept.  Contact [creator's name] to have it unlocked.

This time, all of the scripts were still intact, but it still refused to work. Now it's especially clear they were trying to force me to update, and on top of that, it seemed to be programmed so that an "Empower Adept" could prevent you from using what you purchased. Again, it was never disclosed that I was purchasing a product that could be taken away from me. When you pay for something, isn't the expectation that it'll be yours forever? That no one (except perhaps a Linden) can take it away from you no matter what, not even the creator? The exception is if it relies on some external server not operated by LL, but there was no reason to think this would in order to function.

I tried tinkering with it some more, adding scripts to discover what I could about the black-box scripts it came with, and to try and break the lock mechanism. I was able to have it show up as unlocked and make some of the HUD functionality appear to work again, but the main functionality still didn't work. Here's my script though, in case anyone else has this problem and wants to try. Rez a backup copy of the HUD, delete the updater script, and add my script.

My main question though is, is this type of behavior allowed? I feel like it could be considered a type of bait-and-switch if it's not clearly disclosed. I paid for the product based on what I knew about it, so failing to disclose something like this feels like a type of false advertising. Is this a common thing? I do remember seeing this kind of thing on at least one other product, but that was ages ago.

 

Edited April 13, 2020 by MyAlt4099

[Paul Hexem]

Welcome to SL, where scams are allowed and LL doesn't care because your only recourse is to file a lawsuit against the creator and/or LL- and who's gonna do that for a 4 USD item?

Also, naming the creator on the forums is only gonna get you in trouble instead of them! Isn't it great?

[Adamburp Adamczyk]

I'd be very reluctant to follow a pastebin link on the forums too........................

[Qie Niangao]

2 hours ago, MyAlt4099 said:

My main question though is, is this type of behavior allowed? I feel like it could be considered a type of bait-and-switch if it's not clearly disclosed. I paid for the product based on what I knew about it, so failing to disclose something like this feels like a type of false advertising. Is this a common thing? I do remember seeing this kind of thing on at least one other product, but that was ages ago.

Pretty impossible to disallow this sort of thing. I have no idea what this device does, but stuff regularly just stops working because of changes in the scripting language. The Lab tries not to let this happen, but sometime it's necessary. That may have nothing to do with this HUD, but in general you just can't expect things in SL to keep working forever without updates. And unless this creator was taking a fee to provide ongoing support, really, why would one expect those updates to continue in perpetuity?

So that leaves the question of why this device actively disabled itself when unable to get an update. I can make up some possible reasons: I might want to fix a product so it can no longer be used for an abusive exploit I didn't anticipate. I might need to change the web address of an off-grid server (this could fit with the HUD being unlocked but not functioning, if the function depended on accessing a server that no longer exists). I might want a way to make sure devices disable themselves locally rather than risk them launching a DDoS against my servers due to some defect in my code. Now, I've never done any of these things with any of my scripts, but somebody might.

[Sara Nova]

4 hours ago, Gadget Portal said:

Also, naming the creator on the forums is only gonna get you in trouble instead of them! Isn't it great?

Oh, whoops, didn't know that. I've removed the creator's name. Should I remove the website link as well?

3 hours ago, Adamburp Adamczyk said:

I'd be very reluctant to follow a pastebin link on the forums too........................

How come? All Pastebin hosts is plain text. Even if the code I linked to was malicious, merely clicking the link couldn't execute it, only display it.

2 hours ago, Qie Niangao said:

Pretty impossible to disallow this sort of thing. I have no idea what this device does, but stuff regularly just stops working because of changes in the scripting language. The Lab tries not to let this happen, but sometime it's necessary. That may have nothing to do with this HUD, but in general you just can't expect things in SL to keep working forever without updates. And unless this creator was taking a fee to provide ongoing support, really, why would one expect those updates to continue in perpetuity?

I never said I expected that. It's also perfectly understandable for already-released updates to eventually cease being available to those who don't already have them. But if I don't get the latest update in time, I should still be able to make do with the outdated version I have. And generally, I expect to be able to, at least to whatever extent is technically possible.

 

2 hours ago, Qie Niangao said:

So that leaves the question of why this device actively disabled itself when unable to get an update. I can make up some possible reasons: I might want to fix a product so it can no longer be used for an abusive exploit I didn't anticipate.

What if the existence of that exploit, or knowledge/hope that one could potentially surface, was a factor that motivated the purchase? If no exploit ends up being found, or the person ends up buying it too late to get the version they want, then it wouldn't be reasonable for them to complain. Even a product that disables itself isn't a valid cause for complaint as long as it were stated somewhere prior to purchase that it would. But if not, then that expectation of having a product continue to work, at least for local functionality, would be reasonable, and likely would have been a factor in the decision to purchase.

It's like keeping a game console on an outdated firmware version so you can mod it. They're under no obligation to provide you with that version if you don't already have it, nor to allow you to connect to online services with it. But the product you purchased comes with the expectation that the software on it will continue to work perpetually, at least for local functionality. I don't think this is actually the case for the consoles on the market today, but if not, then that's only because they stipulated it somewhere in the fine print. If this was the case for the HUD I purchased, I wouldn't be complaining.

And of course, it goes without saying that an exploit that affects the creator's server, or other users of the product, can be patched on the server, or in an update that other users can get to protect themselves.

2 hours ago, Qie Niangao said:

I might need to change the web address of an off-grid server (this could fit with the HUD being unlocked but not functioning, if the function depended on accessing a server that no longer exists).

I'm only talking about when functionality is deliberately disabled, not just stops working because of the failure of an external dependency.

2 hours ago, Qie Niangao said:

I might want a way to make sure devices disable themselves locally rather than risk them launching a DDoS against my servers due to some defect in my code. Now, I've never done any of these things with any of my scripts, but somebody might.

If that's something you're worried about, then that's absolutely fine. Just make sure you're upfront about that functionality prior to purchase, and there's no problem.

[Lindal Kidd]

Obviously the creator didn't think his way through all the possible permutations.  Although I admit that it's hard, when you are creating something, to think about "what happens to this thing if I leave SL forever?"

I own a couple of items that rely/relied on an external website to function.  When the creators left SL, they closed down those websites.  Now my items are completely useless, and I paid quite a lot of $L for them, too.

It's just one of the risks we take in SL.

[Rhonda Huntress]

When coding for games you have to be sure to check for integrity.  It sounds like it was caught in an anti-tampering check and thus shut down the system.  In other words, working as intended.

[Lindal Kidd]

1 minute ago, Rhonda Huntress said:

When coding for games you have to be sure to check for integrity.  It sounds like it was caught in an anti-tampering check and thus shut down the system.  In other words, working as intended.

Yes!  But, the creator obviously didn't think through the situation that the OP finds themselves in...it won't work without the update, but the update isn't available, and it also won't work when it's modified to remove the update requirement. 

[Sara Nova]

1 hour ago, Rhonda Huntress said:

When coding for games you have to be sure to check for integrity.  It sounds like it was caught in an anti-tampering check and thus shut down the system.  In other words, working as intended.

That's another thing that should have been disclosed. If an item is advertised as having a certain permission enabled—such as modify—the assumption is that I'll be able to do everything allowed by that permission—including deleting a script—without meeting any kind of resistance. Unintended glitches, sure; there's always a risk of that when doing that kind of edit. Same if the updater had instead been inseparately built into the main script.

But deliberate "anti-tampering checks" have no place in an object sold as modifiable, unless it was made clear what is deliberately excluded from modifiability. I know scripts are often set as "no modify" in spite of said permission being advertised for (and present on) the object itself, but that's a common thing that's pretty much expected. (Though it wouldn't necessarily be obvious to a newbie, I guess.)

Deleting scripts only requires modify permissions on the object itself though, not the scripts. What if you had bought something advertised as modifiable and found that, while the permissions technically are as advertised, the object deliberately breaks if you change the color or texture, and there's no way to disable this without also disabling the core advertised functionality? Or what if an object is advertised as having transfer permissions, but it has a script that disables some or all of the functionality after changing owners, without this having been disclosed?

I've seen modifiable objects before that have some kind of animation with alpha (like blinking eyes) likely using llSetPrimitiveParams, and it ends up resetting the color I've selected as an unintentional side effect. And a transferrable object can easily have a bug where it doesn't work after changing owner, if the creator forgets to do llResetScript (or at least replacing things like llListen) on owner change. Things like this are unfortunate, but they happen. (Though in the latter case, I think it's reasonable to expect the creator to fix the bug.) Even if it is something deliberate, they're technically telling the truth about the permissions. But it still seems dishonest, like false advertising, to not disclose it, if they're deliberately limiting what can be done with the object besides what's normally allowed by the stated permissions.