Fuel cells used as emergency "generators" make sense. There have been times where power may be off, but the natural gas pipes still have pressure.
If we have advances in fuel cell technology, I'd like to see them in making small devices that work with either (or preferably both) CNG and propane. Right now, if I don't have electric and gas, my water heater and furnace become inoperable. Same with my gas dryer. Older RV refrigerators used to be able to run solely off of propane. Now, they require it and 12 volts for the control boards.
It would be nice to have a fuel cell that would give enough power to run an appliance's control board, especially if it already requires gas to function. That way, a gas dryer will work completely independently of the electrical system, similar with a place's HVAC system (although it would be tough for a fuel cell to keep enough juice for an A/C compressor in summer.)
In Europe, Truma sells exactly this, so one doesn't have to use an absorption refrigerator, but can use a regular dorm fridge from the RV's batteries, and the batteries are kept topped off by their propane fuel cell.
I can see fuel cells being useful where natural gas is plentiful so the data center can use CNG cells as an auxiliary generator. In Europe, Truma sells a propane fuel cell for RVs so that the house batteries are always charged, even if the RV solar system is not making any wattage.
I don't see how fuel cells can be useful as energy storage devices just due to the fact that we have electrolysis, and that's it for splitting water into its component atoms.
Instead, why not do like solar plants do, use supercap batteries as a "buffer", then use high-capacity batteries? A couple weeks ago, there was mention of various batteries with impressive (almost within 1-2 orders of magnitude of gasoline) energy density. Why not just go that route?
Hydrogen has its own hazards, and I don't mean Hindenburgs. Why not just put more research into high capacity lithium-air or other batteries and go from there?
What can be done is to use the Swiss data center as a passthrough for encryption.
That way, you have your site -> intermediate storage provider -> destination cloud provider, with both your site and the intermediate provider doing passthrough encryption. This can be changed with public key encryption to the intermediate providers only stepping in to decrypt data with their private key [1]. Encrypted data would just go directly from the client to the end cloud provider.
That way, for data to be accessed without authorization, it would take the destination cloud provider, the intermediate providers with their keys, and the client to all be compromised.
[1]: Or more technically using a symmetric algorithm with the key protected by a public key algorithm a la OpenPGP.
I treat cloud storage as another media type, with its advantages and disadvantages:
Optical, once the disk is finalized, is resistant to tampering, but suffers from bit rot.
Hard drives are not archival media, but they are relatively inexpensive, quick, and easy to use.
Tapes are great for long term archiving, but modern tape drives are expensive.
USB flash drives are cheap and easy to use, but data can vanish from them at any time.
MicroSD cards are excellent for data per volume, but they are relatively slow, and just like USB flash drives, data can vanish, and vanish forever and not be recoverable.
The cloud is "just" another media type. Its advantage is that in theory, stuff stored is stored fairly robustly. However, because the data is stored physically out of one's control, it is only prudent to assume that it is accessible (and alterable) to all and sundry, just like it would be if stored on a public anonymous FTP server. With this in mind, encrypting (and signing) all data before sending it offsite is not a best practice, it is basic sanity.
SLAs are a joke. Good luck suing if the other side breaches their side of the contract, even if they have a SLA that supposedly guards your data. Of course, if a cloud provider goes under, the next owner of the physical servers will own the data on them, free and clear. Business bank records and payroll database? It can be a BitTorrent for all to download, and there is nothing that can be done.
So, cloud storage has its uses. It is fairly fault tolerant, it is durable. However, one needs clientside encryption, no matter what.
Thank you. I just looked it up, and although they are out of stock, it is definitely something to consider, assuming the PKCS/11 driver is findable for it (this allows keyfiles to be stored with TrueCrypt, and though not as secure as using a keypair, it minimizes the time the file is exposed to a potentially compromised machine.
Yes, but that is the rub. It is a lot harder for $ADVERSARY [1] to compromise/coerce every endpoint in a transaction than it is to compromise core servers and CAs.
Nothing is 100% secure, and the XKCD cartoon about the $5 wrench does hold true... but good encryption and key management changes things from passive spying to active compromise, which is a lot harder, more expensive, and potentially more detectable.
Moving to a WoT raises the bar, just as using CAs raised the bar to protect against MITM attacks with a D-H exchange.
[1]: It could be the NSA, ISI, PLA, the Illuminati, or other group in this case.
Maybe the mail client should focus on having a layer of security for protecting data and metadata, but the actual message should be handled by PGP, or at least a separate, independent mechanism?
The reason it is good to have message encryption separate is because OpenPGP has been around longer than SSL, and has stood the test of time. A lot of people use webmail, and if all the security is "baked into" the client, all it would take is for an intruder to compromise the webserver, as opposed to end to end encryption which only gets decrypted on the client side.
What might be a decent replacement for SMTP, but for small messages only (under 1-5 megs) would be a NNTP-like structure.
User "A" at site foo.com wants to send a message to user "B" at bar.com. The message is encrypted with OpenPGP to b@bar.com. Then, the server at foo.com drops it into a store and forward pool similar to a newsgroup. bar.com eventually receives the latest messages, notices a message addressed to one of its users, copies it out of the "newsgroup", and into the user's mailbox.
Of course, a blinding factor can be attached so no other machines with the NNTP-like pool can tell that the message is addressed to someone at bar.com, they can tell it is injected from foo.com and expires in a few hours, but that is that.
Of course, the disadvantage is that a whole lot of irrelevant info goes between company servers. The advantage is that communications are protected, as one might see a server drop a message into the stream, but there is no way to detect a server fishing one out.
PGP has one advantage -- it is completely separate and standalone from whatever messaging system is in use. Yes, metadata can be compromised, but the actual messages would be protected no matter how hosed the underlying protocol is.
In the past, I've used a lot of protocols to send PGP/gpg encrypted messages, be it AIM, UNIX ntalk, mail or write.
However, you are right. It is a separate step, and likely to a different app. However, it is good in a way that PGP is separate from the message medium.
On Windows, the port of gpg isn't that great. The best solution is Symantec's PGP, but for a registered version is $250 or so.
The gpg port on OS X is pretty good and constantly updated.
Linux is decent as well.
I do wish Symantec would lower their price on their "Symantec Encryption Desktop", which they renamed PGP Desktop. I'd be pretty sure they would make money hand over fist on volume because a lot of people are security-conscious now.
The advantage of key servers is their replication and the fact that keys can be validated to check for tampering. If the key server is damaged and completely compromised with every key on there being swapped out with a bogus key, it will end up being evident when people check signatures and even though the keys on the server might have signing connections, none of the keys have any valid signatures.
Replication also is a good thing. An attacker can add a key with the same name and ID, but not the fingerprint. If someone deletes keys on one keyserver, it only will affect that keyserver. To remove a key requires hacking all the keyservers that replicate with each other, and then, if just one has the key, it will re-replicate.
Endpoint weakness is also important, and a good point. There are cryptographic tokens, but GPG realistically doesn't support them (I've tried), so one would have to use the commercial version of Symantec's product to generate/store/use tokens. However, tokens do provide a security increase since the key never leaves the device, and the device does the signing/decryption.
What I'd like to see is an "open source" cryptographic token that can work with gpg. This way, the worst an attacker can do is intercept the token's PIN and generate a bogus signature, but the key material is kept secure regardless.
PGP/gpg's weakness is noticeable, but in this case, the perfect is the enemy of the good, and a WoT is the security solution that sucks the least.
Yes, it takes some time to get keys signed, but the advantage of a WoT over SSL is that you can take a couple people whom you never met, but whom your friends trusted, add up their semi-trust, and be pretty sure that an unknown key is genuine.
There are some fairly sane security measures a maker of a security device can do for fairly cheap to ensure that a tampered device isn't going to work without a lot of money and time put in:
1: If it is something static like a bill checker, take the time to heavily QA the device, including throw prototypes in the field for a while. Then, just have the firmware burned into a ROM (a true ROM, not an EEPROM, EPROM, PROM, flash, or an OS on a HDD... it goes into silicon and is not modifiable, period.) Of course, a bill checker might need updates when the currency gets a facelift, so a bill checker likely would need some type of upgrade mechanism.
2: If an update mechanism is needed, TPM chips are not expensive. In fact, some ARM CPUs have them built in. That solves 95% of the problem right there, because if the OS isn't signed, the OS won't be able to decrypt the last stage and boot.
3: As a subset of #2, the code that allows flashing of ROM images should be in a non-alterable, signed image. This way, if the main OS image has to change, it has to go through the "gatekeeper" image to be written to the boot medium, or it doesn't get on there.
4: Multiple images. This way, if a flash image is verified and copied to a temporary space and is being copied to the main storage, a power failure doesn't brick the device. The TPM boots, finds the signature of the first image fails, tries the backup, boots from that. The flash process updates both images, so only one would be inoperable during an update at a time.
5: To prevent flashing to a less secure previous version, the OS image that does the image update work can be set to look at version IDs, or optionally, if the ID is signed with a certain flag, can allow earlier versions to overwrite newer ones, or have beta images be able to be downgraded if needed.
6: The image flashing would have to be via a physical process, such as a USB connection. This way, devices can't be upgraded over the network, which shuts out a lot of potential exploits.
I'm sure I've missed a few items, but it doesn't take a lot of engineering to have an update mechanism in place that is tamper resistant.
I wonder about wood gas or biogas as well. Biomass is a lot easier to find and cultivate (can be the product of waste material from a gain harvest like hulls), and done right, this can power a generator.
On a larger scale, biomass can be used for energy generation. Here in Texas, there is a 100MW biomass plant in Nacogdoches which is fed by waste from mills, rotten trees, and other by-products. Of course, biomass is something to get away from long term, due to CO2 output, but it is definitely a step up from coal and the pollutants found in that.
Of course, there is solar PV cells that take a significant initial expenditure, but once installed, take relatively little upkeep and can run for 30+ years.
The one thing that coal has for it is that we have a lot of experience making it burn and turn turbines. However, some people say we have already passed "peak coal", especially with the fact that newer plants burn the crappy, lignite coal as opposed to better grades. At least with biomass, it is fairly renewable.
No solution is perfect, but there are some worse than others.
If you buy a generator, buy one now, have an electrician install either an interlock system on the circuit breaker or a transfer switch. (Interlocks are code safe, and allow you more freedom to choose what circuits you want on the generator, but a manual transfer switch is a lot more idiot-resistant.)
When disasters strike, generators go immediately at the hardware stores, so it can't hurt to at least have a portable one (or two Honda 2000 watt models that are paired) to keep the computers and refrigerator running.
I've read about glitches when one does an update, so I wonder if the Wi-Fi problem would go away if someone backed up their device (would have to be dumped to a computer with iTunes), did an erase all, then followed it up by a DFU restore. This method pretty much ensures that all data stored on the device is erased. Then the device can be restored, apps/music reinstalled, and things back to normal.
This also stems from a general IT lesson I learned. If possible, when it comes to OS upgrading time with major number versions [1], one is best off rebuilding a server from scratch than updating it, due to cruft left behind from the previous OS, and other inconsistencies which might cause issues later on. Sometimes this isn't possible, other times, it is easily done.
[1]: The cautious exception are RPM based Linux distros which are really just stacks of filesets snapshotted and regression tested at a certain point in time. Those, I can just increment the version number, run yum upgrade, and be done with it, since it is more of a large update than a major version upgrade. Even with these, it doesn't hurt to install from scratch since it seems that RPM databases tend to get corrupted over time.
I'd be quite happy for a physical keyboard similar to what was on the Motorola CLIQ/DEXT which would spring open and closed.
Of course, the #1 thing in a phone would be an unlocked bootloader, but next to that would be a physical keyboard and a decent amount of RAM so activities don't have to be reloaded when I switch apps.
Of course, there is the pie in the sky stuff: I'd like two features that were present in the Atrix: The fingerprint scanner [1], and the ability to be dropped in a dock and run a lightweight Linux distribution. This would allow me to do basic stuff when on the road, and if someone stole the docking station, whoop-de-do, as all the data would be on the phone.
Of course, being able to use a phone as a NAS would be nice for critical documents because they could be encrypted with a mechanism similar to how Titanium Backup encrypts backups [2], and syncs them to a remote cloud site. Combined with an archive feature (which allows files to be stored on the remote site and removed from the device), it would provide a fairly usable central place for storing documents in a secure manner [3].
[1]: Fingerprint scanners have their flaws, but for a screen lock, or a means of telling an app that it is OK to do a task (like sign/decrypt a file), it is a decent addition.
[2]: Titanium Backup uses RSA public/private keys. For encrypting backups, it uses a public key. When decrypting, it uses a user-set password to unlock the private key, which unlocks the file's symmetric key.
[3]: Of course, cloud providers can go down or have issues, but there are APIs out there to allow data to be sent to multiple providers at once. That way, if Dropbox dies, the data is still retrievable from Skydrive.
The ironic thing is that optical drives, though boring, have their use. For example, I can pay $10 a month for 100 gigs on a cloud storage, or I can pay for a few Blu-Ray blanks, burn the data, and call it done. From there on out, the cost of storing the data is pretty much $0. To boot, it is very difficult for malware to tamper with media finalized on BD-R media.
Yes, a hard disk is cheap and can store a lot, but for small documents, nothing beats burning to WORM media for long term archiving.
It would be nice if the 100GB BD disks came down in price. Next to a modern LTO drive, it would be very useful for backups.
Long term, until fusion is sustainable for production energy, the ideal would be a coal/gas plant as the starter (nuclear plants require power on the grind to come online after a grid outage), then have the general power be primarily nuclear.
With better batteries and solar, that will do a lot to ease peak consumption. If we can get batteries that are within an order of magnitude of gasoline that can store power overnight, this would significantly ease the load from the power grid.
A lot of Americans can't stand CNN, MSNBC, or Fox, just because both slants have done damage to the country. This is why Al Jazeera seems to have taken a foothold (not to say they are always unbiased, but for stuff they don't have a "dog in the hunt" for, they are better than local sites.)
Thank you for the Novaya Gazeta link. It definitely beats the usual anti-West drivel found on Pravda.
I'd like to find a German news site that has been pretty straight with the US news (as their bias is elsewhere), but forgot the name.
I sort of hope that the CAPTCHA-busting code is just vapor, and it doesn't get released.
If it does come out and get into widespread use, what will likely result are websites likely going another step up the chain and doing more annoying stuff such as requiring access through Facebook, demanding a phone number for SMS authentication (of course, said number ends up getting sold to robodialers), or more intrusive means.
I see some CAPTCHA replacement schemes like counting how many cat butts are facing a person in a row of six photos and inputting the number, but those seem at best a stopgap measure, and block out access to the site to the blind.
E-Books are nice, and yes, I have more than one e-book reader. However, paper books have their place for a few ways:
First, if there is a power issue, paper books are still legible in daylight. If the battery runs out on by e-book reader while I'm camping, either I use an external charger or I'm not reading books until I come back to my vehicle or civilization.
Second, DRM. There is nothing stopping book publishers from denying access to one's title list unless a monthly fee was paid, charging by the page or adding additional fees. Think a lawsuit might help? Nope, that EULA was auto-accepted when the app was ran after the update. Of course, books can disappear from readers, just like 1984 did for a period of time. And if done, there is nobody to stay otherwise.
Third, incompatible formats. Kobo, Scribd, Kindle, iBooks, Google Books, Nook, Sony. The formats might be similar, but the DRM is different. The closest thing to a "rosetta stone" is probably an iPad because it can read all those formats. Of course, one should get their books from one e-book store, but sometimes one place may have books another one doesn't.
Fourth, backups. With DRM-ed copies, it might be a backup and restore will not be an option due to the app phoning home for authorization.
e-books are great, as I can carry one device with thousands of titles on it. However, it won't replace paper books.
Of course, it would be nice for Amazon or the big names to sell the e-book and the paper book at one price. That way, I can go download all the relevant stuff I need, and in a few days, have the paper books for the library bookshelf. Best of both worlds.
As a normal user, it is hard. Once the mail hits the main SMTP relay and heads out, it is in plaintext unless one is running Exchange which has secure connectors and one sets up TLS links with other sites.
It would be nice to have a TLS/SSL mechanism where company E-mail servers would be checked if they had a secure transport port, the key fetched and checked with a CA, and then the mail sent.
However, there are really only three choices for E-mail:
1: Have both users share the same provider so mail is just delivered locally.
2: Use S/MIME. The problem with this method is that few mailers except for Thunderbird, mail.app, and Outlook have S/MIME ability. iOS requires special setup to get S/MIME working, and Android varies on MUA.
3: Best of all, have a PGP/gpg web of trust and an application/app which can easily encrypt/decrypt from the clipboard. This way, the message security is entirely independent of every party in between. However, this is very rarely done. The last time I had a truly meaningful PGP-encrypted conversation (other than "yay, I sent you an encrypted message... this is cool" tripe) was in the 1990s when discussing a very obscure bug on a CC: list, and there was worry that the bug could be an easy target for blackhats.
PGP is a very neglected program. It would be nice to see working security token support so a private key would not have to leave a token to be used. One can buy a SafeNet (formerly Aladdin) eToken and use the commercial version of Symantec's PGP to do this, but the $400-500 total cost can be expensive.
If a company really wanted to set the bar higher for security in general, they would make a dedicated security token that one could copy a private key on, and the token would do the decryption/signing on it, so the key never gets exposed to the computer. Bonus points if this can be implemented in an OS-independant way (perhaps present the USB device as a drive with files that act as devices, so one can input the unlock key by appending to a file, send up the file to be signed by another append, then read from the second file for the signed OpenPGP packet.
Slashdot Mirror
Fuel cells used as emergency "generators" make sense. There have been times where power may be off, but the natural gas pipes still have pressure.
If we have advances in fuel cell technology, I'd like to see them in making small devices that work with either (or preferably both) CNG and propane. Right now, if I don't have electric and gas, my water heater and furnace become inoperable. Same with my gas dryer. Older RV refrigerators used to be able to run solely off of propane. Now, they require it and 12 volts for the control boards.
It would be nice to have a fuel cell that would give enough power to run an appliance's control board, especially if it already requires gas to function. That way, a gas dryer will work completely independently of the electrical system, similar with a place's HVAC system (although it would be tough for a fuel cell to keep enough juice for an A/C compressor in summer.)
In Europe, Truma sells exactly this, so one doesn't have to use an absorption refrigerator, but can use a regular dorm fridge from the RV's batteries, and the batteries are kept topped off by their propane fuel cell.
I can see fuel cells being useful where natural gas is plentiful so the data center can use CNG cells as an auxiliary generator. In Europe, Truma sells a propane fuel cell for RVs so that the house batteries are always charged, even if the RV solar system is not making any wattage.
I don't see how fuel cells can be useful as energy storage devices just due to the fact that we have electrolysis, and that's it for splitting water into its component atoms.
Instead, why not do like solar plants do, use supercap batteries as a "buffer", then use high-capacity batteries? A couple weeks ago, there was mention of various batteries with impressive (almost within 1-2 orders of magnitude of gasoline) energy density. Why not just go that route?
Hydrogen has its own hazards, and I don't mean Hindenburgs. Why not just put more research into high capacity lithium-air or other batteries and go from there?
What can be done is to use the Swiss data center as a passthrough for encryption.
That way, you have your site -> intermediate storage provider -> destination cloud provider, with both your site and the intermediate provider doing passthrough encryption. This can be changed with public key encryption to the intermediate providers only stepping in to decrypt data with their private key [1]. Encrypted data would just go directly from the client to the end cloud provider.
That way, for data to be accessed without authorization, it would take the destination cloud provider, the intermediate providers with their keys, and the client to all be compromised.
[1]: Or more technically using a symmetric algorithm with the key protected by a public key algorithm a la OpenPGP.
I treat cloud storage as another media type, with its advantages and disadvantages:
Optical, once the disk is finalized, is resistant to tampering, but suffers from bit rot.
Hard drives are not archival media, but they are relatively inexpensive, quick, and easy to use.
Tapes are great for long term archiving, but modern tape drives are expensive.
USB flash drives are cheap and easy to use, but data can vanish from them at any time.
MicroSD cards are excellent for data per volume, but they are relatively slow, and just like USB flash drives, data can vanish, and vanish forever and not be recoverable.
The cloud is "just" another media type. Its advantage is that in theory, stuff stored is stored fairly robustly. However, because the data is stored physically out of one's control, it is only prudent to assume that it is accessible (and alterable) to all and sundry, just like it would be if stored on a public anonymous FTP server. With this in mind, encrypting (and signing) all data before sending it offsite is not a best practice, it is basic sanity.
SLAs are a joke. Good luck suing if the other side breaches their side of the contract, even if they have a SLA that supposedly guards your data. Of course, if a cloud provider goes under, the next owner of the physical servers will own the data on them, free and clear. Business bank records and payroll database? It can be a BitTorrent for all to download, and there is nothing that can be done.
So, cloud storage has its uses. It is fairly fault tolerant, it is durable. However, one needs clientside encryption, no matter what.
Thank you. I just looked it up, and although they are out of stock, it is definitely something to consider, assuming the PKCS/11 driver is findable for it (this allows keyfiles to be stored with TrueCrypt, and though not as secure as using a keypair, it minimizes the time the file is exposed to a potentially compromised machine.
If it is a USB device, so much the better.
Yes, but that is the rub. It is a lot harder for $ADVERSARY [1] to compromise/coerce every endpoint in a transaction than it is to compromise core servers and CAs.
Nothing is 100% secure, and the XKCD cartoon about the $5 wrench does hold true... but good encryption and key management changes things from passive spying to active compromise, which is a lot harder, more expensive, and potentially more detectable.
Moving to a WoT raises the bar, just as using CAs raised the bar to protect against MITM attacks with a D-H exchange.
[1]: It could be the NSA, ISI, PLA, the Illuminati, or other group in this case.
Devil's advocate:
Maybe the mail client should focus on having a layer of security for protecting data and metadata, but the actual message should be handled by PGP, or at least a separate, independent mechanism?
The reason it is good to have message encryption separate is because OpenPGP has been around longer than SSL, and has stood the test of time. A lot of people use webmail, and if all the security is "baked into" the client, all it would take is for an intruder to compromise the webserver, as opposed to end to end encryption which only gets decrypted on the client side.
What might be a decent replacement for SMTP, but for small messages only (under 1-5 megs) would be a NNTP-like structure.
User "A" at site foo.com wants to send a message to user "B" at bar.com. The message is encrypted with OpenPGP to b@bar.com. Then, the server at foo.com drops it into a store and forward pool similar to a newsgroup. bar.com eventually receives the latest messages, notices a message addressed to one of its users, copies it out of the "newsgroup", and into the user's mailbox.
Of course, a blinding factor can be attached so no other machines with the NNTP-like pool can tell that the message is addressed to someone at bar.com, they can tell it is injected from foo.com and expires in a few hours, but that is that.
Of course, the disadvantage is that a whole lot of irrelevant info goes between company servers. The advantage is that communications are protected, as one might see a server drop a message into the stream, but there is no way to detect a server fishing one out.
PGP has one advantage -- it is completely separate and standalone from whatever messaging system is in use. Yes, metadata can be compromised, but the actual messages would be protected no matter how hosed the underlying protocol is.
In the past, I've used a lot of protocols to send PGP/gpg encrypted messages, be it AIM, UNIX ntalk, mail or write.
However, you are right. It is a separate step, and likely to a different app. However, it is good in a way that PGP is separate from the message medium.
This varies on platform:
On Windows, the port of gpg isn't that great. The best solution is Symantec's PGP, but for a registered version is $250 or so.
The gpg port on OS X is pretty good and constantly updated.
Linux is decent as well.
I do wish Symantec would lower their price on their "Symantec Encryption Desktop", which they renamed PGP Desktop. I'd be pretty sure they would make money hand over fist on volume because a lot of people are security-conscious now.
The advantage of key servers is their replication and the fact that keys can be validated to check for tampering. If the key server is damaged and completely compromised with every key on there being swapped out with a bogus key, it will end up being evident when people check signatures and even though the keys on the server might have signing connections, none of the keys have any valid signatures.
Replication also is a good thing. An attacker can add a key with the same name and ID, but not the fingerprint. If someone deletes keys on one keyserver, it only will affect that keyserver. To remove a key requires hacking all the keyservers that replicate with each other, and then, if just one has the key, it will re-replicate.
Endpoint weakness is also important, and a good point. There are cryptographic tokens, but GPG realistically doesn't support them (I've tried), so one would have to use the commercial version of Symantec's product to generate/store/use tokens. However, tokens do provide a security increase since the key never leaves the device, and the device does the signing/decryption.
What I'd like to see is an "open source" cryptographic token that can work with gpg. This way, the worst an attacker can do is intercept the token's PIN and generate a bogus signature, but the key material is kept secure regardless.
What I fear is that we trade in a protocol at sort of works for one that is patent encumbered or has some unknown issues in it.
PGP/gpg's weakness is noticeable, but in this case, the perfect is the enemy of the good, and a WoT is the security solution that sucks the least.
Yes, it takes some time to get keys signed, but the advantage of a WoT over SSL is that you can take a couple people whom you never met, but whom your friends trusted, add up their semi-trust, and be pretty sure that an unknown key is genuine.
There are some fairly sane security measures a maker of a security device can do for fairly cheap to ensure that a tampered device isn't going to work without a lot of money and time put in:
1: If it is something static like a bill checker, take the time to heavily QA the device, including throw prototypes in the field for a while. Then, just have the firmware burned into a ROM (a true ROM, not an EEPROM, EPROM, PROM, flash, or an OS on a HDD... it goes into silicon and is not modifiable, period.) Of course, a bill checker might need updates when the currency gets a facelift, so a bill checker likely would need some type of upgrade mechanism.
2: If an update mechanism is needed, TPM chips are not expensive. In fact, some ARM CPUs have them built in. That solves 95% of the problem right there, because if the OS isn't signed, the OS won't be able to decrypt the last stage and boot.
3: As a subset of #2, the code that allows flashing of ROM images should be in a non-alterable, signed image. This way, if the main OS image has to change, it has to go through the "gatekeeper" image to be written to the boot medium, or it doesn't get on there.
4: Multiple images. This way, if a flash image is verified and copied to a temporary space and is being copied to the main storage, a power failure doesn't brick the device. The TPM boots, finds the signature of the first image fails, tries the backup, boots from that. The flash process updates both images, so only one would be inoperable during an update at a time.
5: To prevent flashing to a less secure previous version, the OS image that does the image update work can be set to look at version IDs, or optionally, if the ID is signed with a certain flag, can allow earlier versions to overwrite newer ones, or have beta images be able to be downgraded if needed.
6: The image flashing would have to be via a physical process, such as a USB connection. This way, devices can't be upgraded over the network, which shuts out a lot of potential exploits.
I'm sure I've missed a few items, but it doesn't take a lot of engineering to have an update mechanism in place that is tamper resistant.
I wonder about wood gas or biogas as well. Biomass is a lot easier to find and cultivate (can be the product of waste material from a gain harvest like hulls), and done right, this can power a generator.
On a larger scale, biomass can be used for energy generation. Here in Texas, there is a 100MW biomass plant in Nacogdoches which is fed by waste from mills, rotten trees, and other by-products. Of course, biomass is something to get away from long term, due to CO2 output, but it is definitely a step up from coal and the pollutants found in that.
Of course, there is solar PV cells that take a significant initial expenditure, but once installed, take relatively little upkeep and can run for 30+ years.
The one thing that coal has for it is that we have a lot of experience making it burn and turn turbines. However, some people say we have already passed "peak coal", especially with the fact that newer plants burn the crappy, lignite coal as opposed to better grades. At least with biomass, it is fairly renewable.
No solution is perfect, but there are some worse than others.
If you buy a generator, buy one now, have an electrician install either an interlock system on the circuit breaker or a transfer switch. (Interlocks are code safe, and allow you more freedom to choose what circuits you want on the generator, but a manual transfer switch is a lot more idiot-resistant.)
When disasters strike, generators go immediately at the hardware stores, so it can't hurt to at least have a portable one (or two Honda 2000 watt models that are paired) to keep the computers and refrigerator running.
I've read about glitches when one does an update, so I wonder if the Wi-Fi problem would go away if someone backed up their device (would have to be dumped to a computer with iTunes), did an erase all, then followed it up by a DFU restore. This method pretty much ensures that all data stored on the device is erased. Then the device can be restored, apps/music reinstalled, and things back to normal.
This also stems from a general IT lesson I learned. If possible, when it comes to OS upgrading time with major number versions [1], one is best off rebuilding a server from scratch than updating it, due to cruft left behind from the previous OS, and other inconsistencies which might cause issues later on. Sometimes this isn't possible, other times, it is easily done.
[1]: The cautious exception are RPM based Linux distros which are really just stacks of filesets snapshotted and regression tested at a certain point in time. Those, I can just increment the version number, run yum upgrade, and be done with it, since it is more of a large update than a major version upgrade. Even with these, it doesn't hurt to install from scratch since it seems that RPM databases tend to get corrupted over time.
I'd be quite happy for a physical keyboard similar to what was on the Motorola CLIQ/DEXT which would spring open and closed.
Of course, the #1 thing in a phone would be an unlocked bootloader, but next to that would be a physical keyboard and a decent amount of RAM so activities don't have to be reloaded when I switch apps.
Of course, there is the pie in the sky stuff: I'd like two features that were present in the Atrix: The fingerprint scanner [1], and the ability to be dropped in a dock and run a lightweight Linux distribution. This would allow me to do basic stuff when on the road, and if someone stole the docking station, whoop-de-do, as all the data would be on the phone.
Of course, being able to use a phone as a NAS would be nice for critical documents because they could be encrypted with a mechanism similar to how Titanium Backup encrypts backups [2], and syncs them to a remote cloud site. Combined with an archive feature (which allows files to be stored on the remote site and removed from the device), it would provide a fairly usable central place for storing documents in a secure manner [3].
[1]: Fingerprint scanners have their flaws, but for a screen lock, or a means of telling an app that it is OK to do a task (like sign/decrypt a file), it is a decent addition.
[2]: Titanium Backup uses RSA public/private keys. For encrypting backups, it uses a public key. When decrypting, it uses a user-set password to unlock the private key, which unlocks the file's symmetric key.
[3]: Of course, cloud providers can go down or have issues, but there are APIs out there to allow data to be sent to multiple providers at once. That way, if Dropbox dies, the data is still retrievable from Skydrive.
The ironic thing is that optical drives, though boring, have their use. For example, I can pay $10 a month for 100 gigs on a cloud storage, or I can pay for a few Blu-Ray blanks, burn the data, and call it done. From there on out, the cost of storing the data is pretty much $0. To boot, it is very difficult for malware to tamper with media finalized on BD-R media.
Yes, a hard disk is cheap and can store a lot, but for small documents, nothing beats burning to WORM media for long term archiving.
It would be nice if the 100GB BD disks came down in price. Next to a modern LTO drive, it would be very useful for backups.
Long term, until fusion is sustainable for production energy, the ideal would be a coal/gas plant as the starter (nuclear plants require power on the grind to come online after a grid outage), then have the general power be primarily nuclear.
With better batteries and solar, that will do a lot to ease peak consumption. If we can get batteries that are within an order of magnitude of gasoline that can store power overnight, this would significantly ease the load from the power grid.
A lot of Americans can't stand CNN, MSNBC, or Fox, just because both slants have done damage to the country. This is why Al Jazeera seems to have taken a foothold (not to say they are always unbiased, but for stuff they don't have a "dog in the hunt" for, they are better than local sites.)
Thank you for the Novaya Gazeta link. It definitely beats the usual anti-West drivel found on Pravda.
I'd like to find a German news site that has been pretty straight with the US news (as their bias is elsewhere), but forgot the name.
I sort of hope that the CAPTCHA-busting code is just vapor, and it doesn't get released.
If it does come out and get into widespread use, what will likely result are websites likely going another step up the chain and doing more annoying stuff such as requiring access through Facebook, demanding a phone number for SMS authentication (of course, said number ends up getting sold to robodialers), or more intrusive means.
I see some CAPTCHA replacement schemes like counting how many cat butts are facing a person in a row of six photos and inputting the number, but those seem at best a stopgap measure, and block out access to the site to the blind.
E-Books are nice, and yes, I have more than one e-book reader. However, paper books have their place for a few ways:
First, if there is a power issue, paper books are still legible in daylight. If the battery runs out on by e-book reader while I'm camping, either I use an external charger or I'm not reading books until I come back to my vehicle or civilization.
Second, DRM. There is nothing stopping book publishers from denying access to one's title list unless a monthly fee was paid, charging by the page or adding additional fees. Think a lawsuit might help? Nope, that EULA was auto-accepted when the app was ran after the update. Of course, books can disappear from readers, just like 1984 did for a period of time. And if done, there is nobody to stay otherwise.
Third, incompatible formats. Kobo, Scribd, Kindle, iBooks, Google Books, Nook, Sony. The formats might be similar, but the DRM is different. The closest thing to a "rosetta stone" is probably an iPad because it can read all those formats. Of course, one should get their books from one e-book store, but sometimes one place may have books another one doesn't.
Fourth, backups. With DRM-ed copies, it might be a backup and restore will not be an option due to the app phoning home for authorization.
e-books are great, as I can carry one device with thousands of titles on it. However, it won't replace paper books.
Of course, it would be nice for Amazon or the big names to sell the e-book and the paper book at one price. That way, I can go download all the relevant stuff I need, and in a few days, have the paper books for the library bookshelf. Best of both worlds.
If one subscribes, they can use SSL for every page.
As a normal user, it is hard. Once the mail hits the main SMTP relay and heads out, it is in plaintext unless one is running Exchange which has secure connectors and one sets up TLS links with other sites.
It would be nice to have a TLS/SSL mechanism where company E-mail servers would be checked if they had a secure transport port, the key fetched and checked with a CA, and then the mail sent.
However, there are really only three choices for E-mail:
1: Have both users share the same provider so mail is just delivered locally.
2: Use S/MIME. The problem with this method is that few mailers except for Thunderbird, mail.app, and Outlook have S/MIME ability. iOS requires special setup to get S/MIME working, and Android varies on MUA.
3: Best of all, have a PGP/gpg web of trust and an application/app which can easily encrypt/decrypt from the clipboard. This way, the message security is entirely independent of every party in between. However, this is very rarely done. The last time I had a truly meaningful PGP-encrypted conversation (other than "yay, I sent you an encrypted message... this is cool" tripe) was in the 1990s when discussing a very obscure bug on a CC: list, and there was worry that the bug could be an easy target for blackhats.
PGP is a very neglected program. It would be nice to see working security token support so a private key would not have to leave a token to be used. One can buy a SafeNet (formerly Aladdin) eToken and use the commercial version of Symantec's PGP to do this, but the $400-500 total cost can be expensive.
If a company really wanted to set the bar higher for security in general, they would make a dedicated security token that one could copy a private key on, and the token would do the decryption/signing on it, so the key never gets exposed to the computer. Bonus points if this can be implemented in an OS-independant way (perhaps present the USB device as a drive with files that act as devices, so one can input the unlock key by appending to a file, send up the file to be signed by another append, then read from the second file for the signed OpenPGP packet.