SSD has gotten less expensive, but it still is about $75/$1.00 a gig, well more than a comparable spinny platter.
There is also the issue of data retention. This is an unknown with SSD. With a hard disk, the magnetic domains tend to stay magnetized in the patterns they were placed in. SSD, once those electronics are out of the gate, there is no recovery of data, period.
I think eventually something will replace HDDs, such as holographic storage, but for now, HDDs will tend to be a mainstay for tier 2, and the primary media for backups (unfortunately [1].)
[1] HDDs are not archival media. Tapes are made for long term storage, and even then, one doesn't assume that data stored will be there forever, so one stored multiple copies. However, a lot of people use external HDDs as archives, which can be risky.
I wouldn't mind seeing 5G add additional security. Since it would likely require a new type of SIM card, now is the time to a couple security features:
1: Ability to store data on a SIM card in a secure manner. For storing Google Authenticator info, PGP/gpg private keys, tetetc... a SIM card would be perfect because it has protection against brute force built in (PIN/PUK). If changing phones, I'd not have to worry about backing up or generating new authenticator codes.
2: Similar to #1, except allow SD-like card storage. Since a lot of devices do not have a MicroSD card, a SIM that also functions as a SDxD card can come in handy as secondary storage.
This might be another reason that one should consider using VPNs, even if on a trusted network. At least an attacker would be able to see traffic go by, but not know where it is going to, especially if there is a program in the background doing random HTTPS queries to various sites for noise.
Of course, the downside of VPNs is that a lot of them have their outgoing IP address flagged, so Google either demands a CAPTCHA before use, or just gives the middle finger and denies access entirely.
Sometimes I wonder about the US building its own refineries for national security's sake. Not contracted out to some offshore firm, but owned by the Federal government. As of now, refineries are a bottleneck. Oil can be a glut, but gas prices remain high because refineries are at capacity, with no new ones (other than the ones mentioned here) being made. Strategic oil reserves are one thing... but having refining capacity to deal with a disaster at another refinery can be just as critical.
Add more refining capacity into the mix, and this will stabilize what can be a very volatile market which affects virtually every other market. For example, one of the biggest causes of price hikes in everything from milk to airline tickets are fuel prices.
IMHO, too much focus has been done on the US on the Middle East. In reality, what needs to be the focus is Eastern Europe and the Pacific Rim. A Middle East in turmoil is a norm. A pissing contest between Japan, China, Russia, Singapore, the Koreas, and other nations in the area will be no less than World War 3 with its effects felt worldwide.
Oil is a nice thing to have, but keeping China and Japan from going to war with each other is far more important because that conflict would fundamentally affect the US and Europe's economies.
Eventually, when oil becomes too expensive to burn, we might see nuclear plants coupled with thermal depolymerization facilities so garbage in landfills can be "boiled" back to crude.
However, I'm hoping there is some sense in the long term. Eventually we are going to move to nuclear power, or end up being overrun by a country that has done the switchover [1].
[1]: For a lot of intents and purposes, energy is money. There are a lot of chemical processes which, if we had cheaper energy, would be incredibly useful, be it pulling dissolved gold out of seawater, desalinating the seawater, leaving the vital minerals, and pumping it inland so desert areas have irrigation regardless of drought states, and many other uses.
My biggest issue with PowerPoint is that people have a tendency to toss too many slides in. After 100 slides, I'm flipping through what tripe people are sharing on Facebook on my phone, or just asleep, and hopefully don't get so far asleep I fall out of the chair.
I appreciate chalk talks. It takes time to write one's ideas on a board and not just throw a canned presentation and click a mouse. Chalk talks are far more interactive and hold attention.
If there is an Android based audio head that has the same functionality as CarPlay, it almost definitely will not be vulnerable to this type of malware (although I'm sure malware can be injected somehow):
1: The functionality to add apps will be a lot more restricted than a phone the typical and app store. I doubt that there will be the option for sideloading, much less ADB access. Slam this door shut, and this effectively gets rid of malware. Reducing the install points of all software and being an active, brutal guardian is one of the reasons iOS has had a good reputation for security over time.
2: Android can be made pretty secure, especially with SELinux set to enforcing in Android 4.4 as opposed to permissive. Even if something gets root, the OS is still pretty well locked down.
3: Most device makers have solid ways to turn filesystems read-only, even to root, so even if malware got its way unfettered by SELinux, it might be able to hose a partition or two, but couldn't attach somewhere so it could be started on the next device reboot. Again, not 100%, but an effective measure.
4: Android's existing app permission model will be good enough for a car audio head, since in general, one wouldn't be adding apps to it, apps would be on the smartphone or tablet.
iOS integration is nice, but it means only three phones (the iPhone 5, the iPhone 5c, and iPhone 5s) will work with CarPlay. That isn't that many devices, and I'm sure the people running Android will be demanding a decent audio/map experience as well.
I would guess carmakers will solve this by including CarPlay and an Android based analog that provides similar functionality.
It would be nice to to see an ActiveX API be made cross-platform (Linux, OS X, iOS, Android, Windows, QNX, maybe even embedded platforms.) It definitely would beat PHIGS for an OpenGL alternative, although OpenGL is a pretty mature, stable API these days. I don't read about many horror stories by people using it for game writing.
If it could be used on an embedded platform, this gives some interesting possibilities for new and improved UIs (although my cynical side things it would be used for meaningless fluff as opposed to UI elements that are actually worth having.)
What I have seen is that software development generally has two career paths: One stays with the code tree and becomes the head dev guy, or one moves into management. Of course, one can start transitioning to another role, be it training, QA, or make the jump from dev to IT.
Of course, a lot of people move out of the dev industry entirely. If you can write code, you can become an HVAC person, electrician or plumber... and even though those may not be desk jobs... you always will have work regardless of the economy. There isn't any way to offshore those jobs either.
I would never claim even close to 100% security (in fact, when I hear that term, "100% secure", it is something that means Murphy (or Muphry [sic]) is right around the corner.
However, I do like the fact that Android uses dm-crypt. AFIAK, the standard is well documented, well tried and true, and doesn't have any backdoors in it. Of course, they can be added, but for any disk encryption implementation, it is as good as it gets. iOS encrypts as well, but I am leery of its "magic chips" that control the keys, as opposed to just typing in a long passphrase on device bootup, then using a short screen lock PIN when the device is running. (You can separate the two via a root app or via "su -c vdc cryptfs changepw newpass" on a root ADB shell.) I am far more confident that my insanely long passphrase (similar to "correct horse battery staple") will do a decent job in warding off a brute force attack, than trusting a chip which I know has a backdoor in it.
Of course, there are remote attack vectors, but on a local level, dm-crypt is pretty secure.
Sometimes watching encrypted traffic may be needed for some regulatory compliance. Of course, the best thing would be to have a terminal server set up to allow people to use their Web browser free and clear, while direct connections to the Internet would be monitored/logged. This way, personal E-mail and banking info isn't touched, while sensitive internal data is well protected.
The dancing rabbits problem will be a constant plague, unfortunately. It is a choice of lesser evils... allow users to have full access to their device and even with all the warnings, give them the ability to auto-footshoot, or take everything away and have everything happening on a device be at the whim of whatever corporate marketing drones are in charge.
This is the same problem with desktop machines. Do we want full control of our machines, or do we want to cede all authority to a third party who promises to keep us safe at night?
I do agree that Android's permission model needs a shot in the arm. In addition to the all/nothing permissions shown before installation, the device should prompt a user to allow/deny permission to something on first use, be it contacts, the phone itself, photos, the SD card, the microphone, the speaker, etc. Of course, even this runs into issues because too many prompts are like the firewall programs of the early 2000s or Vista's UAC, where the user just starts tapping "Allow". However, it would definitely shore up a weakness in Android.
1: Buy a device that disallows access to the user for anything except inputting a credit card number and buying apps through only specific channels. Access to the hardware will never happen. Take iOS: A user can't footshoot themselves, but neither can they use their device other than the way Tim or the late Steve wants them to. Want to run a Wi-Fi signal scanner or some specialty software... heck, even a Bitcoin wallet? You can play the jailbreak game, but with Apple controlling both the hardware and software down to the CPU, there will be a point where JB-ing just isn't possible or doable in any usable form... or if it is, it gets detected and the phone disabled via an e-Fuse like mechanism.
2: Buy a device that can allow one to click some "accept" buttons and allow themselves to shoot themselves in the foot. Yes, malware can be an issue with this since full control of the device can be obtained by the user.
We had this same war in the early 1990s when TV set top boxes were poised to bring us an Internet analog, but open computers won out. Do we want to lose this victory and go back to only allowing corporate board members having the ability to dictate what we can and cannot do with -our- devices... the ones that we paid for?
I prefer option #2, and some type of speed bump, so the user can leave the walled garden, but they are alerted to the fact so they know damn well know they cannot just walk into Mordor. Right now, the Nexus line does a good job of this, because one has to do several deliberate actions to get root or developer access... something that can't just be done by accident.
I still think Google needs two tiers. One tier in the store brutally curated with a very long agreement that a software vendor must agree to, and Google can refuse to approve anything it chooses to.
The second tier is as it is now -- upload anything, and obvious malware is tossed with the dev banned.
Then on devices, there is a checkbox similar to allowing sideloading to allow access to the more open tier.
This way, Joe Facebook by default is well protected from malware because they are tossed in a walled garden, but with an exit door that will scream a siren for five seconds before opening, so it is a deliberate act.
Of course, this does -nothing- for the stores in China where most malware lurks, but Google can point to where it has sway, malware is held at bay.
Quantum crypto reminds me of holographic storage. Yes, it works, but there are not many efforts in the real world implementing it.
The quantum crypto link isn't really about sending data. It is mainly creating a key and sending it via a secure link (where both sides will either resend, or keep generating random bits until they have enough non-snooped key material.)
However, encrypted data just goes through normal lines. Normal data gets 256 bit AES. Really secure stuff can go via one time pads.
Of course there are valid attacks on quantum cryptography, usually at how it is implemented. Will this next product from Down Under be any more secure? Time will tell.
I have seen that on some server rooms. No badge, and need to exit? Crash bar on the inside door which sounds an alarm for 10 seconds, but will open the door no matter what. This is a decent way for a very sensitive area to check who is in and who isn't, although there are always tailgaters, but some security is better than nothing.
One other difference: The economy in Russia took a BIG punch to the face due to the offensive. The ruble and the Russian stock market paid dearly for this.
I do fear a remake of "The Guns of August", but these are different times. Back then, people thought economic interdependence would keep war from breaking out. I wonder if it will be the case today.
Since the K-cup patents expired in 2012, I don't see why other companies don't just create their own K-cup friendly coffeemakers. Vue cups are covered by a new round of patents, but I wonder if the tradeoffs that the Vue cups provide may be worth the added expense by consumers, so K-cups may be an idea as a "standard".
I'll go out on a limb here, and ask that what does this general threat level help? I can understand having some type of alert is there is some imminent danger... but too much of the message, "be alert... but we can't tell what to watch out for, other than suspicious stuff..." starts to be like crying wolf... and when the wolf does come, people are so jaded by the messages, that few notice or care about the henhouse door left ajar.
For military outposts and such, a DEFCON system makes plenty of sense. However, for the general public, does an alert system make sense, especially when the nature of the threat cannot be communicated?
I can understand "business as usual" and "oh crap, there are enemy boots on the ground about to do something", but the second level needs to be used very rarely, as a lot of the populace wouldn't know what to do in the first place.
The whole system needs to be re-engineered, with appropriate groups having their level of readiness set, but for the general public? Urgent, more urgent, super-urgent, OMG-urgent, etc... just creates fatigue, and it becomes a laughingstock.
The problem is that there are -so many- weak links these days. Anything, be it the application, web server, backend server, DB server, Web browser, Web browser add-ons, OS, firmware, NIC firmware, router, switch, can have a weakness that can be easily exploited to cause a lot of issues. Air-gapping will help prevent those attacks, but I'm sure if it is a big organization wanting the data, rich enough to buy 0-day exploits from an auction, they are rich enough to have "boots on the ground" in a target country to perform physical attacks (sticking a USB flash drive into a machine and letting Autorun/Autoplay do the rest, for example.)
In the '90s, the computer industry had two choices, go the secure route, or go the cheap route. It is obvious how the industry went. Even languages that could offer provable security with known states are all but dead [1], so there is no way other than just keep patching holes, to have any semblance of solid security these days.
It would be nice to start from scratch. There are still ways to have provable states and know how a program will function, even with edge/corner cases. Similar with hardware. If we go with known good embedded operating systems, an attack on an IP stack will have limited consequences.
[1]: Ada may be ugly, but it does offer provable security.
Best way I've seen that handles this well is an app that used to be for previous iOS versions to 6. Sure, the app can get your contacts, position, music, camera, and such. The contacts are randomly generated, same with the songs. The position was settable anywhere in the world. The camera would just give static when used.
That way, the app gets whatever permissions it wants... but what it gets is useless garbage.
I wish there were a utility for Android that did similar. LBE Privacy Guard used to, but it hasn't been updated in ages... and LBE Security Master (the translated successor) is hit or miss.
You also get what you pay for. I pay for Exchange hosted E-mail for my "professional" account, and get top tier reliability... and nobody sifting through the mailbox for ads.
Of course, I do use the "free" E-mails. Might as well have all the FB stuff go somewhere, but if it is anything but junk, a "real" E-mail address is important, just like going to an interview for an IT position wearing proper clothing and not liquid latex and chain mail.
I'm guessing that since FB requires an existing E-mail address to sign up, having @facebook.com would be redundant... not to mention the lack of a really decent E-mail client.
I have a feeling that QNX may be a better choice, just because it is a true RTOS... and has been since the the 1980s.
However, call me crazy, but I wonder if Ford might have been off just a Linux based OS using CONFIG_PREEMPT_RT flipped on. This could be Android, could be a small distro of Linux, or even something completely different with a custom userland.
Of course, this brings a trade-off... QNX has established developer tools, so one can work with Linux in a pseudo-realtime mode, or pay the ticket to entry for QNX, and possibly save more time and man-hours with developers for writing the SYNC front end.
Slashdot Mirror
SSD has gotten less expensive, but it still is about $75/$1.00 a gig, well more than a comparable spinny platter.
There is also the issue of data retention. This is an unknown with SSD. With a hard disk, the magnetic domains tend to stay magnetized in the patterns they were placed in. SSD, once those electronics are out of the gate, there is no recovery of data, period.
I think eventually something will replace HDDs, such as holographic storage, but for now, HDDs will tend to be a mainstay for tier 2, and the primary media for backups (unfortunately [1].)
[1] HDDs are not archival media. Tapes are made for long term storage, and even then, one doesn't assume that data stored will be there forever, so one stored multiple copies. However, a lot of people use external HDDs as archives, which can be risky.
I wouldn't mind seeing 5G add additional security. Since it would likely require a new type of SIM card, now is the time to a couple security features:
1: Ability to store data on a SIM card in a secure manner. For storing Google Authenticator info, PGP/gpg private keys, tetetc... a SIM card would be perfect because it has protection against brute force built in (PIN/PUK). If changing phones, I'd not have to worry about backing up or generating new authenticator codes.
2: Similar to #1, except allow SD-like card storage. Since a lot of devices do not have a MicroSD card, a SIM that also functions as a SDxD card can come in handy as secondary storage.
This might be another reason that one should consider using VPNs, even if on a trusted network. At least an attacker would be able to see traffic go by, but not know where it is going to, especially if there is a program in the background doing random HTTPS queries to various sites for noise.
Of course, the downside of VPNs is that a lot of them have their outgoing IP address flagged, so Google either demands a CAPTCHA before use, or just gives the middle finger and denies access entirely.
Sometimes I wonder about the US building its own refineries for national security's sake. Not contracted out to some offshore firm, but owned by the Federal government. As of now, refineries are a bottleneck. Oil can be a glut, but gas prices remain high because refineries are at capacity, with no new ones (other than the ones mentioned here) being made. Strategic oil reserves are one thing... but having refining capacity to deal with a disaster at another refinery can be just as critical.
Add more refining capacity into the mix, and this will stabilize what can be a very volatile market which affects virtually every other market. For example, one of the biggest causes of price hikes in everything from milk to airline tickets are fuel prices.
IMHO, too much focus has been done on the US on the Middle East. In reality, what needs to be the focus is Eastern Europe and the Pacific Rim. A Middle East in turmoil is a norm. A pissing contest between Japan, China, Russia, Singapore, the Koreas, and other nations in the area will be no less than World War 3 with its effects felt worldwide.
Oil is a nice thing to have, but keeping China and Japan from going to war with each other is far more important because that conflict would fundamentally affect the US and Europe's economies.
Eventually, when oil becomes too expensive to burn, we might see nuclear plants coupled with thermal depolymerization facilities so garbage in landfills can be "boiled" back to crude.
However, I'm hoping there is some sense in the long term. Eventually we are going to move to nuclear power, or end up being overrun by a country that has done the switchover [1].
[1]: For a lot of intents and purposes, energy is money. There are a lot of chemical processes which, if we had cheaper energy, would be incredibly useful, be it pulling dissolved gold out of seawater, desalinating the seawater, leaving the vital minerals, and pumping it inland so desert areas have irrigation regardless of drought states, and many other uses.
My biggest issue with PowerPoint is that people have a tendency to toss too many slides in. After 100 slides, I'm flipping through what tripe people are sharing on Facebook on my phone, or just asleep, and hopefully don't get so far asleep I fall out of the chair.
I appreciate chalk talks. It takes time to write one's ideas on a board and not just throw a canned presentation and click a mouse. Chalk talks are far more interactive and hold attention.
If there is an Android based audio head that has the same functionality as CarPlay, it almost definitely will not be vulnerable to this type of malware (although I'm sure malware can be injected somehow):
1: The functionality to add apps will be a lot more restricted than a phone the typical and app store. I doubt that there will be the option for sideloading, much less ADB access. Slam this door shut, and this effectively gets rid of malware. Reducing the install points of all software and being an active, brutal guardian is one of the reasons iOS has had a good reputation for security over time.
2: Android can be made pretty secure, especially with SELinux set to enforcing in Android 4.4 as opposed to permissive. Even if something gets root, the OS is still pretty well locked down.
3: Most device makers have solid ways to turn filesystems read-only, even to root, so even if malware got its way unfettered by SELinux, it might be able to hose a partition or two, but couldn't attach somewhere so it could be started on the next device reboot. Again, not 100%, but an effective measure.
4: Android's existing app permission model will be good enough for a car audio head, since in general, one wouldn't be adding apps to it, apps would be on the smartphone or tablet.
iOS integration is nice, but it means only three phones (the iPhone 5, the iPhone 5c, and iPhone 5s) will work with CarPlay. That isn't that many devices, and I'm sure the people running Android will be demanding a decent audio/map experience as well.
I would guess carmakers will solve this by including CarPlay and an Android based analog that provides similar functionality.
It would be nice to to see an ActiveX API be made cross-platform (Linux, OS X, iOS, Android, Windows, QNX, maybe even embedded platforms.) It definitely would beat PHIGS for an OpenGL alternative, although OpenGL is a pretty mature, stable API these days. I don't read about many horror stories by people using it for game writing.
If it could be used on an embedded platform, this gives some interesting possibilities for new and improved UIs (although my cynical side things it would be used for meaningless fluff as opposed to UI elements that are actually worth having.)
What I have seen is that software development generally has two career paths: One stays with the code tree and becomes the head dev guy, or one moves into management. Of course, one can start transitioning to another role, be it training, QA, or make the jump from dev to IT.
Of course, a lot of people move out of the dev industry entirely. If you can write code, you can become an HVAC person, electrician or plumber... and even though those may not be desk jobs... you always will have work regardless of the economy. There isn't any way to offshore those jobs either.
I would never claim even close to 100% security (in fact, when I hear that term, "100% secure", it is something that means Murphy (or Muphry [sic]) is right around the corner.
However, I do like the fact that Android uses dm-crypt. AFIAK, the standard is well documented, well tried and true, and doesn't have any backdoors in it. Of course, they can be added, but for any disk encryption implementation, it is as good as it gets. iOS encrypts as well, but I am leery of its "magic chips" that control the keys, as opposed to just typing in a long passphrase on device bootup, then using a short screen lock PIN when the device is running. (You can separate the two via a root app or via "su -c vdc cryptfs changepw newpass" on a root ADB shell.) I am far more confident that my insanely long passphrase (similar to "correct horse battery staple") will do a decent job in warding off a brute force attack, than trusting a chip which I know has a backdoor in it.
Of course, there are remote attack vectors, but on a local level, dm-crypt is pretty secure.
Sometimes watching encrypted traffic may be needed for some regulatory compliance. Of course, the best thing would be to have a terminal server set up to allow people to use their Web browser free and clear, while direct connections to the Internet would be monitored/logged. This way, personal E-mail and banking info isn't touched, while sensitive internal data is well protected.
The dancing rabbits problem will be a constant plague, unfortunately. It is a choice of lesser evils... allow users to have full access to their device and even with all the warnings, give them the ability to auto-footshoot, or take everything away and have everything happening on a device be at the whim of whatever corporate marketing drones are in charge.
This is the same problem with desktop machines. Do we want full control of our machines, or do we want to cede all authority to a third party who promises to keep us safe at night?
I do agree that Android's permission model needs a shot in the arm. In addition to the all/nothing permissions shown before installation, the device should prompt a user to allow/deny permission to something on first use, be it contacts, the phone itself, photos, the SD card, the microphone, the speaker, etc. Of course, even this runs into issues because too many prompts are like the firewall programs of the early 2000s or Vista's UAC, where the user just starts tapping "Allow". However, it would definitely shore up a weakness in Android.
Nail, head hit. There are two choices:
1: Buy a device that disallows access to the user for anything except inputting a credit card number and buying apps through only specific channels. Access to the hardware will never happen. Take iOS: A user can't footshoot themselves, but neither can they use their device other than the way Tim or the late Steve wants them to. Want to run a Wi-Fi signal scanner or some specialty software... heck, even a Bitcoin wallet? You can play the jailbreak game, but with Apple controlling both the hardware and software down to the CPU, there will be a point where JB-ing just isn't possible or doable in any usable form... or if it is, it gets detected and the phone disabled via an e-Fuse like mechanism.
2: Buy a device that can allow one to click some "accept" buttons and allow themselves to shoot themselves in the foot. Yes, malware can be an issue with this since full control of the device can be obtained by the user.
We had this same war in the early 1990s when TV set top boxes were poised to bring us an Internet analog, but open computers won out. Do we want to lose this victory and go back to only allowing corporate board members having the ability to dictate what we can and cannot do with -our- devices... the ones that we paid for?
I prefer option #2, and some type of speed bump, so the user can leave the walled garden, but they are alerted to the fact so they know damn well know they cannot just walk into Mordor. Right now, the Nexus line does a good job of this, because one has to do several deliberate actions to get root or developer access... something that can't just be done by accident.
I still think Google needs two tiers. One tier in the store brutally curated with a very long agreement that a software vendor must agree to, and Google can refuse to approve anything it chooses to.
The second tier is as it is now -- upload anything, and obvious malware is tossed with the dev banned.
Then on devices, there is a checkbox similar to allowing sideloading to allow access to the more open tier.
This way, Joe Facebook by default is well protected from malware because they are tossed in a walled garden, but with an exit door that will scream a siren for five seconds before opening, so it is a deliberate act.
Of course, this does -nothing- for the stores in China where most malware lurks, but Google can point to where it has sway, malware is held at bay.
Quantum crypto reminds me of holographic storage. Yes, it works, but there are not many efforts in the real world implementing it.
The quantum crypto link isn't really about sending data. It is mainly creating a key and sending it via a secure link (where both sides will either resend, or keep generating random bits until they have enough non-snooped key material.)
However, encrypted data just goes through normal lines. Normal data gets 256 bit AES. Really secure stuff can go via one time pads.
Of course there are valid attacks on quantum cryptography, usually at how it is implemented. Will this next product from Down Under be any more secure? Time will tell.
I have seen that on some server rooms. No badge, and need to exit? Crash bar on the inside door which sounds an alarm for 10 seconds, but will open the door no matter what. This is a decent way for a very sensitive area to check who is in and who isn't, although there are always tailgaters, but some security is better than nothing.
One other difference: The economy in Russia took a BIG punch to the face due to the offensive. The ruble and the Russian stock market paid dearly for this.
I do fear a remake of "The Guns of August", but these are different times. Back then, people thought economic interdependence would keep war from breaking out. I wonder if it will be the case today.
Since the K-cup patents expired in 2012, I don't see why other companies don't just create their own K-cup friendly coffeemakers. Vue cups are covered by a new round of patents, but I wonder if the tradeoffs that the Vue cups provide may be worth the added expense by consumers, so K-cups may be an idea as a "standard".
I'll go out on a limb here, and ask that what does this general threat level help? I can understand having some type of alert is there is some imminent danger... but too much of the message, "be alert... but we can't tell what to watch out for, other than suspicious stuff..." starts to be like crying wolf... and when the wolf does come, people are so jaded by the messages, that few notice or care about the henhouse door left ajar.
For military outposts and such, a DEFCON system makes plenty of sense. However, for the general public, does an alert system make sense, especially when the nature of the threat cannot be communicated?
I can understand "business as usual" and "oh crap, there are enemy boots on the ground about to do something", but the second level needs to be used very rarely, as a lot of the populace wouldn't know what to do in the first place.
The whole system needs to be re-engineered, with appropriate groups having their level of readiness set, but for the general public? Urgent, more urgent, super-urgent, OMG-urgent, etc... just creates fatigue, and it becomes a laughingstock.
The problem is that there are -so many- weak links these days. Anything, be it the application, web server, backend server, DB server, Web browser, Web browser add-ons, OS, firmware, NIC firmware, router, switch, can have a weakness that can be easily exploited to cause a lot of issues. Air-gapping will help prevent those attacks, but I'm sure if it is a big organization wanting the data, rich enough to buy 0-day exploits from an auction, they are rich enough to have "boots on the ground" in a target country to perform physical attacks (sticking a USB flash drive into a machine and letting Autorun/Autoplay do the rest, for example.)
In the '90s, the computer industry had two choices, go the secure route, or go the cheap route. It is obvious how the industry went. Even languages that could offer provable security with known states are all but dead [1], so there is no way other than just keep patching holes, to have any semblance of solid security these days.
It would be nice to start from scratch. There are still ways to have provable states and know how a program will function, even with edge/corner cases. Similar with hardware. If we go with known good embedded operating systems, an attack on an IP stack will have limited consequences.
[1]: Ada may be ugly, but it does offer provable security.
Best way I've seen that handles this well is an app that used to be for previous iOS versions to 6. Sure, the app can get your contacts, position, music, camera, and such. The contacts are randomly generated, same with the songs. The position was settable anywhere in the world. The camera would just give static when used.
That way, the app gets whatever permissions it wants... but what it gets is useless garbage.
I wish there were a utility for Android that did similar. LBE Privacy Guard used to, but it hasn't been updated in ages... and LBE Security Master (the translated successor) is hit or miss.
I found that people judge you by your domain.
Custom domain -- professional.
@gmail/yahoo/hotmail -- hack.
You also get what you pay for. I pay for Exchange hosted E-mail for my "professional" account, and get top tier reliability... and nobody sifting through the mailbox for ads.
Of course, I do use the "free" E-mails. Might as well have all the FB stuff go somewhere, but if it is anything but junk, a "real" E-mail address is important, just like going to an interview for an IT position wearing proper clothing and not liquid latex and chain mail.
I'm guessing that since FB requires an existing E-mail address to sign up, having @facebook.com would be redundant... not to mention the lack of a really decent E-mail client.
I have a feeling that QNX may be a better choice, just because it is a true RTOS... and has been since the the 1980s.
However, call me crazy, but I wonder if Ford might have been off just a Linux based OS using CONFIG_PREEMPT_RT flipped on. This could be Android, could be a small distro of Linux, or even something completely different with a custom userland.
Of course, this brings a trade-off... QNX has established developer tools, so one can work with Linux in a pseudo-realtime mode, or pay the ticket to entry for QNX, and possibly save more time and man-hours with developers for writing the SYNC front end.