BD-Rs are good, as well as the newer archival grade DVDs (Verbatim UltraLife, for example.)
My vote is to not just use a single medium. Every storage type has good and bad:
1: Cloud storage is easily accessible and easy to use... but is potentially insecure, and the provider can go down taking your data with it.
2: SSD is fast and usable, but when it dies, there is zero chance of data recovery, long term, once the electronics bail the gates.
3: Tape is archival grade with extremely long lifetimes, limited lifetime warranties on media (not data stored), is fast, and has a high capacity... but tape drives are extremely expensive. There is also the issue of a standard to put data on and off, although LTFS helps mitigate this.
4: Optical is widespread with plenty of drives... but doesn't have much capacity, and some disks wind up with bit rot.
5: Hard disks are quite popular, easy to use, fast... but most have just a year warranty, and tend to fail.
6: Printing to paper is possible... QR codes are one way. There is a utility called Paperback (formerly named Paperbak) which prints files out. However, I have had issues with the 1.0 version and scanning back documents, although 1.1 seems to be a lot better at getting back data. Of course, this doesn't store much data, but paper burns at a lot hotter temperature than most other physical media, so it would be useful for storing recovery keys and such.
I recommend using redundant backup media types, combined with different backup programs, perhaps different encryption mechanisms (TrueCrypt, PGP, GnuPG, etc.) This way, if one can't find a backup or encryption program (I doubt you might be able to find a copy of TC in 10-15 years, but something that decoded PGP is likely to be around), there are other ways.
Backup utilities are also something to watch out for. Every program has a different way of stashing data. You don't just need the utility, but you will also need the license key for it... and even then, I've encountered consumer level programs which will still fail and demand an upgraded version before they might consider restoring data.
tl;dr, diversify. At the minimum, use an external drive with encryption for bare metal backups, and then have documents synced with a cloud provider (encrypted of course)... and occasionally burn critical stuff to optical media.
I just keep good backups. Encrypted, of course. With the fact that SSDs actually overwrite deleted data when the garbage collector decides to, deleted data tends to be -gone- for good.
For real security, the client should just be "eyes/ears" for the server, similar to how MMOs are. This was true back in the UO days, and is true now.
At least phones and mobile devices are easier to track and ban cheaters because you can ban an account and if any new accounts touch that device's IMEI, they get auto-banned after a random period of time as well. A simple check for a su binary on Android or a check if one can write outside the app's directory in iOS will deal with rooted/jailbroken devices.
Another trick is to update often, preferably with completely different offsets for code and/or obfuscation algorithms so if a group is making patches for the game, they would have to be constantly after a moving target, even if the update just changes a constant or two.
Only problem with that logic is that EA and Ubisoft are quite successful right now, which only sets an example that extreme DRM, DLC, and releasing only a few hours worth of content and calling it a game is the way to earn money in the industry. Especially with consoles where there is a 0% piracy rate and the game developers control everything on that platform.
Of course, it would be nice to see another ID or Bioware. I'm sure there is money to be made on games with a long tail like Neverwinter Nights and NWN2 [1]. However, there just doesn't seem to be an interest to push in that direction. It seems that almost all newer games either fall into the bottomless pit of F2P-P2W or are part a mediocre sequel in a franchise. Even the SimCity app on the phone was all about IAP in order to make your city not suck.
[1]: Ignore the NWN OC... IMHO, that was more of a demo of what one can do with the toolkit than something playable.
Same reason why plumbers, electricians, HVAC workers, and vend a goat repairmen don't get offshored... it just costs too much to grab people off the boat, train them in US standards [1], then them licensed in the specific state.
Here is what I don't get: What exactly is a "solar job"?
First, there is the actual placing of PV panels. This is just physical moving of the object, dropping it into place and bolting it down, perhaps making sure the single or double-axis controller is calibrated.
Second, and this is the most important: Electrician work. PV panels, wiring to proper code, not getting high voltage across the nipples, getting power from the PV panels to the inverter or the battery charge controller (depending on if the person wants an on grid or off grid setup.)
Third is architecture and placing panels. Will the panels be too heavy for a roof, are they facing south, etc.
All these skills are not really just "solar skills", but items used from other occupations.
[1]: Since the US was the first country to go electric, the standards in place are primitive. Tesla's three-phase system helped things, and 120VAC was good for the time, but as metals and materials improved, 240VAC is a better standard overall because it allows for thinner gauge wires.
All disks encrypted, which is mainly so the meth-head who breaks in and grabs the hardware doesn't have access to the data. Hardware can be claimed on insurance. Data opens up blackmail, extortion, and many other avenues.
Encrypted VMs as a way to isolate programs from each other, where I can keep my Quicken/QuickBooks in a VM, move it between computers when needed. Backup? Burn the.vmdk or the.vhdx to a BD-R disk.
File based encrypted volumes as a way of stashing client projects, as well as stashing document backups by date before burning to CD.
Of course, it would be nice to have encrypted archives as well, when one doesn't need to hide the length of the files. PGP Zip covers this, but it would be nice to have a higher level of compression like xz, bzip2, or LZMA, as well as the ability to add an ECC record (similar to WinRAR), so if an archive is damaged, it has a chance of being able to be completely repaired.
My ideal would be to have storage and compute nodes interchangeable, and use something like vMotion to move VMs back and forth between local nodes and cloud based nodes. For example, if I have some VMs that do nothing most of the time (a VM that does quarterly/annual reports, for example), it can sit on a remote cloud provider until it needs to be used heavily... then moved to local computer/storage nodes. Once the reports are done, it gets shoved back to the cloud again.
On the storage side, async storage would be useful, especially for volumes that have critical data. At least it is a form of backup, even though there were still I/O transactions still in flight when things went down.
This functionality was mentioned in Windows Server 2016, so when the preview comes out, it might be interesting to see what MS has improved in this department.
Of course, this is assuming security issues are a solved problem... which isn't the case in real life.
The problem is that with those environments, you could find a way to export your data from the locked down computer somehow... even if you turned your database tuples into a very nasty.CSV file and had some programmers import every table back into another format.
There is no physical access to the data in the cloud, and generally few companies will back up their data stored in the cloud... of if they do, the backups are stored in the cloud. So, in theory, all it takes is a bad guy to do a purge on the provider's side... and the cloud provider's client is now out of business.
Without physical possession, how can one actually say who is doing what with the data, and where it is located? For example, what keeps a US cloud provider from outsourcing capacity to a European provider... which outsources to a provider in a hostile country to the US.
At least with an IBM mainframe, you knew where your data was and could back it up. With cloud computing, all your critical business data can be destroyed or corrupted and nobody would be able to tell until it is too late.
I remember seeing one OSS company working on a generic API that works with whatever one's cloud provider of choice, so it doesn't matter what is on the backend, one can spin up a VM, provision it, do what is needed, then kill it. For storage, any application can use the API, and it deals with whatever cloud storage provider one is using (S3, Azure.)
I do worry about cloud computing as a whole for the open aspect, as well as the security aspect... just for the fact that once you lose physical access, you only have someone's word that their security is up to snuff.
Of course, once people are locked into a specific cloud provider, it becomes quite hard to move to a different provider or back to in-house. That is a concern.
With SCOM, SCCM, and in a Hyper-V world, SCVMM, it isn't bad. In fact, Windows Server 2012 and newer ship with Server Core on by default (not hard to get the full UI if you want), because one is expected to use management tools and PowerShell.
No UI (Server Core) is useful. One less subsystem that a bad guy can attack.
This is a double-edged sword. Once people are locked out of their cars, what is to prevent automakers from charging for the ability to go above 45, to go on country roads, to go outside of a state, have more stations on the radio, allow full use of the speakers, allow use of the sunroof, or many other features?
It would be trivial for automakers to license these features just to the owner... so the used car market would dry up, just like it did with used game sales and the fact that most content is from DLC, not on the game disc. Do we want to see automakers demand $5000 from the next person you sell your car to in order to have a software license to start the vehicle?
Look at the console market and how gamers are charged for virtually everything. Would people want that in their cars where they have to pay $100 a month in order to keep access to their climate control and radio? Remember, the car will come with a EULA and those have stood quite well in courts.
IMHO, the Google/Android security team is doing a good job. I have never gotten stung on the Play Store, and I've not encountered "fishy" apps (ones that have horror stories in the reviews) that didn't get taken down quickly in a long time.
Of course, I am still partial to XPrivacy, because it doesn't deny an app permissions... it just feeds it BS. However, I do think Google has kept with the times in terms of security.
The black eye with Android isn't Google's fault. Virtually all reports of malware I see here in the US are due to people going to shady repositories for pirated apps. Yes, it might "save" $1.99 on an app, but there is a good chance, a lot more "functionality" might come with the.apk file.
I've seen people buy a HTC Mini Plus (which is a BlueTooth device that appears as a feature phone, but uses your recent HTC phone) just so they can leave their big phone in their pocket and talk on something less cumbersome.
There are a lot of people who don't want a phablet. The reason why phone makers are making these is less of customer demand... but more surface area needed to disperse the heat on the multi-core CPU/GPU dies that are present.
What should happen is that CAs should be part of SSL's security, not all of it. There should be some additional options:
1: QR codes a company can print out to validate not just their address, but a key ID and fingerprint.
2: Some form of P2P mechanism, coupled with trust weightings. That way, if Alice says a key to Last National Bank is genuine, it has more weight to Bob than 1000 other people who have no reputation, but are showing different key IDs for the same bank.
3: Some caching to notice if an intermediary key changes.
None of this is perfect. #1 can be defeated by an attacker printing out their own flyers. #2 can be defeated by a lot of bogus peers saying that someone else's key is bogus, and by hacking people's accounts for better rep. #3 doesn't work if a computer is new or compromised. However, in combination with a CA, it can help preserve security.
There is always having a key signed by multiple CAs so if one CA is compromised, another shows a key is valid... but the hard part would be making sure people know a key is signed by multiple CAs, versus a bogus key that states they are only vetted by one. Perhaps this could be a different icon (similar to how EV SSL certs have a green titlebar.)
This is why so many variants of adware that sneak their certs into the root CA list and then create a local loopback proxy is so common -- nobody looks at what key is presented. If the lock icon is green... good enough.
Even worse is that certificates can't be removed on some devices. For example, if a CA is broken on iOS, there is no way to mark that CA as untrusted until Apple gets around to pushing out a set of new root certs. Android, it is easier, but still onerous going through every unwanted CA and unchecking it.
The CA system is a subset of a WoT system. It was placed originally because CAs used to be meticulous about who they signed certs for. Now, especially after the fiascos a few years back, no so much.
The fix? Part of it would probably say prompt the user on the device to install the relevant CAs for their geographic region. If on mainland China, having a CA for the HK post office makes sense. Not so in the US, unless one travels abroad or has a lot of business with Chinese sites.
The second fix is that OS and Web browser makers will need to enforce with sheer brutality the rules they have on how CAs behave. If the CA screws up, they get their cert pulled, no questions, no appeals.
The Dash button might be useful in the office or the enterprise, especially if it could be configured to send the order requests to purchasing:
1: You are running out of tape media, and it is time for a quarterly offsite in a few weeks. Mash the button, get the tapes in a few days, continue on.
2: The office supply cabinet is low on pens. Mash the button for the style of pens that is needed, go on one's day.
3: Paper is low. Hit the button by the copier.
I can see a number of uses for this device, more than just ordering bathroom supplies for home.
What we will see are vendors conflating locking the device away from its user with anti-malware protection... two different things, but both are considered "security".
I will also not be surprised to see more remote monitoring, where if a device reports that it was jailbroken or rooted, the cellular network blacklists that device's IMEI.
The future is now. Look at the latest generation of consoles as what we are going to have in our pockets and on our desks. Consoles have no issues with malware and a 0% piracy rate. The main game makers (for the most part) thrive off of the same IP that was out over a decade ago. Any issues result in the console being blacklisted. To boot, you never know if you are being watched. A closed environment like a console can easily have an update pushed to turn the console into a 24/7/365 monitoring device, and there is no way for the user to fix it, outside of physically killing cameras, depowering it or tossing the console in the garbage.
We will also see a tipping point. If a group of people find a bootrom exploit that allows for the next iPhone to be jailbroken, or the exploit allows malware to be put on devices without detection... the malware authors will pay millions for it, while a JB might result in very little. Especially with the time a phone stays jailbroken being days to weeks before Apple pushes an update that closes the hole. In this time, a malware author can make a lot of money with no way to detect or trace his/her works.
Desktops used to be a bastion of freedom, but that is getting encroached as well. The hardware spec for Windows 10 allows CPU vendors to lock down the UEFI Secure Boot to just Windows, and the hardware spec mandates a TPM chip that is shipped on. In fact, any PC certified with Windows 8.1 has the TPM 2.0 chip present.
The only reason why we have not seen a wholesale push to get users completely in the cloud is the fact there is pushback due to the fact that bandwidth in the US is expensive and will remain so.
The sad thing is that we won this battle. In the early 1990s, there was a battle for the device that would be used for consumer browsing. It was the desktop versus the TV set top box. The desktop won because the STB was a monolithic environment and couldn't innovate. Now, we are seeing a rematch, and this time, innovation is stagnant for the desktop and new features, while the set top box has a lot of money behind it, and a lot more technology to lock it down.
A lot of people rather take a console with its ability to report everything you do to anyone upstream and other privacy constaints than a desktop. Trading freedom for security is a dumb thing.
The nice thing about the breadboard is that you can work on one project, and either keep it, or yank the components off and put something different.
Even a short run device that allows one-off PCBs means that if stuff needs modified, the PCB needs to be tossed and a new one made.
I would give this device a place in the lab, but for the original product development, the breadboard will still be king. However, for testing an appliance, being able to one-off custom PCBs... especially multilayered ones... is quite useful.
This gets me curious what tools people use for their larger deployments. I've used Chef and Puppet, as well as Splunk to consolidate logs, but if I get asked to find a tool that is to Linux as SCOM/SCCM is to Windows, what would be the best bet, as I see the above statement, "Linux can't be managed" repeated a lot, and that should be addressed.
One thing that does help is virtualization and downsizing equipment. For example, moving from a desktop to a laptop, buying (or building) a decent server for virtualization, and even using low power devices for LAN services (I use an older Android phone to run a caching DNS service) can make a significant difference.
Especially with older hardware. Almost everyone has that old computer with sturdy hardware that works well. However, those older machines can eat a lot of power.
Slashdot Mirror
Tamperproofing isn't that expensive. The SIM card on a phone will zap itself if decapped, same with my $45 eTokens.
Another example of this was the Java iButtons from Dallas Semiconductors (RIP.)
If a company wanted a tamperproof card, it could be done fairly easily with the entire module epoxy potted to further deter unauthorized modification.
ISO images are likely not going anywhere, so having an ISO of the OS, coupled with an ISO of the decryption files is wise.
I thought of having a VM... but who knows what VM architecture may survive in 15 years, be it Hyper-V, VMWare, Parallels, Xen, KVM, Bochs, or others.
BD-Rs are good, as well as the newer archival grade DVDs (Verbatim UltraLife, for example.)
My vote is to not just use a single medium. Every storage type has good and bad:
1: Cloud storage is easily accessible and easy to use... but is potentially insecure, and the provider can go down taking your data with it.
2: SSD is fast and usable, but when it dies, there is zero chance of data recovery, long term, once the electronics bail the gates.
3: Tape is archival grade with extremely long lifetimes, limited lifetime warranties on media (not data stored), is fast, and has a high capacity... but tape drives are extremely expensive. There is also the issue of a standard to put data on and off, although LTFS helps mitigate this.
4: Optical is widespread with plenty of drives... but doesn't have much capacity, and some disks wind up with bit rot.
5: Hard disks are quite popular, easy to use, fast... but most have just a year warranty, and tend to fail.
6: Printing to paper is possible... QR codes are one way. There is a utility called Paperback (formerly named Paperbak) which prints files out. However, I have had issues with the 1.0 version and scanning back documents, although 1.1 seems to be a lot better at getting back data. Of course, this doesn't store much data, but paper burns at a lot hotter temperature than most other physical media, so it would be useful for storing recovery keys and such.
I recommend using redundant backup media types, combined with different backup programs, perhaps different encryption mechanisms (TrueCrypt, PGP, GnuPG, etc.) This way, if one can't find a backup or encryption program (I doubt you might be able to find a copy of TC in 10-15 years, but something that decoded PGP is likely to be around), there are other ways.
Backup utilities are also something to watch out for. Every program has a different way of stashing data. You don't just need the utility, but you will also need the license key for it... and even then, I've encountered consumer level programs which will still fail and demand an upgraded version before they might consider restoring data.
tl;dr, diversify. At the minimum, use an external drive with encryption for bare metal backups, and then have documents synced with a cloud provider (encrypted of course)... and occasionally burn critical stuff to optical media.
I just keep good backups. Encrypted, of course. With the fact that SSDs actually overwrite deleted data when the garbage collector decides to, deleted data tends to be -gone- for good.
Until it was killed, I had Google index my backups all the time with Google Desktop. It was useful at the time for finding archived files.
For real security, the client should just be "eyes/ears" for the server, similar to how MMOs are. This was true back in the UO days, and is true now.
At least phones and mobile devices are easier to track and ban cheaters because you can ban an account and if any new accounts touch that device's IMEI, they get auto-banned after a random period of time as well. A simple check for a su binary on Android or a check if one can write outside the app's directory in iOS will deal with rooted/jailbroken devices.
Another trick is to update often, preferably with completely different offsets for code and/or obfuscation algorithms so if a group is making patches for the game, they would have to be constantly after a moving target, even if the update just changes a constant or two.
Only problem with that logic is that EA and Ubisoft are quite successful right now, which only sets an example that extreme DRM, DLC, and releasing only a few hours worth of content and calling it a game is the way to earn money in the industry. Especially with consoles where there is a 0% piracy rate and the game developers control everything on that platform.
Of course, it would be nice to see another ID or Bioware. I'm sure there is money to be made on games with a long tail like Neverwinter Nights and NWN2 [1]. However, there just doesn't seem to be an interest to push in that direction. It seems that almost all newer games either fall into the bottomless pit of F2P-P2W or are part a mediocre sequel in a franchise. Even the SimCity app on the phone was all about IAP in order to make your city not suck.
[1]: Ignore the NWN OC... IMHO, that was more of a demo of what one can do with the toolkit than something playable.
Same reason why plumbers, electricians, HVAC workers, and vend a goat repairmen don't get offshored... it just costs too much to grab people off the boat, train them in US standards [1], then them licensed in the specific state.
Here is what I don't get: What exactly is a "solar job"?
First, there is the actual placing of PV panels. This is just physical moving of the object, dropping it into place and bolting it down, perhaps making sure the single or double-axis controller is calibrated.
Second, and this is the most important: Electrician work. PV panels, wiring to proper code, not getting high voltage across the nipples, getting power from the PV panels to the inverter or the battery charge controller (depending on if the person wants an on grid or off grid setup.)
Third is architecture and placing panels. Will the panels be too heavy for a roof, are they facing south, etc.
All these skills are not really just "solar skills", but items used from other occupations.
[1]: Since the US was the first country to go electric, the standards in place are primitive. Tesla's three-phase system helped things, and 120VAC was good for the time, but as metals and materials improved, 240VAC is a better standard overall because it allows for thinner gauge wires.
I like having all of the above:
All disks encrypted, which is mainly so the meth-head who breaks in and grabs the hardware doesn't have access to the data. Hardware can be claimed on insurance. Data opens up blackmail, extortion, and many other avenues.
Encrypted VMs as a way to isolate programs from each other, where I can keep my Quicken/QuickBooks in a VM, move it between computers when needed. Backup? Burn the .vmdk or the .vhdx to a BD-R disk.
File based encrypted volumes as a way of stashing client projects, as well as stashing document backups by date before burning to CD.
Of course, it would be nice to have encrypted archives as well, when one doesn't need to hide the length of the files. PGP Zip covers this, but it would be nice to have a higher level of compression like xz, bzip2, or LZMA, as well as the ability to add an ECC record (similar to WinRAR), so if an archive is damaged, it has a chance of being able to be completely repaired.
My ideal would be to have storage and compute nodes interchangeable, and use something like vMotion to move VMs back and forth between local nodes and cloud based nodes. For example, if I have some VMs that do nothing most of the time (a VM that does quarterly/annual reports, for example), it can sit on a remote cloud provider until it needs to be used heavily... then moved to local computer/storage nodes. Once the reports are done, it gets shoved back to the cloud again.
On the storage side, async storage would be useful, especially for volumes that have critical data. At least it is a form of backup, even though there were still I/O transactions still in flight when things went down.
This functionality was mentioned in Windows Server 2016, so when the preview comes out, it might be interesting to see what MS has improved in this department.
Of course, this is assuming security issues are a solved problem... which isn't the case in real life.
The problem is that with those environments, you could find a way to export your data from the locked down computer somehow... even if you turned your database tuples into a very nasty .CSV file and had some programmers import every table back into another format.
There is no physical access to the data in the cloud, and generally few companies will back up their data stored in the cloud... of if they do, the backups are stored in the cloud. So, in theory, all it takes is a bad guy to do a purge on the provider's side... and the cloud provider's client is now out of business.
Without physical possession, how can one actually say who is doing what with the data, and where it is located? For example, what keeps a US cloud provider from outsourcing capacity to a European provider... which outsources to a provider in a hostile country to the US.
At least with an IBM mainframe, you knew where your data was and could back it up. With cloud computing, all your critical business data can be destroyed or corrupted and nobody would be able to tell until it is too late.
I remember seeing one OSS company working on a generic API that works with whatever one's cloud provider of choice, so it doesn't matter what is on the backend, one can spin up a VM, provision it, do what is needed, then kill it. For storage, any application can use the API, and it deals with whatever cloud storage provider one is using (S3, Azure.)
I do worry about cloud computing as a whole for the open aspect, as well as the security aspect... just for the fact that once you lose physical access, you only have someone's word that their security is up to snuff.
Of course, once people are locked into a specific cloud provider, it becomes quite hard to move to a different provider or back to in-house. That is a concern.
With SCOM, SCCM, and in a Hyper-V world, SCVMM, it isn't bad. In fact, Windows Server 2012 and newer ship with Server Core on by default (not hard to get the full UI if you want), because one is expected to use management tools and PowerShell.
No UI (Server Core) is useful. One less subsystem that a bad guy can attack.
This is a double-edged sword. Once people are locked out of their cars, what is to prevent automakers from charging for the ability to go above 45, to go on country roads, to go outside of a state, have more stations on the radio, allow full use of the speakers, allow use of the sunroof, or many other features?
It would be trivial for automakers to license these features just to the owner... so the used car market would dry up, just like it did with used game sales and the fact that most content is from DLC, not on the game disc. Do we want to see automakers demand $5000 from the next person you sell your car to in order to have a software license to start the vehicle?
Look at the console market and how gamers are charged for virtually everything. Would people want that in their cars where they have to pay $100 a month in order to keep access to their climate control and radio? Remember, the car will come with a EULA and those have stood quite well in courts.
IMHO, the Google/Android security team is doing a good job. I have never gotten stung on the Play Store, and I've not encountered "fishy" apps (ones that have horror stories in the reviews) that didn't get taken down quickly in a long time.
Of course, I am still partial to XPrivacy, because it doesn't deny an app permissions... it just feeds it BS. However, I do think Google has kept with the times in terms of security.
The black eye with Android isn't Google's fault. Virtually all reports of malware I see here in the US are due to people going to shady repositories for pirated apps. Yes, it might "save" $1.99 on an app, but there is a good chance, a lot more "functionality" might come with the .apk file.
I've seen people buy a HTC Mini Plus (which is a BlueTooth device that appears as a feature phone, but uses your recent HTC phone) just so they can leave their big phone in their pocket and talk on something less cumbersome.
There are a lot of people who don't want a phablet. The reason why phone makers are making these is less of customer demand... but more surface area needed to disperse the heat on the multi-core CPU/GPU dies that are present.
What should happen is that CAs should be part of SSL's security, not all of it. There should be some additional options:
1: QR codes a company can print out to validate not just their address, but a key ID and fingerprint.
2: Some form of P2P mechanism, coupled with trust weightings. That way, if Alice says a key to Last National Bank is genuine, it has more weight to Bob than 1000 other people who have no reputation, but are showing different key IDs for the same bank.
3: Some caching to notice if an intermediary key changes.
None of this is perfect. #1 can be defeated by an attacker printing out their own flyers. #2 can be defeated by a lot of bogus peers saying that someone else's key is bogus, and by hacking people's accounts for better rep. #3 doesn't work if a computer is new or compromised. However, in combination with a CA, it can help preserve security.
There is always having a key signed by multiple CAs so if one CA is compromised, another shows a key is valid... but the hard part would be making sure people know a key is signed by multiple CAs, versus a bogus key that states they are only vetted by one. Perhaps this could be a different icon (similar to how EV SSL certs have a green titlebar.)
This is why so many variants of adware that sneak their certs into the root CA list and then create a local loopback proxy is so common -- nobody looks at what key is presented. If the lock icon is green... good enough.
Even worse is that certificates can't be removed on some devices. For example, if a CA is broken on iOS, there is no way to mark that CA as untrusted until Apple gets around to pushing out a set of new root certs. Android, it is easier, but still onerous going through every unwanted CA and unchecking it.
The CA system is a subset of a WoT system. It was placed originally because CAs used to be meticulous about who they signed certs for. Now, especially after the fiascos a few years back, no so much.
The fix? Part of it would probably say prompt the user on the device to install the relevant CAs for their geographic region. If on mainland China, having a CA for the HK post office makes sense. Not so in the US, unless one travels abroad or has a lot of business with Chinese sites.
The second fix is that OS and Web browser makers will need to enforce with sheer brutality the rules they have on how CAs behave. If the CA screws up, they get their cert pulled, no questions, no appeals.
The Dash button might be useful in the office or the enterprise, especially if it could be configured to send the order requests to purchasing:
1: You are running out of tape media, and it is time for a quarterly offsite in a few weeks. Mash the button, get the tapes in a few days, continue on.
2: The office supply cabinet is low on pens. Mash the button for the style of pens that is needed, go on one's day.
3: Paper is low. Hit the button by the copier.
I can see a number of uses for this device, more than just ordering bathroom supplies for home.
Another person mentioned adding a button similar to a watch crown and a color e-Ink display, which would list one's favorite items.
Even without the selector, it would be nice to have this with an e-Ink display just so it can be reused for other items.
This.
What we will see are vendors conflating locking the device away from its user with anti-malware protection... two different things, but both are considered "security".
I will also not be surprised to see more remote monitoring, where if a device reports that it was jailbroken or rooted, the cellular network blacklists that device's IMEI.
The future is now. Look at the latest generation of consoles as what we are going to have in our pockets and on our desks. Consoles have no issues with malware and a 0% piracy rate. The main game makers (for the most part) thrive off of the same IP that was out over a decade ago. Any issues result in the console being blacklisted. To boot, you never know if you are being watched. A closed environment like a console can easily have an update pushed to turn the console into a 24/7/365 monitoring device, and there is no way for the user to fix it, outside of physically killing cameras, depowering it or tossing the console in the garbage.
We will also see a tipping point. If a group of people find a bootrom exploit that allows for the next iPhone to be jailbroken, or the exploit allows malware to be put on devices without detection... the malware authors will pay millions for it, while a JB might result in very little. Especially with the time a phone stays jailbroken being days to weeks before Apple pushes an update that closes the hole. In this time, a malware author can make a lot of money with no way to detect or trace his/her works.
Desktops used to be a bastion of freedom, but that is getting encroached as well. The hardware spec for Windows 10 allows CPU vendors to lock down the UEFI Secure Boot to just Windows, and the hardware spec mandates a TPM chip that is shipped on. In fact, any PC certified with Windows 8.1 has the TPM 2.0 chip present.
The only reason why we have not seen a wholesale push to get users completely in the cloud is the fact there is pushback due to the fact that bandwidth in the US is expensive and will remain so.
The sad thing is that we won this battle. In the early 1990s, there was a battle for the device that would be used for consumer browsing. It was the desktop versus the TV set top box. The desktop won because the STB was a monolithic environment and couldn't innovate. Now, we are seeing a rematch, and this time, innovation is stagnant for the desktop and new features, while the set top box has a lot of money behind it, and a lot more technology to lock it down.
A lot of people rather take a console with its ability to report everything you do to anyone upstream and other privacy constaints than a desktop. Trading freedom for security is a dumb thing.
The nice thing about the breadboard is that you can work on one project, and either keep it, or yank the components off and put something different.
Even a short run device that allows one-off PCBs means that if stuff needs modified, the PCB needs to be tossed and a new one made.
I would give this device a place in the lab, but for the original product development, the breadboard will still be king. However, for testing an appliance, being able to one-off custom PCBs... especially multilayered ones... is quite useful.
This gets me curious what tools people use for their larger deployments. I've used Chef and Puppet, as well as Splunk to consolidate logs, but if I get asked to find a tool that is to Linux as SCOM/SCCM is to Windows, what would be the best bet, as I see the above statement, "Linux can't be managed" repeated a lot, and that should be addressed.
One thing that does help is virtualization and downsizing equipment. For example, moving from a desktop to a laptop, buying (or building) a decent server for virtualization, and even using low power devices for LAN services (I use an older Android phone to run a caching DNS service) can make a significant difference.
Especially with older hardware. Almost everyone has that old computer with sturdy hardware that works well. However, those older machines can eat a lot of power.