Discussion: Use Cases for llOpenFloater()

[Mazidox Linden]

Hello everyone! This week we're putting out a simulator which allows certain experiences everyone is part of - like the experiences that make Portal Park work - to tell a viewer (which we're still working on) to open a browser floater. We've initially limited this LSL function so that only very trusted experiences will be able to even send the message to your viewer, but we anticipate that the scripting community will have ideas around how they could utilize this feature; we're looking forward to hearing what you think!

 

Edit: Hey everyone, just wanted to give you an update after reading your feedback here and in the LSL Scripting Forum, as well as clarify a couple of misconceptions. Currently, the way the llOpenFloater() LSL function is implemented the only class of experiences that are allowed to invoke this function are Linden Owned and Operated Experiences which always function for everyone.

The only thing we have planned with this new LSL function is creating an improved New User Experience. Given the legitimate concerns the community has raised, we don’t foresee opening up the usage of this LSL function to all Experience owners in the future. In addition, we are taking the following actions:
* In a future release, all invocations of llOpenFloater will fail unless the Experience associated with the invoking script both functions for everyone and is Grid Scope. This further limits the pool of possible scripts that could invoke this function.

* Logging a report with Linden Lab any time llOpenFloater is used for accessing any URL besides New User Experience (internally called “Guidebook”) URLs.

Edited May 12, 2021 by Mazidox Linden
Latest update regarding llOpenFloater

[Qie Niangao]

Is there more background available?

Could a script call the floater on the URL of its in-world http server and feed it javascript?

[Lucia Nightfire]

As long as there is an exposed viewer setting to turn automatic website loading by url off.

Even though you're confining it to experience use now, that doesn't mean there aren't direct/sneaky ways to abuse it, let alone definitely abuse it outside of an experience.

I'd rather not elaborate on the whens, wheres and hows.

Edited May 11, 2021 by Lucia Nightfire

[animats]

If you let scripts open floaters, let them close them, too. In fact, that should apply to all popups. Currently, where the listen for a dialog goes away, the floater stays on screen, all buttons dead, until dismissed.

[Lucia Nightfire]

1 hour ago, animats said:

If you let scripts open floaters, let them close them, too. In fact, that should apply to all popups. Currently, where the listen for a dialog goes away, the floater stays on screen, all buttons dead, until dismissed.

Yes, all floater generating functions should be key based and a function llCloseFloater(key floater_key) could be used to close them.

[Gabriele Graves]

What a nightmare.  It doesn't take a lot of imagination to know how this is going to be used.  Floater adverts everywhere on-screen at the very least.  Just hope LL takes responsibility for the legality of what those URLs are loading 🤨

Edited May 11, 2021 by Gabriele Graves

[Henri Beauchamp]

I agree with Lucia's opinion on the ways to abuse such a feature and the need for a kill-switch for it, viewer side...

I'll also add that if you ever implement that feature, you must make sure it will be compatible with all viewers (TPVs often got/implement different floaters, have some non-existing floaters (e.g. for v1 UI TPVs), or on the contrary additional floaters not available in LL's viewer). Granted, a mapping of floater names/keys could be implemented by each TPV developer, but what about scripters making use of TPV floaters that do not exist in LL's viewer ?

At least make sure that if a viewer refuses to open a given floater (be it because it does not have an equivalent, or because of a kill-switch), it will not break the script asking for it.

EDIT: by the way I see that llOpenFloater() is already implemented for URLs in the RC server version to be deployed; where is the code implementing the viewer side of things ?  I cannot find it anywhere on LL's public code repository !

Edited May 11, 2021 by Henri Beauchamp

[arabellajones]

3 hours ago, Gabriele Graves said:

What a nightmare.  It doesn't take a lot of imagination to know how this is going to be used.  Floater adverts everywhere on-screen at the very least.  Just hope LL takes responsibility for the legality of what those URLs are loading 🤨

There is some Second Life content, and system behaviour, which is of doubtful legality in other countries, and vice versa.

A giant economy-size can of worms is in the post.

[Anna Nova]

I suspect this is the beginning of the end for my participation in Second Life.

Let's make it quite clear, the first advert that pops up on my viewer will be the last time that viewer will log in.

Edit:  Unless I have a control to turn this functionality completely off for my viewer, of course.

Edited May 11, 2021 by Anna Nova
clarification

[KT Kingsley]

This feature is likely to make many of us currently perfectly happy to join experiences turn our backs on them. It certainly won't do anything to allay the fears and suspicions of users who already shun them.

This absolutely must be something users can turn off completely. And, LL, if you don't provide that ability in your own viewer, don't you dare try to bully TPV developers into excluding it too.

[Rowan Amore]

Why?  When there are so many things people actually WANT.

[Solar Legion]

3 minutes ago, Rowan Amore said:

Why?  When there are so many things people actually WANT.

Redelivery Terminals, Web based item controls (very few of these around these days it seems), 'embedding' of FAQ pages into HUD (and other) item buttons ....

Oh yes and lets not forget that at least some of what "people actually want" is not wanted by a fair few as well ....

Part Devil's Advocate and part sarcasm here.

[Rowan Amore]

14 minutes ago, Solar Legion said:

Redelivery Terminals, Web based item controls (very few of these around these days it seems), 'embedding' of FAQ pages into HUD (and other) item buttons ....

Oh yes and lets not forget that at least some of what "people actually want" is not wanted by a fair few as well ....

Part Devil's Advocate and part sarcasm here.

Kind of my point in a way.  Has LL ever done any type of survey on what people want?  I know you can request features with a jira but most people have never gone there or even know it exists.  Maybe a direct email asking people their opinion?  Even this thread.  How many people will even bother to read it?

[Solar Legion]

1 minute ago, Rowan Amore said:

Kind of my point in a way.  Has LL ever done any type of survey on what people want?  I know you can request features with a jira but most people have never gone there or even know it exists.  Maybe a direct email asking people their opinion?  Even this thread.  How many people will even bother to read it?

As far as a survey is concerned .... Yeah, that's about as useful as this thread (among other things). You will have people who won't bother to answer for one reason or another, skewing the results. Ditto for not sending it out to everyone (at least then you'll have a somewhat more comprehensive grasp on the matter - refusal to answer from some or not).

Meh.

Like much that has come to pass over the years, I'll personally just end up rolling with it - like/agreeing with it or not.

[Aishagain]

@Mazidox LindenI'm only going to say this: In Game Purchasing.  If Linden Lab's new money-grabbing owners are looking for another way to monetise SL this sounds like the way they'd do it. 

REPREHENSIBLE.

[Profaitchikenz Haiku]

I would ask that there is a preferences or debug setting to allow the end-user to specify where on the screen the floater should open.

It can be very annoying when you have the viewer laid out so you can see your radar, chat history, mini map and camera controls and then suddenly one of them gets occluded by a popup telling you that somebody has come online, or you have entered private property and are going to be ejected within 10 seconds (and when such a popup obscures your inventory with the landmarks where you would wish to quickly click-and-flee it's doubly annoying).

[Chaser Zaks]

If implemented, I am hoping that llOpenFloater is more than just llOpenFloater(string url);, as llOpenFloater could have much more use potential.

I'd see something like llOpenFloater(string floaterName, list options); being a better suited function layout, as this would allow, in the future, more than just a webpage. Perhaps a floater asset that can be custom designed by using XUI in-world(sanity checked of course, I've done crashed myself a few times when editing XUI).

Though with webpages being the initial selling feature, is does kind of seem like a re-implementation of llLoadURL, though without explicit user permissions. There is reasons why llLoadURL, media streams, and MOAP have permission dialogs, and that's redzone, we don't need a repeat of that. No amount of money is going to stop people from being malicious with it, just take the landlords who spam people with notecards weekly if you happen to get on their mailing list somehow.

Perhaps webpages should be whitelisted in a similar fashion to media URLs, initially whitelisting *.lindenlab.com and *.secondlife.com, and allowing users to choose to accept whether or not a URL is allowed or not.

[panterapolnocy]

I may be wrong, but from what I see the function does not open a viewer floater window like @Henri Beauchampsuggests, but a web browser window ("function will (..) open a new browser floater pointed at the URL provided by the LSL script") and it won't be THAT easy to use it for spamming, as the deploy plan message specifies that "function is restricted to being invoked by experiences that are enabled for all Residents" - and as far as I know not many experiences have such privileged status - their owners won't risk losing them by disrupting user experience. Especially for newcomers, in newcomer friendly areas / Portal Park installations. For what purpose this function was actually created: "(...) New User Experience (which will rely on this function being present)."

Edited May 11, 2021 by panterapolnocy

[Qie Niangao]

I imagine we'll get more information at the Simulator User Group starting in a few minutes.

This doesn't have to be the "spam" problem folks seem to dread most; that's certainly not my greatest concern, and can at least by curtailed by only allowing the function to be called inside certain specific event handlers. I'd like to think this could be a script UI better than the lame dialog boxes we have now, or the cumbersome and fraught MoaP HUD surfaces that are now so feared as to be barely worth implementing despite offering such an improved, almost modern UX.

I do, however, wonder how some fairly obvious exploits can be prevented, short of making the function available only in "app store"-like vetted applications (which just isn't practical in SL).

[Kitty Barnett]

4 minutes ago, panterapolnocy said:

the deploy plan message specifies that "function is restricted to being invoked by experiences that are enabled for all Residents" - and as far as I know not many experiences have such status - their owners won't risk losing them by disrupting user experience. Especially for newcomers, in newcomer friendly areas / Portal Park installations. For what purpose this function was actually created: "(...) New User Experience (which will rely on this function being present)."

Grid-wide experiences were supposed to be generally available but so far it's only Linden experiences and I think a few residents who participated in the testing.

That said, there are already 'shared experiences' out there where someone offers up their experience to the community at large, and which can then be used for griefing (one reason avSitter is banned from executing RLV commands).

 

Even if grid-wide experiences end up being more tightly controlled by LL that then just shifts the risk to the security of the individual scripter. The in-world browser is old and not frequently updated so for force-opening URLs seems like a bad security move until that gets addressed and improved.

I can unfortunately see blocking this functionality becoming an option on most TPVs, and then having it enabled by default which would limit its usefulness significantly and it would probably have been nice to have this discussion/announcement happen at the bi-weekly TPV meeting .

[Coffee Pancake]

This has an astounding potential to be abused.

I totally understand LL's desire to open web pages with documentation as part of the on-boarding process (because RTFM is always the best solution to accessibility & usability problems, right?).

I can totally see this being used to spam people as they visit a region or open webpages with embedded google tracking or far far worse.

[Coffee Pancake]

46 minutes ago, Qie Niangao said:

I imagine we'll get more information at the Simulator User Group starting in a few minutes.

PANIC OVER

We wont be getting to play with this.

Good thing too !!

[Lucia Nightfire]

1 hour ago, Coffee Pancake said:

PANIC OVER

We wont be getting to play with this.

Good thing too !!

LL(after seeing the push back): "I mean.......auto-allowing experiences only will use it! Yeah! Did we not specify that already? Silly us!"

BTW, there are plenty of resident owned, land scope, auto-allowing experiences out there and some of them have been hijacked in the past and/or have been abused in the wrong hands.

There are SECs and ARs filed over this already.

[Candide LeMay]

What is an "auto-allowing experience"?

[Lucia Nightfire]

2 hours ago, Candide LeMay said:

What is an "auto-allowing experience"?

An experience that can force you to join/allow it without giving you a choice nor will it let you disallow/forget/block it.

Most of them in the wild are Linden owned.

Edited May 11, 2021 by Lucia Nightfire