Yes, there is an advantage of hard disks, because all it takes is just the cost of a drive. However, if there is valuable data on the drive and it conks, it is far harder to recover than a tape. A tape, you can hand to a recovery company (Kroll for example) who has equipment to get something off, be it reading raw patterns, decompressing them, and getting something back. HDDs, it isn't just the media, it is the drive heads, the platters, the magnetic media, the controller, and numerous other variables, which complicate recovery immensely.
This is purely anecdotal, but in the years of working in IT, I have encountered one hard error from a LTO tape drive among thousands of tapes. I have plenty of dead hard disks, so from experience, I have a far higher chance of recovering from a tape than from a HDD sitting on the shelf. If I use a sane backup process where there are multiple copies (even a variant of grandfather/father/son), the chance of me permanently losing data is low.
Now, other media such as 8mm and 4mm have been different, where the format wasn't designed for backups, as opposed to an audio/video format for consumers.
Plus, it is easier to manage 50 tapes than 50 hard disks. Buy a couple sheets of labels for the tapes, and that job is done. Yes, one can use HDDs, but that isn't there intended purpose.
As for long term storage, hard disks are not designed for this task. There is a reason why the warranty on all but enterprise HDDs tends to be a year, while LTO tapes have a lifetime warranty. Even though this doesn't mean one can get data back if it fails, it shows how much faith the maker of the media has in their products.
For small amounts of data, I like backing it up to multiple locations. Burn to CD/DVD/BD with Nero's SecureDisk (which creates disks that have error correction on them. If one wants to be beholden to Windows, it also offers AES-256 encryption and signature validation.) For use with a cloud, one can create an encrypted TrueCrypt container, and stash that on DropBox. Then, have an external laptop HDD that gets a copy of data. This is great for having a pile of documents that can be worked on from multiple machines at once.
Eventually I'm going to bite the bullet, pay the $1800 and get an external LTO-5 drive (with a SAS card). Then, for $40, I can back up 1.5 TB (LTO-5's uncompressed capacity) of data with ease. Combine this with a SATA or USB-3 drive (USB-3 can do 625MB/sec, the LTO drive can do 280MB/sec, so I have enough I/O overhead that the drive won't shoe-shine, especially if attached to a dedicated server), and that is as close to an ideal backup solution for large data as you will find, period. To boot, LTO-4 and LTO-5 drives have onboard hardware encryption, so the drive hardware can handle both compression and encryption, making backups faster.
Drop a tape, if it isn't physically damaged, it will be A-OK. Drop a hard disk, and who knows if there might be hidden damage. So, for long term archiving (preferably with multiple backups and taking time to copy to new media), tape is king.
As for the cloud for large amounts of data, don't bother. For the price of stashing a terabyte of data on most cloud providers, you can buy a 2-3 terabyte external HDD a month. The cloud is good for small documents, but anything past around 20-30 gig, find another solution, especially with ISPs charging by the megabyte after a certain limit.
I do consider tape the best answer to backups. No, it isn't flashy like cloud storage, or the latest Internet rendition of it (be it a glorified file share, rsync, etc.)
Modern tape drives are a lot more reliable than the old 8mms and QIC cartridges. I still have DLT tapes from '98 which are still readable.
It all depends on the size of data. For the amount the OP has, if there is money, I'd consider an external LTO tape drive. They are around $1400 on NewEgg for a LTO-3 external, plus one will need a couple C notes for a SAS card. However, LTO-3 tapes are $15-$20, so $200 would back up 3-4 TB of compressed data, and with uncompressed, definitely more. Once the drive is bought, having the ability to save off the data completely for $200 or so is pretty economical. To boot, once the read/write tap gets flicked to read-only, nothing software-wise is going to be able to corrupt the tapes, and you can always pay for LTO-3 WORM tapes if you want true tamper-resistance.
Tape will always have a place in IT, even if it is just for a place to save data cheaply long term for pleasing the auditors.
LBE Privacy Guard is also a good tool on a rooted phone. I use it with DroidWall to ensure that apps that have too many permissions don't get to use them.
The downside is that it takes a little bit on boot for the LBE Privacy Guard daemon to load, but it is an excellent tool that in reality should be part of the OS.
Depends. The nice thing about the OpenPGP protocol is that one can specify different algorithms. If I wanted DSS and Triple-DES, that is doable. However, RSA and AES are the most common used.
I'd not worry about bits as much as the algorithm and the block size.
Ideally, one would cascade three solid encryption algorithms, be it AES, Serpent, and Twofish. Not so one can say they have a 768 bit key [1], but if one of the algorithms has a weakness that reduces its strength, the data is still protected. This is why I wish programs which signed documents would not just use RSA or DSS, but that, as well as a ECC key, as well as using a public/private key system that isn't vulnerable to Shor's Algorithm (and thus isn't crackable via quantum computing.)
[1]: In reality, you only gain 3x the security by using cascaded algorithms, 258 bits at most total.
There was an article about using 380 volts a couple weeks ago on/. in the data center.
Having DC brings some benefits, mainly just needing to step down voltage and not have to rectify it smoothly with capacitors to even out the output current.
However, there are some downsides:
1: AC power supplies in devices tend to be more tolerant of power fluctuations. An all DC shop might completely be halted by a power surge/spike that wouldn't bother a data center on AC.
2: DC sparks a lot when connecting/disconnecting. AC has plenty of zero-crossings a second (120 or so), so it won't make the fireworks show when plugging/unplugging. This makes switches rated for DC a lot more expensive than AC.
3: There is no such thing as a NEMA 380VDC connector. So, either items would have to be wired up to a bus bar similar to how 48VDC telco stuff gets, or it will end up like 12VDC with at least 5+ connectors (direct wires, cig lighter, airplane, marine connector, male/female combined connector, motorcycle accessory connector, banana plugs.)
4: Safety. 12 VDC shocks are annoying; a shock from 380VDC will be fatal, especially because of DC's tendency to get muscles to "lock". (This is why stun fences uses AC, while kill electric fences use DC so they can keep the target locked on the wires long enough to get the amps across the heart.)
5: Issues with wire length. AC, it isn't hard to use a transformer to deal with voltage drop. DC, that will be a lot harder.
All and all, 380VDC seems like a solution in search for a problem. We really don't need another standard. Heck, just pointing out 120VAC in the US means I have to doublecheck if I'm dealing with 15 amps, 20 amps, 30 amps, or 50 amps, and the locking versions of each, which means six plug types and minimum wire gauges.
What is bad is if password hashes are grabbed from a database, and in a number of cases, it becomes hard to tell if this happens, and if/when it does, there will be break-ins to accounts that are hard to trace, usually only when the legit account owner finds themselves locked out.
Of course, there is a way to mitigate that... use database triggers/procedures to have the RDBMS do the password validating, and to start having timeouts/lockouts on too many wrong entries.
As for remote login, one would be surprised. Decent sysadmins have lockouts, 2+ factor authentication, or public keys. However, there are a lot of systems out there that likely be taken over by just brute forcing root on ssh. Most Linux distros have root open and even though it will ask for a password, this is still a mechanism that can have some success. (It would be nice to have a mechanism built into ssh that can be configured to deny, or at least tarpit ssh attempts by IP address.)
So, advances in brute forcing still are important, especially if an attacker manages to get the equivalent of/etc/shadow, or access to a domain controller.
What I see happening are some roads being auto controlled only, and cars being spaced apart by a central road computer. Easily twice as many cars can be packed on a road because there isn't the reaction time a human requires. To boot, cars can be spaced where longer distance commutes can take further left lanes.
Heck, even four way intersections can be changed to not require any signals... just slow up one set of cars so another gets through without smashing.
I'm all for this. It not just allows cars to be moved around autonomously, but it opens up the ability to borrow cars. Not just like Zipcars or Car2Gos, but for people to allow others to "rent" their vehicle at times they don't need them in use.
This is arguably the most effective solution in the US, especially the suburban areas to handle the higher traffic densities where rail, even bus stops are just plain economically not doable. Of course, more urban areas are better served by subways, trams, light rail, and bicycles, but for areas where a commute may be 50+ miles, autonomous vehicles and roads that can space/maneuver vehicles would be ideal.
Exactly. Having a copy of the OS in ROM, even if it is a "1.0" version that doesn't have the gewgaws of more recently releases would be a very useful thing.
These days, it would come into handy. For example, someone setting up a computer at a remote location that has Internet access, but no media available. Booting into a ROM based OS, downloading install images, and partitioning and installing the main OS would be a relative cinch. Couple this with repos/stores/marketplaces, a laptop user with just their laptop and no optical drive could completely reinstall from system failure just by using a wi-fi connection. It wouldn't be pleasant, but it beats having it be impossible.
Of course, it would be nice to have a recovery OS, and read-only images of the OS media, so a complete restore is just rebuilding the OS, installing patches, hitting the store/repository for applications, mounting the TrueCrypt drive stored on a cloud provider and restoring documents.
In the early 1990s, there was a brief war of what devices would win the networking war in the home, be it the computer or the TV set-top box offering a basic keyboard (essentially a larger TV remote.)
I'm glad the set-top boxes lost. Had those won, virtually everything would be completely different, and a lot more costly. Instead of typing on/., doing a quick search in Google, it would require spending $20 for an old, clunky keyword based search, hoping one got some relevant results (and not too many as sifting through them was tedious), not to mention the charge per minute online (probably $20/hour), and freedom of speech would still be present, at the whim of the online provider. Any bad news or anything that wasn't agreeable with corporate PR, and the poster(s) would be kicked off with zero recourse.
More advanced versions of this had not just the usual stuff in ROM, but a full complement of utilities.
It boggles me why computers are light-years ahead of the 8086/8088 models of yore, but still can't stick a workable OS in ROM for recovery purposes. It doesn't have to be a full version of Windows or a complete Linux distro, but something good enough to run fsck or chkdsk, a partition editor, be able to mount/decrypt LUKS/BitLocker for recovery, and run an antivirus utility or integrity checker to search for tenacious rootkids on an offline volume. With the fact that SSDs are becoming cheaper (although not as cheap as how hard disk capacities skyrocketed and prices plummeted), it would be nice if motherboard makers would have an OS in ROM that not just can be used for recovery tasks, but in a pinch, basic productivity (word processing, Web browsing, ssh/VNC/Citrix client, etc.)
Heck, even my Android phone has the ability to run a fairly limited Linux distro (Webtop). Why can't this be a part of motherboards?
One can do mental gymnastics, but this is how I look at it:
If the NSA has a backdoor, eventually someone will find it and then glean knowledge of how they work. This may weaken them in the end. Plus, even if the NSA did, they can't really use it unless it would be an extremely high value target, or else their hand gets tipped.
A similar argument can be mounted against SELinux and PGP, where if the NSA did have backdoors, they would have to be extremely clever, as well as not used unless the target is extremely high value.
Heck, Motorola can use the same hardware for their mass produced phones so they benefit from economies of scale. The difference could be a dedicated sub-ROM chip that gets code loaded on at a TS/SCI cleared facility (the same way the old Clipper chips were made in a normal facility, then the Skipjack algorithm was loaded.)
This way, most phones can have unlocked bootloaders and are free to run the latest CM version, while the phones for secure duty get the added code.
That's why I wish these could be sold to the US masses. That way, it may or not be someone working for a TLA, but perhaps someone who wants some decent on phone security.
Pre-ICS, one thing that Motorola [1] phones had as an advantage was the ability to encrypt internal storage as well as the SD card. The advantage of this, especially coupled with remote wipe and wipe after "x" amount of bad password tries should be obvious.
It would be nice to have an Android device that can run apps, but still be designed for decent security, even if someone's E-mails matter to only them.
[1]: OK, since Google owns Motorola Mobility fair and square, they really need to start unlocking bootloaders.
Instead of the handcuffs, why not take the humble BitLocker functionality with a TPM chip available in business line laptops, desktops, and servers, and add a smart card reader to that for a CAC.
Then, when the laptop boots up, it asks for the CAC, the passphrase for that, and boots up. No authorized public key, the laptop won't boot.
PGP Whole Disk Encryption had this functionality with cryptographic tokens like Safenet's eTokens. This way, a thief would have to not just steal the laptop, but steal the token, and beat up the token's holder for the PIN (a la the XKCD strip) in order to get access.
Realistically, I just wonder why NASA just didn't go with a Citrix or remote access solution, so laptops can just have a plain OS on them and the Citrix Receiver with nothing else.
I'd say LBE Privacy Guard + DroidWall make an excellent defense, something that can be said to tip the scales in favor for Android, assuming a clued user and a rooted phone.
iOS has/had Firewall IP, but not sure if that has been updated to keep up with the latest iOS 5 vagaries. It also requires a jailbreak, which can be daunting, come iOS 5.1 and forced upgrades on restores. So, unless one gets that working, the only way to tell that an app is slurping from the message logs is to have the phone on a wireless connection with a packet sniffer.
For a non-clued Android user, the best thing to do is read the permissions. If a fleshlight app is wanting full access to contacts, phone history, etc... find another one.
When using a temporary phone that was just there for emergencies when I was on vacation [1], I use a $14 low end Nokia [2] that is on T-Mobile, which I added minutes to. So far, that is the best solution.
To boot, if one needs another number, even though one eats the cost of minutes on cards, the phone goes in the donation box, and 5 minutes and $14 later, one has a new number and device to talk on. No calling to change the number or anything.
[1]: I use a separate phone because there are people who think an "emergency" is not a true emergency, so I just use a phone whose number is only known to cow-orkers and family when on a true getaway.
[2]: It boggles the mind when the cheap Nokia phones have one of the better UIs out there.
I'd like to see a standard password database storage format. Yes, there are ways to generate and and store passwords, but usually, it is pretty difficult (and prone to leaks) to transfer the entries between one password program to another, especially on different devices.
For example, the best password storage on the iPhone would be 1Password since it uses a PIN (10 mistries == wipe), as well as the passphrase. Android, last time I checked, the app had far last functionality. KeePass is as close to a standard as one can get for multiplatform access, but good luck keeping all those in sync.
The solution close to an ideal likely would use private keys, such as what devices use, in combination with a good passphrase. This way, if someone gets ahold of the encrypted key material that might be sitting on Dropbox, the passphrase can't be brute forced because it would require decryption on a device that has been configured with that key storage.
For Android devices, it isn't speed that is an issue, but capacity. Right now, the largest MicroSD card that I can find for an Android phone is 32 gigs. A 64GB card was announced last May, but still is vapor.
I'd like to see an Android phone that can step up to the plate and keep competitive with the iPhone 4S on this front. At the minimum, add another SD card, so apps that can point to a storage place other than/sdcard or/mnt/sdcard can use it.
I wonder about that... if there were a "press button to cross" at intersections, which had a time delay to get all cars in the system stopped, then I wonder if this would be an issue. Freeways, it would be less of a problem because people won't be walking on those, but this definitely would rear its head in the city.
I can't think of any disadvantages of driverless vehicles once the kinks are worked out. In fact, on the highway, with a grid system, cars can be packed far closer together because there isn't need to have the space needed for human reaction time. Coupled with a local/regional highway computer, vehicles can be shifted from lane to lane depending on their destination and mechanical ability.
Heck, even roads could be designed differently because roads wouldn't have to deal with drivers behind the wheel who have 2-3 too many bowls, and 4-6 too many Bud Lights. Four way intersections on expressways could be made because the local computer could time when to send a northbound car so it doesn't hit an eastbound car that is currently in the intersection, or slow down a southbound car so it hits the intersection right after two cars going on a cross street pass.
Of course, nothing is perfect, but there was a time when computers were thought of never being the king of the chessboard, and now are top dog. Self driving cars were laughed off previously, but as connectivity and technology matures, it might be the answer to US transportation issues, especially in sprawling regions where a bus/train/tram system would be impossible.
This also would provide ease of renting/reserving cars. If someone didn't want to own one, they could have one reserved to be sitting in front of their place when they needed to go to work.
Apple's mechanism for checking for signed apps is, IMHO, a very good thing. What this does is force the user to really think about installing a program where the developer wasn't interested enough in obtaining a signing key.
All OSes should have some signed executable mechanism available. What this provides is resistance from attack should a repo/store/marketplace be tampered with, and ownership.
Windows has had Authenticode for years now, to the point where if an application developer doesn't care enough to sign their installer and code, businesses won't buy their product.
As for the OS X App store, yes, it is a double edged sword, and there is justification for being worried that Apple is slowly boiling the frog, but having a store/repo is a security benefit overall, which has been proven with Linux repositories.
For me, most are interchangeable except for one thing: Business level machines will have an onboard TPM chipset. With Windows, this is important because I can enable that, flip on BitLocker (saving off the recovery key somewhere safe but secure), and the machine is decently secure. Someone yanking out the HDD will not be able to access data, nor would a MBR compromise yield access to an attacker next boot. Add a PIN to that, and that provides brute force resistance (TPMs add an exponentially increasing delay after 3-4 wrong guesses.)
For some, this wouldn't matter at all, but if one has to run Windows, BitLocker + TPM is probably the easiest set/forget encryption there is for the platform.
Slashdot Mirror
Yes, there is an advantage of hard disks, because all it takes is just the cost of a drive. However, if there is valuable data on the drive and it conks, it is far harder to recover than a tape. A tape, you can hand to a recovery company (Kroll for example) who has equipment to get something off, be it reading raw patterns, decompressing them, and getting something back. HDDs, it isn't just the media, it is the drive heads, the platters, the magnetic media, the controller, and numerous other variables, which complicate recovery immensely.
This is purely anecdotal, but in the years of working in IT, I have encountered one hard error from a LTO tape drive among thousands of tapes. I have plenty of dead hard disks, so from experience, I have a far higher chance of recovering from a tape than from a HDD sitting on the shelf. If I use a sane backup process where there are multiple copies (even a variant of grandfather/father/son), the chance of me permanently losing data is low.
Now, other media such as 8mm and 4mm have been different, where the format wasn't designed for backups, as opposed to an audio/video format for consumers.
Plus, it is easier to manage 50 tapes than 50 hard disks. Buy a couple sheets of labels for the tapes, and that job is done. Yes, one can use HDDs, but that isn't there intended purpose.
As for long term storage, hard disks are not designed for this task. There is a reason why the warranty on all but enterprise HDDs tends to be a year, while LTO tapes have a lifetime warranty. Even though this doesn't mean one can get data back if it fails, it shows how much faith the maker of the media has in their products.
Nail, head hit.
For small amounts of data, I like backing it up to multiple locations. Burn to CD/DVD/BD with Nero's SecureDisk (which creates disks that have error correction on them. If one wants to be beholden to Windows, it also offers AES-256 encryption and signature validation.) For use with a cloud, one can create an encrypted TrueCrypt container, and stash that on DropBox. Then, have an external laptop HDD that gets a copy of data. This is great for having a pile of documents that can be worked on from multiple machines at once.
Eventually I'm going to bite the bullet, pay the $1800 and get an external LTO-5 drive (with a SAS card). Then, for $40, I can back up 1.5 TB (LTO-5's uncompressed capacity) of data with ease. Combine this with a SATA or USB-3 drive (USB-3 can do 625MB/sec, the LTO drive can do 280MB/sec, so I have enough I/O overhead that the drive won't shoe-shine, especially if attached to a dedicated server), and that is as close to an ideal backup solution for large data as you will find, period. To boot, LTO-4 and LTO-5 drives have onboard hardware encryption, so the drive hardware can handle both compression and encryption, making backups faster.
Drop a tape, if it isn't physically damaged, it will be A-OK. Drop a hard disk, and who knows if there might be hidden damage. So, for long term archiving (preferably with multiple backups and taking time to copy to new media), tape is king.
As for the cloud for large amounts of data, don't bother. For the price of stashing a terabyte of data on most cloud providers, you can buy a 2-3 terabyte external HDD a month. The cloud is good for small documents, but anything past around 20-30 gig, find another solution, especially with ISPs charging by the megabyte after a certain limit.
I do consider tape the best answer to backups. No, it isn't flashy like cloud storage, or the latest Internet rendition of it (be it a glorified file share, rsync, etc.)
Modern tape drives are a lot more reliable than the old 8mms and QIC cartridges. I still have DLT tapes from '98 which are still readable.
It all depends on the size of data. For the amount the OP has, if there is money, I'd consider an external LTO tape drive. They are around $1400 on NewEgg for a LTO-3 external, plus one will need a couple C notes for a SAS card. However, LTO-3 tapes are $15-$20, so $200 would back up 3-4 TB of compressed data, and with uncompressed, definitely more. Once the drive is bought, having the ability to save off the data completely for $200 or so is pretty economical. To boot, once the read/write tap gets flicked to read-only, nothing software-wise is going to be able to corrupt the tapes, and you can always pay for LTO-3 WORM tapes if you want true tamper-resistance.
Tape will always have a place in IT, even if it is just for a place to save data cheaply long term for pleasing the auditors.
LBE Privacy Guard is also a good tool on a rooted phone. I use it with DroidWall to ensure that apps that have too many permissions don't get to use them.
The downside is that it takes a little bit on boot for the LBE Privacy Guard daemon to load, but it is an excellent tool that in reality should be part of the OS.
Depends. The nice thing about the OpenPGP protocol is that one can specify different algorithms. If I wanted DSS and Triple-DES, that is doable. However, RSA and AES are the most common used.
I'd not worry about bits as much as the algorithm and the block size.
Ideally, one would cascade three solid encryption algorithms, be it AES, Serpent, and Twofish. Not so one can say they have a 768 bit key [1], but if one of the algorithms has a weakness that reduces its strength, the data is still protected. This is why I wish programs which signed documents would not just use RSA or DSS, but that, as well as a ECC key, as well as using a public/private key system that isn't vulnerable to Shor's Algorithm (and thus isn't crackable via quantum computing.)
[1]: In reality, you only gain 3x the security by using cascaded algorithms, 258 bits at most total.
PGP does this, as every message/file sent has its own symmetric encryption key, with only the key material encrypted with RSA/DSS.
However, if the public/private key gets broken, all bets are off.
There was an article about using 380 volts a couple weeks ago on /. in the data center.
Having DC brings some benefits, mainly just needing to step down voltage and not have to rectify it smoothly with capacitors to even out the output current.
However, there are some downsides:
1: AC power supplies in devices tend to be more tolerant of power fluctuations. An all DC shop might completely be halted by a power surge/spike that wouldn't bother a data center on AC.
2: DC sparks a lot when connecting/disconnecting. AC has plenty of zero-crossings a second (120 or so), so it won't make the fireworks show when plugging/unplugging. This makes switches rated for DC a lot more expensive than AC.
3: There is no such thing as a NEMA 380VDC connector. So, either items would have to be wired up to a bus bar similar to how 48VDC telco stuff gets, or it will end up like 12VDC with at least 5+ connectors (direct wires, cig lighter, airplane, marine connector, male/female combined connector, motorcycle accessory connector, banana plugs.)
4: Safety. 12 VDC shocks are annoying; a shock from 380VDC will be fatal, especially because of DC's tendency to get muscles to "lock". (This is why stun fences uses AC, while kill electric fences use DC so they can keep the target locked on the wires long enough to get the amps across the heart.)
5: Issues with wire length. AC, it isn't hard to use a transformer to deal with voltage drop. DC, that will be a lot harder.
All and all, 380VDC seems like a solution in search for a problem. We really don't need another standard. Heck, just pointing out 120VAC in the US means I have to doublecheck if I'm dealing with 15 amps, 20 amps, 30 amps, or 50 amps, and the locking versions of each, which means six plug types and minimum wire gauges.
What is bad is if password hashes are grabbed from a database, and in a number of cases, it becomes hard to tell if this happens, and if/when it does, there will be break-ins to accounts that are hard to trace, usually only when the legit account owner finds themselves locked out.
Of course, there is a way to mitigate that... use database triggers/procedures to have the RDBMS do the password validating, and to start having timeouts/lockouts on too many wrong entries.
As for remote login, one would be surprised. Decent sysadmins have lockouts, 2+ factor authentication, or public keys. However, there are a lot of systems out there that likely be taken over by just brute forcing root on ssh. Most Linux distros have root open and even though it will ask for a password, this is still a mechanism that can have some success. (It would be nice to have a mechanism built into ssh that can be configured to deny, or at least tarpit ssh attempts by IP address.)
So, advances in brute forcing still are important, especially if an attacker manages to get the equivalent of /etc/shadow, or access to a domain controller.
What I see happening are some roads being auto controlled only, and cars being spaced apart by a central road computer. Easily twice as many cars can be packed on a road because there isn't the reaction time a human requires. To boot, cars can be spaced where longer distance commutes can take further left lanes.
Heck, even four way intersections can be changed to not require any signals... just slow up one set of cars so another gets through without smashing.
I'm all for this. It not just allows cars to be moved around autonomously, but it opens up the ability to borrow cars. Not just like Zipcars or Car2Gos, but for people to allow others to "rent" their vehicle at times they don't need them in use.
This is arguably the most effective solution in the US, especially the suburban areas to handle the higher traffic densities where rail, even bus stops are just plain economically not doable. Of course, more urban areas are better served by subways, trams, light rail, and bicycles, but for areas where a commute may be 50+ miles, autonomous vehicles and roads that can space/maneuver vehicles would be ideal.
Exactly. Having a copy of the OS in ROM, even if it is a "1.0" version that doesn't have the gewgaws of more recently releases would be a very useful thing.
These days, it would come into handy. For example, someone setting up a computer at a remote location that has Internet access, but no media available. Booting into a ROM based OS, downloading install images, and partitioning and installing the main OS would be a relative cinch. Couple this with repos/stores/marketplaces, a laptop user with just their laptop and no optical drive could completely reinstall from system failure just by using a wi-fi connection. It wouldn't be pleasant, but it beats having it be impossible.
Of course, it would be nice to have a recovery OS, and read-only images of the OS media, so a complete restore is just rebuilding the OS, installing patches, hitting the store/repository for applications, mounting the TrueCrypt drive stored on a cloud provider and restoring documents.
In the early 1990s, there was a brief war of what devices would win the networking war in the home, be it the computer or the TV set-top box offering a basic keyboard (essentially a larger TV remote.)
I'm glad the set-top boxes lost. Had those won, virtually everything would be completely different, and a lot more costly. Instead of typing on /., doing a quick search in Google, it would require spending $20 for an old, clunky keyword based search, hoping one got some relevant results (and not too many as sifting through them was tedious), not to mention the charge per minute online (probably $20/hour), and freedom of speech would still be present, at the whim of the online provider. Any bad news or anything that wasn't agreeable with corporate PR, and the poster(s) would be kicked off with zero recourse.
More advanced versions of this had not just the usual stuff in ROM, but a full complement of utilities.
It boggles me why computers are light-years ahead of the 8086/8088 models of yore, but still can't stick a workable OS in ROM for recovery purposes. It doesn't have to be a full version of Windows or a complete Linux distro, but something good enough to run fsck or chkdsk, a partition editor, be able to mount/decrypt LUKS/BitLocker for recovery, and run an antivirus utility or integrity checker to search for tenacious rootkids on an offline volume. With the fact that SSDs are becoming cheaper (although not as cheap as how hard disk capacities skyrocketed and prices plummeted), it would be nice if motherboard makers would have an OS in ROM that not just can be used for recovery tasks, but in a pinch, basic productivity (word processing, Web browsing, ssh/VNC/Citrix client, etc.)
Heck, even my Android phone has the ability to run a fairly limited Linux distro (Webtop). Why can't this be a part of motherboards?
One can do mental gymnastics, but this is how I look at it:
If the NSA has a backdoor, eventually someone will find it and then glean knowledge of how they work. This may weaken them in the end. Plus, even if the NSA did, they can't really use it unless it would be an extremely high value target, or else their hand gets tipped.
A similar argument can be mounted against SELinux and PGP, where if the NSA did have backdoors, they would have to be extremely clever, as well as not used unless the target is extremely high value.
I wouldn't mind Motorola doing exactly this.
Heck, Motorola can use the same hardware for their mass produced phones so they benefit from economies of scale. The difference could be a dedicated sub-ROM chip that gets code loaded on at a TS/SCI cleared facility (the same way the old Clipper chips were made in a normal facility, then the Skipjack algorithm was loaded.)
This way, most phones can have unlocked bootloaders and are free to run the latest CM version, while the phones for secure duty get the added code.
That's why I wish these could be sold to the US masses. That way, it may or not be someone working for a TLA, but perhaps someone who wants some decent on phone security.
Pre-ICS, one thing that Motorola [1] phones had as an advantage was the ability to encrypt internal storage as well as the SD card. The advantage of this, especially coupled with remote wipe and wipe after "x" amount of bad password tries should be obvious.
It would be nice to have an Android device that can run apps, but still be designed for decent security, even if someone's E-mails matter to only them.
[1]: OK, since Google owns Motorola Mobility fair and square, they really need to start unlocking bootloaders.
Instead of the handcuffs, why not take the humble BitLocker functionality with a TPM chip available in business line laptops, desktops, and servers, and add a smart card reader to that for a CAC.
Then, when the laptop boots up, it asks for the CAC, the passphrase for that, and boots up. No authorized public key, the laptop won't boot.
PGP Whole Disk Encryption had this functionality with cryptographic tokens like Safenet's eTokens. This way, a thief would have to not just steal the laptop, but steal the token, and beat up the token's holder for the PIN (a la the XKCD strip) in order to get access.
Realistically, I just wonder why NASA just didn't go with a Citrix or remote access solution, so laptops can just have a plain OS on them and the Citrix Receiver with nothing else.
I'd say LBE Privacy Guard + DroidWall make an excellent defense, something that can be said to tip the scales in favor for Android, assuming a clued user and a rooted phone.
iOS has/had Firewall IP, but not sure if that has been updated to keep up with the latest iOS 5 vagaries. It also requires a jailbreak, which can be daunting, come iOS 5.1 and forced upgrades on restores. So, unless one gets that working, the only way to tell that an app is slurping from the message logs is to have the phone on a wireless connection with a packet sniffer.
For a non-clued Android user, the best thing to do is read the permissions. If a fleshlight app is wanting full access to contacts, phone history, etc... find another one.
When using a temporary phone that was just there for emergencies when I was on vacation [1], I use a $14 low end Nokia [2] that is on T-Mobile, which I added minutes to. So far, that is the best solution.
To boot, if one needs another number, even though one eats the cost of minutes on cards, the phone goes in the donation box, and 5 minutes and $14 later, one has a new number and device to talk on. No calling to change the number or anything.
[1]: I use a separate phone because there are people who think an "emergency" is not a true emergency, so I just use a phone whose number is only known to cow-orkers and family when on a true getaway.
[2]: It boggles the mind when the cheap Nokia phones have one of the better UIs out there.
I'd like to see a standard password database storage format. Yes, there are ways to generate and and store passwords, but usually, it is pretty difficult (and prone to leaks) to transfer the entries between one password program to another, especially on different devices.
For example, the best password storage on the iPhone would be 1Password since it uses a PIN (10 mistries == wipe), as well as the passphrase. Android, last time I checked, the app had far last functionality. KeePass is as close to a standard as one can get for multiplatform access, but good luck keeping all those in sync.
The solution close to an ideal likely would use private keys, such as what devices use, in combination with a good passphrase. This way, if someone gets ahold of the encrypted key material that might be sitting on Dropbox, the passphrase can't be brute forced because it would require decryption on a device that has been configured with that key storage.
For Android devices, it isn't speed that is an issue, but capacity. Right now, the largest MicroSD card that I can find for an Android phone is 32 gigs. A 64GB card was announced last May, but still is vapor.
I'd like to see an Android phone that can step up to the plate and keep competitive with the iPhone 4S on this front. At the minimum, add another SD card, so apps that can point to a storage place other than /sdcard or /mnt/sdcard can use it.
I wonder about that... if there were a "press button to cross" at intersections, which had a time delay to get all cars in the system stopped, then I wonder if this would be an issue. Freeways, it would be less of a problem because people won't be walking on those, but this definitely would rear its head in the city.
I can't think of any disadvantages of driverless vehicles once the kinks are worked out. In fact, on the highway, with a grid system, cars can be packed far closer together because there isn't need to have the space needed for human reaction time. Coupled with a local/regional highway computer, vehicles can be shifted from lane to lane depending on their destination and mechanical ability.
Heck, even roads could be designed differently because roads wouldn't have to deal with drivers behind the wheel who have 2-3 too many bowls, and 4-6 too many Bud Lights. Four way intersections on expressways could be made because the local computer could time when to send a northbound car so it doesn't hit an eastbound car that is currently in the intersection, or slow down a southbound car so it hits the intersection right after two cars going on a cross street pass.
Of course, nothing is perfect, but there was a time when computers were thought of never being the king of the chessboard, and now are top dog. Self driving cars were laughed off previously, but as connectivity and technology matures, it might be the answer to US transportation issues, especially in sprawling regions where a bus/train/tram system would be impossible.
This also would provide ease of renting/reserving cars. If someone didn't want to own one, they could have one reserved to be sitting in front of their place when they needed to go to work.
I will play devil's advocate here:
Apple's mechanism for checking for signed apps is, IMHO, a very good thing. What this does is force the user to really think about installing a program where the developer wasn't interested enough in obtaining a signing key.
All OSes should have some signed executable mechanism available. What this provides is resistance from attack should a repo/store/marketplace be tampered with, and ownership.
Windows has had Authenticode for years now, to the point where if an application developer doesn't care enough to sign their installer and code, businesses won't buy their product.
As for the OS X App store, yes, it is a double edged sword, and there is justification for being worried that Apple is slowly boiling the frog, but having a store/repo is a security benefit overall, which has been proven with Linux repositories.
For me, most are interchangeable except for one thing: Business level machines will have an onboard TPM chipset. With Windows, this is important because I can enable that, flip on BitLocker (saving off the recovery key somewhere safe but secure), and the machine is decently secure. Someone yanking out the HDD will not be able to access data, nor would a MBR compromise yield access to an attacker next boot. Add a PIN to that, and that provides brute force resistance (TPMs add an exponentially increasing delay after 3-4 wrong guesses.)
For some, this wouldn't matter at all, but if one has to run Windows, BitLocker + TPM is probably the easiest set/forget encryption there is for the platform.