Second Life 1.9.0(17) version of Linux client alpha released!

I got the feeling that the Open Source SL Client may also be the Universal Browser that I seem to have heard of...

If they are reachitecturing the SL client into a browser type application, the security issues vanish to a Very Large Extent. And a re-architecture COULD mean that it is also easy to a) modularize, so its maintainable, and b) sharply split between the Display and the Processing, enabling security completely on the server side, and none necessary in the SL Client (Browser). The SL Browser would be purely a presentation interface, with a few limited protocols to communicate to the SL servers.

Open Source would then be very doable...

Just another rumour for the mill

PS: Security ONLY in terms of a home-made client that would allow the server data to be hacked... That is my concern, and that of our "untrusting" fellow SLers..

They can publish the protocol, though:
http://openhbci.sourceforge.net/index.html

I think Firefox is a fair comparison... it's more than "just a viewer". I can have it send commands back to the bank and move money around all I like, including moving it to accounts that I do not control. All this happens over an open protocol (encrypted, yes, but open) called HTTP. Maybe you've heard of it . The bank doesn't have to publish their API (although it wouldn't kill them to do it, as long as their server is up to snuff) for people to mess with it, anyone malicious enough and skilled enough can cause trouble for insecure software.

The server is the gatekeeper, and it's up to the server to validate the commands it is given. If you're running a server that doesn't check into what it's about to do, and for whom, you've got more problems than an open protocol (which isn't a problem to begin with). Hacked clients can't mess with a solidly designed and written server, whether that server is open source or not. This especially true with SL, since the client doesn't do much of anything but display the environment and send back well-defined commands (just like a web browser). All the real work is done on the server and the results are streamed out to the clients.

Of course, there is always the possibility of trojaned clients, but the same is true for basically everything else. If a bad guy can get you to run the code he gives you, you're screwed. So don't run SL clients from suspicious, unfamiliar sources. Just like everything else. If you found a site called thebestestfirfoxever.com, and it made huge (misspelled) promises, would you run that code? (Hint: your answer better be no )


Angel: Things like the embedded web browser and open source SL make me think of the guy in the novel Snow Crash who was severely disabled (essentially immobile) in real life, but had an elaborate existence in the metaverse...

Do what with a web browser? Bank? Security sensitive stuff? Since we're all talking about this, I'd say we expect that with SL too.


You also see people hunting for (and finding) security problems with closed source software (look at Windows and IE). The difference with open source is that there are more chances for the good guys to find and fix the problems.

This all comes down to trusting LL to do a good job with the server code (whether it's open or not). If they do a bad job, we've got problems, and they'll be out of business.

A web browser is not comparable to an online game client for a variety of reasons. The mode important reason would be, that the client gets data the player is not supposed to see or to change. A web broswer however does never get any secret data (and I don't mean passwords or encrypted pages, since on the user's end the contents get decrypted anyway). To display and manage your SL surroundings the client needs to know a lot more about what's going on than the user is meant to see. A hacked client could use this data to cause massive problems for gameplay of others as well as cheating, maybe even adding inventory items or money, effectively crashing the L$ monetary system. All this is not possible via web browser and i.e. a home banking application, unless it's very crappy code

Well, Counter Strike is closed source, but there are TONS of cheats for it (wallhacks, aimbots, etc).

So what's the point?

If it's possible to add inventory items or money from the client, a good hacker can find it and exploit it today, too. So how's that security?

Nobody is suggesting that open source software is less secure than closed source. The only difference is closed source has the additional protection of security by obscurity. (and before anyone suggests that obscurity is no security, hands up everyone who uses passwords and doesn't tell anyone else what they are).

Its overly simplistic. A bug in firefox that causes your website to render vivid green, does not mean all subsequent visitors see a green website. This is possible with the second life client.

Firefox would only comes close to being a valid comparison if EVERY web site was a wiki.

Cheats in counter strike are a pain in the backside, they do not compromise the very existence of counter strike.

But the user can see this data right now, with relaively little difficulty. Run SL from gdb, and run ethereal while you play. Now you can see all that data, and if it's encrypted in the stream, you should be able to see it in gdb post-decryption.

If the Client-Server API is robust, then this isn't an issue. Sure, the user can see a variety of data about the world around him, but being able to see it doesn't do any good unless you can modify it. Again, a robust API should prevent this. If we're talking about seeing other people's no-mod scripts, those *should* only be sent to non-owning users in a compiled format, so, no problem there. I can't think of a single example of data that the client *must* have that the user *must not* know about.

It is true, you can sniff the data, you can even try to reverse-engeneer the data and send manipulated requests back to the servers. But all this requires a LOT of knowledge and time. A complete client, delivering all the data in nicely packaged messages at your disposal, would make the job very much easier.

I still believe that it would be possible to protect the servers from modified clients, but that would probably mean a huge effort to get the protocol safe and robust enough. And as we all know, sims are bound to crash on a client's hiccup, so I really don't want to know what damage one could do if they decyphered the protocol

I think you have not understand what security by obscurity means. You state that it is the same as protecting account data. but the criticism of security by obscurity means that this is really SECURITY BY ILLUSION:

I recently attended a real life LUG meeting. Some guys hacked a private WLAN. We discovered that the access data of the DSL account was stored in the router in an obscure way:

* If you opened the router web admin interface you saw dots in the password field.
* If you opened the same page in source view you could see that these dots where inserted only by a javascript and that the access data really was in plain text there !!! (Can you believe this. I think this was one of the currently most widly used Siemens WLAN routers in Germany (I think it was the T-Sinus 154DSL).

Such things only happen in closed source projects. Companies like Siemens are not that small and they SHOULD know better, but: WELL NOBODY KNOWS!!?? this is what security by obscurity is about: We hide our concepts and that means that the public is not informed about the security holes - only hackers see them (and as they are positive ppl they might make it public to save the privacy of the customers) and the criminals. The criminals do the same as hackers but use it for their own benefit.

So hiding information in the long term is good for criminals, nobody else. It is a good habbit though not to make security holes known to everybody immediately but give developers a chance to quickly make patches available.

The problem with closed source than again is that ppl can not do their own patches. Well ... some can.

So whoever hides code and believes that will protect his system that surely just means that the GOOD people are not knowing that the EVIL guys already abuse the system.

And also we could say: "Security by itself is an illusion" there is only relative security. And OTOH: A dozen pair of eyes do see more than just one or two pair of eyes. That's just a fact.



Vinci

Yes - thats exactly it. There is no security, you just keep your mouth shut. I didn't lock my car, some one might try the handle, they might not. If I don't tell everyone I see thats my cars unlocked I stand a pretty good chance of it still being my car when I get back.

OTOH, I could make my car like fort knox, publish all my schematics so everyone can see how secure it is. maybe they will even see things I have missed and help me fix them! Maybe they will just use the information to steal my car and run me over with it.

Who cares, my car might just be a beat up pite of sh1t that isnt worth stealing.



D--|>

...... Here, let me lend you this shovel. Just keep on digging, there be gold down there somewhere!

I think the security argument is a bit of a red herring -- especially since I've seen a lot of speculation about it by armchair quarterbacks, but I haven't seen anything that suggests it's an official position.

No, if there's resistance to open-sourcing the application, I suspect it has very little to do with security, and a lot to do with trade secrets. In the business world, if you invent something and want to stay a step ahead of your competitors, you either keep it a trade secret, or you patent it -- and I doubt many people in this crowd are willing to argue in favor of software patents.

To get back on topic, I'll give a quick review of my preliminary experience with this release...

The new client loaded fine for me once I installed the db42 package. I copied over the contents of the SecondLife/user_settings folder, and this seemed to retain all my old settings, including my autologin data.

Frame rates for me have been really poor running 1.9.x under Windows 2000 -- noticably lower than 1.8. The Linux client gives me 1.5 to 2 times the frame rate the Windows one does, which makes the game feel snappier. Textures load very slowly in both clients, which seems to be a 'feature' of all the recent SL versions. Every new version they release gets a little bit slower, sorta like Windows itself.

I noticed some glitches with avatar textures not updating, or being replaced with parts of the window. This also occurs in the Windows client, though, so it's not a Linux-specific bug. The first time your shirt gets replaced by the menu bar, it's kind of amusing. After that it gets old. Logging out and logging back in doesn't resolve it; it's necessary to change clothing to get a normal appearance back. I'm not sure if this is just a local display glitch or if it's visible to other characters. Again, this doesn't seem to be just a Linux bug, though.

Some keyboard shortcuts don't work. For example, Home to fly/stop flying works, and Ctrl-Shift-1 to bring up the statistics panel works, but M for mouselook doesn't work. At first I thought Alt-Click didn't work, but then I realized KDE was grabbing it for its own purposes. Once I changed KDE's configuration, it worked fine.

Connecting with the Linux client causes my charater to assume an arms-out pose until I move. Slight annoyance, nothing big.

Does anybody have an idea of how long it will be until the major bugs, like the misdetection of system memory, will take to fix? Right now the Linux client is ok to poke around in a little bit, but it's not really useful as my main client because it's stuck in low-rez mode. I'd be happy with even just a workaround like a commandline switch.

Also, I wonder if the SL client has some SSE or MMX code in it that is disabled at the moment because it can't detect the processor correctly? The Linux client is way slower (2-8 FPS at 1024x76 than the Windows client (20-30 FPS at 1280x1024) for me, and I'm wondering if this might be the reason.

I'm not complaining (it is an alpha after all, bugs are expected), but it just seems like the big game breaking bugs aren't there release after release while the little stuff that barely mattered is fixed.

I have no idea when any upgrades of the client are planned, but I would REALLY like to see memory detection, have sound, and an interface to the file system (uploads/downloads).

I am sorry to hear about your low framerates, but this sounds more like a Video Driver issue, as far as I can tell from the posts on this. I also have the same Linux Alpha problems, with a tweaked settings.ini for things like graphic memory, debug, etc and my frame rate is quite a bit higher than on Windows XP.

As far as I can see, the framerate is not affected negatively by the cut-down linux client; it will probably drop a bit, when things like Shiny and Ripple Water and Sound work

But the nature of the Video Card driver (native or Mesa or X) seems to make a huge difference.

There are still a couple of issues with 1.9, I think... maybe in a few days, we will get some news as to what we can expect on this.

Frankly, it is just about worth opening a new thread - When Can We Expect More Linux Integration?

Very funny
In fact, most cars are stolen with knowledge of the system (mechanics or electronics). This is the exact reason the factory-inbuilt alarm and immobilizer system in a car is worth sh*t. No sane person relies on it.

Factories try to keep their data more secret, but it seems they don't have much chance against the well organized car stealer groups.

Beware, maybe your graphics card memory size is not detected/set correctly in Linux, or other distance settings might be different in the Linux install?

Hear, hear!

File uploads didn't get included in the vote on least favourite missing features but surely this is the most shameful omission. I guess I haven't thought about the impact of this in focusing on the social, for me music and performance, side of the game.

I try not to dual boot so I'm using the linux client for building and exploring as well as socialising recently and it is running quite nicely at high res. No 800x600 days! And no full screen! I love tinkering around with mplayer, checking emails without living in mortal fear of a game crash.

I'm running JeugaLinEx, which is a gaming build of Debian (Sarge). I have a cheap 64MB PCI GeForce 550 on a P4 2400 with 1GB RAM.

My experience is similar.

I had forgotten just how slow the windows client was, until I tried it again yesterday.

Th windows video driver is one generation newer; but of course windows DOES have sound, though I normally have it turned off, and shiny. The rest is set up the same, though.

To compensate, I can see across two sims in linux, and 1/3 sim is all I manage in windows, with a much reduced fps count.

Maybe I have an old version of windows?

Instead of trying to get the SL viewer installed (which used to run) there is another viewer that is based upon SL viewer. Can someone help me get this HIPPO version 5.1 compiled and installed on www.PCBSD.org OS.

http://www.daemonforums.org/showthread.php?t=2928

Thanks in advance for any assistance you may be able to provide!

wrong posting sorry