I believe in the KISS principle. Even though people say that a hacker with the 0-days to go after IoT devices won't go after individual users... I will agree there. Individually, they won't bother with people. However, their script that walks the Internet and seizes control of devices, is what would be done, with that info being sold to another party, just like credit card dumps. In fact, a list of vulnerable/cracked devices a person owns might even be in the same database tuple as their name, social security number, and other item sold on the black market.

There are some things I don't need. I can look at the date of items in my fridge and tell they are going to expire. I don't need to have a fancy infrastructure in place so that some company can sell me milk in the next round of banner ads. I can look near the commode and tell how many rolls of TP that I have, and don't need to upload that info somewhere. I don't need a toilet which checks sugar levels, but quietly uploads that to health insurance companies so they have an excuse to raise premiums. If I'm worried about sugar levels, I can always get a meter and a roll of test strips and do the job right.

We do not need an IoT. We are being sold this shit because "market expansion" balloons stock prices even though it may or may not make revenue.

IoT devices will be engineered to be as cheap to produce as possible. They will be coming out of the cheapest factory in China, and engineered to barely work. At best, they will barely pass UL standards, if they don't just come with a fake UL tag in the first place. It will be a given that there will be little thought to security [1], and the only way to fix them will be replacing them with devices that are even buggier and more expensive.

If we want monitoring, the parent had one way to do it "right". I'd prefer a wired bus that is engineered the reverse of early USB. Devices can send info, but the top node that gets the info cannot initiate or send data... just send an ack that it got received. Even with this, there are still ways to hack it, so the ideal is no system at all.

Because it be connected to the Internet, doesn't mean it should. Take the Internet connected deadbolt. We don't need junk like that. Instead, the time it takes to engineer that should have been spent making a better locking mechanism/door/jamb system to help against actual threats like lock bumping and kick-ins.

[1]: I've heard "security has no ROI" many a time, coupled by "Infosys/Geek Squad can fix anything if we get hacked", when I ask the followup question about contingency plans.

Microsoft has two technologies in Windows Server 2012: Storage Spaces (which is LVM level), and ReFS. Both when used together can detect bit rot, but IIRC, only when the Storage Space volume is set to mirroring, nor parity.

This is similar with ZFS. RAID-Z will detect bit rot, but won't fix it. RAID-1, RAID-Z2, and RAID-Z3 will detect and fix bit rot on a scrub. One can also use copies or ditto blocks.

Linux, there isn't much either way. I have no clue if LVM2 + btrfs will do anything about bit rot, assuming it has the ability to repair it from a mirror or a RAID 6 volume. This seems to be one of those "ask four people, get five answers" type of items.

If I were setting up a file server or backend RAID, I'd probably will go with Linux and ZFS (from the zfsonlinux projects.) The / and /boot filesystems wouldn't be able to be placed on ZFS, but almost everything else can. With a RAID-Z2 pool, this will go far in detecting and handling bit rot.

This might be another good reason to learn kanji or traditional Chinese as a character set. This definitely would get the amount of characters needed per slot down by quite a number.

I think it might have a niche utility, but to use a car example, this is like making a very top tier points/condensor/magneto system for a car's engine... while the world has moved on to common rail EFI.

I am glad it got released (I remember it being the dream of document presentation well before Mosaic appeared on the NeXT), but there are many other document utilities out there with similar function. PDF and HTML come to mind, perhaps nroff on a limited basis. However, the world has moved on. On the other hand, Xanadu deserves its place in history, just for the concept.

We sort of have that with OpenPGP encrypted files, and Web add-ons. However, it assumes one is going to load their private keys into the Web browser... and because the Web browser is the first thing that gets its face curb-stomped come a 0-day, this may not be a wise thing unless there is OS support for keeping the keys, decryption module, and decrypted text viewer/attachment manager well out of the browser's OS context.

The reason I suggest an old fashioned MUA is because they tend to not be as vulnerable to malformed E-mail messages when configured properly. The spammy E-mails either try to get someone to download a wrapped executable (.scr extensions are commonplace), or get the user to visit a bad site. The E-mail themselves tend to not by themselves be dangerous, assuming scripting is turned off by default.

Maybe only queries or certs that make sense as per laws, such as 13, 18, 21, 25, 65, etc. There wouldn't be a legal reason that a bar would need to know anything more than if they are legal, unless they were doing a retiree special (which the over 65 cert would cover.) The goal is to provide the minimal amount of info as needed for regulations.

I've wondered about an ID system with a smart chip, except based around a certificate and trust model. For example, Alice's ID would have a cert (each cert has a different life span [1]) showing that she is over 21, has a valid driver's license, is a US citizen, is not a felon.

At the bar, the card gets swiped, the cert shows she is over 21, so is allowed in. No birthdate needed.

When going for a loan, there is a cert showing her FICO score is above a threshold, her income is above a certain amount, and she is a US citizen. Just three pieces of info that are needed.

When going for a car purchase, there is a signature stating she has valid insurance, and a valid license. No more details are needed.

This would greatly improve privacy if done right.

[1]: The criminal record certs can have a short life, so someone who gets convicted either has the "not a felon" cert revoked, or it expires in a week's time.

ISIS is becoming a carrier standard for this. It uses NFC, a special SIM card with the ISIS application (so it can have its own PIN separate from the SIM's PIN/PIN2), and an Amex or Wells Fargo credit card.

Is ISIS a good thing? Possibly, but you have to open a new line of credit to use it, in most cases.

Of course, there is Google Wallet and PayPal as well, so there may be a standard war between those three companies.

I wouldn't say it would be the end of credit card fraud. It makes people more dependent on their phone, which means dire consequences if it is stolen, or if malware seizes control of the unit and is able to key-log the PIN.

Another issue is that some protocols are viewed negatively. Tor comes to mind, because it is anonymous and works well... but it becomes a source of abuse, and it is also associated with the Four Horsemen of the Infocalypse. If one could get mainstream users not just using Tor, but setting up usable exit nodes, it might change the perception.

Sometimes, I wonder about an encryption protocol implementation like iMessage being broken up into multiple companies, all separate, perhaps in different countries:

1: The company that codes the client.
2: The company with the servers where messages reside.
3: The company that writes the protocol.
4: The company that officially signs the executables to be distributed, but vets the code base for unauthorized changes before doing so.

By splitting this up, it would take compromise of at least two of the above, and definitely the company with the servers.

I've used both PGP and GPG, but I have run into the spam filters. With S/MIME, I've run into people flipping out when they see the ribbon icon in a received E-mail on Outlook, to the point getting their company's legal department and a LEO involved because they thought a validated signature was malware.

What I'd like to see is a signing system that piggybacks onto GPG, or perhaps S/MIME that would allow for read receipts (provided the receiver chose to allow it to be sent)... but maybe allow for mail to be "un-sent", although the mechanism involved would have to be flawless, or else it would be a big security issue.

Maybe this is pure Ludditism, but the best security is gotten by having a MUA that is separate from the e-mail provider, and the MUA handles PGP/gpg or S/MIME keys.

There is something nice and convenient about Web based E-mail, but it is at a cost of end to end security.

It isn't as good as end to end, but with Exchange, one can do encrypted TLS connectors with other Exchange sites that one does a lot of E-mail or other messaging with. This will secure the E-mail as it goes from site "A" to site "B". However, if site "C" still uses unencrypted SMTP, then anything going there isn't really secured.

I just wonder how long it will be until some microbe evolves that can chew on polymers, breaking them up into something digestible.

In theory, Google can be forced to push out an add-on that slurps up private keys and uploads them. However, no solution is 100%, and anything is better than nothing.

The best solution is to have a MUA, (not a Web browser... a dedicated MUA that isn't a general purpose renderer) handle all E-mail, with separate modules that don't autoupdate that handle PGP/gpg and other encryption. However, anything is better than nothing, and this will do a decent job at protecting against intrusion internally.