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.

Windows has the ability to stash login credentials securely, but on Linux, this functionality isn't present, so having the browser "pack its own parachute" with its own encryption would be nice.

I wish for a feature that is in Firefox... and that is the ability to set a master password and encrypt all password manager contents. That way, stored passwords and certificates are independently protected.

My concern about always-on storage is that if someone gets root, they can zero out the backup storage, purge all snapshots, then rsync the zeroed out changes.

I sometimes wonder about using hard disks instead of tapes in a silo. Perhaps something like iMation's RDX, except with modern, high capacity drives, or maybe even a robotic mechanism that can handle bare bones disks, moving them from a storage part to a reader [1], and so on.

Hard disks are not as reliable as tapes, but if done right, could be used as a way to have backups that can't easily be dumped with a single command as backups stashed on an Avamar or other appliance could be. Plus, there is also the benefit of being able to offsite media as well and rotate it in and out.

[1]: I looked into making a prototype of this circa 2009, and what companies would do the robotics accurately enough to handle bare-bones drives. It is a lot easier if the drives are in an enclosure, but bare-bones means that there are no enclosure "standards" to deal with.

In the early 1990s, AIX allowed you to partition drives (physical volumes) where a logical volume could be residing on the inner or outer part of a drive. That way, DB indexes and critical tables could be placed where access was relatively fast, while the stash for archive logs, program files, and stuff not really accessed could be placed on the outer part. Not SSD speed, but it was a way to help with database performance, especially if one had a lot of spindles.

Slots apps are a good example of this. Virtually all of them will toss you a small amount of coins every four hours, and you gain levels by spending coins, so you can play more elaborate simulated slots, some of which only are playable for 30 minutes. Of course, if you don't want to wait the rest of the four hours, you can do in-app-purchases.

In fact, it seems most games on the smartphone tablet are this way... you need to consume/use "X" resource to gain levels to do more stuff... and the only way to do that quickly is to spend hundreds on some resource (coins, brains, smurfberries) to do so.

IMHO, a smartphone game that goes back to the pre-2011 IAP style of offering a decent game without forcing you to buy stuff -at all-, other than levels would be a hit. A good example of this would be "The Quest" game on iOS, which has a lot of additions to play through.

Nothing is 100%, but an air gap will force a black hat to either get someone physically on site, do some social engineering, or find someone that they can control to do their work for them.

By keeping stuff off the Internet, either air gapping or having a separate network with tightly controlled access points (or perhaps even something like a data diode [1]), it blocks all but the most well-heeled attackers, and big firms/governments are well adapted to deal with physical threats far more than stuff coming via the Internet.

[1]: I've taken two machines, each on a different network, plugged in a serial cable with one of the lines cut (so bits only moved one way), then used syslog on the secure network, and redirecting the port's output to a file on the insecure network. This wasn't fast, but it got data to people who needed it, while keeping stuff on the secure side off the Internet unless someone physically accessed it. A true data diode does the same thing, except faster... however expensive. As a hack, a dedicated line-level Ethernet tap might be something to be used because the computer plugged into the mirrored port will be unable to change or reply to the network stream coming from the secure side.