In theory, a server should never be able to compromise a browser (no matter what URL the server is hosted at *eye roll*), so yes, it's possible. Is it *practical*? Probably not. Modern browsers are complex beasts, with tons of attack surface and a constant push towards better performance.

Great post.

For the record, though, IE's sandbox is pretty bad. It allows read (though not write) access a lot of stuff. It also turns off by default when visiting a page on the local network. This sounds sane until you realize that:
A) A sandbox is only useful for containing a browser compromise.
B) A compromised browser can probably run arbitrary code.
C) You can run a web server from inside the sandbox.
D) Localhost counts as a local network page.
E) If you've got a browser compromise, you can definitely direct the compromised browser to web server hosting another copy of the exploit.

So yeah, most of the time the IE sandbox is going to be a speedbump at best. Chrome's sandbox (on Windows, at least) uses similar mechanisms, but runs at even lower privileges and additionally has a bunch of other restrictions; it's so unprivileged that it can't even launch another executable under its own privilege level. On the other hand, Firefox still just runs as your user account without even a speedbump to accessing anything you can access if it should get compromised.

You can petition the professor (and loop in whoever is responsible for IT security, and work your way up the university bureaucracy as needed, pointing out that Java browser plugins are insecure and the university is putting student data and university network infrastructure at risk by requiring them to be enabled. Far better cause than most of the things I saw student petitions about, and a lot of those were addressed anyhow.

For the record, I completed my Bachelors in Computer Engineering in 2010, in the US. I never once needed a Java web plugin. I don't know how "widely used" it was back then, much less today, but it certainly wasn't required.

Admittedly, universities are... lets say "not the most security-conscious" of environments. But I still say there's no excuse for ongoing use of Java (and it does put student and university machines at risk). It's really not actually required in the academic world, and there *are* alternatives.

Sorry, I'd play you some music but I put my tiny violin somewhere and now I can't find it without a magnifying glass. Found a megaphone, though:

FUCKING STOP FINANCIALLY REWARDING COMPANIES THAT REQUIRE JAVA APPLETS!

When was the last time you refreshed your hardware, any of it? If it was in the last five years (and I'm being generous there, Java applets were known to be idiotic before that, too) and you purchased anything that requires a Java applet, then you are part of the problem and I have *no* sympathy for you. Make a migration timeline, get bids from vendors, include a specific requirement prohibiting dependencies on things like the Java plugin, and try actually making the world a better place. I don't expect that you can drop it all tomorrow, but you can damn well start on a plan to drop it today...

Who the hell modded this Troll? Oracle fanboys (do those even exist?) getting modpoints?

Java in the browser was a bad idea to begin with, and is damn near inexcusable today. If it absolutely must exist, it should do so on a whitelist system, rather than just allowing arbitrary websites to run arbitrary applets.

Just because we don't *know* about Java applet 0-days (that's what makes them 0-days, after all) doesn't mean they don't exist. Proper use of NoScript (even if we assumed NoScript didn't block Java) might keep you safer than blocking Java, but blocking Java is an easy change that requires almost no user knowledge and will impact very few people.

Or just hook the keystroke window messages in the victim apps. You can do that using the debug APIs (assuming you are executing, and the other process isn't more trusted than your process or in a different user session), or by setting Image File Execution Options (requires Admin) to tell Windows to load a specific DLL into every process...

Little-known fact about Windows: you can have it do keyboard shortcuts like that too! This isn't even new; I know it was in Windows 2000 and is probably even older. The only problem is that it can't replace built-in or app-defined shortcuts, so things like Win+W won't work (On Win8, at least, that's a Search panel for Settings).

Right-click any shortcut (including from the Taskbar or Start menu/screen), and select Properties (or open Properties some other way). There will be an option for "Shortcut Key". Select the option, press the combination of meta-keys + character to use to launch the shortcut, and hit OK.

Search on Win95 was nigh-worthless. Even back then, you had to waste a lot of time organizing stuff or you'd lose it utterly. A decent OS should (and some do) have search features that make this a non-issue.

Any time I try using a pre-Vista version of Windows - a blessedly rare event now, with XP out of extended support - it drives me insane. I can't launch programs from Start using search, I can't quickly find files across a folder tree using search, I have to spend a bunch of time navigating menus / directories even on a well-organized system, and visually scrolling anything else...

Win95's UI was minimalist, but it wasn't *good*. The abysmal search was only one of its problems. If you remember it fondly, I suspect you haven't used it in a long time.

Definitely a whoosh, although there's actually some perks to the Windows NT kernel vs. the Linux one.

In any case, I use Windows significantly more than Linux (though I use both regularly), and the Linux I use is usually (though not always) in a VM and thus it doesn't have to deal with really weird hardware. Nonetheless, I get about the same number of kernel panics in each OS (1-3 per year, across three different regularly-used machines and various client loaners).

F9 #4 is the one where "a first stage engine acted up", but (contrary to your claim) it is inaccurate to say that "the secondary payload failed to reach orbit". With the loss of one engine from the first stage, the remaining engines burned longer to reach the desired orbit. This was successful (F9 being one of very few rocket boosters capable of mission completion despite an engine loss at any stage of the flight).

HOWEVER, while both payloads successfully made orbit, the secondary payload would have required an additional burn to place it in its intended orbit. The F9 second stage almost certainly could have done this; it had the fuel, and it had the relight capability. However, the primary payload was bound for the ISS, and that means that the secondary payload would need to be placed in a safely different orbit. The confidence that F9's second stage could do so dropped below the extremely high threshold set by NASA (IIRC, it dropped to a mere 95% confidence), so NASA told them not to conduct the second burn. Consequently, the second payload was released in lower-then-designed orbit (though still in orbit) and re-entered after a relatively brief period.

There's better options than PBKDF2, like scrypt. Also, both require you to chose some parameters; PBKDF2 with a salt of String.Empty, hash algorithm of MD5, and iteration count of 1 is... just an MD5-hashed password. Obviously, those are terrible and stupid parameters, but if people were *good* at choosing secure options then this whole thread wouldn't exist. At least scrypt *only* has the work factor, and it's pretty straightforward.

There's generally no way to send the user a secure (i.e. encrypted) message. All you can do is make the token short-lived and hope that nobody is intercepting server-to-server email traffic (and that the user's email account is secure, both from malicious clients and from server-to-client interception). It sucks, but until email encryption of one sort or another becomes more ubiquitous, it's the only workable option.

Don't ever store passwords (reversibly) encrypted. Don't even (just) hash them; hash functions are way too fast (and yes, fast is bad here). There should be no way for anybody to get the password out of the info stored in the database, even if they know all your keys.

Use a slow key derivation function instead. PBKDF2 is popular, because it's easy to understand and widely supported; it's basically just taking a value (the password), salting it (you are using a strong, cryptographically random, per-user salt... right?) hashing it, salting the resulting digest again, hashing the salted digest, and repeating the last two steps over and over (tens of thousands of iterations are common). At the end of that, you compare the resulting digest to the value stored in the database; if they match, the user is authenticated. Obviously, don't try implementing this yourself; even simple crypto should always be written by an expert, and you should use the resulting library. There are lots of places to find it, though.

Alternatively, you can use the purpose-built algorithms like scrypt or bcrypt. These are more complex (and less widely implemented) than PBKDF2, but they also offer more advantages against brute forcing, such as requiring a lot of RAM during the computation so you can't build a massively parallel hash-cracking machine (a commodity GPU can do billions of hashes per second in parallel; these algorithms make those parallel attacks harder).

Not in line with any of SpaceX's launch sites, I think. You could probably find some suitable sites that are reachable on certain launch trajectories, but for most launches that would be a pretty huge diversion. Also, the desert may be clear but the coastlines are generally not, and - at least for the first launches - I think the goal was to avoid having the first stage do its boostback burn towards *anything* inhabited, even if it was expected to fly over the inhabited region a few miles up. That's just a guess though.

For anybody who doesn't know about it, http://spacexstats.com/index.p... is a neat site that lists upcoming SpaceX missions with countdowns to expected launch times, or estimates where the exact time isn't yet determined. It also has some statistics (though, sadly, they're almost always out of date) about things like launch records, flight times, payload mass, and so on. Obviously not as useful as SpaceX.com itself on launch day, but handy for checking when launch day will come (or when, for example, the first flight of a new vehicle is expected). It also has links to info about past launches.

I'm not affiliated with the site in any way (if I were, it'd keep those statistics better up to date) but I thought it might interest some other folks who like to follow SpaceX. Oh, and for the record, the link to tomorrow/today's launch is http://spacexstats.com/mission...