I wouldn't mind the ability to sideload apps (one can do this in a limited fashion already)... but what will happen is that a Dancing Pigs 0-day will happen, Joe Sixpack and Jane Sertraline will follow the directions that the rogue website gives to download the.ipa file, load it in, then one can view the bouncing bunnies.
Some websites which are set up to exploit any device they can already try this with apk files for Android and.deb files for jailbroken iPhones. I'm sure there are people who will download them because they are called "security updates", enable sideloading, and then install the files.
Of course, after the sideload, their phone gets compromised, and they then hit the lawyers and press and blame Apple for allowing them to step out of the walled garden.
Cisco isn't perfect, but I wouldn't be surprised to see their stock remain strong. IPv6 rollouts, security issues, and future IPv6 items [1] will ensure that existing customers will be buying new equipment.
Cisco also benefits from the fact that fiber channel is getting tossed for FCoE. With FCoE or iSCSI, it just takes one fabric to handle both storage and networking, while FC requires a separate switching network to handle zoning and I/O. With 40gigE around the corner, fiber channel is going to be left in the dust until faster HBAs come in 2016.
Would I consider Cisco stock a "buy"? I'm not going to give investment advice, but I wouldn't consider their stock tanking anytime soon. They are the biggest player in a core industry that isn't going away anytime soon.
[1]: IPv6, while getting deployed, still has yet to go through the real-world torture testing the IPv4 stack went through back in the late 1990s with land, teardrop, ping of death, smurf, and other packet based attacks which would drop machines.
Most of the people I know (and I say most) would take a position like this serious and do the best they can.
I am comparing this to jury duty. Yes, there are horror stories, but juries seem to have made their place as something that passes for "working". Our elected system obviously isn't showing the values of the US because Congress has had lower approval ratings than herpes, especially around this time last year when both sides managed to get the government shut down.
Take Slashdot for example. I would probably say that virtually anyone reading this, yes, even the goatse poster, would be a better representative and have a higher approval rating to the people of the US than most of Congress (and this applies to both parties.)
However, how easily can that waiver be pulled? Is Tesla standing with a just flick of a governor's pen between them and having to shutter the entire factory, or is there some due process in place so they can't be shut down if they don't toe the politicians' line exactly?
We really need different organizations. As above, the military needs to be strictly hierarchical. However, the civilian leadership needs to be representative of the people's wants. Here is my proposal:
Instead of elections, why not have all representatives be picked from a lottery of all citizens, similar to jury duty. Instead of a jury picking a foreman, they nominate and elect a president.
This way, the elected people are truly a cross section of the governed, voter fraud isn't an issue, and with proper enforcement of bribery laws, the big "campaign donations" that plague the US wouldn't be an issue. After four years, a new lottery takes place, and a new bunch of people get into office.
1: Without an active moderator, it can get pointless. 2: Forcing people to register or means people will create fake accounts and then troll the living heck out of the board. 3: Forcing people to log in with FB seems to help, as one can't create those accounts willy-nilly. However, I don't want FB to be my authentication provider. I don't trust them with private stuff, why should I with the key to the gates? 4: Having registering then having people pay for their account to be activated is another tactic, but unless the forum had a following, this wouldn't be viable.
I've wondered about someone setting up an authentication business. Users would register with them, then can get a handle to use at member websites. The member websites would not know the user's real name or other info (unless explicitly provides), but the website can do a ban by that person's name and any attempts at creating a second account to log on would be blocked. That way, people have privacy when posting, but yet there is some accountability, and bans mean something.
There is a "good enough" point. What SSDs bring to the table is the fact that any number of processes can access the drive at virtually the same time without queuing up for the drive head to get in line with the data wanted, or hopefully find the data in the cache.
What I see that may become more common are drive units that have 256 gigs or so of SSD space and several terabytes of HDD, presenting themselves to the OS as two separate volumes. This allows the OS and core applications to boot and quickly while still having a lot of space for documents and other files, perhaps even backups. So far, I've seen one drive do this, and I wouldn't be surprised to see other models follow.
The advantage of SD cards is that in a pinch, the manufacturer can always ship a SD card to the customer (especially if the item is a more expensive appliance like a CNC mill.) As for a SD card reader, those are not too difficult to find (most modern laptops except MacBook Air models tend to have them built in.)
I do agree that a USB flash drive would be better, but a SD card reader is fairly static. One knows that it will have the same device ID (in Linux) or drive letter (in Windows) no matter what, while one can attach a hub and all sorts of devices to a USB port, trying to exploit any possible faults in the USB controller or the OS wondering why it is seeing another keyboard when it is expecting a drive.
SD cards are not perfect, but for a relatively high-value device, they are decent. If a device manufacturer is worried about physical attack, they could always ship SD cards using the built in signing/encryption (CPRM) and secure area to ensure that the ROM on the card hasn't been tampered with.
Of course, for something uber cheap where the only thing that matters is price, one can just have the device be a USB destination, and just allow the user to copy the updated firmware via PTP or MTP to a space on the device, then power cycle. However, this assumes the device is small and portable.
With a SD card and signed firmware, it definitely isn't 100%, but it will keep most attacks at bay. If more security is needed, the manufacturer can ship update SD cards out using the copy-protected region so the data on the card can't be tampered with, and it would provide another security layer against even physical tampering.
The problem is that bugtastic firmware is just a sign to the "good enough" race to the bottom that plagues a lot of industries.
Secure firmware upgrades are not rocket science. If a device doesn't have to be connected to the Internet [1], a SD card [2], a routine for signing firmware, and having an atomic transaction based upgrade process (so the upgrade either 100% completes or gets rolled back... no in between states) will solve this. Of course, some way to revert or roll back would be useful. Perhaps a "version 1.0" firmware burned into a ROM as an absolute failsafe.
For Internet connected devices, a mechanism similar to above coupled with SSL/TLS and a failsafe way of checking hosts for updates. Since this is a separate mechanism from Web browsing, the SSL/TLS certs can be signed with a non-standard CA (although I'd not self-sign them just in case the cert got compromised on the server.) Then, it can basically do a wget on the firmware image, then pass it on to another mechanism for checking the signature and flashing the new firmware.
[1]: If one questions that if -has- to be connected to the Internet or not; it doesn't need it.
[2]: SD card specifically. Not a USB port, as USB devices can present themselves as many other items than just a drive. SD cards are hard to use as a base for intrusion. Well, harder than USB, IEE1394, or other general use protocols that allow a device full DMA access.
Android can firewall by app, so my AWS program can access what it needs, while another app with more nefarious intentions can be blocked.
No, this isn't a cure for anything. In fact, it is a last resort. XPrivacy is the best solution for starters, as it will prompt when an app tries to use a permission, and you can allow or deny it. It would be nice to have a "fake" option, so the app -thinks- it has full permissions to do something... but in reality, it is being fed bogus data.
I can see an x86 (well, more accurately x86_64 because it is the AMD 64 bit extensions) tablet taking the role of a main desktop, similar to how the Microsoft Surface Pro is starting to do.
I would like to see five things on it to make it a serious contender for a desktop replacement role:
1: Two Thunderbolt connectors on a port replicator or docking station. These would work for video out, as well as provide 8 (in TB 1) or 16 (in the TB 2 spec) PCI lanes. I wonder if this would be enough for an external video adapter.
2: USB 3.1 with a type C connector. This is small enough to be on the device itself and support high amperage charging (as well as voltage higher than 5 volts if negotiated through the plug.)
3: A decent docking station. Something that the device can easily be plugged or slid into (and can handle a lot of insertions without breaking), and offer connectors for video, keyboard, mouse, HDDs, multiple NICs, eSATA, USB ports (and lots of them), and so on. Bonus points if the tablet can be locked in place, as a theft-deterrent.
4: Decent RAM and disk space. For starters, it should have 16 GB of RAM, and at last 1TB of SSD.
5: A read-only drive that has OS media on it. This way, reinstalling the machine from malware-free media (not the "reset" button or recovery partitions that wind up just as infected as the main partition) would be doable, and there would not be a case of losing the install media that came with the box. Heck, Tandy did this in 1984 with MS-DOS, why can't it be done with a modern machine?
The one nice thing about Android (assuming a rooted device) is the ability to turn on and use Linux's iptables to prevent apps from phoning home. After that, Xposed and XPrivacy are good (although the interface is nowhere as nice as Protect My Privacy from Cydia on iOS) to enforce restrictions on apps that ask for more than they should.
It would be nice if XPrivacy would fake data like PMP does, so if an app asks for GPS info, it will get GPS info, but not anything useful, or if an app asks for contacts on the phone, it gets random sets of garbage.
I've wondered about someone making a device, basically a classic, pre-smartphone, PDA that doesn't have any wireless connectivity. It would use a USB port and mount as a drive (with some device files for functionality, so the drive can be locked until the proper password entered by catting it to a file on there, similar to how some tuning is done with/proc.)
From there, an open source utility like KeePass could be used.
The device would use LUKS and encrypt everything but the kernel and the initial image to get it booting, then use a PIN from there on out with a timeout after too many attempts.
If one had to have cellular access, 3G chips are cheap, and passwords are relatively small. This would provide for backups (each device would have its own private key, so that when one wanted to access the cloud-stored backup with a new device, and old one would have to unlock and re-encrypt the backup, adding the new device's key.) It would also provide for remote erase capabilities [1].
[1]: Even just a TRIM on a SSD based device would prevent recovery unless someone could decap the NAND chips. A SSD that used encryption and had a secure erase feature that regenerated a new key... recovery would be impossible.
What I am afraid of is what happens after. There is a difference between security from remote attackers, and security from "jailbreakers". For example, my Android phone is just as secure rooted as not.
My fear is that what steps would be taken would force the car into the shop for any minor issue. Already, one automaker, if you change the battery out, the vehicle will refuse to start until the vehicle goes into the dealership and the battery is "registered" into the ECM.
Automakers should just keep stuff isolated. The radio should not have access to the brakes. Hell, the radio should not even be on the CAN. It should just be vital components, and have the doodads be stuck on another bus that can be "dirty".
Biometrics are useful, but what about just going with a tried and true PIV/CAC token?
I have always used authentication tokens. (Preferably, multiple tokens for redundancy.) For example, I have several Aladdin eTokens. They are set with a fairly short (16 character) user passphrase, and an obnoxiously long (but memorable) admin passphrase. Both passphrases will permanently lock if more than a certain number of bad attempts are done.
These days, I wish there were a way to make an application that runs on a SIM card, similar to the ISIS e-Wallet system [1]. That way, decryption of keys could be done on the SIM (with the app having its own PIN/password), and it would have the same security as my old eTokens, except without the hassle of trying to find the PKCS#11 drivers.
This would also allow for client certificates. They are unwieldy because they have to be copied to where one is browsing... but they take care of the authentication problem with ease. An intruder who hacks a Web server will get a list of certificates in use... which might show who may be using the server, but for any other use, would be worthless.
If DARPA wants better password authentication, there can be two things done. One, we have a quite open mechanism in place -- TKIP, which is used by the Google Authenticator, Amazon, and many other places. The second would be DARPA/DoD to agree on some type of PIV/CAC spec, perhaps having a way to have cards be read by USB ports without a dedicated reader, or somehow get more vendors (Apple specifically) to embed a smartcard reader in their computers. Then, sell the smartcards.
Done right, this would make life fairly easy, since a user just puts their card in a reader, types their PIN (perhaps it gets typed in on a different keyboard, or a light comes on the normal keyboard showing that the BIOS is reading it, nothing else.) Then from there, authentication almost anywhere is automatic, or a dialog pops up confirming/denying use of the key.
[1]: No relation to ISIS/ISIL, except a bad name choice in retrospect.
Most panels I have seen have a 25 year limited power warranty, where they are guaranteed 85-90% efficiency. Past that, panels still keep going. I have several friends who have panels put up in the 1980s, and the panels, although nowhere near as efficient as ones made today, still do the job (usually providing some power for an outbuilding or a weather monitor.)
The problem with solar is that it has a long tail which is unappetizing to today's culture. People want results -now-, growth -now-, and with solar, all the costs are up front, with relatively little upkeep (dusting panels off, battery maintenance) as time goes on.
That $400,000 number is suspect. What conditions are what I wonder about.
Don't forget regulation. I can go get some wood pallets behind S-Mart [1], rip them up and make a frame that props a solar panel roughly south, have the wires go to a $10 charge controller, a cast-off battery, and an el cheapo inverter fresh off the Chinese slowboat... and I have a little bit of electric for an outbuilding, for the total cost for well under a C-note, especially if the panel is a cast off or factory second. This isn't a reliable setup, but for a redneck solution to keep a shed lit at night, it is workable.
There is no way in Hell one could ever approach anything nuclear related without billions of dollars in assets. Even a small reactor in the low megawatts will take tens to hundreds of millions of red tape fees, dealing with the anti-nuke lobby and the NIMBY people, then finding a contractor who will actually make a reactor head out of the correct materials and not pot metal, not to mention all the other costs with each step of getting the reactor up and running.
Nuclear power is great scaling up, because it provides the most energy generation for the least amount of real estate. However, it takes no regulation other than basic electrical codes to get solar operational.
How would that be more dangerous than propane? LP gas would do exactly as stated above, if someone poked a hole in a fuel tank with their drill, they would get sprayed by rapidly evaporating fuel.
IMHO, this might be the way to have a hydrogen economy. If a nitrogen fixing process is easy and economical, making liquid ammonia is a lot easier and requires less pressure than converting water to hydrogen via electrolysis.
The downside is that ammonia has a bad rep here in the US. Because it is a major ingredient in meth, anhydrous ammonia tanks tends to be a prime target for "lab assistants" to obtain their reagents. However, if done right, ammonia might just be what is needed to make the "hydrogen economy" a reality, because it has a decently high energy density.
Of course what would be nice would be a fuel cell that uses ammonia directly without the conversion to hydrogen.
That is the rub. PGP is better security hands-down, but it requires people to have a grasp of concepts like key infrastructure, webs of trust, keeping their private key somewhere secure, making revocation certificates and stashing them somewhere separate just in case (so the private key can be pulled out of circulation), and so on.
S/MIME, vulnerable to a CA as it may be, just requires clicking a button to use. A recipient just has to view the message for the signature verification and decryption to happen. Pure point and drool.
Of course, PGP is better for security as a whole, but trying to move a notch up and encrypt E-mail is far better than nothing, similar to how SSL is flawed, but it is a lot better than just sending HTTP in the clear.
That question can only really be answered by having both mechanisms in place for now.
I would say that RedHat did a lot with RHEL 7, which, though not without issues, has added a lot of functionality:
1: systemd is a decent boot mechanism. On a SSD-based machine, RHEL 7 will boot to a graphical login screen in five seconds, due to firing off daemons asynchronously.
2: firewallD is of some benefit, but it adds the concept of zones, similar to how Windows works, which does help integrate Linux machines in a MS environment (where one has public, private, and domain networks.)
3: Docker and containers are going to be a big thing going forward. This is similar to BSD jails, Solaris containers, or AIX WPARs, and provide decent package isolation without the need for a hypervisor.
4: It looks like with the latest version of the Linux kernel released this week, that btrfs is stable enough for prime time. RHEL7 allows for a btrfs install. It may not have the bells and whistles of ZFS, but it is a step in the right direction, and files can be checked (and possibly repaired) for bit rot with a find and a btrfs scrub.
5: The ability to use SSD as a "landing zone" for writes, then move those to a lower tier of disk.
None of these features are revolutionary... but they do bring RedHat and its downstreams (CentOS) on par with AIX, Windows, and Solaris for enterprise level features.
So, I can see that RedHat's future looks rosy, especially when it comes to virtualization and having a competitor in the enterprise to VMWare. VMWare still is top dog, but competition is always good.
S/MIME is better than nothing. I use it often because of exactly the fact that it is part of most MUAs, and it takes zero effort on the recipient's side for a signature to be validated.
However, S/MIME is just like SSL/TLS, being one bad CA away from being useless, while PGP's web of trust system is far more robust and can handle a bad key introducer fairly easily.
If we can get people used to making webs of trust, especially if Yahoo made some type of utility for this, it would go far with security.
Old school keyservers are engineered to make deleting keys impossible (where if one server deletes a key, on the next propagation, the key is re-copied.) So, there is a lot of cruft and lost/abandoned keys in the database. However, an attacker can't delete someone's key (they can make a ton of fake keys though.) It is a trade-off.
I have been thinking of a keyserver setup similar to that (where keys are not deleted), but keys would have an expiration date. This could be a few years after the key hit the first server, or a period of time after the last signature on the key. That way, a key sitting around for a number of years and not getting other people signing it (or signatures renewed) eventually drops.
Yahoo hasn't been bad by any means. I use them as my default provider for a spam/mass E-mail catch-bucket. For this purpose, I've never had any downtime or E-mail loss with them in many years. However, since most of the E-mail are lists or just ads from companies I do business with, I may not notice the ad for the latest zombie rated chainsaw available at Gnome Depot that might have gone missing.
Of course, my preference for E-mail is an Exchange or Zimbra hosted provider, but when it comes to free E-mail, beggars can't be choosers.
There are always ways to ensure data is encrypted and stays encrypted. The simplest is to have an offline computer with a SD card slot, and read/sign sensitive stuff on that machine. Of course, this isn't 100%, but it forces someone to have "boots on the ground" in order to obtain data.
One can get fancy with an offline setup (only boots from a "trusted" USB flash drive only on a keychain, then requires a long passphrase to mount/home, etc), but the idea is to have an air gap, which will block 99.999% of the attacks out there and force an adversary to have to have a physical presence.
Even if one doesn't do that, just having using S/MIME is a big step up from what we have now.
I'm reminded of one encrypted E-mail provider in this regard. They did nothing wrong, but were given the choice between having people face jail time or hand over data (because if one views E-mail on the server rather than a Java client, the server has the ability to decrypt it.)
I still use them, but I have concerns about tying the endpoint encryption/decryption to the mail provider. As stated above, it wouldn't take much to force Yahoo to push an update to the one "user of interest" that would either retain the decrypted E-mail or upload the key.
What Yahoo -can- do is make key exchange and key management easier, with keyserver functionality. That way, Alice can sign Bob's key for Charlie, upload it to Yahoo's keyserver, then Charlie will have a good chance that the key purported to be Bob's is actually the right one. Making a web of trust easier for people is something that is desperately needed.
Slashdot Mirror
I wouldn't mind the ability to sideload apps (one can do this in a limited fashion already)... but what will happen is that a Dancing Pigs 0-day will happen, Joe Sixpack and Jane Sertraline will follow the directions that the rogue website gives to download the .ipa file, load it in, then one can view the bouncing bunnies.
Some websites which are set up to exploit any device they can already try this with apk files for Android and .deb files for jailbroken iPhones. I'm sure there are people who will download them because they are called "security updates", enable sideloading, and then install the files.
Of course, after the sideload, their phone gets compromised, and they then hit the lawyers and press and blame Apple for allowing them to step out of the walled garden.
Cisco isn't perfect, but I wouldn't be surprised to see their stock remain strong. IPv6 rollouts, security issues, and future IPv6 items [1] will ensure that existing customers will be buying new equipment.
Cisco also benefits from the fact that fiber channel is getting tossed for FCoE. With FCoE or iSCSI, it just takes one fabric to handle both storage and networking, while FC requires a separate switching network to handle zoning and I/O. With 40gigE around the corner, fiber channel is going to be left in the dust until faster HBAs come in 2016.
Would I consider Cisco stock a "buy"? I'm not going to give investment advice, but I wouldn't consider their stock tanking anytime soon. They are the biggest player in a core industry that isn't going away anytime soon.
[1]: IPv6, while getting deployed, still has yet to go through the real-world torture testing the IPv4 stack went through back in the late 1990s with land, teardrop, ping of death, smurf, and other packet based attacks which would drop machines.
Most of the people I know (and I say most) would take a position like this serious and do the best they can.
I am comparing this to jury duty. Yes, there are horror stories, but juries seem to have made their place as something that passes for "working". Our elected system obviously isn't showing the values of the US because Congress has had lower approval ratings than herpes, especially around this time last year when both sides managed to get the government shut down.
Take Slashdot for example. I would probably say that virtually anyone reading this, yes, even the goatse poster, would be a better representative and have a higher approval rating to the people of the US than most of Congress (and this applies to both parties.)
Yes, the rules are waived... for now.
However, how easily can that waiver be pulled? Is Tesla standing with a just flick of a governor's pen between them and having to shutter the entire factory, or is there some due process in place so they can't be shut down if they don't toe the politicians' line exactly?
We really need different organizations. As above, the military needs to be strictly hierarchical. However, the civilian leadership needs to be representative of the people's wants. Here is my proposal:
Instead of elections, why not have all representatives be picked from a lottery of all citizens, similar to jury duty. Instead of a jury picking a foreman, they nominate and elect a president.
This way, the elected people are truly a cross section of the governed, voter fraud isn't an issue, and with proper enforcement of bribery laws, the big "campaign donations" that plague the US wouldn't be an issue. After four years, a new lottery takes place, and a new bunch of people get into office.
It can be a tough job:
1: Without an active moderator, it can get pointless.
2: Forcing people to register or means people will create fake accounts and then troll the living heck out of the board.
3: Forcing people to log in with FB seems to help, as one can't create those accounts willy-nilly. However, I don't want FB to be my authentication provider. I don't trust them with private stuff, why should I with the key to the gates?
4: Having registering then having people pay for their account to be activated is another tactic, but unless the forum had a following, this wouldn't be viable.
I've wondered about someone setting up an authentication business. Users would register with them, then can get a handle to use at member websites. The member websites would not know the user's real name or other info (unless explicitly provides), but the website can do a ban by that person's name and any attempts at creating a second account to log on would be blocked. That way, people have privacy when posting, but yet there is some accountability, and bans mean something.
There is a "good enough" point. What SSDs bring to the table is the fact that any number of processes can access the drive at virtually the same time without queuing up for the drive head to get in line with the data wanted, or hopefully find the data in the cache.
What I see that may become more common are drive units that have 256 gigs or so of SSD space and several terabytes of HDD, presenting themselves to the OS as two separate volumes. This allows the OS and core applications to boot and quickly while still having a lot of space for documents and other files, perhaps even backups. So far, I've seen one drive do this, and I wouldn't be surprised to see other models follow.
The advantage of SD cards is that in a pinch, the manufacturer can always ship a SD card to the customer (especially if the item is a more expensive appliance like a CNC mill.) As for a SD card reader, those are not too difficult to find (most modern laptops except MacBook Air models tend to have them built in.)
I do agree that a USB flash drive would be better, but a SD card reader is fairly static. One knows that it will have the same device ID (in Linux) or drive letter (in Windows) no matter what, while one can attach a hub and all sorts of devices to a USB port, trying to exploit any possible faults in the USB controller or the OS wondering why it is seeing another keyboard when it is expecting a drive.
SD cards are not perfect, but for a relatively high-value device, they are decent. If a device manufacturer is worried about physical attack, they could always ship SD cards using the built in signing/encryption (CPRM) and secure area to ensure that the ROM on the card hasn't been tampered with.
Of course, for something uber cheap where the only thing that matters is price, one can just have the device be a USB destination, and just allow the user to copy the updated firmware via PTP or MTP to a space on the device, then power cycle. However, this assumes the device is small and portable.
With a SD card and signed firmware, it definitely isn't 100%, but it will keep most attacks at bay. If more security is needed, the manufacturer can ship update SD cards out using the copy-protected region so the data on the card can't be tampered with, and it would provide another security layer against even physical tampering.
The problem is that bugtastic firmware is just a sign to the "good enough" race to the bottom that plagues a lot of industries.
Secure firmware upgrades are not rocket science. If a device doesn't have to be connected to the Internet [1], a SD card [2], a routine for signing firmware, and having an atomic transaction based upgrade process (so the upgrade either 100% completes or gets rolled back... no in between states) will solve this. Of course, some way to revert or roll back would be useful. Perhaps a "version 1.0" firmware burned into a ROM as an absolute failsafe.
For Internet connected devices, a mechanism similar to above coupled with SSL/TLS and a failsafe way of checking hosts for updates. Since this is a separate mechanism from Web browsing, the SSL/TLS certs can be signed with a non-standard CA (although I'd not self-sign them just in case the cert got compromised on the server.) Then, it can basically do a wget on the firmware image, then pass it on to another mechanism for checking the signature and flashing the new firmware.
[1]: If one questions that if -has- to be connected to the Internet or not; it doesn't need it.
[2]: SD card specifically. Not a USB port, as USB devices can present themselves as many other items than just a drive. SD cards are hard to use as a base for intrusion. Well, harder than USB, IEE1394, or other general use protocols that allow a device full DMA access.
Android can firewall by app, so my AWS program can access what it needs, while another app with more nefarious intentions can be blocked.
No, this isn't a cure for anything. In fact, it is a last resort. XPrivacy is the best solution for starters, as it will prompt when an app tries to use a permission, and you can allow or deny it. It would be nice to have a "fake" option, so the app -thinks- it has full permissions to do something... but in reality, it is being fed bogus data.
I can see an x86 (well, more accurately x86_64 because it is the AMD 64 bit extensions) tablet taking the role of a main desktop, similar to how the Microsoft Surface Pro is starting to do.
I would like to see five things on it to make it a serious contender for a desktop replacement role:
1: Two Thunderbolt connectors on a port replicator or docking station. These would work for video out, as well as provide 8 (in TB 1) or 16 (in the TB 2 spec) PCI lanes. I wonder if this would be enough for an external video adapter.
2: USB 3.1 with a type C connector. This is small enough to be on the device itself and support high amperage charging (as well as voltage higher than 5 volts if negotiated through the plug.)
3: A decent docking station. Something that the device can easily be plugged or slid into (and can handle a lot of insertions without breaking), and offer connectors for video, keyboard, mouse, HDDs, multiple NICs, eSATA, USB ports (and lots of them), and so on. Bonus points if the tablet can be locked in place, as a theft-deterrent.
4: Decent RAM and disk space. For starters, it should have 16 GB of RAM, and at last 1TB of SSD.
5: A read-only drive that has OS media on it. This way, reinstalling the machine from malware-free media (not the "reset" button or recovery partitions that wind up just as infected as the main partition) would be doable, and there would not be a case of losing the install media that came with the box. Heck, Tandy did this in 1984 with MS-DOS, why can't it be done with a modern machine?
The one nice thing about Android (assuming a rooted device) is the ability to turn on and use Linux's iptables to prevent apps from phoning home. After that, Xposed and XPrivacy are good (although the interface is nowhere as nice as Protect My Privacy from Cydia on iOS) to enforce restrictions on apps that ask for more than they should.
It would be nice if XPrivacy would fake data like PMP does, so if an app asks for GPS info, it will get GPS info, but not anything useful, or if an app asks for contacts on the phone, it gets random sets of garbage.
I've wondered about someone making a device, basically a classic, pre-smartphone, PDA that doesn't have any wireless connectivity. It would use a USB port and mount as a drive (with some device files for functionality, so the drive can be locked until the proper password entered by catting it to a file on there, similar to how some tuning is done with /proc.)
From there, an open source utility like KeePass could be used.
The device would use LUKS and encrypt everything but the kernel and the initial image to get it booting, then use a PIN from there on out with a timeout after too many attempts.
If one had to have cellular access, 3G chips are cheap, and passwords are relatively small. This would provide for backups (each device would have its own private key, so that when one wanted to access the cloud-stored backup with a new device, and old one would have to unlock and re-encrypt the backup, adding the new device's key.) It would also provide for remote erase capabilities [1].
[1]: Even just a TRIM on a SSD based device would prevent recovery unless someone could decap the NAND chips. A SSD that used encryption and had a secure erase feature that regenerated a new key... recovery would be impossible.
What I am afraid of is what happens after. There is a difference between security from remote attackers, and security from "jailbreakers". For example, my Android phone is just as secure rooted as not.
My fear is that what steps would be taken would force the car into the shop for any minor issue. Already, one automaker, if you change the battery out, the vehicle will refuse to start until the vehicle goes into the dealership and the battery is "registered" into the ECM.
Automakers should just keep stuff isolated. The radio should not have access to the brakes. Hell, the radio should not even be on the CAN. It should just be vital components, and have the doodads be stuck on another bus that can be "dirty".
You hit the nail on the head.
Biometrics are useful, but what about just going with a tried and true PIV/CAC token?
I have always used authentication tokens. (Preferably, multiple tokens for redundancy.) For example, I have several Aladdin eTokens. They are set with a fairly short (16 character) user passphrase, and an obnoxiously long (but memorable) admin passphrase. Both passphrases will permanently lock if more than a certain number of bad attempts are done.
These days, I wish there were a way to make an application that runs on a SIM card, similar to the ISIS e-Wallet system [1]. That way, decryption of keys could be done on the SIM (with the app having its own PIN/password), and it would have the same security as my old eTokens, except without the hassle of trying to find the PKCS#11 drivers.
This would also allow for client certificates. They are unwieldy because they have to be copied to where one is browsing... but they take care of the authentication problem with ease. An intruder who hacks a Web server will get a list of certificates in use... which might show who may be using the server, but for any other use, would be worthless.
If DARPA wants better password authentication, there can be two things done. One, we have a quite open mechanism in place -- TKIP, which is used by the Google Authenticator, Amazon, and many other places. The second would be DARPA/DoD to agree on some type of PIV/CAC spec, perhaps having a way to have cards be read by USB ports without a dedicated reader, or somehow get more vendors (Apple specifically) to embed a smartcard reader in their computers. Then, sell the smartcards.
Done right, this would make life fairly easy, since a user just puts their card in a reader, types their PIN (perhaps it gets typed in on a different keyboard, or a light comes on the normal keyboard showing that the BIOS is reading it, nothing else.) Then from there, authentication almost anywhere is automatic, or a dialog pops up confirming/denying use of the key.
[1]: No relation to ISIS/ISIL, except a bad name choice in retrospect.
Most panels I have seen have a 25 year limited power warranty, where they are guaranteed 85-90% efficiency. Past that, panels still keep going. I have several friends who have panels put up in the 1980s, and the panels, although nowhere near as efficient as ones made today, still do the job (usually providing some power for an outbuilding or a weather monitor.)
The problem with solar is that it has a long tail which is unappetizing to today's culture. People want results -now-, growth -now-, and with solar, all the costs are up front, with relatively little upkeep (dusting panels off, battery maintenance) as time goes on.
That $400,000 number is suspect. What conditions are what I wonder about.
Don't forget regulation. I can go get some wood pallets behind S-Mart [1], rip them up and make a frame that props a solar panel roughly south, have the wires go to a $10 charge controller, a cast-off battery, and an el cheapo inverter fresh off the Chinese slowboat... and I have a little bit of electric for an outbuilding, for the total cost for well under a C-note, especially if the panel is a cast off or factory second. This isn't a reliable setup, but for a redneck solution to keep a shed lit at night, it is workable.
There is no way in Hell one could ever approach anything nuclear related without billions of dollars in assets. Even a small reactor in the low megawatts will take tens to hundreds of millions of red tape fees, dealing with the anti-nuke lobby and the NIMBY people, then finding a contractor who will actually make a reactor head out of the correct materials and not pot metal, not to mention all the other costs with each step of getting the reactor up and running.
Nuclear power is great scaling up, because it provides the most energy generation for the least amount of real estate. However, it takes no regulation other than basic electrical codes to get solar operational.
[1]: Not Wal-Mart, they want $10 per pallet.
How would that be more dangerous than propane? LP gas would do exactly as stated above, if someone poked a hole in a fuel tank with their drill, they would get sprayed by rapidly evaporating fuel.
IMHO, this might be the way to have a hydrogen economy. If a nitrogen fixing process is easy and economical, making liquid ammonia is a lot easier and requires less pressure than converting water to hydrogen via electrolysis.
The downside is that ammonia has a bad rep here in the US. Because it is a major ingredient in meth, anhydrous ammonia tanks tends to be a prime target for "lab assistants" to obtain their reagents. However, if done right, ammonia might just be what is needed to make the "hydrogen economy" a reality, because it has a decently high energy density.
Of course what would be nice would be a fuel cell that uses ammonia directly without the conversion to hydrogen.
That is the rub. PGP is better security hands-down, but it requires people to have a grasp of concepts like key infrastructure, webs of trust, keeping their private key somewhere secure, making revocation certificates and stashing them somewhere separate just in case (so the private key can be pulled out of circulation), and so on.
S/MIME, vulnerable to a CA as it may be, just requires clicking a button to use. A recipient just has to view the message for the signature verification and decryption to happen. Pure point and drool.
Of course, PGP is better for security as a whole, but trying to move a notch up and encrypt E-mail is far better than nothing, similar to how SSL is flawed, but it is a lot better than just sending HTTP in the clear.
That question can only really be answered by having both mechanisms in place for now.
I would say that RedHat did a lot with RHEL 7, which, though not without issues, has added a lot of functionality:
1: systemd is a decent boot mechanism. On a SSD-based machine, RHEL 7 will boot to a graphical login screen in five seconds, due to firing off daemons asynchronously.
2: firewallD is of some benefit, but it adds the concept of zones, similar to how Windows works, which does help integrate Linux machines in a MS environment (where one has public, private, and domain networks.)
3: Docker and containers are going to be a big thing going forward. This is similar to BSD jails, Solaris containers, or AIX WPARs, and provide decent package isolation without the need for a hypervisor.
4: It looks like with the latest version of the Linux kernel released this week, that btrfs is stable enough for prime time. RHEL7 allows for a btrfs install. It may not have the bells and whistles of ZFS, but it is a step in the right direction, and files can be checked (and possibly repaired) for bit rot with a find and a btrfs scrub.
5: The ability to use SSD as a "landing zone" for writes, then move those to a lower tier of disk.
None of these features are revolutionary... but they do bring RedHat and its downstreams (CentOS) on par with AIX, Windows, and Solaris for enterprise level features.
So, I can see that RedHat's future looks rosy, especially when it comes to virtualization and having a competitor in the enterprise to VMWare. VMWare still is top dog, but competition is always good.
S/MIME is better than nothing. I use it often because of exactly the fact that it is part of most MUAs, and it takes zero effort on the recipient's side for a signature to be validated.
However, S/MIME is just like SSL/TLS, being one bad CA away from being useless, while PGP's web of trust system is far more robust and can handle a bad key introducer fairly easily.
If we can get people used to making webs of trust, especially if Yahoo made some type of utility for this, it would go far with security.
Old school keyservers are engineered to make deleting keys impossible (where if one server deletes a key, on the next propagation, the key is re-copied.) So, there is a lot of cruft and lost/abandoned keys in the database. However, an attacker can't delete someone's key (they can make a ton of fake keys though.) It is a trade-off.
I have been thinking of a keyserver setup similar to that (where keys are not deleted), but keys would have an expiration date. This could be a few years after the key hit the first server, or a period of time after the last signature on the key. That way, a key sitting around for a number of years and not getting other people signing it (or signatures renewed) eventually drops.
Yahoo hasn't been bad by any means. I use them as my default provider for a spam/mass E-mail catch-bucket. For this purpose, I've never had any downtime or E-mail loss with them in many years. However, since most of the E-mail are lists or just ads from companies I do business with, I may not notice the ad for the latest zombie rated chainsaw available at Gnome Depot that might have gone missing.
Of course, my preference for E-mail is an Exchange or Zimbra hosted provider, but when it comes to free E-mail, beggars can't be choosers.
There are always ways to ensure data is encrypted and stays encrypted. The simplest is to have an offline computer with a SD card slot, and read/sign sensitive stuff on that machine. Of course, this isn't 100%, but it forces someone to have "boots on the ground" in order to obtain data.
One can get fancy with an offline setup (only boots from a "trusted" USB flash drive only on a keychain, then requires a long passphrase to mount /home, etc), but the idea is to have an air gap, which will block 99.999% of the attacks out there and force an adversary to have to have a physical presence.
Even if one doesn't do that, just having using S/MIME is a big step up from what we have now.
I'm reminded of one encrypted E-mail provider in this regard. They did nothing wrong, but were given the choice between having people face jail time or hand over data (because if one views E-mail on the server rather than a Java client, the server has the ability to decrypt it.)
I still use them, but I have concerns about tying the endpoint encryption/decryption to the mail provider. As stated above, it wouldn't take much to force Yahoo to push an update to the one "user of interest" that would either retain the decrypted E-mail or upload the key.
What Yahoo -can- do is make key exchange and key management easier, with keyserver functionality. That way, Alice can sign Bob's key for Charlie, upload it to Yahoo's keyserver, then Charlie will have a good chance that the key purported to be Bob's is actually the right one. Making a web of trust easier for people is something that is desperately needed.