This approach works, but generally it's better to just modify the behavior into "download but don't install (yet)". That's just a single registry change away. This isn't even the first time that Microsoft has tried to do this, but nobody (Microsoft included) remembers anything about Windows RT... Anyhow, just because the UI for delaying or manually installing updates was removed doesn't mean the functionality to do so was (it's still present in higher editions, after all). RT had the same behavior, and it was easily changed. Microsoft even tells you how!https://technet.microsoft.com/... (scroll down to the "Automatic Updates" section).
Controlling updates has always been a trivial registry value (a single integer). Just because they're removing the option in the UI for "let me choose when to install updates" doesn't mean they're actually going to force you to install them, just to demonstrate that you have non-trivial Windows administration skill. Considering how often I've wished for an "I'm not an idiot" option for most operating systems, Windows included (though on Linux you can usually get it by just making the right choice of distro), I'm OK with this.
For the record, Windows RT 8.0 - released three years ago - had this same behavior (no UI for delaying updates, configured to install them automatically). It was trivial to fix it then (and the mechanism was immediately found), and I doubt it'll be any different this time.
Don't give me any shit about "but what if granny can't defer a borked update that will blow up her machine...?". Granny has never been able to do that. She either installs all updates and on rare occasion "there's something wrong with the computer", or never installs them and gets hosed by malware until it blows up her computer.
Oh, FFS it's even documented by Microsoft. Scroll down to the "Automatic Update configuration options". https://technet.microsoft.com/...
Flash on the Nokia N800 worked fine (in late 2007), within the limits of the (400MHz, IIRC) processor and input devices (i.e. you couldn't do hover, because touchscreen). It was slow - the N800 was a damn good device for its time, but that was before mobile hardware development *really* took off the way it has the last few years - but it was usable for nearly all Flash-based sites, including things like Pandora and some of the lighter-weight games. It wasn't some crippled "Flash Lite" thing either; it could load any applet that the desktop version could, hardware (RAM, display resolution, etc.) permitting.
Don't get me wrong, many Flash applets were battery hogs (as many games were, once iPhone users got the ability to install such things). It added the user experience downsides of Flash, like Flash ads on websites (thankfully, there was a build of AdBlock Plus for Maemo, which made for by far the best mobile browsing experience at the time). It was a potential exploit vector, as Flash has always been and always will be until killed off for good. But still, to claim that there was no usable mobile Flash around that time is false.
Yeah, "moving to"... a feature that Windows has had since late 2006? Whoo...
Ever since Start search became available on Windows (Vista betas), using any version of Windows that lacks it is infuriating. I hit the Windows key, type a few letters, hit Enter (all in under a second), and... something random happens, rather than actually launching the program or control panel I identified.
For a single-boot install, it's always best to just delete all the partitions and let Windows install to the unpartitioned drive (it will add its own partitions, in fairly sane layout, and you can adjust them later). Obviously that's not an option for multi-boot systems where Windows isn't the first OS you're installing, but for single-boot it has never failed me (and I've run into lots of weird installer / partitioning issues when I tried doing otherwise).
Flash for Android is unsupported and hilariously out of date. Running it isn't so much like wearing a sign that says "kick me" as it is a fluorescent bulls-eye on your chest and back.
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.
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...
I'm going to assume you've been doing the/. equivalent of living under a rock, since this question comes up (and gets answered) every single time this topic is discussed, and that's a lot. But what the hell...
Landing on solid ground is, generally, preferable. However, unlike the ocean where you can tell all the boats to get out of a safety zone, land has these inconvenient things like buildings and infrastructure that can't simply be told to stay away for their own safety. Until it was clear how precisely SpaceX could bring the rocket down - and remember, we're talking about something returning from the edge of space, at supersonic speeds, with barely any fuel remaining, in a maneuver that had never been attempted before - it would have been foolish to bring the rocket down anywhere near any inhabited regions. Given the geography around the launch sites they use, that means the ocean is the best bet by far.
Also, sometimes they may not have a choice. The rocket *really* doesn't have a lot of fuel left as it returns, and it's going really, really fast in a direction that is decidedly away from the launch site (but not fast enough to make it all the way around the world, or the second stage wouldn't be needed to actually achieve orbital velocity). SpaceX pulls a lot of cool tricks to guide the rocket's return, like using the stage as a lifting surface (with a truly abysmal lift/drag ratio, I assume, but they're also trying to scrub speed) while controlling it with little folding grid fins (which are quite effective at those speeds). However, at the end of the day, even Falcon 9 may not have the fuel margin to return to the spaceport after launches even though it has enough fuel to launch *somewhere*. The center core of the Falcon Heavy - which flies for much longer than the F9 first stage - will be much too far downrange to boost back to the spaceport in most cases. Thus, for FH's center core, the barge may be the only landing option. Landing on a ship may be harder than landing at a conventional spaceport, but the ship can be almost anywhere there's ocean, while land-based spaceports are not noted for their mobility.
Now, with all that said, the goal is to, eventually, be able to land at the spaceport. The next F9 launch after this one will, according to a cool site called SpaceX Stats, attempt to return to the launch site and land there. This presumably demonstrates that SpaceX has been found to have sufficient precision in the first-stage landing attempts so far for it to be safe to land near people and expensive buildings. I wish them the very best of luck!
Oh look, somebody else who apparently doesn't understand how computers work. How do you expect to stop a program[me] from changing a setting in another program[me] when they both run under the same privileges? Chrome has to store its default search provider configuration somewhere. The Java installer can edit that "somewhere" and change the stored configuration. Even if Chrome stores its search configuration in "the cloud", the installer could just use Chrome's cached credentials to change the configuration there.
The only way to change this is if apps don't have the ability to interact with each other's data (something like the isolation/sandboxing used for mobile apps). Anything else, any setting that you (the user) can change, any software running on your behalf can change (whether you want it to or not). I'd expect readers of this site to be able to grasp that, but it keeps coming up so maybe not...
Yeah, the limiting it to only the highest editions of Windows was stupid. It was in XP Pro, and in all editions of Server, but in anything non-server with an Enterprise or Ultimate SKU, it was only in those editions. You could force it to run, in much the same way you can trick Home editions of Windows so they'll join a domain, but it was a hassle.
For what it's worth, Windows has a built-in grep alternative. Findstr.exe (in System32, so it's in the PATH) has slightly different syntax than grep, but it's generally not too hard to switch between them. Windows also has, and has had since DOS, more (it's actually still called more.com, though it's a full 32-bit or 64-bit Windows application), but it's grossly inferior to the options on anything *nix-like.
No equivalents of tail, sed, ssh, curl, whois, etc. or of course *nix shells (Powershell has some cool tricks but it's not the same thing) without installing recompiled versions, though, and those usually don't work as well anyhow.
Slashdot Mirror
This approach works, but generally it's better to just modify the behavior into "download but don't install (yet)". That's just a single registry change away. This isn't even the first time that Microsoft has tried to do this, but nobody (Microsoft included) remembers anything about Windows RT... Anyhow, just because the UI for delaying or manually installing updates was removed doesn't mean the functionality to do so was (it's still present in higher editions, after all). RT had the same behavior, and it was easily changed. Microsoft even tells you how! https://technet.microsoft.com/... (scroll down to the "Automatic Updates" section).
Controlling updates has always been a trivial registry value (a single integer). Just because they're removing the option in the UI for "let me choose when to install updates" doesn't mean they're actually going to force you to install them, just to demonstrate that you have non-trivial Windows administration skill. Considering how often I've wished for an "I'm not an idiot" option for most operating systems, Windows included (though on Linux you can usually get it by just making the right choice of distro), I'm OK with this.
For the record, Windows RT 8.0 - released three years ago - had this same behavior (no UI for delaying updates, configured to install them automatically). It was trivial to fix it then (and the mechanism was immediately found), and I doubt it'll be any different this time.
Don't give me any shit about "but what if granny can't defer a borked update that will blow up her machine...?". Granny has never been able to do that. She either installs all updates and on rare occasion "there's something wrong with the computer", or never installs them and gets hosed by malware until it blows up her computer.
Oh, FFS it's even documented by Microsoft. Scroll down to the "Automatic Update configuration options".
https://technet.microsoft.com/...
Flash on the Nokia N800 worked fine (in late 2007), within the limits of the (400MHz, IIRC) processor and input devices (i.e. you couldn't do hover, because touchscreen). It was slow - the N800 was a damn good device for its time, but that was before mobile hardware development *really* took off the way it has the last few years - but it was usable for nearly all Flash-based sites, including things like Pandora and some of the lighter-weight games. It wasn't some crippled "Flash Lite" thing either; it could load any applet that the desktop version could, hardware (RAM, display resolution, etc.) permitting.
Don't get me wrong, many Flash applets were battery hogs (as many games were, once iPhone users got the ability to install such things). It added the user experience downsides of Flash, like Flash ads on websites (thankfully, there was a build of AdBlock Plus for Maemo, which made for by far the best mobile browsing experience at the time). It was a potential exploit vector, as Flash has always been and always will be until killed off for good. But still, to claim that there was no usable mobile Flash around that time is false.
Yeah, "moving to"... a feature that Windows has had since late 2006? Whoo...
Ever since Start search became available on Windows (Vista betas), using any version of Windows that lacks it is infuriating. I hit the Windows key, type a few letters, hit Enter (all in under a second), and... something random happens, rather than actually launching the program or control panel I identified.
Activation can be delayed on Windows at least twice. It's kind of hidden but is supported. Lets you have sort of a trial period.
Open a root prompt (cmd, powershell, whatever). /rearm /r /t 0 if you want to use the command line for that too).
slmgr[.vbs]
Reboot (shutdown
The slmgr (Software Licensing Manager) script, and its rearm flag, is documented here: https://technet.microsoft.com/...
For a single-boot install, it's always best to just delete all the partitions and let Windows install to the unpartitioned drive (it will add its own partitions, in fairly sane layout, and you can adjust them later). Obviously that's not an option for multi-boot systems where Windows isn't the first OS you're installing, but for single-boot it has never failed me (and I've run into lots of weird installer / partitioning issues when I tried doing otherwise).
Flash for Android is unsupported and hilariously out of date. Running it isn't so much like wearing a sign that says "kick me" as it is a fluorescent bulls-eye on your chest and back.
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...
I'm going to assume you've been doing the /. equivalent of living under a rock, since this question comes up (and gets answered) every single time this topic is discussed, and that's a lot. But what the hell...
Landing on solid ground is, generally, preferable. However, unlike the ocean where you can tell all the boats to get out of a safety zone, land has these inconvenient things like buildings and infrastructure that can't simply be told to stay away for their own safety. Until it was clear how precisely SpaceX could bring the rocket down - and remember, we're talking about something returning from the edge of space, at supersonic speeds, with barely any fuel remaining, in a maneuver that had never been attempted before - it would have been foolish to bring the rocket down anywhere near any inhabited regions. Given the geography around the launch sites they use, that means the ocean is the best bet by far.
Also, sometimes they may not have a choice. The rocket *really* doesn't have a lot of fuel left as it returns, and it's going really, really fast in a direction that is decidedly away from the launch site (but not fast enough to make it all the way around the world, or the second stage wouldn't be needed to actually achieve orbital velocity). SpaceX pulls a lot of cool tricks to guide the rocket's return, like using the stage as a lifting surface (with a truly abysmal lift/drag ratio, I assume, but they're also trying to scrub speed) while controlling it with little folding grid fins (which are quite effective at those speeds). However, at the end of the day, even Falcon 9 may not have the fuel margin to return to the spaceport after launches even though it has enough fuel to launch *somewhere*. The center core of the Falcon Heavy - which flies for much longer than the F9 first stage - will be much too far downrange to boost back to the spaceport in most cases. Thus, for FH's center core, the barge may be the only landing option. Landing on a ship may be harder than landing at a conventional spaceport, but the ship can be almost anywhere there's ocean, while land-based spaceports are not noted for their mobility.
Now, with all that said, the goal is to, eventually, be able to land at the spaceport. The next F9 launch after this one will, according to a cool site called SpaceX Stats, attempt to return to the launch site and land there. This presumably demonstrates that SpaceX has been found to have sufficient precision in the first-stage landing attempts so far for it to be safe to land near people and expensive buildings. I wish them the very best of luck!
Oh look, somebody else who apparently doesn't understand how computers work. How do you expect to stop a program[me] from changing a setting in another program[me] when they both run under the same privileges? Chrome has to store its default search provider configuration somewhere. The Java installer can edit that "somewhere" and change the stored configuration. Even if Chrome stores its search configuration in "the cloud", the installer could just use Chrome's cached credentials to change the configuration there.
The only way to change this is if apps don't have the ability to interact with each other's data (something like the isolation/sandboxing used for mobile apps). Anything else, any setting that you (the user) can change, any software running on your behalf can change (whether you want it to or not). I'd expect readers of this site to be able to grasp that, but it keeps coming up so maybe not...
Yeah, the limiting it to only the highest editions of Windows was stupid. It was in XP Pro, and in all editions of Server, but in anything non-server with an Enterprise or Ultimate SKU, it was only in those editions. You could force it to run, in much the same way you can trick Home editions of Windows so they'll join a domain, but it was a hassle.
For what it's worth, Windows has a built-in grep alternative. Findstr.exe (in System32, so it's in the PATH) has slightly different syntax than grep, but it's generally not too hard to switch between them. Windows also has, and has had since DOS, more (it's actually still called more.com, though it's a full 32-bit or 64-bit Windows application), but it's grossly inferior to the options on anything *nix-like.
No equivalents of tail, sed, ssh, curl, whois, etc. or of course *nix shells (Powershell has some cool tricks but it's not the same thing) without installing recompiled versions, though, and those usually don't work as well anyhow.