Jump to content

Jenni Darkwatch

Resident
 View Profile  See their activity

  • Posts

    1,703

  • Joined

  • Last visited

 Content Type 

Posts posted by Jenni Darkwatch

    My first notebook purchase - Vaio S-series with Radeon(TM) HD 6630M 1GB

    in General Discussion Forum

    Posted

    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.

    GTX 460

    in Second Life Viewer

    Posted

    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.

    metaRL.com Problems

    in General Discussion Forum

    Posted

    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".

    HTTPRequest and Databases - Safest Way?

    in LSL Scripting

    Posted

    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.

    HTTPRequest and Databases - Safest Way?

    in LSL Scripting

    Posted

    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.

    How Has Your Avatar Evolved?

    in Your Avatar

    Posted

    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:TinyFizzlePop.png

    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:HorseAvi.jpeg

    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.

    Coping with Second Death

    in Make Friends

    Posted

    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.

    Concurrency dropping.

    in General Discussion Forum

    Posted

    ~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.

    Concurrency dropping.

    in General Discussion Forum

    Posted

    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.

    Concurrency dropping.

    in General Discussion Forum

    Posted

     

    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....

    nonono

     

    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.

    Concurrency dropping.

    in General Discussion Forum

    Posted

     

    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.

     

    Concurrency dropping.

    in General Discussion Forum

    Posted

     

    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.

     

    Concurrency dropping.

    in General Discussion Forum

    Posted

     

    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.

     

    Concurrency dropping.

    in General Discussion Forum

    Posted

     

    Void Singer wrote:

     
    Jenni Darkwatch wrote:

    LL could easily have made SL accessible via cellphones. It's trivial to do, yet no one there seems to see beyond the walls of their crystal palace.

     

    this one statement puzzles me more than any other.... how exactly would SL be feasibly available from a cellphone?

    nevermind for the moment the limitations of content to screen size, I'm going to assume you mean cloud rending of scenes, which means massive live video bandwith use, and forget about the inherent delay time to render and send, plus the cost associated with that much wireless phone usage, or the fact that the jitter on most wireless signals and overall stability is not really  reliable.

    and for what? a low rez grainy image or a "live" virtual world that you are constantly lagging behind, all at ridiculous service and bandwith costs? that was a pipe dream even before they tried it with the "interest" beta.

     

    not every product is suited for the general market or to every particular directed purpose.... it's often better to target a core market, even a niche one, and then flexible enough to take in closely related markets...

     

    Smartphone was of course what I meant, and even there, more the tablet hybrids. Sorry, not a native speaker here. Cloud rendering is an interesting concept, but that wasn't even remotely what I meant. SL on the go isn't what I am really talking about either, though I'm guessing some people would find that appealing too... while driving their car into a crowd of people. For smartphones I feel augmented reality makes much more sense than virtual reality though.

    The way I see it, more and more people will use relatively low-power "portable" computers. Tablets most likely, considering their popularity. They have decent sized screens but not the oomph to run something like SL without draining the batteries in the time it takes to log in. On the other hand, many have built-in video stream decoding, as used for example by Netflix for streaming vids to iPhone and iPad. So the bandwidth is obviously there. The bandwidth costs... that's an issue of course, but likely less than one would think, especially if programmed right. There's quite a few techniques to limit bandwidth in such environments. Scale the image dynamically according to screen size. Lower the streams FPS if nothing much changes on-screen. If a user wishes to, turn off the visuals and go to text/voice chat only... simple things.

    Why bother though? SL has, it seems, reached the ceiling. Trying to expand into new markets and become a pioneer is something LL does neither have the vision for, nor would the current user base appreciate it. After all there's still people who honestly think SL was better in '03.

×
×
  • Create New...