The previous poster was referring to a motor-generator system, where turbine engines are used to generate electricity to power electric motors that drive the propellers. The APUs you confused them with are "Auxiliary" Power Units, and have never been used to make the plane move.
What I wonder about in such a system is the cost of converting the power to electricity before creating thrust. You have to carry around heavy coils of wire in each motor and generator, whereas the turbofan only has to carry a drive shaft (or transmission) between the turbine and the fan. Plus, electric conversion is not perfectly efficient, some losses are introduced. I have to assume the engineers have minimized most of those impacts. On the other hand, decoupling the motors from the generators would allow for extra margins of safety: a flameout of one turbine would result in an overall loss of power, but it would not necessarily be an unbalanced loss of thrust.
Then what the f**k are these devices doing even directly connected to the public Internet?
I'm not aware of any such devices being directly connected to the public internet. But, they're on a hospital or pharmacy's internal network, and those networks almost always have direct access to the Internet.
Hospital network admins have a thankless job. They have to secure their networks against all this kind of crap, but every time they lock down some terrible gaping security hole, the doctors scream "I need this Ultrasound machine to send PDFs to my office! You can't disable the FTP function or close the FTP ports on the firewall just because you claim there's a security flaw! I need them sent NOW!!"
With luck, the admins can do some simple things, like segregate the WiFi hotspot traffic from the internal hospital traffic. They can run IDP appliances, and sometimes they can configure switches to detect rogue MAC addresses. But when it comes to the devices that the doctors interact with, no excuses are acceptable.
Sure, you need to audit the systems (as the anesthesiologist pointed out above, he believes he could siphon 10% of his prescriptions without notice.) But the human side isn't the security issue here. Any automated dispensing system is going to need auditing of the inventory, regardless of how "digitally secure" the appliance is, because it's full of really valuable drugs.
The real problems at stake are access when it's needed; and integrity that the drug dispensed is the drug prescribed in the correct quantities and dosages.
An ordinary hacker could infect the Pyxis system with ransomware just by chance, because the dispenser happened to be on the same subnet as the nurse who opened the infected Word attachment. That's a classic denial of service, and in the wrong circumstances could delay access to lifesaving medicine.
Worse, a dedicated hacker could get malware on there to try to cause havoc; perhaps the patient who was prescribed 2 250mg capsules of Tylenol actually received 2 500mg capsules of Oxycontin. Sure, the nurse scans the patient's bracelet before administering the dose, but the system reports that it dispensed exactly what was prescribed; so nobody catches the error until it's too late.
There are plenty of Hollywood scenarios that could play out here; watch the (terrible) movie The Net to see one happen to Dennis Miller's character.
Sure there's a way. The owner of the phone could voluntarily use an Apple-provided key escrow service. If you buy an iPhone for your son, register a recovery key with Apple. If you buy iPhones for your employees, keep a recovery key for your company. If you buy an iPhone for yourself, and don't want a recovery key, don't register one; but don't cry to Apple if you lose your passcode.
If the police have a warrant, they can demand the escrowed password, if one exists, because it's no longer 'personal' once it's shared. That's part of the conditions of using an escrow service.
Does that make the escrow service a giant target for hackers and the NSA? Sure. Want to avoid that risk? Don't escrow your password. Your choice.
Someone signed up for Facebook is surprised that Facebook collects and sells their personal data? Really?
LMFTFY: Someone who bought a virtual reality device is surprised to find that Facebook is collecting an selling their personal data. Really.
You didn't read even the first line of the summary: "It turns out when you install the software to run Facebook's Oculus Rift" [emphasis mine]. It's a Facebook product. If I buy a Honeywell thermostat with WiFi that provides thermostat access via the cloud, I would expect it to be in frequent contact with Honeywell's servers. Similarly, I would have every expectation that a Facebook VR set would contact Facebook's servers.
The real questions anyone should have are "what data do they collect, how do they use it, who do they share it with, and how long do they store it?" Given that it's Facebook, I'm guessing the answers are: "every single byte; to build a better model of their customers to better market to them, and to match people with their personal network; they share it with everyone, warrant or not; and forever".
The credit card sector figured out how to incorporate patching into their requirements - not applying regular patches means no PCI certification. The FDA has to climb into this millennium and start requiring the ongoing patching of medical systems as well. And that means everything from nurse's station PCs to ultrasound units to drug pumps.
This is how I see it (roughly estimating the numbers):
A machine with an FDA-approved configuration performs safely 99.99% or more of the time. FDA approval is needed for any change to a machine, including patches. Non-certified patches take a machine out of compliance. FDA approval for testing a patched configuration takes lots of money, which is negative incentive on the manufacturer to release frequent patches. FDA approval for testing a patched configuration takes a long time. A tested machine is vulnerable to all exploits discovered since the creation time of the tested configuration. Loss of availability is less risky to patient health than incorrect or erratic functioning, which is less risky than deliberately harmful functioning. A bad patch will most likely cause loss of availability instead of incorrect functioning; and will never cause deliberate harm. Malware may cause prolonged loss of availability, incorrect or erratic functioning, or even deliberately harmful functioning.
I conclude: A machine with an FDA-approved configuration is vulnerable to more exploits than a recently patched machine. A machine with patches that take it out of FDA approval will perform safely 99.9% of the time, with the delta being primarily loss of availability. A machine infested with malware performs safely anywhere from 0% - 95% of the time, with the possibility of deliberately created patient harm. Therefore, the current FDA approval process is exposing patients to more risk than patching.
The FDA should therefore immediately require the ongoing patching of operating systems controlling medical devices.
They could do what cellular radios do to increase sharing: cut transmit power until both radios agree the message is acceptably low but still reliably receivable. Then, when you need to increase the density of transmitters, you do so by distributing more access points. It also helps conserve transmit power, which is good for battery life.
And if they don't think CSMA/CD is effective enough, once the density of collisions is too high, they could let the access points switch to a time slice mode. They could be either self clocking, or timed on a separate shared control frequency.
Those were two data points taken on a very, very large rock. Nobody knew for sure if some ancient craters hadn't been filled by moon dust, and if the astronauts weren't about to land in a giant trap of quicksand. At least that's how the news of the day covered it.
I was a kid then, so I don't know if they were just speculating to add to the drama. Knowing what I know about NASA today, I think they were probably much more confident than the news media expressed, but were cautious enough that they wouldn't have provided a guarantee.
Re:People say "custom-made" like it's a bad thing
on
Why BART Is Falling Apart
·
· Score: 3, Interesting
Asking that question today doesn't tell us much, because the answer is now obvious: "no, it's very expensive". Instead, let's ask "Back in 1968, when BART was being designed, what were the expected benefits of using a non-standard gauge track?" Maybe it allowed the designers to consider higher speed curves, or better platform designs.
Maybe the rail vendor was trying to create a new standard for mass transit rail systems, and gave them a discount for using an over-sized gauge. Maybe the vendor was completely sleazy, and was trying to create a vendor-lock-in system where only they would be able to sell spare parts. Maybe the politicians of the day were corrupt and took kickbacks to look the other way?
Regardless, there were probably a bunch of engineers shouting "don't buy non-standard gauge rolling stock!", and BART happened anyway.
Except even that is too much. Allowing a macro to modify an external file is chock full of fail. If the restriction is limited to "preventing execution", then attackers will just write a macro to modify a file type that embeds malware when it's viewed. Imagine a Word document containing a macro writing a.PDF document, and in that PDF it has the malware to infect the machine. The macro has a large, friendly button that says "Click here to produce a PDF version to share with your friends", which is irriyou then send around. Same result - cryptolocker for everyone!
Even allowing macro-infested documents to read external data sources of any kind (files) is risky, because the macro could still be capable of grabbing a copy of SekritPasswords.docx and shipping it to a server in Elbonia.
Would this kind of security break stuff? Some. In the past I've written a macro that parsed a bunch of log files, analyzed the contents, and produced the results in a chart in Excel. But as long as I'm not emailing it or downloading it from the internet, the macro would keep working.
Laugh if you want, but I really do have two "clouds" controlled by my smart house. They're ultrasonic mist emitters that fill our orchid-growing cabinets with fog, three times a day. It keeps the humidity inside the glass cases above 95%, which is ideal for some of the equatorial cloud-forest species.
And yes, the electrical plug is kept safely outside of the cabinets. Condensing humidity is a very bad environment for electrical appliances.
Sorry, I certainly wasn't trying to be one of the "deregulation" crowd. I was looking at the business pressures to avoid the cost of including the software in the testing, and then considered the loopholes in the testing regulations that permitted the company to skimp on testing.
I was trying to conclude that the regulatory testing requirements were inadequate because they didn't require testing of the whole device, thus blaming the regulators for allowing those loopholes to exist. That doesn't mean that all regulations are bad, it means that in this case the regulators failed to do an adequate job of regulating.
Yeah, I looked at OpenHAB for a while, but their grandly named "OpenHAB Designer" turned out to be nothing more a copy of Eclipse running a text editor to modify the necessary half-dozen configuration files and check them for syntax errors. It is definitely not ready for an advanced installation professional, let alone the average homeowner.
I've had great luck so far with Vera (getvera.com). It can use the cloud if you let it, but everything is configured and run locally. Configuration is not quite plugThe only reason for the cloud is secure remote access, as their API is unsecured and I wouldn't expose it to the web. The best thing about Vera is the very active community; they have developed literally hundreds of various applications that support all kinds of external devices. Some devices are locally accessed (OpenSprinkler), others reach out to web services to allow integration with a device that doesn't provide a local interface (Honeywell thermostats, for example.) All Vera's plug-in modules are defined in XML and written in lua, and you can run and test everything locally, so there are no giant hurdles to development.
The bulk of my home runs on Z-Wave. I've had a lot of disappointing results, but once you finally discover and get rid of the troublesome devices from your Z-Wave network, things can improve. Essentially it's become one big experiment where I'm testing its ease-of-use on friends and family. I've learned a lot, I've bought a lot of crap, and I'm getting better at recognizing the stinkers.
I wonder if it's a variant of the CRIME attack, where the attacker iteratively observes the success or failure of compression based on fuzzing the inputs, tail first. But those attacks just recover the encrypted data, and don't reveal anything about the key. Don't know yet -- maybe the article is just poorly written, and they aren't actually decrypting the photos, they're just recovering them.
Spoofing the Apple servers is plausible if the iMessage app isn't using pinned certificates. That would be really lame, because they've learned that lesson before on their update servers, back when all the jailbreakers were intercepting the updates.
The real problem with the IoT is that everyone and their brother is trying to be the One True Provider of All Home Automation, and they want to do it in the cloud so they can charge you for integrating with everyone else's clouds. Nest has the whole Nest-Certified thing, running in the cloud. Samsung has the Samsung Smart Home, running your washers, dryers, and air conditioners in their cloud. AssureLink will happily run your garage door openers in their cloud. Honeywell has their thermostat system, in their cloud. Rheem has their EcoNet for running hot water heaters, in their cloud. LG has a cloud service for their TVs. Schlage has a cloud for running door locks. D-Link has a cloud for viewing their security cameras. Fitbit cloud-enables your health data. Philips' cloud runs your Hue lights. And so on.
Cloud solves some thorny problems. It enables easier configuration of the home user's environment by removing most of the barriers, which is critical to commercial success. Ordinary people don't know they need to poke a hole in their firewalls, and they also know they don't want to know all those technical details. But they still want to remotely access their IoThings from their iPhones. Having the IoThings phone home to the cloud means there's a central point to discover and communicate with them, making the consumer's installation woes less painful - ease of use is critical to driving sales. And the cloud can back up those configurations, allowing you to replace your old device 1.0 with new device 2.0, all without pain.
Clouds can also improve end user security - from a certain kind of threat. If your home device is connecting to the cloud and never listening for input on its own, its attack surface is much smaller than if it has opened a port on your firewall. And when your home device needs a security patch, the cloud can push it. Obviously, that means your home devices place their trust in the cloud to be secure, which is the point of TFA.
But the main problem cloud solves is that clouds provide an ongoing "service" for which the device provider can charge $9.99/month. And it's all about the continual extraction of money from the consumers. Why sell an overpriced sprinkler system only once when you can have that wealthy sprinkler system owner send your cloud service a check every single month? That's really why everyone wants to be the company that sells you the One True System, so they are the ones you're willing to pay on a monthly basis.
What I want (and have) is a server in my house that handles the home automation communications and executes rules without requiring a cloud. Unfortunately, most of the commercial hubs come needlessly saddled with clouds. There is no technical reason for an Iris hub or a Wink hub to connect to a cloud, yet they do. Amazon Echo runs everything to the cloud, including your voice. Better systems make the cloud optional.
There are also better choices on the horizon. OpenHAB is making great progress on providing an open source Java package that can handle a wide variety of home automation devices; GUI control is getting there, but setup and configuration is still a complex problem that's out of reach of the average homeowner.
Except the THERAC problem was almost the opposite of unregulated quality control. Because getting new software tested and certified was so very expensive, they decided to reuse their existing certified software in a new model of machine, thus avoiding the cost of the review process. The new device was slightly different, though, and more susceptible to the latent bug that caused the fatally high doses of radiation. (As I recall, it was an error handler in the patient name field that caused it to misinterpret the dose the technician selected.)
The regulatory process was partially at fault for making regulations so burdensome the company would rather play a game to get around them. I'm not saying we shouldn't have rigorous testing for safety critical applications, but that certification testing needs to incorporate the whole application plus its intended environment, not just testing the different bits from the last time it was certified.
I think one of the reasons Harris Stingrays and other IMSI catchers have been sold under very restrictive non-disclosure agreements is that they have always been in clear violation of the FCC's rules, and every user is guilty of frequency jamming, regardless of the warrants. If even one case goes before the FCC, the whole IMSI catching business could be shut down if the judge is sufficiently pissed off.
The flaw with that argument is there is no way to predict the urgency of the other communications trying to use the frequencies being jammed during the time of the jamming. Pacemakers automatically call 9-1-1 in the event of heart failure; a crime victim could be calling the police. Those people have a licensed device and they have the right to use the airwaves according to the terms of the license.
This is not new, this is not some recent "loss of proportionality". The FCC's stance was published at the advent of radio telecommunications, long before cell phones existed, and has been very, very consistent for at least 80 years: the airwaves are a shared resource, and cooperation is vital to their ongoing utility; you will not deliberately deny others their licensed use of their frequencies, or Uncle Charlie will come down with his Very Big Hammer. And the hammer has always been big: 40 years ago the max fines were in the $10,000 range. Not even the Secret Service has official permission to jam frequencies around the president (although I suspect they have the equipment at the ready.)
That's only a problem for people who don't want to share their data. Having the data on a server, shared with people you know, is a very useful attribute for people who need the psychological boost they get from competition. Getting 10,000 steps a day might be my original goal, but if my friend Brian always gets 11,000 steps a day, I might want to up my game just to beat him. I would see this as beneficial to my fitness as well as Brian's.
Gamification is a very powerful motivator for some people. And you can't play the game unless someone's keeping score. Fitbit's in the business of marketing their scoreboard to sell game-playing devices. And they're making money by the wheelbarrow-full doing it.
Of course, that data is useful for many other purposes. Having an aggregate view of the overall population's activity levels might be important for a government making health policies, for a local city deciding on budgets for spending on walking and biking paths, or for a medical researcher trying to understand diseases or injuries. These uses can benefit society as a whole.
But we're also seeing people who are not playing the game that are interested in the data for more nefarious reasons - insurers, employers, con-artists, all might have a potential use for this data that's not in the best interests of the participants. The Dutch are trying to put a stop to that.
Slashdot Mirror
I'm amazed that in all humanity, nobody's tried it.
"Oh, all the humanity!"
The previous poster was referring to a motor-generator system, where turbine engines are used to generate electricity to power electric motors that drive the propellers. The APUs you confused them with are "Auxiliary" Power Units, and have never been used to make the plane move.
What I wonder about in such a system is the cost of converting the power to electricity before creating thrust. You have to carry around heavy coils of wire in each motor and generator, whereas the turbofan only has to carry a drive shaft (or transmission) between the turbine and the fan. Plus, electric conversion is not perfectly efficient, some losses are introduced. I have to assume the engineers have minimized most of those impacts. On the other hand, decoupling the motors from the generators would allow for extra margins of safety: a flameout of one turbine would result in an overall loss of power, but it would not necessarily be an unbalanced loss of thrust.
Then what the f**k are these devices doing even directly connected to the public Internet?
I'm not aware of any such devices being directly connected to the public internet. But, they're on a hospital or pharmacy's internal network, and those networks almost always have direct access to the Internet.
Hospital network admins have a thankless job. They have to secure their networks against all this kind of crap, but every time they lock down some terrible gaping security hole, the doctors scream "I need this Ultrasound machine to send PDFs to my office! You can't disable the FTP function or close the FTP ports on the firewall just because you claim there's a security flaw! I need them sent NOW!!"
With luck, the admins can do some simple things, like segregate the WiFi hotspot traffic from the internal hospital traffic. They can run IDP appliances, and sometimes they can configure switches to detect rogue MAC addresses. But when it comes to the devices that the doctors interact with, no excuses are acceptable.
In a hospital, the doctors give God orders.
Sure, you need to audit the systems (as the anesthesiologist pointed out above, he believes he could siphon 10% of his prescriptions without notice.) But the human side isn't the security issue here. Any automated dispensing system is going to need auditing of the inventory, regardless of how "digitally secure" the appliance is, because it's full of really valuable drugs.
The real problems at stake are access when it's needed; and integrity that the drug dispensed is the drug prescribed in the correct quantities and dosages.
An ordinary hacker could infect the Pyxis system with ransomware just by chance, because the dispenser happened to be on the same subnet as the nurse who opened the infected Word attachment. That's a classic denial of service, and in the wrong circumstances could delay access to lifesaving medicine.
Worse, a dedicated hacker could get malware on there to try to cause havoc; perhaps the patient who was prescribed 2 250mg capsules of Tylenol actually received 2 500mg capsules of Oxycontin. Sure, the nurse scans the patient's bracelet before administering the dose, but the system reports that it dispensed exactly what was prescribed; so nobody catches the error until it's too late.
There are plenty of Hollywood scenarios that could play out here; watch the (terrible) movie The Net to see one happen to Dennis Miller's character.
Sure there's a way. The owner of the phone could voluntarily use an Apple-provided key escrow service. If you buy an iPhone for your son, register a recovery key with Apple. If you buy iPhones for your employees, keep a recovery key for your company. If you buy an iPhone for yourself, and don't want a recovery key, don't register one; but don't cry to Apple if you lose your passcode.
If the police have a warrant, they can demand the escrowed password, if one exists, because it's no longer 'personal' once it's shared. That's part of the conditions of using an escrow service.
Does that make the escrow service a giant target for hackers and the NSA? Sure. Want to avoid that risk? Don't escrow your password. Your choice.
Someone signed up for Facebook is surprised that Facebook collects and sells their personal data? Really?
LMFTFY: Someone who bought a virtual reality device is surprised to find that Facebook is collecting an selling their personal data. Really.
You didn't read even the first line of the summary: "It turns out when you install the software to run Facebook's Oculus Rift" [emphasis mine]. It's a Facebook product. If I buy a Honeywell thermostat with WiFi that provides thermostat access via the cloud, I would expect it to be in frequent contact with Honeywell's servers. Similarly, I would have every expectation that a Facebook VR set would contact Facebook's servers.
The real questions anyone should have are "what data do they collect, how do they use it, who do they share it with, and how long do they store it?" Given that it's Facebook, I'm guessing the answers are: "every single byte; to build a better model of their customers to better market to them, and to match people with their personal network; they share it with everyone, warrant or not; and forever".
The credit card sector figured out how to incorporate patching into their requirements - not applying regular patches means no PCI certification. The FDA has to climb into this millennium and start requiring the ongoing patching of medical systems as well. And that means everything from nurse's station PCs to ultrasound units to drug pumps.
This is how I see it (roughly estimating the numbers):
A machine with an FDA-approved configuration performs safely 99.99% or more of the time.
FDA approval is needed for any change to a machine, including patches. Non-certified patches take a machine out of compliance.
FDA approval for testing a patched configuration takes lots of money, which is negative incentive on the manufacturer to release frequent patches.
FDA approval for testing a patched configuration takes a long time.
A tested machine is vulnerable to all exploits discovered since the creation time of the tested configuration.
Loss of availability is less risky to patient health than incorrect or erratic functioning, which is less risky than deliberately harmful functioning.
A bad patch will most likely cause loss of availability instead of incorrect functioning; and will never cause deliberate harm.
Malware may cause prolonged loss of availability, incorrect or erratic functioning, or even deliberately harmful functioning.
I conclude:
A machine with an FDA-approved configuration is vulnerable to more exploits than a recently patched machine.
A machine with patches that take it out of FDA approval will perform safely 99.9% of the time, with the delta being primarily loss of availability.
A machine infested with malware performs safely anywhere from 0% - 95% of the time, with the possibility of deliberately created patient harm.
Therefore, the current FDA approval process is exposing patients to more risk than patching.
The FDA should therefore immediately require the ongoing patching of operating systems controlling medical devices.
They could do what cellular radios do to increase sharing: cut transmit power until both radios agree the message is acceptably low but still reliably receivable. Then, when you need to increase the density of transmitters, you do so by distributing more access points. It also helps conserve transmit power, which is good for battery life.
And if they don't think CSMA/CD is effective enough, once the density of collisions is too high, they could let the access points switch to a time slice mode. They could be either self clocking, or timed on a separate shared control frequency.
Those were two data points taken on a very, very large rock. Nobody knew for sure if some ancient craters hadn't been filled by moon dust, and if the astronauts weren't about to land in a giant trap of quicksand. At least that's how the news of the day covered it.
I was a kid then, so I don't know if they were just speculating to add to the drama. Knowing what I know about NASA today, I think they were probably much more confident than the news media expressed, but were cautious enough that they wouldn't have provided a guarantee.
Asking that question today doesn't tell us much, because the answer is now obvious: "no, it's very expensive". Instead, let's ask "Back in 1968, when BART was being designed, what were the expected benefits of using a non-standard gauge track?" Maybe it allowed the designers to consider higher speed curves, or better platform designs.
Maybe the rail vendor was trying to create a new standard for mass transit rail systems, and gave them a discount for using an over-sized gauge. Maybe the vendor was completely sleazy, and was trying to create a vendor-lock-in system where only they would be able to sell spare parts. Maybe the politicians of the day were corrupt and took kickbacks to look the other way?
Regardless, there were probably a bunch of engineers shouting "don't buy non-standard gauge rolling stock!", and BART happened anyway.
I didn't realize it was so easy to treat depression. You should write a book.
The problem is that everyone who would benefit from it is too ignorant to read it.
Yeah, but my Karma is Excellent!
Except even that is too much. Allowing a macro to modify an external file is chock full of fail. If the restriction is limited to "preventing execution", then attackers will just write a macro to modify a file type that embeds malware when it's viewed. Imagine a Word document containing a macro writing a .PDF document, and in that PDF it has the malware to infect the machine. The macro has a large, friendly button that says "Click here to produce a PDF version to share with your friends", which is irriyou then send around. Same result - cryptolocker for everyone!
Even allowing macro-infested documents to read external data sources of any kind (files) is risky, because the macro could still be capable of grabbing a copy of SekritPasswords.docx and shipping it to a server in Elbonia.
Would this kind of security break stuff? Some. In the past I've written a macro that parsed a bunch of log files, analyzed the contents, and produced the results in a chart in Excel. But as long as I'm not emailing it or downloading it from the internet, the macro would keep working.
Laugh if you want, but I really do have two "clouds" controlled by my smart house. They're ultrasonic mist emitters that fill our orchid-growing cabinets with fog, three times a day. It keeps the humidity inside the glass cases above 95%, which is ideal for some of the equatorial cloud-forest species.
And yes, the electrical plug is kept safely outside of the cabinets. Condensing humidity is a very bad environment for electrical appliances.
Sorry, I certainly wasn't trying to be one of the "deregulation" crowd. I was looking at the business pressures to avoid the cost of including the software in the testing, and then considered the loopholes in the testing regulations that permitted the company to skimp on testing.
I was trying to conclude that the regulatory testing requirements were inadequate because they didn't require testing of the whole device, thus blaming the regulators for allowing those loopholes to exist. That doesn't mean that all regulations are bad, it means that in this case the regulators failed to do an adequate job of regulating.
Yeah, I looked at OpenHAB for a while, but their grandly named "OpenHAB Designer" turned out to be nothing more a copy of Eclipse running a text editor to modify the necessary half-dozen configuration files and check them for syntax errors. It is definitely not ready for an advanced installation professional, let alone the average homeowner.
I've had great luck so far with Vera (getvera.com). It can use the cloud if you let it, but everything is configured and run locally. Configuration is not quite plugThe only reason for the cloud is secure remote access, as their API is unsecured and I wouldn't expose it to the web. The best thing about Vera is the very active community; they have developed literally hundreds of various applications that support all kinds of external devices. Some devices are locally accessed (OpenSprinkler), others reach out to web services to allow integration with a device that doesn't provide a local interface (Honeywell thermostats, for example.) All Vera's plug-in modules are defined in XML and written in lua, and you can run and test everything locally, so there are no giant hurdles to development.
The bulk of my home runs on Z-Wave. I've had a lot of disappointing results, but once you finally discover and get rid of the troublesome devices from your Z-Wave network, things can improve. Essentially it's become one big experiment where I'm testing its ease-of-use on friends and family. I've learned a lot, I've bought a lot of crap, and I'm getting better at recognizing the stinkers.
I wonder if it's a variant of the CRIME attack, where the attacker iteratively observes the success or failure of compression based on fuzzing the inputs, tail first. But those attacks just recover the encrypted data, and don't reveal anything about the key. Don't know yet -- maybe the article is just poorly written, and they aren't actually decrypting the photos, they're just recovering them.
Spoofing the Apple servers is plausible if the iMessage app isn't using pinned certificates. That would be really lame, because they've learned that lesson before on their update servers, back when all the jailbreakers were intercepting the updates.
The real problem with the IoT is that everyone and their brother is trying to be the One True Provider of All Home Automation, and they want to do it in the cloud so they can charge you for integrating with everyone else's clouds. Nest has the whole Nest-Certified thing, running in the cloud. Samsung has the Samsung Smart Home, running your washers, dryers, and air conditioners in their cloud. AssureLink will happily run your garage door openers in their cloud. Honeywell has their thermostat system, in their cloud. Rheem has their EcoNet for running hot water heaters, in their cloud. LG has a cloud service for their TVs. Schlage has a cloud for running door locks. D-Link has a cloud for viewing their security cameras. Fitbit cloud-enables your health data. Philips' cloud runs your Hue lights. And so on.
Cloud solves some thorny problems. It enables easier configuration of the home user's environment by removing most of the barriers, which is critical to commercial success. Ordinary people don't know they need to poke a hole in their firewalls, and they also know they don't want to know all those technical details. But they still want to remotely access their IoThings from their iPhones. Having the IoThings phone home to the cloud means there's a central point to discover and communicate with them, making the consumer's installation woes less painful - ease of use is critical to driving sales. And the cloud can back up those configurations, allowing you to replace your old device 1.0 with new device 2.0, all without pain.
Clouds can also improve end user security - from a certain kind of threat. If your home device is connecting to the cloud and never listening for input on its own, its attack surface is much smaller than if it has opened a port on your firewall. And when your home device needs a security patch, the cloud can push it. Obviously, that means your home devices place their trust in the cloud to be secure, which is the point of TFA.
But the main problem cloud solves is that clouds provide an ongoing "service" for which the device provider can charge $9.99/month. And it's all about the continual extraction of money from the consumers. Why sell an overpriced sprinkler system only once when you can have that wealthy sprinkler system owner send your cloud service a check every single month? That's really why everyone wants to be the company that sells you the One True System, so they are the ones you're willing to pay on a monthly basis.
What I want (and have) is a server in my house that handles the home automation communications and executes rules without requiring a cloud. Unfortunately, most of the commercial hubs come needlessly saddled with clouds. There is no technical reason for an Iris hub or a Wink hub to connect to a cloud, yet they do. Amazon Echo runs everything to the cloud, including your voice. Better systems make the cloud optional.
There are also better choices on the horizon. OpenHAB is making great progress on providing an open source Java package that can handle a wide variety of home automation devices; GUI control is getting there, but setup and configuration is still a complex problem that's out of reach of the average homeowner.
Except the THERAC problem was almost the opposite of unregulated quality control. Because getting new software tested and certified was so very expensive, they decided to reuse their existing certified software in a new model of machine, thus avoiding the cost of the review process. The new device was slightly different, though, and more susceptible to the latent bug that caused the fatally high doses of radiation. (As I recall, it was an error handler in the patient name field that caused it to misinterpret the dose the technician selected.)
The regulatory process was partially at fault for making regulations so burdensome the company would rather play a game to get around them. I'm not saying we shouldn't have rigorous testing for safety critical applications, but that certification testing needs to incorporate the whole application plus its intended environment, not just testing the different bits from the last time it was certified.
See http://www.news-medical.net/ne... for the news blurb of a pacemaker under research in India a while ago, and http://www.inderscience.com/of... for the abstract of the paper.
For more current news, see the Telepatch: https://www.medicompinc.com/in...
I think one of the reasons Harris Stingrays and other IMSI catchers have been sold under very restrictive non-disclosure agreements is that they have always been in clear violation of the FCC's rules, and every user is guilty of frequency jamming, regardless of the warrants. If even one case goes before the FCC, the whole IMSI catching business could be shut down if the judge is sufficiently pissed off.
The flaw with that argument is there is no way to predict the urgency of the other communications trying to use the frequencies being jammed during the time of the jamming. Pacemakers automatically call 9-1-1 in the event of heart failure; a crime victim could be calling the police. Those people have a licensed device and they have the right to use the airwaves according to the terms of the license.
This is not new, this is not some recent "loss of proportionality". The FCC's stance was published at the advent of radio telecommunications, long before cell phones existed, and has been very, very consistent for at least 80 years: the airwaves are a shared resource, and cooperation is vital to their ongoing utility; you will not deliberately deny others their licensed use of their frequencies, or Uncle Charlie will come down with his Very Big Hammer. And the hammer has always been big: 40 years ago the max fines were in the $10,000 range. Not even the Secret Service has official permission to jam frequencies around the president (although I suspect they have the equipment at the ready.)
That's only a problem for people who don't want to share their data. Having the data on a server, shared with people you know, is a very useful attribute for people who need the psychological boost they get from competition. Getting 10,000 steps a day might be my original goal, but if my friend Brian always gets 11,000 steps a day, I might want to up my game just to beat him. I would see this as beneficial to my fitness as well as Brian's.
Gamification is a very powerful motivator for some people. And you can't play the game unless someone's keeping score. Fitbit's in the business of marketing their scoreboard to sell game-playing devices. And they're making money by the wheelbarrow-full doing it.
Of course, that data is useful for many other purposes. Having an aggregate view of the overall population's activity levels might be important for a government making health policies, for a local city deciding on budgets for spending on walking and biking paths, or for a medical researcher trying to understand diseases or injuries. These uses can benefit society as a whole.
But we're also seeing people who are not playing the game that are interested in the data for more nefarious reasons - insurers, employers, con-artists, all might have a potential use for this data that's not in the best interests of the participants. The Dutch are trying to put a stop to that.
I would have enough to FINALLY beat that little bastard Pac-Man!
Is that a docker interface?