Discussion: Use Cases for llOpenFloater()

[Qie Niangao]

6 hours ago, Mollymews said:

i would like it to be named llHud because this is what most people want. The ability to create rich interactive HUDs for their experiences and products in a whole lot easier way

Yeah. In the interest of retrieving the baby from the bathwater, I'm trying to convince myself there's a way to prevent RedZone redux—not because I care about that exposure myself, but because there are enough people who are concerned about it that anything that exposes it will face the same dead end that MoaP suffers now: users will demand a way to disable it, and then we may as well just use the MoaP we've got now.

The perceived threat of MoaP and RedZone was the ability to associate agent identity with IP address (and thus make good guesses about alts). The llHud script obviously knows the identity of the agent on whose viewer llHud will appear (for an attachment, that's the owner). Is there a way to restrict javascript (and/or anything else that makes this a viable UI environment) so it cannot discover the IP address where it's executing? At first glance, javascript seems safe as long as llHud is sandboxed from making external network connections and the implementation doesn't include WebRTC (and why should it?). I guess, worst case, we'd need an opaque proxy layer that all llHud traffic passes through to anonymize the viewer's IP address.*

Nothing I ever thought about before. I bet there's a standard, accepted-safe approach for this, huh?

__________________
* which would have saved MoaP and other SL media, at the expense of a whole lot of real time network traffic.

[Kathrine Jansma]

 

1 hour ago, Qie Niangao said:

Nothing I ever thought about before. I bet there's a standard, accepted-safe approach for this, huh?

It's called TOR.

And if you look at the shenannigans that fly out of the browser customization needed to keep it safe, it is pretty much an uphill battle if you want to enable interactive stuff like Javascript and external resources.

The other way you could do it would be Appstore style walled garden with compiled apps that simply lack the APIs to get close to anything identifying. And just watch the whole supercookie, canvas fingerprinting or HSTS fingerprinting efforts by the ad industry you can basically forget it as well. You do not need the IP to identify a machine/user. Once you have device dependent timings, you have lost.

So, if one really wanted it, one could do a kind of "streaming texture", where you attach something like a VNC/RDP datastream to a prim texture and just have the browser running headless on some common cloud services rendering its output to the VNC display. (think Google Stadia/Gefore Now or similar concepts). But that has obvious costs attached as the VNC setup would need to be run by a trusted 3rd party.

Edited May 13, 2021 by Kathrine Jansma

[Mollymews]

3 hours ago, Profaitchikenz Haiku said:

Agreed, I can think of several good uses for this, interactive fiction for a start. The only complication I see is that if you want to implement fully interactive huds with it, the HTML is going to have to handle image-maps, otherwise there's going to be some messy to-and-fro between the floater and a texture with llDetectedTouchUV

i was thinking more like HTML5.x capability, for example a texture applier HUD that goes like:

<input type="button" onclick { text='Button1, 1, 1, image_name_in_object_contents' } style="background-image:url('image_name_in_object_contents')"/>

when the user clicks on the button then in LSL listen event

listen(integer channel, integer name, key id, string text)
{
   if (channel == -99 && id == llGetOwner())
   {
       list data = llCSV2List(text);
       string button = llList2String(data, 0);
       if (button == "Button1")
       {       
            integer link = llList2Integer(data, 1);
            integer face = llList2Integer(data, 2);
            string texture = llList2String(data, 3);
            llSetLinkedPrimitiveParams(link, [ PRIM_TEXTURE, face, texture, ... ]);
       }
   }
}

the onclick alternatives could be:

onclick { text= 'Button1,'+JSON(1) }  where JSON(1) is the 1th record in the datasource provided in llHud(..., string json, ...);

the Linden for Linden/LPDW version has onclick { script: ..some_javascript.. } which would be ignored if we resident (non Linden/LDPW Experience developer) included this in our HTML

 

[Qie Niangao]

46 minutes ago, Mollymews said:

image_name_in_object_contents

Coincidentally, the first thing I saw when reviewing applicability of my MoaP stuff (besides jquery and scary comms with my in-world http_request server) was a network reference link to a favicon image file, which got me wondering how any assets, even simple images, would get from the script-running sim to the llHud viewer window. Is there an existing path from SL's CDN-resident jpeg2000 textures to expose them on a web page? Or would we (or Linden/LDPW) need a separate user-populated repository of stuff that can be painted on the llHud "canvas"?

[Mollymews]

27 minutes ago, Qie Niangao said:

Coincidentally, the first thing I saw when reviewing applicability of my MoaP stuff (besides jquery and scary comms with my in-world http_request server) was a network reference link to a favicon image file, which got me wondering how any assets, even simple images, would get from the script-running sim to the llHud viewer window. Is there an existing path from SL's CDN-resident jpeg2000 textures to expose them on a web page? Or would we (or Linden/LDPW) need a separate user-populated repository of stuff that can be painted on the llHud "canvas"?

i think that from a design pov, llHud isn't (or shouldn't be) a web service canvas, as we already have this with MOAP. It is (or should be) just a HTML markup canvas. Don't over-complicate this and try to re-invent MOAP in a different way

and as a markup canvas then the region script (html markup) engine can resolve the CDN server address of the image/texture file, in the same way as the script engine does now for images/textures in Contents and/or image/texture uuids 

edit add: with href links then they are Relative and are restricted to the Second Life domain. And when is a valid url within the domain it opens the users nominated web browser. Like marketplace, etc. Any Absolute href url that points to an external website (beyond the Second Life domain) is ignored by the script (html markup) engine

Edited May 13, 2021 by Mollymews

[Profaitchikenz Haiku]

What you're sketching out is close to the HTML popup in the Auran Trainz simulator. It displays text with minimal formatting, such as H1 to 6, bold, italic, will put up an OK button or a tick checkbox to close, and will also throw up a single field to allow simple input. Is this what you think is sufficient? If it' limited purely to in-world inventory items (ie HTML must be contained within the script and no external inks are allowed) does that take care of the many reservations about security that others have voiced here?

[Extrude Ragu]

15 hours ago, Ardy Lay said:

https://places.secondlife.com/

This is honestly the first time in my life I've seen this page - Is there somewhere in the viewer that brings this up?

[Whirly Fizzle]

40 minutes ago, Extrude Ragu said:

This is honestly the first time in my life I've seen this page - Is there somewhere in the viewer that brings this up?

Nope. It's a well hidden feature & hardly anyone seems to know it exists.

[Qie Niangao]

21 minutes ago, Whirly Fizzle said:

Nope. It's a well hidden feature & hardly anyone seems to know it exists.

If we were confident Place Pages were here to stay and under serious consideration for enhancement, I'd start a thread about what we might want them to do. (Although, if they were to go away, Mainland Auctions would need another complete revamp.)

FWIW, back in 2017, I decided to use Place Pages to document some of Virtual Railway Consortium's main railside real estate, with eleven of them linked from a simple Wordpress site. I also used them in a build originally for the group's SL Birthday exhibit that year, also intended to help popularize Place Pages themselves.

(There's a whole story about how that plan was defeated by a resident SLB organizer role-playing a trademark lawyer and "overruling" the Lindens themselves.)

[arabellajones]

I can see why, for helping new users, Linden Lab would want to open web pages. I know how some groups in SL have tutorial web pages.

I have my DNS running through an ad-blocker. Some domain names return an NX response. This isn't like the ad blocker in some web browsers. There are blocklists out there which block more obviously malicious sites, such as malware and phishing If the tech had been around, it could have blocked Redzone.

I have never hit any problems with the CDN. I do know of a couple of in-world shops which have put offer-links in their groups which have used dodgy servers.

Try not to be stupid, OK

[Ardy Lay]

When I want to offer a URL to somebody, I put it in local chat or IM and let them decide what to do.  There may be some good reasons why LL does not want to contiue using local chat for their tutorial URLs.  If I had to guess I would say it's because of the malicious cloud of hooligans that hang out at the places where new accounts enter Second Life.

[Quistess Alpha]

I knew I had seen a similar function in the list before but couldn't put my finger on it for days. . . how is http://wiki.secondlife.com/wiki/LlOpenFloater substantially different from http://wiki.secondlife.com/wiki/LlLoadURL ?

[Wulfie Reanimator]

1 hour ago, Quistessa said:

I knew I had seen a similar function in the list before but couldn't put my finger on it for days. . . how is http://wiki.secondlife.com/wiki/LlOpenFloater substantially different from http://wiki.secondlife.com/wiki/LlLoadURL ?

They're presented differently.

llLoadURL will open that blue dialog (with ugly formatting since it contains way too much text for its size), and then takes the user out of SL, especially users without a second monitor.

llOpenFloater will, without confirmation, open an in-viewer web browser.

[Coffee Pancake]

llLoadURL presents the option to open a URL in your desktop browser, in the same way a script might present a menu.

llOpenFloater auto opens the browser built into the client at the specified URL, in the same way early 2000's internet explorer would popup install the bonzai buddy search toolbar.

Edited May 14, 2021 by Coffee Pancake

[Mollymews]

13 hours ago, Profaitchikenz Haiku said:

What you're sketching out is close to the HTML popup in the Auran Trainz simulator. It displays text with minimal formatting, such as H1 to 6, bold, italic, will put up an OK button or a tick checkbox to close, and will also throw up a single field to allow simple input. Is this what you think is sufficient? If it' limited purely to in-world inventory items (ie HTML must be contained within the script and no external inks are allowed) does that take care of the many reservations about security that others have voiced here?

i think that quite a lot of HTML5 could be enabled. All of the standard input types could be made available, along with div tables etc. CSS also

the security concerns seem to be about phishing. Allowing links to external websites thru this function just opens up another attack vector on top of the existing vectors

a second more businessy concern with the web service floater as proposed is: If other residents could include this in their scripts then how many residents are going to block it? I think that number would be about the same as MOAP blockers. Which for some significant number of resident scripters would render moot any effort/time they might have otherwise have thought to invest in  it. So they won't

from the sounds of it Linden are going to go ahead with llOpenFloater for their own purposes and seems they may one day allow vetted resident experience providers access to this function. And I ok with that

as llOpenFloater and llHud aren't mutually exclusive, there can be both. And Linden being the arbiter of these things will make their decisions after going thru their own internal processes as they do

[Extrude Ragu]

One of the use cases presented is simply to display help dialogs.

If we consider for a moment that Notecards automatically open when given to a user - Why doesn't LL want to use them?

I think the answer is a mixture of "They're ugly" and "Nobody reads them". Why does nobody read them? I think because there is no visible structure, headings, dividers etc to make it easier to skim read - So nobody bothers because it puts too high a load on their brain. Ain't nobody got time fo that in 2021.

How about just putting Markdown support into Notecards. Add a 'markdown' checkbox and suddenly the content can be structured visibly appealing and most importantly readable to mere mortals whilst not incurring all the security issues etc.

[Quistess Alpha]

8 hours ago, Wulfie Reanimator said:

They're presented differently.

llLoadURL will open that blue dialog (with ugly formatting since it contains way too much text for its size), and then takes the user out of SL, especially users without a second monitor.

llOpenFloater will, without confirmation, open an in-viewer web browser.

 

8 hours ago, Coffee Pancake said:

llLoadURL presents the option to open a URL in your desktop browser, in the same way a script might present a menu.

llOpenFloater auto opens the browser built into the client at the specified URL, in the same way early 2000's internet explorer would popup install the bonzai buddy search toolbar.

Maybe I'm too naive, but couldn't the viewer be configured to 'load' llLoadURL links in the in-viewer browser instead of the system one? having the option to either see web links in-viewer or off-viewer could be the best of both worlds.

[Quistess Alpha]

58 minutes ago, Extrude Ragu said:

How about just putting Markdown support into Notecards. Add a 'markdown' checkbox and suddenly the content can be structured visibly appealing and most importantly readable to mere mortals whilst not incurring all the security issues etc.

even just a viewer option to open notecards in the in-viewer web-browser and interpret them as html could be a plus.

[Wulfie Reanimator]

1 hour ago, Extrude Ragu said:

If we consider for a moment that Notecards automatically open when given to a user - Why doesn't LL want to use them?

The inventory/item is only opened if the appropriate viewer settings are enabled.

13 minutes ago, Quistessa said:

Maybe I'm too naive, but couldn't the viewer be configured to 'load' llLoadURL links in the in-viewer browser instead of the system one? having the option to either see web links in-viewer or off-viewer could be the best of both worlds.

It does respect the viewer settings, but you're still dealing with the ugly dialog and an extra confirmation step that more inexperienced users might even miss completely. The whole point of Experiences (and the main difference for llOpenFloater) is that there is only one confirmation at the beginning and everything else is free to work as they need to.

Edited May 14, 2021 by Wulfie Reanimator

[Quistess Alpha]

Does the SL viewer still use those god awful blue windows? Blue links on blue backgrounds with white text is a fairly serious issue. Ugly and potentially unreadable test is unacceptable in 2021.

 

[Gabriele Graves]

llLoadURL() uses a dialog window because it has these two attributes: 1) There can only be one on screen at a time  - so no spamming and 2) You can vet the URL before deciding to open it.  No automatic loading of a URL into a browser is a good thing when the URL has the potential to load abusive/offensive or otherwise undesired content.

[Gabriele Graves]

Years of having to deal with notecard/texture/LM spam is why we have the option not to auto-popup these types of content.  This is especially so when auto-accept is turned on so that you never lose purchases (yes this still happens unless auto-accept is on).  Auto-accept cannot distinguish between things you want and the things you don't want being sent to you.  If they are auto-accepted for you when you are offline, when you are online and receive any notecards/textures/LMs they would be displayed and so Is often turned off for sanity reasons.

So I don't think relying on this is a good solution if the idea is to guarantee it's display.  If the idea was make changes to enforce their display when sent from behind Experience permissions, then having a purpose built safer alternative would be better.

Edited May 14, 2021 by Gabriele Graves

[Gabriele Graves]

For me it comes down to whether an ordinary Experience user should have to expect things popping up on their screen.  I guess that boat has sailed with Experience-based automatic temporary HUD attachments which can completely cover your viewer display once you have accepted it.  Not that I like that state of affairs but at least a user can decline the whole thing and block the Experience if they don't like it.

The most benign choice seems to be having a single user re-positionable window that can be displayed/closed and which can be refreshed by scripts with new content but can only render HTML (no javascript) or the simpler markup code.  Having one or more floater type windows with no obvious way of managing their location, lifespan or knowing the location of other items on each user's HUD would clearly be a bad choice.

Remote content should either use LL-run servers to bring down any remote content without exposing any identifying avatar data to the remote server or if performed by the viewer with the built-in browser engine it should do it's best to protect the security and privacy of the user but most importantly come with an option to disable remote content for exactly the same reasons we have them for MOAP.  The former option is clearly preferable if you want to guarantee that the content would be displayed.

In the end though the abusive, obnoxious and intrusive uses some people would use this for would far overshadow the subtle, clever, non-intrusive and useful uses it could be used for.  It would be very likely to further taint Experiences in the minds of the user base because of this.
 

[Whirly Fizzle]

On 5/13/2021 at 1:00 PM, Qie Niangao said:

Is there an existing path from SL's CDN-resident jpeg2000 textures to expose them on a web page?

Yes - https://picture-service.secondlife.com/UUID/widthxheight.jpg
Example: https://picture-service.secondlife.com/379f805e-82ac-48bb-0425-7a4e92a709ef/320x240.jpg

[Lucia Nightfire]

2 hours ago, Whirly Fizzle said:

Yes - https://picture-service.secondlife.com/UUID/widthxheight.jpg
Example: https://picture-service.secondlife.com/379f805e-82ac-48bb-0425-7a4e92a709ef/320x240.jpg

Sadly, that doesn't seem to allow native resolutions.

Only really seems to allow 320x240 for anything.