How would a cloud provider assure customers that their data will remain secure if they go bankrupt or just quit the business?
As of now, if a provider tanks, the servers go to the auction house, and in theory, are blanked. However, in reality, there is no assurance of that, and the buyer will get all data stored free and clear. If they wanted to do a multi-terabyte torrent of a failed bank's account and transaction data, they can, and nothing legally could stop them.
I personally have used Xymon with more than that many systems. It takes time to classify them, but it is doable.
The price is right on Xymon, however, if I were to recommend a monitoring solution for both real time, "oh shit" monitoring such as a drive array about to fail as well as a historical log (for security and finding a baseline), I'd go with Splunk if possible due to the tools available, and the fact that you can send management-friendly reports about the health of the enterprise up the chain.
Again, a monitoring server is one of the most sensitive boxes you can have (and usually one that isn't secure), so take the time to harden it and do it right.
I would elaborate on that a bit. I would have in the colo facility a Cisco ASA or other hardened appliance, and use that for the VPN connection.
I would then build a hardened server that accepts the stuff the parent points out, SNMP traps, syslog (both TCP and UDP), but I would recommend a tool like Splunk or a similar item. Splunk has served me well in my dealings. Once that is in place, I'd set up Splunk forwarders on critical machines for more detailed monitoring.
From there, I'd create a dashboard for realtime reporting, and a daily report detailing notable events from the past 24 hours. One can customize this to their liking. You can even have the reports mailed to you via the VPN to an internal site.
The Splunk server will need locked down, but if one is in IT, this is an assumed part of the skillset. I would at least leave SELinux enabled, enroll the Splunk server's SSL key in your PKI, and for the OS, enable SSH keys and two factor authentication. I might even consider placing the Splunk indexes on an encrypted filesystem so if the hardware is physically stolen, the data on your machines is protected.
Again, the thing to be careful about is the fact that so much sensitive data is on this machine, so it needs a separate firewall, and the box itself needs to be hardened.
Why should content protection be part of the Internet standard? Why do my devices (routers, computers, etc.) have to have built in DRM which will end up getting cracked, or at least possibly exploited from offshore?
This also is going to be met with a lot of suspicion. Who keeps the keys, gets to keep content locked, owns the license servers, and is able to come in via backdoors mandated as part of the protocol? The UN? Give me a break. China? Sure, we can trust them allright, provided we give them 51% ownership of any venture. It won't be the US because BRIC will sooner create their own network and completely split off.
I don't reject change... but what does this new protocol give me? IPv4 and to a lesser extent IPv6 have been torture tested, are completely open, and one can cobble together adequate defenses against attacks not too expensively (Cisco ASAs on the low end are a couple C-notes, and there are always smaller routers). A protocol based around DRM and content protection, stuff that is made to obfuscate and lock down is not going to be of any benefit to anyone but a few.
To boot, this seems like a complex mess. A network protocol should be brain-dead simple in order to reduce the attack surface, and reduce bugs. Adding DRM at layer 2 is at best will slow things down, at worst, allow the bad guys to hide behind bogus certificates.
Grabbing my tinfoil hat, I'm wondering if this protocol is something that will end up mandated within hours as soon as a "warhol event", or something more known as a "cyber 9/11" happens. I would not be surprised if this is already written and ready to be thrown on the floor as a bill on both houses the second some major security breach happens that causes catastrophic damage.
I'm seeing shades of the Clipper chip again, with the same problems. The bad guys getting access to the backdoors, compromising everyone in a way that cannot be patched, the bad guys closing the backdoors so they can't be investigated by LEOs... and the biggest losers are the good guys.
Does FERPA have any teeth in it? I've yet to hear about it actually being enforced. Similar with HIPAA, I've read about a slap on the wrist here and there after some medical facility had all their info lost. Even PCI-DSS seems to be more lip service than anything else, mainly CYA if that.
The only way we are going to see anything but miserable, failed excuses of security as SOP in the industry is if there are grave consequences for breaches, and not just XYZ company getting fined, declaring bankruptcy and reforming as ABC company (with all the assets owned by holding organizations), but actual "go to jail, do not pass go, do not collect $200" consequences on someone other than some low-level lackey who is still standing when the music stops.
Easy fix... one time pads. Tank number 128 gets a transaction, it decodes it using the OTP it has in a secure part of the controller, then blows e-fuses on the other equipment.
Since there isn't a need for public key encryption, having a remote site and the tank share a pad is feasible and as per basic crypto theory, if the key is as long or longer than the encrypted communication, there is no feasible way to break it. An attack would have to be done at the remote site, or at the tank itself.
If I can get code to execute in a context of a jailed UNIX process, such as a webserver, which would allow me to send traffic in and out, a malware writer has a usable client for a botnet, for spam, DDoS, and other uses. Even if they just have control of that webserver's port 80, they can use that and modify the server to occasionally serve malformed pages in hopes of nailing a buggy browser or browser add-on.
Similar to a program that just gets access to a user context in Windows. With just user access, their files can be encrypted for random, pictures can be copied off for blackmail, and the machine can still function as a botnet client.
Layers are critical. Even with limited contexts, firewalls are still crucial (to prevent a web server from making outgoing communication, for example), as well as integrity checks.
In a way, I'm hoping for more eyes on Linux for security vulnerabilities. The reason is that if they appear, they can get fixed almost immediately. MS is decent at handling patches, but most bugs end up waiting until Patch Tuesday, unless it warrants an out of band fix.
Maybe I'm showing my age... part of the standard procedure of getting Linux set up and deployed was getting onto security mailing lists like Bugtraq and its successors. It is a lot of mail, but better some time spent finding and fixing a vulnerability, than the time it takes dealing with a successful attack, or even an intrusion attempt, especially if an organization has different IT groups (network, system, SAN, etc.)
On one hand, Linux has had a reputation for being secure. On the other hand, Windows has made great strides in improving things.
On the gripping hand, security really belongs to the person sitting at the admin console [1]. The first thing a lot of Linux users do is kill SELinux, which weakens the security model tremendously, where it takes is just one weak SUID program or one running as root to have the machine. The second thing is that because Linux doesn't have signed executable functionality [2], something like AIDE or tripwire is a must.
From there, it is about basic security practices. If a server sits for months to years without updates, it doesn't matter what OS it runs, eventually there will be a hole, and eventually it will get pwned.
[1]: Be it an actual window, a serial port, a VMWare console, SCVMM window, remoted in via SSH or RDP.
[2]: It would be nice if the Linux kernel had functionality compared to trustchk in AIX. It isn't signed executables per se (since it uses a manifest list), but it does help prevent unauthorized stuff from loading, even libraries.
grsec, and AppArmor. SELinux is a very good system, but AppArmor is easier to understand and work with.
Going blue-sky, having the ability to turn on a trusted executable list similar to AIX would be nice. It doesn't have to be signed executables per se, but a way to have a manifest list of OK things to run.
What would be close to ideal would be something like jail() except that the jailed program would get its own loopback filesystem. This way, if a malicious task does things like make a lot of files in effort to consume all free inodes or create a directory link so deep rm() can't unlink it, the damage just affects that partition, and nothing else. I've found malware that did that in Windows, so when I use sandboxes, they go to their own dedicated volume that can be easily reformatted.
Even earlier than that, my ancient HTC Wizard, a 2006 vintage device, could handle a couple gigs on its miniSD card, and for e-books, that can hold a lot of stuff. The 2009 vintage Motorola CLIQ with a MicroSD card, similar.
It doesn't take much for a device to handle e-books.
One thing I wish Exchange [1] had was the ability (and would be turned off by default like POP and IMAP support) to have application passwords, as well as the ability to support 2FA if someone is logging in via the Internet.
It is ironic that all of my "free" E-mail accounts have 2FA on them, while my paid providers don't have this functionality.
[1]: Probably AD as well, for storing the random seed key for the secondary authenticator, as well as when to ask for the authenticator versus just the password only.
For car and RV batteries, the lack of energy density, the self discharge rate, and the maximum discharge rate are demerits. However, for a standalone installation where stringing power cables isn't an option, I think these batteries would be ideal, due to their "set and forget" nature. For example, something like a carport that is detached from the house that has enough space for solar panels. There would be more of a cost initially to use LED lighting, solar panels, a charge controller, inverter, and batteries, but 20-30 years down the road (assuming nothing untoward happens like a direct lightning strike), the setup would still be running.
I wonder how it would compare to AGM (absorbed glass mat) lead-acid batteries. AGM cells are usually drop-in replacement for flooded batteries, and are sealed, so they rarely vent hydrogen gas unless greatly overcharged.
AGM batteries are twice the price on average compared to the flooded lead-acid type. However, if Ni-Fe batteries were the same price or cheaper, it might be worth buying one of those, just for the fact that they are far less toxic, and will last longer than the 1-5 years of life that an average car battery does.
Assuming a lot longer battery life, Iron Edison batteries would be extremely useful for stationary (and RV) solar installs, just because it minimizes replacement costs. However, I've not read much good or bad on these batteries.
I wonder if they need a special battery charger. One good thing about lead-acid batteries is that you can have a RV charger, an alternator, a solar charge controller, and then various electrical loads, all connected at the same time. Try this on a lithium-ion battery, and -boom-. Other forms of batteries require a single charge/discharge controller in order to function in a safe manner, and this can get very expensive for solar storage use (five digits.)
A couple months ago, someone mentioned high capacity, high temperature batteries that used iron, with antimony not part of the picture whatsoever, and IIRC, were within a magnitude of gasoline, although due to the temperature required, wasn't something usable for the phone or Prius.
If I had money to throw at something, it would be battery research. Get batteries that would work at room temperature, were reasonably inexpensive, and had energy density by volume within an order of magnitude of gasoline or diesel... the whole transportation picture will change completely. The Otto/Diesel cycle engines can be tossed for electric motors with max torque at 0 RPM (where it usually is needed the most), and with the fact that gasoline engines use up most of their energy out the exhaust, one might just come out ahead with batteries as a fuel replacement.
There are other ways to store energy, be it pumping water to a lake, but not all municipal areas have that luxury, and in a lot of the world, real estate is expensive, so stacking up very energy-dense (by volume) batteries is probably the only option.
Ideally, all providers should have some 2FA mechanism. name.com has two options, true 2FA with TKIP [1], and an authorized IP list where if you are not using an IP the site knows about, it will E-mail you with a link to log on. Of course, the IP list isn't extremely secure as if the E-mail account is compromised, it can be added... but it would stop entry for someone who managed to guess a password.
[1]: One can use many apps for this: Google's Authenticator, Amazon's AWS, or decent number of others.
The ironic thing is that WPA2-PSK is decently secure. I've not read of any significant breaks, assuming the key is of a decent length.
The problem is that there are shortcuts given (WPS) which make having a solid shared key pointless.
UPnP? Just asking for trouble. If a game has to have ports open, I'll manually open them myself. Otherwise, they should remain closed.
WEP? This shouldn't even be present in any router made in recent years. My HTC Wizard, circa 2006, had an application (before the word "app" was in common use on smartphones) to break WEP-protected Wi-Fi access points.
Open guest networks? No thanks. Guest networks with a WPA2 password that is turned off after a gathering? Possibly.
Remote admin? Nope. If I want this functionality, I'll have some sort of port knocking, a DMZ machine, and SSH with 2FA or via RSA keys to an inside machine to access the router.
MAC locking? Too much trouble than it is worth, especially when you get a new device. It adds little to security, but is a hassle. With a decent, 63 character, passphrase for the WEP key, assuming no device gets compromised, that will provide decent security, as far as I know.
DHCP is probably the only service I bother enabling because so many devices don't have the option for a static IP, or if configured, they can't be used on another SSID unless one manually flips the config back to dynamic IP addresses.
What would be nice would be a cross between WPA2-Enterprise and WPA2-PSK. This way, each device can have its own preshared key, without needing the complexity of RADIUS. Done right, the key can be shared to the device by typing it in, snapping a QR code, or many other ways, and if one device is sold, no need to change the key and have to reconfigure all the wireless devices on the segment.
Correction: Russian territory. This was done in 1918 to keep the Germans from getting stockpiles at the port cities. It can be considered a footnote in history for the West, but it is a sore point for Russia, and adds to the "US cannot be trusted" sentiment.
The US invaded Russia territory post WWI (Arkangel and Murmansk, for example.) The territory wasn't held for long, and the US actually kept the Japanese from invading around that timeframe, but this is something still imprinted on the Russian psyche.
NWN 1 to me (and this is IMHO, so take it for what it is worth; little to none) is a must have. However, I would also take in all the hundreds of very good player written modules as well. The OC for the game was more of a primer on how to write modules right than a decent game in itself. SoU and HotU had decent scripts, but I would say that the top tier player written content (with the CEP and CTP) was some of the best I've played. A number of persistent worlds were outstanding as well.
NWN2 to a lesser extent. The graphics are better, but one couldn't do as much with the toolset.
Of course, the precursors to that, BG1, BG2, are a must.
Going backwards from there, the old Wizardrys and most of the old Ultimas are classics. Ultima 1-6 are timeless, but 7 afterward are sort of like Metallica post-"Black" album... same genre, but really different works with little to do with the previous except name.
Wizardry 1-3 are also classics. I'd probably go for an Apple 2 emulator and the images for them as opposed to the DOSBox version, but that is just me.
Another one is a game that wasn't that popular, but it was interesting for the time. Deathlord from EA. It was like the Ultima series... but was a lot harder, and had quite a large world to do stuff in.
Even though Itanium is all but dead, I did like the fact that you had 128 GP registers to play with. One could do all the loads in one pass, do the calculations, then toss the results back into RAM. The amd64 architecture is a step in the right direction, and I'd say that even though it was considered a stopgap measure at the time, it seems to have been well thought out.
With Moore's law flattening out, the pendulum might end up swinging back that way.
Right now, for a lot of tasks, we have CPU to burn, so the ISA doesn't really matter as much as it did during the 680x0 era.
But who knows... Rock's law may put the kibosh on Moore's law eventually, so we might end up seeing speed improvements ending up being either better cooling (so clock speeds can be cranked up), or adding more and more special purpose cores [1]. At this point, it might be that having code optimized by a compiler for a certain ISA may be the way of developing again.
[1]: High-power CPUs, low-energy CPUs, GPUs, FPUs, FPGAs, and even going from there, CPUs intended for I/O (MIPS.) It might be that we might have a custom core just to run the OS's kernel, another to run security sensitive code, and still others for applications.
Or just have the V2V set to check if the speed limit was exceeded in "x" amount of time and automatically send the ticket. Or have it log if someone stopped with the tip 1-2 cm past a stop line, and send another citation, etc.
Unless it is implemented right, it will be ripe for abuse, just like the red light cameras which have no yellow, or will briefly flash red, enough to pop a picture, then go back to green.
Of course, when the bad guys start messing around with V2V, it will be even worse, especially when someone starts transmitting "rear-end collision is imminent, slam brakes on NOW" on the highway to vehicles" at random times.
I've found SELinux useful. Yes, it can be a pain, but if the device is Internet facing or in the DMZ, it can do a lot to contain a security breach. As always, it can be shut off with a single command, but it is a layer of security that is generally worth having if at all possible. That way, even if the Web server has an exploit, an attacker manages to get into its context, then get root... they still are limited to the directories the Web server is allowed into. It isn't perfect, but it does help.
Unfortunately, the days of a static UNIX that stays the same are long gone. Security issues, feature demands [1], need to configure large numbers of hosts at once, and other items push vendors like RedHat to do updates.
[1]: One of those is having machines boot faster, thus moving to systemd, upstart, or another mechanism to allow asynchronous starting/stopping.
Slashdot Mirror
How would a cloud provider assure customers that their data will remain secure if they go bankrupt or just quit the business?
As of now, if a provider tanks, the servers go to the auction house, and in theory, are blanked. However, in reality, there is no assurance of that, and the buyer will get all data stored free and clear. If they wanted to do a multi-terabyte torrent of a failed bank's account and transaction data, they can, and nothing legally could stop them.
I personally have used Xymon with more than that many systems. It takes time to classify them, but it is doable.
The price is right on Xymon, however, if I were to recommend a monitoring solution for both real time, "oh shit" monitoring such as a drive array about to fail as well as a historical log (for security and finding a baseline), I'd go with Splunk if possible due to the tools available, and the fact that you can send management-friendly reports about the health of the enterprise up the chain.
Again, a monitoring server is one of the most sensitive boxes you can have (and usually one that isn't secure), so take the time to harden it and do it right.
I would elaborate on that a bit. I would have in the colo facility a Cisco ASA or other hardened appliance, and use that for the VPN connection.
I would then build a hardened server that accepts the stuff the parent points out, SNMP traps, syslog (both TCP and UDP), but I would recommend a tool like Splunk or a similar item. Splunk has served me well in my dealings. Once that is in place, I'd set up Splunk forwarders on critical machines for more detailed monitoring.
From there, I'd create a dashboard for realtime reporting, and a daily report detailing notable events from the past 24 hours. One can customize this to their liking. You can even have the reports mailed to you via the VPN to an internal site.
The Splunk server will need locked down, but if one is in IT, this is an assumed part of the skillset. I would at least leave SELinux enabled, enroll the Splunk server's SSL key in your PKI, and for the OS, enable SSH keys and two factor authentication. I might even consider placing the Splunk indexes on an encrypted filesystem so if the hardware is physically stolen, the data on your machines is protected.
Again, the thing to be careful about is the fact that so much sensitive data is on this machine, so it needs a separate firewall, and the box itself needs to be hardened.
Why should content protection be part of the Internet standard? Why do my devices (routers, computers, etc.) have to have built in DRM which will end up getting cracked, or at least possibly exploited from offshore?
This also is going to be met with a lot of suspicion. Who keeps the keys, gets to keep content locked, owns the license servers, and is able to come in via backdoors mandated as part of the protocol? The UN? Give me a break. China? Sure, we can trust them allright, provided we give them 51% ownership of any venture. It won't be the US because BRIC will sooner create their own network and completely split off.
I don't reject change... but what does this new protocol give me? IPv4 and to a lesser extent IPv6 have been torture tested, are completely open, and one can cobble together adequate defenses against attacks not too expensively (Cisco ASAs on the low end are a couple C-notes, and there are always smaller routers). A protocol based around DRM and content protection, stuff that is made to obfuscate and lock down is not going to be of any benefit to anyone but a few.
To boot, this seems like a complex mess. A network protocol should be brain-dead simple in order to reduce the attack surface, and reduce bugs. Adding DRM at layer 2 is at best will slow things down, at worst, allow the bad guys to hide behind bogus certificates.
Grabbing my tinfoil hat, I'm wondering if this protocol is something that will end up mandated within hours as soon as a "warhol event", or something more known as a "cyber 9/11" happens. I would not be surprised if this is already written and ready to be thrown on the floor as a bill on both houses the second some major security breach happens that causes catastrophic damage.
I'm seeing shades of the Clipper chip again, with the same problems. The bad guys getting access to the backdoors, compromising everyone in a way that cannot be patched, the bad guys closing the backdoors so they can't be investigated by LEOs... and the biggest losers are the good guys.
Does FERPA have any teeth in it? I've yet to hear about it actually being enforced. Similar with HIPAA, I've read about a slap on the wrist here and there after some medical facility had all their info lost. Even PCI-DSS seems to be more lip service than anything else, mainly CYA if that.
The only way we are going to see anything but miserable, failed excuses of security as SOP in the industry is if there are grave consequences for breaches, and not just XYZ company getting fined, declaring bankruptcy and reforming as ABC company (with all the assets owned by holding organizations), but actual "go to jail, do not pass go, do not collect $200" consequences on someone other than some low-level lackey who is still standing when the music stops.
Easy fix... one time pads. Tank number 128 gets a transaction, it decodes it using the OTP it has in a secure part of the controller, then blows e-fuses on the other equipment.
Since there isn't a need for public key encryption, having a remote site and the tank share a pad is feasible and as per basic crypto theory, if the key is as long or longer than the encrypted communication, there is no feasible way to break it. An attack would have to be done at the remote site, or at the tank itself.
If I can get code to execute in a context of a jailed UNIX process, such as a webserver, which would allow me to send traffic in and out, a malware writer has a usable client for a botnet, for spam, DDoS, and other uses. Even if they just have control of that webserver's port 80, they can use that and modify the server to occasionally serve malformed pages in hopes of nailing a buggy browser or browser add-on.
Similar to a program that just gets access to a user context in Windows. With just user access, their files can be encrypted for random, pictures can be copied off for blackmail, and the machine can still function as a botnet client.
Layers are critical. Even with limited contexts, firewalls are still crucial (to prevent a web server from making outgoing communication, for example), as well as integrity checks.
In a way, I'm hoping for more eyes on Linux for security vulnerabilities. The reason is that if they appear, they can get fixed almost immediately. MS is decent at handling patches, but most bugs end up waiting until Patch Tuesday, unless it warrants an out of band fix.
Maybe I'm showing my age... part of the standard procedure of getting Linux set up and deployed was getting onto security mailing lists like Bugtraq and its successors. It is a lot of mail, but better some time spent finding and fixing a vulnerability, than the time it takes dealing with a successful attack, or even an intrusion attempt, especially if an organization has different IT groups (network, system, SAN, etc.)
On one hand, Linux has had a reputation for being secure. On the other hand, Windows has made great strides in improving things.
On the gripping hand, security really belongs to the person sitting at the admin console [1]. The first thing a lot of Linux users do is kill SELinux, which weakens the security model tremendously, where it takes is just one weak SUID program or one running as root to have the machine. The second thing is that because Linux doesn't have signed executable functionality [2], something like AIDE or tripwire is a must.
From there, it is about basic security practices. If a server sits for months to years without updates, it doesn't matter what OS it runs, eventually there will be a hole, and eventually it will get pwned.
[1]: Be it an actual window, a serial port, a VMWare console, SCVMM window, remoted in via SSH or RDP.
[2]: It would be nice if the Linux kernel had functionality compared to trustchk in AIX. It isn't signed executables per se (since it uses a manifest list), but it does help prevent unauthorized stuff from loading, even libraries.
grsec, and AppArmor. SELinux is a very good system, but AppArmor is easier to understand and work with.
Going blue-sky, having the ability to turn on a trusted executable list similar to AIX would be nice. It doesn't have to be signed executables per se, but a way to have a manifest list of OK things to run.
Or something close to the BSD jail() command.
What would be close to ideal would be something like jail() except that the jailed program would get its own loopback filesystem. This way, if a malicious task does things like make a lot of files in effort to consume all free inodes or create a directory link so deep rm() can't unlink it, the damage just affects that partition, and nothing else. I've found malware that did that in Windows, so when I use sandboxes, they go to their own dedicated volume that can be easily reformatted.
Even earlier than that, my ancient HTC Wizard, a 2006 vintage device, could handle a couple gigs on its miniSD card, and for e-books, that can hold a lot of stuff. The 2009 vintage Motorola CLIQ with a MicroSD card, similar.
It doesn't take much for a device to handle e-books.
One thing I wish Exchange [1] had was the ability (and would be turned off by default like POP and IMAP support) to have application passwords, as well as the ability to support 2FA if someone is logging in via the Internet.
It is ironic that all of my "free" E-mail accounts have 2FA on them, while my paid providers don't have this functionality.
[1]: Probably AD as well, for storing the random seed key for the secondary authenticator, as well as when to ask for the authenticator versus just the password only.
For car and RV batteries, the lack of energy density, the self discharge rate, and the maximum discharge rate are demerits. However, for a standalone installation where stringing power cables isn't an option, I think these batteries would be ideal, due to their "set and forget" nature. For example, something like a carport that is detached from the house that has enough space for solar panels. There would be more of a cost initially to use LED lighting, solar panels, a charge controller, inverter, and batteries, but 20-30 years down the road (assuming nothing untoward happens like a direct lightning strike), the setup would still be running.
I wonder how it would compare to AGM (absorbed glass mat) lead-acid batteries. AGM cells are usually drop-in replacement for flooded batteries, and are sealed, so they rarely vent hydrogen gas unless greatly overcharged.
AGM batteries are twice the price on average compared to the flooded lead-acid type. However, if Ni-Fe batteries were the same price or cheaper, it might be worth buying one of those, just for the fact that they are far less toxic, and will last longer than the 1-5 years of life that an average car battery does.
Assuming a lot longer battery life, Iron Edison batteries would be extremely useful for stationary (and RV) solar installs, just because it minimizes replacement costs. However, I've not read much good or bad on these batteries.
I wonder if they need a special battery charger. One good thing about lead-acid batteries is that you can have a RV charger, an alternator, a solar charge controller, and then various electrical loads, all connected at the same time. Try this on a lithium-ion battery, and -boom-. Other forms of batteries require a single charge/discharge controller in order to function in a safe manner, and this can get very expensive for solar storage use (five digits.)
A couple months ago, someone mentioned high capacity, high temperature batteries that used iron, with antimony not part of the picture whatsoever, and IIRC, were within a magnitude of gasoline, although due to the temperature required, wasn't something usable for the phone or Prius.
If I had money to throw at something, it would be battery research. Get batteries that would work at room temperature, were reasonably inexpensive, and had energy density by volume within an order of magnitude of gasoline or diesel... the whole transportation picture will change completely. The Otto/Diesel cycle engines can be tossed for electric motors with max torque at 0 RPM (where it usually is needed the most), and with the fact that gasoline engines use up most of their energy out the exhaust, one might just come out ahead with batteries as a fuel replacement.
There are other ways to store energy, be it pumping water to a lake, but not all municipal areas have that luxury, and in a lot of the world, real estate is expensive, so stacking up very energy-dense (by volume) batteries is probably the only option.
Ideally, all providers should have some 2FA mechanism. name.com has two options, true 2FA with TKIP [1], and an authorized IP list where if you are not using an IP the site knows about, it will E-mail you with a link to log on. Of course, the IP list isn't extremely secure as if the E-mail account is compromised, it can be added... but it would stop entry for someone who managed to guess a password.
[1]: One can use many apps for this: Google's Authenticator, Amazon's AWS, or decent number of others.
The ironic thing is that WPA2-PSK is decently secure. I've not read of any significant breaks, assuming the key is of a decent length.
The problem is that there are shortcuts given (WPS) which make having a solid shared key pointless.
UPnP? Just asking for trouble. If a game has to have ports open, I'll manually open them myself. Otherwise, they should remain closed.
WEP? This shouldn't even be present in any router made in recent years. My HTC Wizard, circa 2006, had an application (before the word "app" was in common use on smartphones) to break WEP-protected Wi-Fi access points.
Open guest networks? No thanks. Guest networks with a WPA2 password that is turned off after a gathering? Possibly.
Remote admin? Nope. If I want this functionality, I'll have some sort of port knocking, a DMZ machine, and SSH with 2FA or via RSA keys to an inside machine to access the router.
MAC locking? Too much trouble than it is worth, especially when you get a new device. It adds little to security, but is a hassle. With a decent, 63 character, passphrase for the WEP key, assuming no device gets compromised, that will provide decent security, as far as I know.
DHCP is probably the only service I bother enabling because so many devices don't have the option for a static IP, or if configured, they can't be used on another SSID unless one manually flips the config back to dynamic IP addresses.
What would be nice would be a cross between WPA2-Enterprise and WPA2-PSK. This way, each device can have its own preshared key, without needing the complexity of RADIUS. Done right, the key can be shared to the device by typing it in, snapping a QR code, or many other ways, and if one device is sold, no need to change the key and have to reconfigure all the wireless devices on the segment.
Correction: Russian territory. This was done in 1918 to keep the Germans from getting stockpiles at the port cities. It can be considered a footnote in history for the West, but it is a sore point for Russia, and adds to the "US cannot be trusted" sentiment.
The US invaded Russia territory post WWI (Arkangel and Murmansk, for example.) The territory wasn't held for long, and the US actually kept the Japanese from invading around that timeframe, but this is something still imprinted on the Russian psyche.
NWN 1 to me (and this is IMHO, so take it for what it is worth; little to none) is a must have. However, I would also take in all the hundreds of very good player written modules as well. The OC for the game was more of a primer on how to write modules right than a decent game in itself. SoU and HotU had decent scripts, but I would say that the top tier player written content (with the CEP and CTP) was some of the best I've played. A number of persistent worlds were outstanding as well.
NWN2 to a lesser extent. The graphics are better, but one couldn't do as much with the toolset.
Of course, the precursors to that, BG1, BG2, are a must.
Going backwards from there, the old Wizardrys and most of the old Ultimas are classics. Ultima 1-6 are timeless, but 7 afterward are sort of like Metallica post-"Black" album... same genre, but really different works with little to do with the previous except name.
Wizardry 1-3 are also classics. I'd probably go for an Apple 2 emulator and the images for them as opposed to the DOSBox version, but that is just me.
Another one is a game that wasn't that popular, but it was interesting for the time. Deathlord from EA. It was like the Ultima series... but was a lot harder, and had quite a large world to do stuff in.
Even though Itanium is all but dead, I did like the fact that you had 128 GP registers to play with. One could do all the loads in one pass, do the calculations, then toss the results back into RAM. The amd64 architecture is a step in the right direction, and I'd say that even though it was considered a stopgap measure at the time, it seems to have been well thought out.
With Moore's law flattening out, the pendulum might end up swinging back that way.
Right now, for a lot of tasks, we have CPU to burn, so the ISA doesn't really matter as much as it did during the 680x0 era.
But who knows... Rock's law may put the kibosh on Moore's law eventually, so we might end up seeing speed improvements ending up being either better cooling (so clock speeds can be cranked up), or adding more and more special purpose cores [1]. At this point, it might be that having code optimized by a compiler for a certain ISA may be the way of developing again.
[1]: High-power CPUs, low-energy CPUs, GPUs, FPUs, FPGAs, and even going from there, CPUs intended for I/O (MIPS.) It might be that we might have a custom core just to run the OS's kernel, another to run security sensitive code, and still others for applications.
Or just have the V2V set to check if the speed limit was exceeded in "x" amount of time and automatically send the ticket. Or have it log if someone stopped with the tip 1-2 cm past a stop line, and send another citation, etc.
Unless it is implemented right, it will be ripe for abuse, just like the red light cameras which have no yellow, or will briefly flash red, enough to pop a picture, then go back to green.
Of course, when the bad guys start messing around with V2V, it will be even worse, especially when someone starts transmitting "rear-end collision is imminent, slam brakes on NOW" on the highway to vehicles" at random times.
I've found SELinux useful. Yes, it can be a pain, but if the device is Internet facing or in the DMZ, it can do a lot to contain a security breach. As always, it can be shut off with a single command, but it is a layer of security that is generally worth having if at all possible. That way, even if the Web server has an exploit, an attacker manages to get into its context, then get root... they still are limited to the directories the Web server is allowed into. It isn't perfect, but it does help.
Unfortunately, the days of a static UNIX that stays the same are long gone. Security issues, feature demands [1], need to configure large numbers of hosts at once, and other items push vendors like RedHat to do updates.
[1]: One of those is having machines boot faster, thus moving to systemd, upstart, or another mechanism to allow asynchronous starting/stopping.