In Game Browser Comment/Feedback

Absolutely Cool beans what people are doing (hacking f1 to use browser in game and ultimately allowing browser textures). I love it. Want to see the capability for browser-textured prims....BUT!!!!

Security: We gotta be able to turn off rendering options of anything but HTML.
Turn off Javascript, components like Flash, Shockwave, etc....

User Control/Choice: What happens when I walk into a sim with 5000 web pages on prims...is my computer going to come to a raging halt as it tries to start up 5000 web downloads? Isn't texture downloading bad enough without complicating it with tcp sessions out the wazoo? Won't my firewall come to a standstill?

For THIS REASON alone - they cannot be automatically displayed and rendered.

Prims with external content should be able to have a texture that:
1. Makes it obvious the content is EXTERNAL to SL. (uBrowser logo?)
2. Allows the user to activate the URL on the prim through mousewheel action and a confirmation button.
a. Allows confirm and save confirmation per URL, maintaining a list of permitted URLs
3. Hovertip on textured face clearly indicates the full URL being passed to the browser.

Comments, please.


Great things will come about! Integrate the XML-RPC with an external game that uses XML-RPC to return results to Second Life scripts, and you could offload server scripting to PHP or CGI applications, like slot machines that merely return a result to the Cash-Out function on an ingame slot machine (that now only needs one prim for the face!!), and all versions of the game can be updated at once!!!

Maybe limit URL on a prim sensibly to say, 6 nearby URLs (ignoring duplicate URLs, e.g if you're downloading a texture from a web-page onto several prims). Maybe if there's some way for SL to throttle the rate at which external sites can download stuff, by reserving it's allocation of bandwidth (in network settings) and only dling URLs in spare kbps, displaying a loading texture/animation to let you know what's happening?

What's to stop someone from pointing at a 10GB URL? We need additional throttling capability that we have as options.

By giving us controls to allow us to start the download (or even an option to not automatically begin downloads), we will have the option of how paranoid we can decide to be.

Or... just give us the ability to turn off HTML within game, and to manually activate any pages we choose to see within an external browser of our choice.

Very few things in SL are forced upon us against our will - so why do we have to have HTML on a prim, the contents of which we seem to have no control over receiving or not.

It's not paranoia... it's common sense, just like you don't write your pin number on the back of your bank card in case you forget it.

Lewis

Dont get me wrong - I LIKE paranoia! It's a good thing. Haven't been infected yet...

On a purely mundane and practical level, I want to be able to use an inworld browser to acess the forums and the LSL wiki (did you notice that I'm trying to learn my way around?) At the very least, an inworld browser avoids having to change windows and lets me work on a script, for example, while I consult scripting tips... I understand the security concerns, but I'm blocked out of the 2 sites I need to use.

Is there anyway to unblock certain sites if the request(s) are coming from inworld? For example, I can't log into the forums with the inworld browser, but if the request is coming from inworld, that information is certainly available to the browser.

The browser's not even supported yet It's really only supported for access to the help page.

There's still implementation and design decisions (like cookie support, target _blank design decision on a prim [spawn new prim? spawn new window?], cookie support, and I'm sure many more questions).

My post about turning stuff off is just stuff I want to make sure they consider as they make these decisions. I, also, wish to access the wiki's in game, and the forums in game. But I want the option to not allow other sites to run Flash on my computer automatically, Javascript, or the newest 0-day exploit...

So this thread was begun mostly to discuss considerations for what needs to be done to be both as secure as possible without pulling the plug [the only secure solution].

I don't. I want to have the ability to programatically bake prim textures without the overhead of a browser.

I would much rather have the option of "external link" requests rendered in an in-SL browser window... but nothing deeper than a window. The overhead of a browser object for every surface texture effect is horrific.

I´d like to see a ghost town, with tumbleweeds and ruins of buildings all textured with a blank 404 Not found and Forbidden (error) web pages.

Which would make HTML on a prim useless for anything but HUDs and standalone vendors, plus the "occlusion lag" problem would hit you... as you moved your camera you'd get browsers popping up and going away.

HTML on a prim - no. Jut let us render text onto a surface. Have the client bake the string into a temporary local texture - it already has this kind of ability for the appearance editor with temporary skin textures.

I really wanted tabbed browsing on the in-world browser. Tabbed browsing first, HTML on a prim next.

Chris

What I mean is active ones sorry, ie limit the number of HTML surfaces that can be downloading at one time, probably dynamically based on the bandwidth available (if you're already downloading tons then load one HTML prim at a time with the spare kbps).