HTML in SL

I have, twice in fact.

I would like it if other people would post the question in hotline too -- for some reason I have a very high record for my hotline posts never being answered. I'm not real keen on this fact.

Maybe I'm just too thick to understand your security concerns, but it seems to me most of you have entirely the wrong end of the stick, and are panicking over nothing.

There will be no browser or rendering engine in the SL client at all. Is there a quicktime player incorporated into it now ?

All it will do is send the fixed url assigned to a texture for the land (and shown on some prims) to your existing browser. It will seize the browser output, and paint it onto any prim with the texture. Only if you have opted to turn the feature on, of course.

If we're lucky, the SL client will relay clicks on the prim face to the browser. So the land url will just be the starting point for some normal surfing around.

So where is the extra risk ? The browser security settings will be as you have set them. As you use them every day. It will be simply calling to your very own normal browser.

So someone else has chosen what url to send your browser to? So what? Someone else has done that every time you click a url normally.

So someone could hide the texture, so you don't notice the web page? So what? People do it to you all the time. Never seen one of those tiny little browser windows tucked away in the corner, so you won't notice?

Maybe some of you would like to use more restricted browser settings with SL than you normally do, for some reason ?

I would suggest the SL client could allow you to select which copy of your browser to use (in preferences). So you can have a second copy, with different settings, specially configured (by you, normally) for SL's use. Don't see why, but if it makes you feel safer ?

I just dont see how this is any different from using your browser normally. All the same risks, but no more.

Come on, help me. If there is something I am missing, can someone set me straight, please?

Cost to the server?
Surely the server is not involved. Like streaming video.

Correct, however, your assumptions are wrong.

Yes, every time we click a HREF in a browser, we go to a URL that someone else has defined.

However, we start off by visiting the initial site. There are plenty of unsafe sites out there to visit, and I would not visit them, and if a site I consider 'safe' redirected me to one of these sites, I would likely contact them with at the minimum a nastygram.

Secondly, when there are known browser exploits in the wild, I am extra careful which sites I visit until such time as patches are applied.

The problem? The concern?

Under this system, you do NOT have to click something to reach the initial webpage. That's the start of the problems, the end of the problems.

I do not want someone to have the ability to point my web browser to anything, anytime, anywhere, without me choosing so.

You've made a number of assumptions here.

First, you've assumed that only one URL will be able to be assigned as a texture for land, as is the case with QT media now. I don't think that's implied in this proposal.

Second, you've assumed that you wil need to approve the launch, just as you currently approve the launch of media when you first enter a parcel that has media turned on. (And currently, you approve media for every plot at once with that decision.) That is not guaranteed with this proposal either, though it would be the minimum level of security I would consider acceptable.

Finally, you've assumed that the browser can act like a plugin, as QT does. True, QT is not built into SL, but it uses a regular defined interface which is intended to allow it to be displayed in other programs (i.e., browsers). In this case, the SL client itself is acting as the browser. In the case of a browser, it's an entire program itself, not a plugin with a defined interface, and not easily incorporated into the SL client, unless somebody knows something about browsers that I don't (quite possible).

Again, I don't want to use a prim face like a normal browser. I can see what images and QT movies look like now, rendered through the SL client, and web pages would be unreadable and unusable. I think this proposed feature would be useful only if it were used to allow dynamic display of text and possibly images or non-executable media specifically designed for the prim in question. That would require the incorporation of a basic browser engine.

Heck, I'd say build in lynx and be done with it. But then, I'm a function-over-form kind of person.

neko

You astonish me. This description of a way of using the internet bears no relation to anything I do, have seen, or would previously have thought feasible.

The idea of being able to decide, before I click any link, whether a site is "safe" or not. I cannot imagine how you could possibly know, unless you restricted yourself to so few sites that you might as well not have the internet at all. Do you inspect the url behind every link, and compare it with a list, before you decide? Or is this an automatic process, under the guidance of some sort of monitoring site with a huge list of checked-out urls ? And what is meant by safe ?

I'd love to hear how you do it.

I based the first and second assumptions on the way SL have dealt with similar situations in the past. Certainly I agree we should insist on the second.

With regard to the "plugin", I am assuming that the client could grab the output meant for the screen, and hoping it could take over click inputs too. I dont think this can only be done via the "plugin" format.

I assume this simply because LL are very busy with enhancements and bug fixes to SL, and I don't believe they would promise us anything that would require them to incorporate a browser engine inside their own client. Surely that would be a huge undertaking, fraught with complexity, and completely beyond the scope of a small feature addition to SL ? Much more difficult than grabbing the i/o of an existing browser, wouldn't you expect ?

Oddly enough, I use the internet in a similar way, and I still find internet access very useful. I spend the most time on a small number of sites I have been dealing with for a long time. When looking for new information, I start from sites I trust, and if I use a search engine, I tend to look fairly carefully at the domain and summary before I click. I also have a personal firewall installed along with the usual anti-viral software -- and I'm using a Unix variant (MacOSX) and I don't use IE, so my system security is rather better than that of the average Windows user. But then I've been an IT professional for the past 15 years, and I've seen a lot of damage caused by lax security. Perhaps I'm more conservative in my internet usage than most.

I'll put it simply. If this feature merely renders web pages including executable content on a prim face, I'll leave it turned off unless I'm at a plot owned by someone I know and trust. (If I'm able to examine the URL before turning it on temporarily, I might view content at the plot of someone I don't know, based on examination of the URL.) If I can't leave it turned off by default, and can't find a way to keep SL from figuring out how to launch my web browser, I'll either restrict my visits in SL to the plots of people I know well and trust (and boycott telehubs entirely), or quit SL altogether.

I already have my system audio on "mute" when I enter SL, because I don't feel like listening to every audio stream I pass through. I expect I'll have to manually unconfigure QT media now that I've actually experimented with it, because SL doesn't keep "don't play" settings for audio as you pass from plot to plot, so why should it for QT? And on that basis, I don't expect good tools for handling web page rendering if LL decides to handle it using the audio and QT model, which means most of the time I just won't see the web page on the prims, and neither will plenty of other people, I think.

For me, the assumption that executable content will be rendered by the user's browser makes the feature pretty much useless and we might as well go back to XyText to get text on prims. Once again, I don't want to use SL as a web browser. I have one already. HTTP would be a useful channel to be able to bring in dynamic data, or if the HTTP channel is not enabled, HTML would still be a great way to be able to format text and perhaps images for display on a prim. I don't know how many SL users feel the way I do, and how many just want to be able to look at web pages in toto on a prim. I suggest LL would do well to find out before attempting to implement this feature. A feature that is "easy to implement" but goes unused is still a waste of development resources.

neko

Just to drive the point home, I'll explain how this can be turned into an exploit to gain control of your computer with relative ease.

First, a security exploit is found in internet explorer or firefox or whatever rendering engine they use in the background for handling web pages on prims. This happens all the time with IE, and occasionally with firefox.

Second, I develop or find an exploitation program and post it on some random web server somewhere. I dress up the page to look innocuous. Maybe just an image so it looks like a normal textured prim.

Third, I set up a web-page-on-prim on some plot with high fly-over traffic (say, next to a telehub?).

Fourth, I sit back and wait for you to fly over. You teleport in and take off, flying over my plot. The webpage loads automatically, in the background. My program takes control over your computer. You have no idea. I start doing nasty stuff when I get around to it, like deleting all your stuff.


The point is that if we don't have some kind of ability to prevent web pages from being loaded, this makes it very simple to send users to malicious web pages. I'm sure you get virus emails all the time, but those emails don't have any way of getting you to actually visit a webpage. You have to click the links. No one is forcing you to, it requires conscious activity on your part. In this case, however, the ivisit to the web page is automatic, and therefore the system breakin is automatic. There will be people that take advantage of this.

I use what is typically referred to as "judgement". Perhaps you've heard of it. It's the wonderful thing of human disgression which computers are unfortunately not capable of replicating, and is the basis of most computer related security problems.

An example, you say? OK, here's a good one.

I do a decent bit of business on eBay, and payments through PayPal. I regularly get emails saying that my account will be suspended, and I must update my information immediately.

A lot of times, these emails contain a URL which is even a redirect page from eBay or PayPal domains. However, through my own judgement I can realize that these are a scam, and not visit the URL in question.

Does this mean I can't use eBay or Paypal? No. However, it does mean I can use my own judgement to determine that the link provided in this email is not "safe", and that going to www.ebay.com is "safe".

We're not talking about absolutes here -- we're talking about real world risk assessment. Computer security is not an absolute. You can not make your computer "secure". However, the difference between what is considered a secure platform and one which is not, as well as proper security practices, is in mitigating risks.

The system that we're discussing here is a high risk version, versus a low risk version. What I want to know is what Linden Labs has in mind (should they do this at all) to mitigate the risks involved.

If you would like to know more about security risk mitigation and threats, I suggest you visit some associations like SANS, CERT, etc and do some research. It doesn't sound like you have a very good knowledge of risk assessment in general.

can for get popup prims lol
seriously if we could get it to work out of game as well we could get scripts to store data on a webpage for us which would give shop owners a greater advantage.

Frankly, i'm still a bit puzzled how one exercises judgement by looking at the average url. Spam email trying to con you into entering your password into a simulated website is surely not a good example. It is not the act of going there that is necessarily dangerous, its the more the foollsh act of typing in information you shouldn't.

However, you have made me reflect, and investigate a little, and it does seem that I was indeed making some unfounded assumptions in my original post.

It seems that it is indeed more likely that SL will incorporate a browser into the client, rather than seize the i/o of your existing external browser. Apparently there are several open-source browser modules intended for precisely such incorporation/customisation. My apologies - whoever corrected me was right - I was wrong. My assumption of parallels with the way SL uses quicktime was premature.

With regard to security, it seems again that I jumped the gun a bit. As a Mac user, I guess I am a little spoiled.

My point was that the risks were no more than in normal browsing. I now learn that there are real risks, which are caused by weak points in the browser/opsystem combination. With Microsoft, as usual, being the worst. If we will indeed be using a special integrated browser, then it is the security of that module which will be our weak point. This will NOT therefore be the same as in normal browsing. So LL need to choose carefully if this is the way it is done. Mac users will probably get a well scrutinised module of Unix-origin, but Windows machines cannot draw on this huge resource I guess?

Maybe we wont get a full browser at all. Just the ability to render html text onto a prim face. No clicks, no surfing around, no java, no javascript, no cookies, no forms. Just straight html. As a way of painting a page.

Data could be got through to the webserver, not by browser url clicking, but by using scripts to change the url being read (maybe associated with the land). So it would be possible, for example, to use voice command to select data to display from a database. But presumably no script could read the displayed data, just the eye of the avatar.

If we need full communication with a website, I guess it all comes back to needing a good polished XML/RPC implementation.

This is actually quite easy to do for 'simple' HTML. Perl, for example, has modules that can be compiled in-line to C and other languages, and a few of the modules available deal with both web server and web crawler/client in simple and complex forms.

Note I'm not promoting Perl for the interface, just an example of how LL can get an implementation placed in simply for internal trials and feasibility studies (to determine timeline).



Probably. I do not have knowledge in that format to judge on it (plus many others have already weighed in on the subject). At the very least fill it out though for a use as a good data-stream or external interface.

I pretty much assumed that the dangers of unsolicited client-side access to unknown URLs would be obvious without explaining, so I didn't bother to explain, sorry. But Lex Neva has explained typical risk scenarios perfectly clearly, thanks Lex. Anyone who isn't aware of the security problems that MSIE in particular has been having in recent years hasn't been paying attention.

That's why I'm hoping that there is no client-side activity at all in LL's implementation of "HTML in SL", but merely barebones server-end HTML rendering of a script-specified URL to repaint the appropriate prim's texture. Any structured info that comes back with the page should end up captured within the script, and definitely not sent down to the client.

(That's where "some cost to the server" comes in, Lindar. Definitely not like direct streaming video, that's exactly the nightmare scenario we want to avoid, ie. the danger of client-side browser activity triggered every time we approach a web-enabled prim.)

In the 2.0 time frame, Cory wants to have client-side scripting and communication with in-world objects, so presumably one will be able to pass desired web-captured info back into the client under LSL and/or C# control. That should be pretty powerful, but not inherently dangerous, because which client-side scripts you run will be under your direct control rather than triggered by some arbitrary URL.

I will be thrilled if this comes hand-in-hand with better inworld text formatting, such as notecards.

Gee, Morgaine, so you actually think it might be best for the server to access the url for us, and send down the rendered page as a texture for the client to paste onto a prim?

Have I got that right ? Despite the extra work for server and link ?

I give up. I see I have insufficient knowledge to contribute in this area. I'll just watch fascinated.

Let me try to answer in broad strokes, more details as we know more:
1) We're going to use the Mozilla/Firefox code to render XHTML. Work that we and/or others do in the Mozilla code to render to Open GL will, of course, be released in accordance with the Mozilla Public License.
2) Rendering will be done client side although actual HTTP traffic may or not be routed via the simulators, depending on whether the creator wants the rendered page to be shared per person or not. If you want to do collaborative browsing, the packets need to route via the simulator. If you want to do HTTPS or are using XHTML as part of an interface, you need a direct connection.
3) Folks here (and elsewhere) have raised excellent security concerns wrt rendering unsolicited urls. Residents will need, at a minimum, an ability to set security settings for whether or not they want to render an url.
4) Regarding the DHTML, Flash, JavaScript, etc mojo that makes the web cool, our eventual goal is to render whatever Mozilla/Firefox can. However, our first priority is to have a solid XHTML renderer. Because . . .
5) If we can render an url, we can render XHTML from a script or notecard.
6) As was pointed out, our goal is not to replace the browser, since you already have a perfectly good browser on your desktop. However, it would clearly be nice to have Boing Boing and Slashdot in world !
7) We are currently working on this but it is too early to commit to a date.

Why wouldn't it be? Isn't that the very definition of innovation?

Shall I quote Philip?
"SL will take over the world." (Town Hall, last fall)

alot of good stuff in there Cory. please tell me we can go the other way and render XHTML in a notecard. please please please.

Simply doing XHTML rendering has the added bonus of being secure as well.

Can we please have our votes back now?

FIREFOX has full SVG (scaleable vector graphics) suport!

I'd rather have a committed target release first, before we let it off the radar.

neko

I just figure if they are working on it they should be able to accept it and we can move on to to our second favorite feature )

Cory, please sandbox the module that runs the Mozilla code, good and hard, inside a separate process that's chrooted and running with the near-zero permissions of user "nobody".

I have no idea how you can do that on Windoze, but Linux and Mac will allow that easily, needless to say. [We will have the Linux client long before then, won't we?]

Using the client's resources as a renderer is fine, that's scalable. Causing it to crash or to compromise its host because of some of the nasty stuff out there on the net is not fine though, and it can be prevented. The embedded renderer must have absolutely zero ability to affect the local machine.