Jenni Darkwatch

Hmmmm since you mentioned you reinstalled everything... did you install the ATI driver from their web page, or used the windows default driver?

Weird, it doesn't give me that line on my viewer... but then again, I'm neither on Windows nor using ATI: OpenGL Version: 4.1.0 NVIDIA 260.19.06

Ah oke. Thanks for the clarification, and that does make sense. We don't accept anon prepaids either (in-store, RL). Too much fraud.

There used to be a very weird bug that hit me a few times - if i'd mute a sound channel, the viewer would become insanely slow. That was a long, long time ago though. Regardless of that, this here made me wonder if there's still a driver issue: OpenGL Version: 4.0.10151 Compatibility Profile Context

In my own experience, Vaios seem to generally run extremely hot compared to some other brands. Also, if you do run SL on _any_ laptop, don't expect much battery life. 3D graphics simply drain batteries, _especiall_ since SL is programmed in a rather cruddy way: It uses as much of your GPU as it can, with no way to throttle it that I know of. Reducing graphics quality doesn't significantly reduce the problem, as SLs framerate will then simply go through the roof even if it makes no sense to have FPS higher than the screen refresh. I do not know if Blender suffers from the same issue, though I'd hope not. External/secondary batteries help, though they are generally quite heavy. I second the suggestion about a lap cooling pad. And for outdoors, do check if the display is even useable outdoors. Quite a few are nigh unreadable in the sun.

PeterCanessa Oh wrote: [@ Jenni - neither pre-paid cards nor paypal are accepted by LL for most people] Really? Ew. Didn't know that.

Anti-Aliasing is a hit&miss setting especially when shadows are enabled. With that card you should pretty much be able to run shadows fulltime and still get ~30FPS in all but the busiest venues.

I used them in the past, never had any problems. However, when they were swamped it could take a week or two until they got around to sending the L$. Hoever, whether you have a CC or not - it's FAR cheaper to just buy L$. Get a prepaid card or use PayPal. Why cheaper? Well. L$250 is about US$1. Unless you really enjoy spending hours to get a few L$, neither money trees nor MetaRL are worth the time and effort. Btw, MetaRL is not affiliated with LL, therefore asking LL for help is not going to do you any good. And unless you're a paying member, LL won't help you anyway. Edit: I just looked at the page again... there's at least two links on there that lead to very, VERY dangerous downloads (Trojan-infected spyware). Guess they really changed from "ok" to "very suspect".

I'd say there might be some who use viewers without support for it, but the majority these days probably do support it. I've used it for months now, and so far never had anyone say it didn't work for them.

More or less soon your point might be moot. LL is working on code to deal with encroaching on other peoples land.

Bound parameters should prevent injection attacks As for the owner key in the header... there you'd want one additional check, to validate that the request came from one of the SL servers. That'd be a two-stage check: First, check if the remote host name gethostbyaddr($_SERVER["REMOTE_ADDR"]) ends with ".agni.lindenlab.com". Notice the dot, it's kinda important, though less so in this specific case. Second, take the full name you got from the gethostbyaddr call and reverse it, i.e. gethostbyname() and see if the resulting IP matches $_SERVER["REMOTE_ADDR"]. If either of the two don't match, someone is trying to spoof the reply from some offworld site. As far as I'm aware it should not be possible to spoof the headers (i.e. owner key) from within LSL, though don't quote me on that Also, don't use base64 as "encryption", because it's not. It's a transfer encoding to ensure binary data gets passed safely. For your password, use llSHA1String to encrypt it before transmitting it. That way, the password itself never gets transmitted and someone would have to brute force the password. That principle is known as "Pre-Shared Keys", PSK. Preventing replay attacks is a bit more involved. You're right, it means replaying a command (or data stream) over and over. The problem has to do with a relatively simple problem, like this example: 1. Your LSL script sends a "Start Game", hashing the password with SHA1 into something like 2E73318E547AF1B28CC0C96F95DDC9B1EE906B8D 2. The server gets that command, and checks that the SHA1 matches the password it already knows. They match so it starts the game. ...game progresses and ends... and then... 3. Malicious user takes the whole game session and "replays" it against the server, essentially duplicating the game progress. Most often that's used to skew the stats by unfairly replaying a good game over and over. Now, with the communication between the SL server and your machine, the communication should in theory remain private. Practically, it may or may not be. The trick is to make the replay impossible. One very common way you can do it is by adding a so-called "Nonce" to the password hash. Simply: 1. Your PHP server generates a nonce and sends it to the LSL script 2. The LSL script generates a nonce and sends it to the PHP server 3. The LSL script now "signs" all communication with llSHA1String(sPassword+sNonceFromPHP) 4. The PHP Server now signs all communication with sha1(sPassword.sNonceFromLSL) II think you're on the right track.

Sieht so aus als waer die Einstellung nicht veraenderbar wenn Voice nicht aktiv ist. Also kurz Voice aktivieren, dann kannst du die Einstellung veraendern.

Void has mentioned some of the more pertinent points. There are a few security best practices (depending a lot on what level of security you want/need): 1. Never, EVER, use the root or admin account to update your DB or script your DB in any way shape or form. 2. If you use MySQL, use something like mysql_real_escape_string. If you use another DB, use the equivalent. 3. Add as many sanity checks to input data as you can. If you expect numeric data, make sure you get numeric data. If you expect string data, add plausibility checks as you see fit. 4. Headers can easily be spoofed. Do not ever trust headers for authentication or verification purposes, maybe with the exception of server vars set by your web server. 5. For any kind of auth mechanism, make sure it's not vulnerable to replay attacks. What that means is that someone replaying the data stream to your server should not succeed. One common approach is to have the server provide a random token on the initial handshake, the LSL script then combines that with its own secret key and sends it back to the server. If the server knows that password, it can then verify that the LSL script also knows it - without ever transmitting the actual password over the wire in any form. One easy way to do so would be llSHA1String(sPassword+sNonceToken), which equates to sha1($sPassword.$sNonceToken) in PHP. 6. There is no good way to encrypt data in LSL. The wiki has a few implementations, though they all have the disadvantage that they are fairly slow. XTEA is about the fastest there I think, but it still ain't fast. Worst thing you can do is create your own And if I haven't mentioned it enough: Add as many plausibility checks as you possibly can. Go overboard if you have to. On the LSL side it's a bit painful to do that, but... still a good idea Generally, you don't want your server to get hacked though.

To add to Randalls excellent answer: Beware of length limits in the description field, and also keep in mind that this info is accessible to anyone examining the object.

~shrug~ The fact remains, people are morons if they post _any_ personal information about themselves online. It's your responsibility to whom and what you reveal, and that includes friends.

I started out with one of the default avis... Forgot what that one was called, it's not in the library anymore. Eventually spent a lot of time recreating my RL shape in SL, rezzing reference prims to get measurements right and so on and so on. All that stopped after I had yet another dumb HNG (Horny Net Geek) hit on me. Sorry, don't have a pic of that avi. Then I went tiny. Love the avi to bits, but tinies just wear me out - they're a bit _too_ lively and exuberant for my old soul. Here it is: Then I went through a plethora of animal avis... leopard, cat, wolf, cheetah... until I found my favorite: Horse avatars! That's what I am most days, though in varying appearance and various breeds. including unicorn, pegasus, fae, kelpie and so on: Sorry for the low contrast. These days, not many people can say they've ever seen me human. About the only time I use my human avi is in no-script sims, and then I'm excessively shy, anti-social and unwilling to talk to anyone.

I'm too old to care anymore. So many times people vanished, sometimes with an explanation, sometimes without. It hurt the first time, hurt less the second time, nowadays it _may_ elicit an indifferent shrug. Online culture is largely transient, indifferent, apparently unwilling to see that there's a human being with feelings behind that avatar. Myself, if I know someone well enough to care, I'll give them my RL contact information.

Back on topic, just stumbled across this: http://www.kurzweilai.net/virtual-conferencing-using-3d-avatars-may-be-imminent The article felt to me like someone really missed the boat. Or maybe lived in a cave in the last 20 years.

~chuckle~ Sounds familiar. In a former life, I did some pentesting. It was always fun to prove just how easy it is to take a company down. Sometimes it's as easy as confidently walking into an office, grabbing the server, and walking out with some mumblings of "maintenance, will be right back". Your anecdote doesn't have enough info to really tell, but sounds to me like someone in IT "forgot" to enable host isolation. I hope they at least had departmental subnet isolation. Either way, in this case IT blew it. Royally. Along with the division boss.

Totally agreed. If they want to expand, they need to find new markets. Your idea of licensing the grid software is great, as long as they don't do it the ridiculous way they tried with behind-the-firewall solutions Kingdon backed. The HyperGrid project seems to be very much dead though. An idea... how about licensing pre-installed "sims" to SL members in good standing? I.e. with verified RL info on file, NDA signed, but hooked to the SL asset servers for a lower monthly fee? It'd offload bandwidth costs from LL, might be an idea.

Void Singer wrote: well somthing has to render the content, since it's dynamic and not static, so for low powered devices, that would have to be cloud rendering of some sort. (which will need to be paid for by someone) and while they may be able to handle a yuotube video of a few minutes, anything more is going to cost in bandwidth (more cash), as well as power consumption (tech limitation for mobile computing)... and still be squeezed into a relatively small space... I think anyone trying to queeze SL's dynamic world into that sort of microsm just isn't realizing that that it doesn't work like that... certain content and paradigms require certain resources, and mobile tech just doesn't have it yet. and trying to cram SL into that tiny add living in clip paradigm will never work.... it can't handle the level of dynamicism involved. I'm not entirely convinced that SL on mobile platforms like tablets would take off in the long run - if nothing else it might generate some good publicity. As I said, I believe for such devices "augmented reality" will become much more popular sometime down the road. For the time being I'd stay away from cloud rendering, it's still a fair bit too experimental. On the other hand, a lot of people who _do_ have tablets still have their desktop PCs collecting dust. Why not use them for rendering? The additions to the client aren't any more difficult than adding this new ill-implemented basic mode. The latency would, I think, be tolerable for the visuals. SL isn't a First Person Shooter after all, even if some use it for that. fire every employee that gets hit with malware... seriously? well now we know how a hacker could both shut down any company you are running, and cherry pick head hunt your best people while they're at it.... In our case, we have a simple policy: You don't open an attachment unless it came from within the company. Spreadsheets and word processing documents get converted to our standardized document format at ingress, a process that kills common malware and would require a lot of inside knowledge to bypass. Any other kind of attachment is strictly prohibited on the corporate network, should one make it through (hasn't happened in the last few years). Emails are the weakest spot, so there's enough levels of protection there to provide a reasonable level of safety. The only web pages that are directly accessible from work PCs are work-related intranet pages. Safe use of work PCs gets taught twice a year to every employee with any kind of partial Internet access, once a year to everyone else. We have two networks - one for internal use, no direct Internet access, one for full web access (i.e. not the same as full Internet access) from a sandboxed environment that's open to everyone. The sandboxes do get trashed by malware once in a blue moon. Since sandboxes have no persistence beyond the session, no biggie. Full Internet access is also available if people bring their own hardware in, something which we generally allow to employees in good standing. After another training session, of course. Thus, yes, if someones work PC gets hit with malware, they did something that violated policy. And hence they don't need to come back the next day. So far, that has happened twice. In both cases the PCs were killed automatically before any harm was done. Maybe it sounds draconian, but with sensitive information in our databases it's simple necessity. There's still one vector that allows successful theft of that data. The boss doesn't believe thieves can get into secure data facilities, despite proof to the contrary. ~shrug~ At least "breaking in" was a fun distraction.

I'd disable the unwanted dialog, if you're the creator. You cannot actually prioritize or otherwise influence dialog windows via script, though you could add an llSleep to the dialog call you want to show on top.

leliel Mirihi wrote: Right, because nobody buys a new computer because it's faster. Lamest argument ever. For work, PCs should be bought when there is a need, not to fulfill someones fancy. What you do on your private dime is of course up to you. Actually... for most malware, that's exactly how it gets on the system. Users clicking on email attachments or on lovely webpage ads/popups. Malware that actually uses OS exploits is what corporate firewalls are for. With portable devices it gets a bit more complicated, but really not by too much. There's plenty of documentation out there to explain how that's done, no need for me to go into details. Actually...not. Users clicking on a hand crafted email attachment that exploits a bug in Word/Excel/Acrobat then it exploits a bug in windows to escalate itself to system level. Web sites that do fly by infections, no clicking required, and exploit a bug in the browser/plugin, then escalates itself to system level through a windows bug. You're about a decade behind on your malware knowledge. Funny how that word decade keeps popping up. Exactly what I said. Users clicking on BS they shouldn't click on. But even so - if such a click infects a work PC, fire the employee, then fire whoever is responsible for your IT security.

leliel Mirihi wrote: How do you think the malware gets onto your system? It's not like Microsoft puts a handy little short cut on the desktop labeled "Malware click here to pwn the system". Actually... for most malware, that's exactly how it gets on the system. Users clicking on email attachments or on lovely webpage ads/popups. Malware that actually uses OS exploits is what corporate firewalls are for. With portable devices it gets a bit more complicated, but really not by too much. There's plenty of documentation out there to explain how that's done, no need for me to go into details.

leliel Mirihi wrote: The phrases decade old, fast and responsive, and web browser don't belong in the same sentence. Two hundred dollars will buy you a 4 year Core 2 duo that's 6 times faster than the fastest Pentium 4 Intel ever released. Just imagine what the latest and greatest can do. So you'll buy new PCs just because they're newer? Grand. Remind me never to hire you, it's be very bad for the bottom line.