Done right, storing passwords on the web can be decently secure, especially if there is some part of the decryption key (be it a public key, a secondary authenticator, or a keyfile) that is not available to the attacker, in combination with the master passphrase.
I'd say the best implementation of this would be a utility that piggybacked on the cloud provider of choice, so one isn't limited to GDrive, Dropbox, Box, Skydrive, iCloud, or others. The utility would ask for permission just for its own directory (if possible), and would store its main DB file, as well as some backups in that directory. That way, the password program author or company doesn't have to maintain a cloud infrastructure.
Hate responding to my own posts, but adding another idea... Each endpoint device has its own private key... so the data that is stored on the backend cloud provider would be conventionally encrypted, but would be unlockable by any key in the access list, similar to a PGP attachment that lists multiple public keys. That way, one can add and remove devices by using their key, and no common file needs to be shared.
I'd probably say KeePass is as secure as things get, since it doesn't use the Web in any way, shape, or form.
What I'd like to see with password apps that use a cloud provider for backend storage, (be it 1Password, mSecure, or so on), would be a keyfile that is manually transferred between devices, and never is put on the cloud backend. This way, if/when the cloud provider is hacked, the password file is not just protected by the passphrase, but by a keyfile that an attacker would have to compromise a physical device to get.
There is also the fact that some failure modes will take both sides down. I've seen disk controllers overwrite shared LUNs, hosing both sides of the HA cluster (which is why I try to at least quiesce the DB or application so RTO/RPO in case of that failure mode is acceptable.)
HA can also be located on different points on the stack. For example, an Oracle DB server. It can be clustered on the Oracle application level (active/active or active/passive), or it can be sitting in a VMWare instance, clustered using vSphere HA, where the DB itself thinks it is a single instance, but in reality, it is sitting active/passive on two boxes.
Even if the backup stays up, failing back can be an issue. I've seen HA systems where it will happily drop to the backup node... but failing back to the primary can require a lot of downtime. For active/active setups, it can require a performance hit for resyncing.
Even on fairly simple things (yum updates from mirrors, AIX PTFs, Solaris patches, or Windows patches released from WSUS), I like babysitting the job.
There is a lot that can happen. A backup can fail, then the update can fail. Something relatively simple can go ka-boom. A kernel update doesn't "take" and the box falls back to the wrong kernel.
Even something stupid as having a bootable CD in the drive and the server deciding it wants to run the OS from that rather than from the FCA or onboard drives. Being physically there so one can rectify that mistake is a lot easier when planned as opposed to having to get up and drive to work at a moment's notice... and by that time, someone else likely has discovered it and is sending scathing E-mails to you, CC:5 tiers of management.
For gaming, things have been "good enough" going on almost a decade.
For true studio work, I've not checked recently, but I think M Audio has a PCI interface card for a few C-Notes. I think things have shifted to AI (audio interface) cards anyway, as opposed to discrete sound cards like SoundBlaster successors.
However, I wouldn't say SBs are pointless... for retro gaming, some games have better sounding music coming from the "primitive" FM synthesis at that time.
Worst case, replace the keyboard with something like the Optimus Maximus keyboard with the keys changing characters every time a password is asked.
What really is needed are what we had before everything got linked to the Internet. We need separate networks. Examples of this would be SIPRnet, NIPRNet, and GRU's equivalents.
Yes, this network can be hacked, but it adds an additional barrier -- one has to hack the network (which likely will be designed with this in mind from the ground up), forge access as a trusted machine (tough, due to machines having their own public keys), then try to attack the targets themselves.
I wonder why this isn't done. I would think a "BIPRNet" would be obvious since it gets sensitive traffic and things like wide-open SCADA systems completely off the Internet, but still allows remote access and management.
Another problem with electronic voting is the complexity. Paper ballots are simple. A mark or a hole punched through some wood pulp.
With electronic voting, there are so many vulnerabilities. From voting machines that will change one's vote to Kodos before it even gets registered on the machine, to votes being switched in transit, there are no real ways to actually protect that info from a determined, well-heeled intruder. Paper trails are still forgable, but we have had thousands of years dealing with paper, and it requires a definite physical presence to alter results.
This isn't to say it cannot be done, but it would require a cryptographic infrastructure from a dedicated smart card that the voter has, to cryptography at every link (so votes added/subtracted from a county would be detected)... and all this assuming the hardware maker didn't add their backdoors.
Maybe NYC is right... time to go back to mechanical voting machines or at least pen and pencil.
Supercap technology is one of those that addresses it. Yes, it takes a lot of amperes, but instead of feeding a battery a constant voltage/amperage and nursing it along with its chemical reactions, while watching its SoC and temperature level, a supercap can be charged quite quickly, since the charge is a physical process (electrons stashed at one end of the dielectric.)
Of course, the problem is that batteries have such a relatively low energy density per volume. Get battery energy within an order of magnitude of diesel or gasoline, and this revolutionizes things. Ineffecient diesel and gasoline engines that have a sizable chunk of their energy spat out the tailpipe now get replaced by vastly more efficient electric motors. Noxious fuels get replaced by whatever electrical source is usable in a region, be it geothermal, wind, solar, or others. Petroleum can be used for its most important use -- making plastics, rather than just turned into carbon dioxide.
I have a machine of a similar vintage running an age-old copy of RHEL. I keep it, but the chances of me firing it up are slim to none, because I can fire up VMWare Workstation with an older OS release. Plus, even if the hardware is rock stable, it uses more energy than a modern computer and OS. Running a VM from a SATA SSD consumes a lot less power than an older 3.5" IDE HDD which might have at most 128 or so gigs.
It is fun to fire up old hardware, but other than having the right stuff to play a game (DOSBox is good, but some older MS-DOS games won't work correctly unless they are on bare metal, and don't sound "right" unless they are played on an antediluvian FM-synthesis sound card), there isn't much of a point to it.
Of course, said code module can change, so even if your deps are right now... it might be that the black box code library that does some essential functions might not work the same after it gets updated. In some ways, this is easy to find (if you do a library upgrade and things break, with no other changes.) However, if there are other confounding variables, this might be a fairly difficult task.
When in CS, I had a prof that had one rule that for release (not beta/alpha/dev) code, if the code had even a single warning, it was unshippable unless there was an extremely good reason (which would be part of the README) of why it happened. Yes, this was a PITA, but he was trying to teach something that seems to have been lost.
It verges on astounding. I've read for years that Germany has ceded sovereign control of its land to Russia for natural gas, and that German citizens would freeze by the tens of thousands if Putin turned off the taps. However, Germany is still going strong and doesn't have brownouts or rolling blackouts as naysayers have been saying would be a certainty.
This doesn't mean nuclear power is bad. The ideal would be to work on the latest generation plants, maybe even thorium plants. However, due to NIMBY syndrome and fearmongering, any advances in nuclear power are swept under the rug, while anything that might happen bad with 50-60 year old plants that (by moratoriums in place) cannot be upgraded/replaced will be blasted on the front pages of any periodical or website.
I do agree about storage. I'm hoping Germany is a frontline player when it comes to higher energy density per volume and weight when it comes to batteries. If a battery is made that even comes within an order of magnitude of gasoline or diesel's energy by volume, this would fundamentally change transportation as we know it.
I would love a spiritual successor to NWN, or a NWN-like RPG that one can fairly easily build player-written modules and other content, with characters that can persist between modules.
This was the nice thing about NWN1 and NWN2. Both had long tails, and had not just single player campaigns, but player-written content that was just as good if not better, as well as persistent worlds which has the long-lost roleplay feel of MUDs gone by.
So far, I've dropped a little bit of cash on a failed Kickstarter, but there just isn't anything in this genre [1]. I would love a spiritual successor to NWN.
[1]: I'm not meaning F2P MMOs like Neverwinter, but a game that focuses on the RPG aspect as well as the player creation tools, as opposed to just buying the latest DLC.
Expanding on that, the US Navy (and I'm sure other nation's ship fleets) have excellent nuclear reactors. Even with current technology, thermal depolymerization wouldn't be that hard to do, especially near the Pacific Gyre with the large amount of floating waste available there. Then said ship either stays put, transferring the recovered crude to another vessel, or returns to harbor with useful resources.
I do a similar version of this. I have a few document escrow services and a couple friends that have pieces of my master keys. It is a system that requires "x out of y" pieces to re-assemble the keys, so if one person is out, the key can still be recovered.
I have a couple symmetric keys and a private key. That way, if RSA or ECC get broken, the core data is still protected until all the escrow places plop down their segment of the keys.
To be safe, the key part and the SSSS (Shamir's Secret Sharing Scheme) utility is not just stored on an archival grade DVD and a USB flash drive, but also UUencoded and printed out (with a QuickPAR recovery record just in case.)
Some Android devs are trying to do their best to work around it. It requires root, but I highly recommend the XPrivacy tool, which will allow you to restrict what apps can actually contact. I also like using a DroidWall successor as a thing of last resort, especially with apps that are bandwidth hungry, so they get forced to Wi-Fi only and not on the cellular network.
LBE Privacy Guard used to be a good tool, but the successor has yet to be officially translated to English yet.
The bad thing is that apps from the Play Store are all or nothing. The good thing is that the people at xda-developers and other sites have spent many man-hours to rectify that.
We are getting some advances in that direction (where people/organizations want to cover a large surface area cheaply, so they get some energy coming in, even though it may not be as much as panels that are more expensive, but are made for getting as many watts per square centimeter as possible.
Flexible panels come to mind. Similar with window film that might get 5%, but covers a large expanse on a building. Flexible panels still have a ways to go, but they are getting there. For RVs, they are a lot easier to mount than a rigid PV panel (no holes need to be drilled for the panel's mountings, as the flexible panels are taped into place with double-sided adhesive.)
What I'd like to see are not just solar roof tiles, but the corrugated fiberglass or polycarbonate panels that are used for carports have some sort of solar capability. It won't be near as much as having dedicated panels, but it will bring in some electricity on otherwise wasted space.
One type that is used for limited space, engineered to get as many watts from each square centimeter as possible, even if it is more costly. RV-ers come to mind, because for most rigs, space is at a premium.
The second type is to obtain a decent amount of watts, but be cheaper, for larger areas such as a roof. Here, price per watt is more important.
In both cases, reliability is very important and not to be overlooked. Panels don't take much to maintain once in place, but are expensive to install and replace if something breaks.
I have found that the cost and quality of solar deployments can vary tremendously. For example, I can buy panels at 75 cents per watt. However, if I go for a kit, that cost jumps up significantly. If I let a "solar installer" do it, that might bump costs up a good amount too.
I have found that solar can be used in increments, so a starting investment can be relatively small. For example, having a 15 amp circuit or two in a house that runs off of batteries is a good way to keep the parasitic devices that draw a 10-20 watts, but draw that 24/7, off the electric bill. It doesn't sound like much, but the watts used by the little devices (battery chargers for example) can add up. If one buys a high quality pure sine wave inverter, it also prolongs the life of devices on that line as well because they don't eat power transients or surges/sags that might come from the utility company. In fact, one's computer might be able to be put on one of these circuits, so a UPS wouldn't be needed, barring a direct lightning strike.
As part of a new house, I see solar as a "why not" as opposed to a "why bother" item. With a PV cut switch so that a fire causes the panels to automatically disconnect, safety issues are mitigated. Plus, with hybrid grid systems, it can be used for feeding the grid, providing UPS power, or both.
I think the key is how the solar install is packaged and sold. There is a wide price range and wide quality range [1]. I'm hoping as companies get more experience with this that install quality becomes more consistent and improves overall.
[1]: One thing often neglected or skimped on in solar installs is wire thickness. Too skinny wires between the charge controller and batteries, and the batteries will never be completely charged.
Spam has shifted gears. Before, it was mainly advertising and "chop your dollar" scams. Now, I mainly see phishing attempts either to get people to give up data or to go to a site that would attempt a large number of exploits (even trying to offer bogus "securityscan.apk" files on Android.) This isn't surprising because getting a victim's computer on a botnet is far more lucrative for a spammer than actually getting them to buy some pills or fall for yet another 419 scam.
Watt/hours do add up. Fridges, water heaters, and HVAC systems do slurp up electricity, but don't run all the time. However, what can be a factor in the bill are devices that have 5-20 watts... but run 24/7.
For things like that, it may not hurt to drop in a small solar charging system to put those parasitic devices on their own circuit. It wouldn't be cheap (a couple thousand to do the job right [1]), but it would move all the parasitic devices (whose energy use does add up over time) off the mains power. As another benefit, those devices get very clean power [2], and would still function if the mains power goes off. How long until a system like this pays for itself? If mains power is dirty, it might pay for itself fairly quickly since power bricks and devices would need to be replaced less often.
[1]: Doing it right would mean a pure sine wave inverter, a set of decent AGM batteries, a MPPT charge controller and good panels. It also would mean having a charge controller that attaches to the mains power, so if the batteries get too low and the solar power isn't charging, the batteries still will get charged, keeping the appliances on that circuit still operable. The cost of all this is about the same as a true online UPS.
[2]: Assuming a good quality PSW inverter. A MSW inverter is cheap, but will barbecue components in no time.
The power supply on one of my servers is rated at 800 watts. Does it mean the machine uses 800 watts 24/7? Definitely not. In fact, I should hook it up to a Kill-O-Watt meter, as I'm not sure if it even would get past 100-200 watts, other than the inrush current from the hard disk array spindles starting.
Refrigerators can be surprisingly thrifty. In fact, when RV-ing, a dorm fridge can be run from a battery bank, inverter, and a decent (250 watts) solar panel setup. Yes, the compressor does take energy... but it only runs a fraction of the time, so if it takes 350 W/h to run at a 100% duty cycle, it might only use 75-100 W/h realistically.
Electric water heaters are also decently efficient. They take a good chunk of energy to get the water to the set temperature... but once the water is heated, they tend not to use that much over time due to the decent insulation used.
Done right, storing passwords on the web can be decently secure, especially if there is some part of the decryption key (be it a public key, a secondary authenticator, or a keyfile) that is not available to the attacker, in combination with the master passphrase.
I'd say the best implementation of this would be a utility that piggybacked on the cloud provider of choice, so one isn't limited to GDrive, Dropbox, Box, Skydrive, iCloud, or others. The utility would ask for permission just for its own directory (if possible), and would store its main DB file, as well as some backups in that directory. That way, the password program author or company doesn't have to maintain a cloud infrastructure.
Hate responding to my own posts, but adding another idea... Each endpoint device has its own private key... so the data that is stored on the backend cloud provider would be conventionally encrypted, but would be unlockable by any key in the access list, similar to a PGP attachment that lists multiple public keys. That way, one can add and remove devices by using their key, and no common file needs to be shared.
I'd probably say KeePass is as secure as things get, since it doesn't use the Web in any way, shape, or form.
What I'd like to see with password apps that use a cloud provider for backend storage, (be it 1Password, mSecure, or so on), would be a keyfile that is manually transferred between devices, and never is put on the cloud backend. This way, if/when the cloud provider is hacked, the password file is not just protected by the passphrase, but by a keyfile that an attacker would have to compromise a physical device to get.
There is also the fact that some failure modes will take both sides down. I've seen disk controllers overwrite shared LUNs, hosing both sides of the HA cluster (which is why I try to at least quiesce the DB or application so RTO/RPO in case of that failure mode is acceptable.)
HA can also be located on different points on the stack. For example, an Oracle DB server. It can be clustered on the Oracle application level (active/active or active/passive), or it can be sitting in a VMWare instance, clustered using vSphere HA, where the DB itself thinks it is a single instance, but in reality, it is sitting active/passive on two boxes.
Even if the backup stays up, failing back can be an issue. I've seen HA systems where it will happily drop to the backup node... but failing back to the primary can require a lot of downtime. For active/active setups, it can require a performance hit for resyncing.
Even on fairly simple things (yum updates from mirrors, AIX PTFs, Solaris patches, or Windows patches released from WSUS), I like babysitting the job.
There is a lot that can happen. A backup can fail, then the update can fail. Something relatively simple can go ka-boom. A kernel update doesn't "take" and the box falls back to the wrong kernel.
Even something stupid as having a bootable CD in the drive and the server deciding it wants to run the OS from that rather than from the FCA or onboard drives. Being physically there so one can rectify that mistake is a lot easier when planned as opposed to having to get up and drive to work at a moment's notice... and by that time, someone else likely has discovered it and is sending scathing E-mails to you, CC:5 tiers of management.
For gaming, things have been "good enough" going on almost a decade.
For true studio work, I've not checked recently, but I think M Audio has a PCI interface card for a few C-Notes. I think things have shifted to AI (audio interface) cards anyway, as opposed to discrete sound cards like SoundBlaster successors.
However, I wouldn't say SBs are pointless... for retro gaming, some games have better sounding music coming from the "primitive" FM synthesis at that time.
Worst case, replace the keyboard with something like the Optimus Maximus keyboard with the keys changing characters every time a password is asked.
What really is needed are what we had before everything got linked to the Internet. We need separate networks. Examples of this would be SIPRnet, NIPRNet, and GRU's equivalents.
Yes, this network can be hacked, but it adds an additional barrier -- one has to hack the network (which likely will be designed with this in mind from the ground up), forge access as a trusted machine (tough, due to machines having their own public keys), then try to attack the targets themselves.
I wonder why this isn't done. I would think a "BIPRNet" would be obvious since it gets sensitive traffic and things like wide-open SCADA systems completely off the Internet, but still allows remote access and management.
Another problem with electronic voting is the complexity. Paper ballots are simple. A mark or a hole punched through some wood pulp.
With electronic voting, there are so many vulnerabilities. From voting machines that will change one's vote to Kodos before it even gets registered on the machine, to votes being switched in transit, there are no real ways to actually protect that info from a determined, well-heeled intruder. Paper trails are still forgable, but we have had thousands of years dealing with paper, and it requires a definite physical presence to alter results.
This isn't to say it cannot be done, but it would require a cryptographic infrastructure from a dedicated smart card that the voter has, to cryptography at every link (so votes added/subtracted from a county would be detected)... and all this assuming the hardware maker didn't add their backdoors.
Maybe NYC is right... time to go back to mechanical voting machines or at least pen and pencil.
Supercap technology is one of those that addresses it. Yes, it takes a lot of amperes, but instead of feeding a battery a constant voltage/amperage and nursing it along with its chemical reactions, while watching its SoC and temperature level, a supercap can be charged quite quickly, since the charge is a physical process (electrons stashed at one end of the dielectric.)
Of course, the problem is that batteries have such a relatively low energy density per volume. Get battery energy within an order of magnitude of diesel or gasoline, and this revolutionizes things. Ineffecient diesel and gasoline engines that have a sizable chunk of their energy spat out the tailpipe now get replaced by vastly more efficient electric motors. Noxious fuels get replaced by whatever electrical source is usable in a region, be it geothermal, wind, solar, or others. Petroleum can be used for its most important use -- making plastics, rather than just turned into carbon dioxide.
I have a machine of a similar vintage running an age-old copy of RHEL. I keep it, but the chances of me firing it up are slim to none, because I can fire up VMWare Workstation with an older OS release. Plus, even if the hardware is rock stable, it uses more energy than a modern computer and OS. Running a VM from a SATA SSD consumes a lot less power than an older 3.5" IDE HDD which might have at most 128 or so gigs.
It is fun to fire up old hardware, but other than having the right stuff to play a game (DOSBox is good, but some older MS-DOS games won't work correctly unless they are on bare metal, and don't sound "right" unless they are played on an antediluvian FM-synthesis sound card), there isn't much of a point to it.
Of course, said code module can change, so even if your deps are right now... it might be that the black box code library that does some essential functions might not work the same after it gets updated. In some ways, this is easy to find (if you do a library upgrade and things break, with no other changes.) However, if there are other confounding variables, this might be a fairly difficult task.
When in CS, I had a prof that had one rule that for release (not beta/alpha/dev) code, if the code had even a single warning, it was unshippable unless there was an extremely good reason (which would be part of the README) of why it happened. Yes, this was a PITA, but he was trying to teach something that seems to have been lost.
It verges on astounding. I've read for years that Germany has ceded sovereign control of its land to Russia for natural gas, and that German citizens would freeze by the tens of thousands if Putin turned off the taps. However, Germany is still going strong and doesn't have brownouts or rolling blackouts as naysayers have been saying would be a certainty.
This doesn't mean nuclear power is bad. The ideal would be to work on the latest generation plants, maybe even thorium plants. However, due to NIMBY syndrome and fearmongering, any advances in nuclear power are swept under the rug, while anything that might happen bad with 50-60 year old plants that (by moratoriums in place) cannot be upgraded/replaced will be blasted on the front pages of any periodical or website.
I do agree about storage. I'm hoping Germany is a frontline player when it comes to higher energy density per volume and weight when it comes to batteries. If a battery is made that even comes within an order of magnitude of gasoline or diesel's energy by volume, this would fundamentally change transportation as we know it.
I would love a spiritual successor to NWN, or a NWN-like RPG that one can fairly easily build player-written modules and other content, with characters that can persist between modules.
This was the nice thing about NWN1 and NWN2. Both had long tails, and had not just single player campaigns, but player-written content that was just as good if not better, as well as persistent worlds which has the long-lost roleplay feel of MUDs gone by.
So far, I've dropped a little bit of cash on a failed Kickstarter, but there just isn't anything in this genre [1]. I would love a spiritual successor to NWN.
[1]: I'm not meaning F2P MMOs like Neverwinter, but a game that focuses on the RPG aspect as well as the player creation tools, as opposed to just buying the latest DLC.
I feel stupid by asking this, but what would be a decent off-the-shelf permissions/licensing manager suitable for a small business?
Expanding on that, the US Navy (and I'm sure other nation's ship fleets) have excellent nuclear reactors. Even with current technology, thermal depolymerization wouldn't be that hard to do, especially near the Pacific Gyre with the large amount of floating waste available there. Then said ship either stays put, transferring the recovered crude to another vessel, or returns to harbor with useful resources.
I do a similar version of this. I have a few document escrow services and a couple friends that have pieces of my master keys. It is a system that requires "x out of y" pieces to re-assemble the keys, so if one person is out, the key can still be recovered.
I have a couple symmetric keys and a private key. That way, if RSA or ECC get broken, the core data is still protected until all the escrow places plop down their segment of the keys.
To be safe, the key part and the SSSS (Shamir's Secret Sharing Scheme) utility is not just stored on an archival grade DVD and a USB flash drive, but also UUencoded and printed out (with a QuickPAR recovery record just in case.)
Some Android devs are trying to do their best to work around it. It requires root, but I highly recommend the XPrivacy tool, which will allow you to restrict what apps can actually contact. I also like using a DroidWall successor as a thing of last resort, especially with apps that are bandwidth hungry, so they get forced to Wi-Fi only and not on the cellular network.
LBE Privacy Guard used to be a good tool, but the successor has yet to be officially translated to English yet.
The bad thing is that apps from the Play Store are all or nothing. The good thing is that the people at xda-developers and other sites have spent many man-hours to rectify that.
We are getting some advances in that direction (where people/organizations want to cover a large surface area cheaply, so they get some energy coming in, even though it may not be as much as panels that are more expensive, but are made for getting as many watts per square centimeter as possible.
Flexible panels come to mind. Similar with window film that might get 5%, but covers a large expanse on a building. Flexible panels still have a ways to go, but they are getting there. For RVs, they are a lot easier to mount than a rigid PV panel (no holes need to be drilled for the panel's mountings, as the flexible panels are taped into place with double-sided adhesive.)
What I'd like to see are not just solar roof tiles, but the corrugated fiberglass or polycarbonate panels that are used for carports have some sort of solar capability. It won't be near as much as having dedicated panels, but it will bring in some electricity on otherwise wasted space.
I see two types of panels being sold:
One type that is used for limited space, engineered to get as many watts from each square centimeter as possible, even if it is more costly. RV-ers come to mind, because for most rigs, space is at a premium.
The second type is to obtain a decent amount of watts, but be cheaper, for larger areas such as a roof. Here, price per watt is more important.
In both cases, reliability is very important and not to be overlooked. Panels don't take much to maintain once in place, but are expensive to install and replace if something breaks.
I have found that the cost and quality of solar deployments can vary tremendously. For example, I can buy panels at 75 cents per watt. However, if I go for a kit, that cost jumps up significantly. If I let a "solar installer" do it, that might bump costs up a good amount too.
I have found that solar can be used in increments, so a starting investment can be relatively small. For example, having a 15 amp circuit or two in a house that runs off of batteries is a good way to keep the parasitic devices that draw a 10-20 watts, but draw that 24/7, off the electric bill. It doesn't sound like much, but the watts used by the little devices (battery chargers for example) can add up. If one buys a high quality pure sine wave inverter, it also prolongs the life of devices on that line as well because they don't eat power transients or surges/sags that might come from the utility company. In fact, one's computer might be able to be put on one of these circuits, so a UPS wouldn't be needed, barring a direct lightning strike.
As part of a new house, I see solar as a "why not" as opposed to a "why bother" item. With a PV cut switch so that a fire causes the panels to automatically disconnect, safety issues are mitigated. Plus, with hybrid grid systems, it can be used for feeding the grid, providing UPS power, or both.
I think the key is how the solar install is packaged and sold. There is a wide price range and wide quality range [1]. I'm hoping as companies get more experience with this that install quality becomes more consistent and improves overall.
[1]: One thing often neglected or skimped on in solar installs is wire thickness. Too skinny wires between the charge controller and batteries, and the batteries will never be completely charged.
Spam has shifted gears. Before, it was mainly advertising and "chop your dollar" scams. Now, I mainly see phishing attempts either to get people to give up data or to go to a site that would attempt a large number of exploits (even trying to offer bogus "securityscan.apk" files on Android.) This isn't surprising because getting a victim's computer on a botnet is far more lucrative for a spammer than actually getting them to buy some pills or fall for yet another 419 scam.
Watt/hours do add up. Fridges, water heaters, and HVAC systems do slurp up electricity, but don't run all the time. However, what can be a factor in the bill are devices that have 5-20 watts... but run 24/7.
For things like that, it may not hurt to drop in a small solar charging system to put those parasitic devices on their own circuit. It wouldn't be cheap (a couple thousand to do the job right [1]), but it would move all the parasitic devices (whose energy use does add up over time) off the mains power. As another benefit, those devices get very clean power [2], and would still function if the mains power goes off. How long until a system like this pays for itself? If mains power is dirty, it might pay for itself fairly quickly since power bricks and devices would need to be replaced less often.
[1]: Doing it right would mean a pure sine wave inverter, a set of decent AGM batteries, a MPPT charge controller and good panels. It also would mean having a charge controller that attaches to the mains power, so if the batteries get too low and the solar power isn't charging, the batteries still will get charged, keeping the appliances on that circuit still operable. The cost of all this is about the same as a true online UPS.
[2]: Assuming a good quality PSW inverter. A MSW inverter is cheap, but will barbecue components in no time.
The power supply on one of my servers is rated at 800 watts. Does it mean the machine uses 800 watts 24/7? Definitely not. In fact, I should hook it up to a Kill-O-Watt meter, as I'm not sure if it even would get past 100-200 watts, other than the inrush current from the hard disk array spindles starting.
Refrigerators can be surprisingly thrifty. In fact, when RV-ing, a dorm fridge can be run from a battery bank, inverter, and a decent (250 watts) solar panel setup. Yes, the compressor does take energy... but it only runs a fraction of the time, so if it takes 350 W/h to run at a 100% duty cycle, it might only use 75-100 W/h realistically.
Electric water heaters are also decently efficient. They take a good chunk of energy to get the water to the set temperature... but once the water is heated, they tend not to use that much over time due to the decent insulation used.