Isn't a corporation a robot that exists specifically to hold assets? Some of them are better at being rich than others; but surely a corporation that owns the expert system that runs the corporation would be a rich robot; were it successful...
Mental health and substance abuse social work looks to be doubly golden. Because the takeover by machines will surely increase the number of unemployed people with mental health and substance abuse problems.
Depends on the political climate: if some bleeding heart is calling the shots, sure; but if it's tough-on-crime time, then the rapidly maturing world of combat robotics will be tapped to provide low-cost 'treatment' solutions to these populations.
'Real' empathy would require a strong AI, more or less by definition(and a relatively human-like strong AI at that). Conveniently, though, there's no externally visible difference between real and fake empathy, and faking it is on the level of passing a Turing test, which is hardly trivial; but likely to actually happen in the comparatively near future.
The best diagnosticians might actually be the ones who see the chopping block sooner. Traversing decision trees, crunching patient statistics, and doing machine vision on whatever comes back from radiology and histology are all things that computers are either already good at or improving and plausibly expected to continue to do so at a reasonable clip. "Getting a patient's report of their symptoms and making them feel as though they've been duly listened to" or "calming some screaming brat long enough to innoculate it" are not things computers are terribly promising at. However, they are things that can be done, even done well, by basically the cheapest category of went-to-less-school-than-the-doctor-or-some-of-the-fancier-types-of-nurse medical workers you can legally get away with using for the task. Somebody will still have to do medical research; and it'll likely take a while for the public to accept that ResectXact(tm) software is a better candidate than some well-reputed surgeon to chop them open and do some maintenance; but attrition is likely to be brutal among the relatively expensive people whose specialized skills are amenable to expert systems and whose bedside manner and basic patient interaction are no better than a much, much, cheaper nurse or tech of some flavor.
Lawyers, in the same way, are going to require some people who are sharp enough to not fail during oral argument, who know how to work a jury, who can project a besuited air of consummate professionalism when dealing with clients who are paying well for the services of Somebody, Somebody, and That Other Guy; but it's hard to imagine that humans are going to last long against glorified search engines when it comes to "Traverse the entire law code and case law, give me the top hits, flag anything from things that the presiding judge has cited in decisions he has written in the past". Until computer generated text stops sounding so much like markov chain word salad, they'll probably still need some peons to stitch things together; but that will be a dead-end, unbearably soul crushing paralegal sweatshop of misery, not even an entry level job.
The one major complication to keep in mind is that robots/automation almost never literally 'replace' you. Rather, they allow for a different way of doing things that no longer requires you.
Robots built to replicate human capabilities are, despite continued effort, relatively pitiful. Competent bipedal locomotion, a couple of dexterous hands, fallible but very, very, adaptable image recognition, etc. are a fairly tricky package to put together on a reasonable budget. Outside of tech demos, that's why you don't bother to build the robot to resemble the worker, you restructure the task to play to the strengths of the robot(see basically all contemporary manufacturing processes). This task restructuring can also involve the user: replacing a telephone operator, say, would have been impossible until relatively recently; you need speech recognition software good enough to do the job and computers cheap enough to run it. So we didn't: Pulse code dialing allows line switching to be done with relatively simple electromechanical devices, which is why operators were on their way toward the exit more than a century ago, despite AVR 'agents' still being considered lousy and terrible to work with today.
You will almost always be misled if you try to predict odds of replacement based on 'what the job requires' rather than 'what the job produces'. Beating the people currently doing a job at the skills that the job requires is difficult, frequently impossible or uneconomic. Achieving whatever goal their job exists to fulfill(or achieving something else that eliminates that goal); is almost always how it gets done.
What I'd be interested to see is if, and how aggressively, they take action against image collections that are not of any use for their desired purposes.
They obviously can't be too capricious and unpredictable, or they'll spook users; but you can't offer 'unlimited' storage without making some provision for 'that guy who hacks together a FUSE filesystem that uses images uploaded to Google Photos as a storage medium' or the 'Cool, this will make my next time-lapse video project way easier' cases.(and, of course, if you are feeling particularly uncreative,/dev/random just needs a dash of formatting information to be as many bitmaps as you could possibly desire.)
Are they just going to go with the ISP-style 'I said unlimited; but I actually meant X photos or Y GB of traffic per month; apparently I'm allowed to get away with that, so STFU', are they going to have peons manually examine accounts whose size gets out of hand and decide what to do?
We can only hope that Uber's notoriously...risk tolerant...approach to just ignoring regulations that they don't like will result in a lot of spam that is actually 'spam' for the purposes of the CAN-SPAM Act of 2003 being sent out.
That particular law is more or less a dead letter, given how easy covert or extraterritorial spamming is(and, of course, it's assorted gaping loopholes); but there are theoretical penalties that could stack up fast if you actually fuck up.
In this case, if grabbing people's contact lists doesn't count as 'email address harvesting' in the context of the prohibition on sending to harvested addresses, I'm not sure what would.
Honestly, it's downright impressive. Uber has managed to get markedly sleazier since they did their "Oh, 'god view' and threatening to stalk reporters who piss us off was naughty; we promise to be good..." charm offensive bullshit.
Given that the store doing the advertising presumably stocks the banned goods, and it's a lot harder to hide physical merchandise in a hurry; I'd assume that the plan depends on the costs of being discovered being less than the value of the advertising, with the cute little trick being there to make it newsworthy, not to fool the cops(even if there were somehow zero machine vision errors or plainclothes cops in Russia; it can't be that uncommon for off-duty cops to wear street clothes; or for the families of police to talk to them).
There is probably a small but nonzero risk that, thanks to the buzz, some humorless enforcer will throw the book at them; but barring that the plan would appear to depend on the actual penalties for 'banned' goods being pretty toothless.
This article seems(somewhat bizarrely) to be written from the perspective of Google, Inc. but purporting to be talking about "android" and its prospects.
There is certainly a place for analysis of "So, did this 'android' stuff pay off for Google? Was it roughly break-even? A strategic failure?"; but that's quite different than "How is Android doing? What are its prospects?". Conflating the two, though, is confused at best and outright nonsense at worst(especially when examining the 'running Android, possibly even developing it in some way; but not running "Android+Google Play Services"' slice of the market'.
So, is Apple the one actually making money on smartphones? Hell yeah. Has Android been tepid in terms of actually making Google any money? At best; it may well be directly losing money and only appearing to pull its weight as a strategic play. Are the margins for most Android handset manufacturers pretty unexciting compared to Apple? Also hell yeah. However(much like the PC OEMs), that may not actually affect Android: None of the Android OEMs gets the option of joining Apple in making iPhones(except the ones that happen to also have divisions that manufacture components for Apple, like Samsung). Apple has zero interest in letting them do that. So, they can either ship Android handsets with Google, ship AOSP+their own or somebody else's stuff; ship Windows Phone, attempt to build their own OS entirely, or leave the market. Shipping Android handsets with Google isn't a terribly high-margin strategy; but it is so far unclear whether any of the other options are any higher margin.
It is very likely that Google isn't getting nearly as much of what they want from Android as they would like; and Android OEMs certainly aren't earning terribly exciting margins on their devices; but that's their problem. It only becomes Android's problem if Google decides to pull the plug, or if OEMs abandon it in favor of WP or one of the assorted linux-with-stuff-on-top-but-not-android options. So far, WP has gotten fairly good reviews; but struggled for marketshare, and the not-Android Linux derivatives are all writhing around near the noise floor. This isn't obviously a good thing, Android is a pile of mediocrity in quite a few respects, even if some of Google's applications and services for it are pretty good; but it is still the case: Since nobody gets to be an iOS vendor except Apple, and Nokia is MS' special buddy, with other OEMs allowed but sharing a very small pond; 'Android' is a fight over some pretty unexciting margins; but unless a company simply wishes to stop manufacturing smartphones and tablets, it's a fight they'll probably remain in for some time to come.
Sure, I'd love the second coming of WebOS to sweep away the unbelievers and deliver us; but that doesn't appear to be in the cards.
In Qatar, substantially by letting impoverished migrant laborers handle the outdoor stuff, under more and less voluntary conditions, and air conditioning.
While the people in this video are utter morons(even if you have actually verified the existence of a safety cut-off on a dangerous piece of hardware; Why would you test it on yourself?); Volvo's response seems...tactically unwise.
There may be good reasons for the 'pedestrian detection' feature to be an extra purchase(more sensors, more DSP, recouped development costs, etc.) or it may just be a single bit in the firmware waiting to be flipped in a magic screwdriver upgrade; but either way, "Yeah, we have a feature that would have prevented that accident; but it didn't because we prefer to charge more for it." seems like the sort of statement that is likely to attract the wrong sort of scrutiny.
If you admit to having the mature capability; how long before failing to include it is negligence? Will you be able to keep it as an add-on, rather than a standard feature like antilock braking? Are you absolutely sure that your sales people didn't misrepresent the capabilities of what they sold? and so on.
It seems as though they'd be much better off just issuing a flat 'don't do stupid irresponsible things' and quietly dropped the matter.
In thinking about it, and how much of a clusterfuck this is likely to be; it struck me that there might actually be a way to restructure the incentives to provide some kind of hope:
Historically, 'retail' insurance, for individuals and little stuff, was mostly statistical with a side of adversarial: Aside from a few token offers of a free fitbit or whatever, the insurer basically calculates your expected cost as best they can based on your demographics and history and charges you accordingly, and tries to weasel out of anything too unexpectedly expensive.
However, for larger endeavors, (the ones I'm most familiar with are utility and public works projects, there may well be others), sometimes a more collaborative model reigned: the insurer would agree to pay out in the event of accidents, jobsite deaths, and so on, as usual, and the client would pay them for that; but the insurer would also provide guidance to the project, best practices, risk management, specialist expertise on how to minimize the number of expensive fuckups on a given type of project, expertise that the customer might not have, or have at the same level. This was mutually beneficial, since the customer didn't want accidents, the insurer didn't want to pay for accidents, and everyone was happiest if the project went smoothly.
In a case like this; the incentives might align better if the contractor were were delivering both the security and the breach insurance: this would immediately resolve the argument over whether the policyholder was negligent or the insurer needs to pay up: if the IT contractor got the systems hacked through neligence, that's their fault; and if they secured the systems; but a hack was still pulled off, that's where the insurance policy comes in.
This scheme would run the risk of encouraging the vendor to attempt to hide breaches small enough to sweep under the rug; but it would otherwise align incentives reasonably neatly: an IT management/insurance hybrid entity would internalize the cost of the level of security it manages to provide(more secure presumably means greater expenditures on good IT people; but more secure also means lower effective cost of providing insurance, since you can expect fewer, smaller, breaches; and fewer, smaller, claims). If the equilibrium turns out to be 'slack off, pay the claims', that suggests that the fines for shoddy data protection need to be larger; but the arrangement would induce the vendor to keep investing in security until the marginal cost of extra work on IT was higher than the marginal gain from lower expected costs in claims; so the knob to turn to get better security is relatively accessible.
Not that real world IT systems often ascend to this level of security; but the issue is not going to be clarified by the fact that the analogy to physical security is only partially accurate: everyone accepts that (for a given purpose; bank vaults and nuclear installations get judged differently than houses) there is some level of 'reasonable security', which reflects appropriate caution on the policyholder's part; but is known to be breakable. Materials have limited strength, police have nonzero response time, sensors generate false negatives.
With IT systems(at least at the level of software attacks, if they break in at the silicon level it's another story), there is a platonic essence of 'the secure' floating out there, though generally far, far, far, too expensive, cumbersome, and slow to build to ever see the light of day; and there really isn't the same degree of agreement about what counts as 'secure enough for X' or 'incompetent'. Gross incompetence is something you can identify, and there are various formally proven systems in existence, mostly for the constrained use cases of cost-insensitive customers; but the stuff in the middle is very much up in the air.
For one brief shining moment, I thought that this story was about a health insurance company being dragged into court and beaten on by their insurance company; and my heart leapt and sang with the unalloyed joy of a Norman Rockwell puppy; because that would just be so beautiful.
Alas, 'Cottage Health' is a medical provider of some sort, so such feelings swiftly evaporated.
That aside, this seems like a situation that is simultaneously common sense(Obviously you won't be able to buy 'cyber insurance' that covers egregious negligence, at least not for any price that doesn't reflect an essentially 100% chance of payout, plus the insurer's profit margins and transaction cost); and likely to be an endless nightmare of quibbling about what 'security' is.
We've all seen the long, long, history of attempts to do security-by-checklist, most of which allow you to say that you 'followed industry best practices' by closing the barn door after the horse is long gone, so long as the barn door was constructed with galvanized nails of suitable gauge and is running any antivirus product, efficacy irrelevant. It's not as though 'security' is fundamentally unknowable and intersubjective, man; but it sure isn't something you'd want a lawyer or a layman attempting to boil down into a chunk of contractual language. Barring some miracle of clarity, I suspect that we'll see quite a few dustups that basically involve the insurer's expert witnesses smearing the policyholder's security measures(if they did it by the checklist, the expert witnesses will be snide grey hats who eat 'best practices' for lunch, if they deviated from the checklist, it'll be hardasses on loan from the PCI compliance auditing process, if they implemented a mathematically proven exotic microkernel it'll be somebody asking why Windows Updates weren't being applied in a timely manner); and the policyholder's expert witnesses puffing like salesmen about how strong the security was; and how it must have been an 'advanced persistent threat' to have hacked through such durable code walls.
The fundamental question of 'did you fail to lock the door, or did somebody take a crowbar to it?' is sensible enough in the context of an insurance claim; but rigorously defining what 'locking the door' means in a complex IT operation; and where the boundary between 'incompetence' and 'unavoidable imperfection' lies, is not going to be pretty. My only hope is that if any of these go to jury, the lawyers decide to strike anyone who sounds like they might know something about computers; because it's going to be a long, boring, slugging match of a case.
If I had the slightest confidence that this would actually involve a 'top to bottom' cleaning; I might be more optimistic(though with the caveat that 'top to bottom' purges have the unfortunate side effect of causing massive attrition among your skilled labor, even the stuff not in position to do anything more corrupt than take an extra long lunch break; which could be pretty brutal for an entity that is supposed to do rocket science). As it is, this sounds a lot more like some deck-chair shuffling.
If that is the case, our very own 'Department of Homeland Security' represents a reshuffling at least as large, absorbing as it did various departments under the vague theory that they hadn't been anti-terrorist enough. It...hasn't really been much to write home about.
I think that you could bodge together a proof of concept with basically any router and either a smartcard reader that supports CAC-style behavior, or any of the fobs that can do keypair auth(I know yubikeys can, I haven't done much poking around); but the one snag is that, to my knowledge, there's nothing (at least nothing remotely standard) that does both robust crypto token and just enough writeable storage for the little bit of configuration data that would allow a user without much technical aptitude to autoconfigure a VPN, or trust of a given certificate, or any other use case that requires both the transmission of a small amount of data and robust authentication.
For myself, I'm interested just because hardware crypto tokens are so strong compared to passwords of any remotely tractable-to-humans complexity, and less vulnerable to untrustworthy clients than doing keypair auth with a private key that lives on a relatively vulnerable computer, rather than never leaving dedicated hardware; but for it to be something useful outside geeks and IT-managed environments, the extra bit of configuration data capability seems like it would be necessary.
So, let me get this straight: your public-sector space program is a fucked-up labyrinth of corruption, fraud, and mismanagement.
You propose to replace it with a sole-source, crony capitalist, 'state corporation', to take advantage of the important synergies between the public sector's capabilities in corruption and mediocrity and the private sector's sophistication in financial and organizational malfeasance?
Christ, guys, if you keep this up I'll start feeling good about US mil/aero procurement practices by comparison...
You can argue about the relative virtues of public sector and private sector agents for various purposes; but there is no lower form of life than the crony capitalist entity when it comes to corruption.
Two-factor auth is so far ahead of the current situation that the risk of 'what if they try to configure the router from a compromised PC?' probably isn't on the radar.
What I would love to see, though, would be a router that uses some USB or NFC security fob for idiot-proof and robust VPN setups: just imagine: plug the fob into the router, or set it on the NFC pad, press the 'bless' button; and the router would perform the appropriate cryptographic handshaking with the fob, and provide the configuration information for setting up the VPN(url, VPN type, etc.).
Then you bring the fob over to a computer or mobile device, hit 'make it so', and the VPN client reads out the config data, makes the appropriate configuration changes, and the fob authenticates the connection. Quick, trivially easy, much more secure than a password or even a certificate file on a USB drive; and you are neatly tunneled back to your home network regardless of the hostile and untrusted networks you may encounter during the day.
Should you lose the fob; hit the 'unbless all' button and all fobs need to be re-blessed before they can be used(obviously, web or other interfaces to the router could allow more granular and advanced control; but having to re-bless a few fobs is likely to be easier than having to understand a more complex interface for many unsophisticated users, who probably only have a small number of active fobs anyway).
The fact that there are telnet services listening on WAN ports 15 years after OpenSSH became available makes me suspect that nothing short of a vigorous scourging with nuclear fire could solve the utterly lax approach to even rudimentary security in consumer electronics.
Well, that and DRM. Tell 'em that the pirates will steal their precious 'premium content' and suddenly they get real interested in security, albeit more in the 'building prisons' than 'building fortresses' sense of the word.
Cable modems are a bit of a special case, and not in a good way. By design, they do what is called "DOCSIS Provisioning". As you might imagine, given that the 'Data over Cable Service Interface Specification' is produced by CableLabs, an industry R&D and standards organization operated by cable companies; the process is designed for the convenience of the service provider, not for the user.
Most cable modems do have some sort of web interface, config settings to fiddle with, etc.; but when you connect one to a cable network, after performing the low-level analog black magic required to get a working digital channel up, the modem makes a DHCP request, which the operator CMTS responds to with an IP and a TFTP server address from which the modem downloads a configuration file. The modem then applies that config file, ignoring any manual configuration made, and operates accordingly.
If you fancy a look at the gory details, Here are some links; and there is a software package for playing with being the party doing the provisioning. Punchline is, though, that a successful cable modem connection more or less implies that the cable modem will be operating according to the provider's configuration for the duration of the connection. Depending on whether or not your ISP is a dick about it, you may or may not lose access to http status pages, SNMP, and any other features the modem possesses; but that's all their call. A disconnected cable modem isn't much use; but it will generally show you whatever its firmware has to offer.
It doesn't help that more than a few router firmwares, whether out of malice or incompetence, simply ignore configuration changes made through their configuration interface. The checkbox may even be there, and may even stay checked or unchecked correctly across reboots; but the actual status of the device just doesn't change.
I had to retire a POS Netgear unit(WNDR3400, in case anyone cares); because it simply ignored the 'Enable Wireless Protected Setup' option. I chose 'hell no'; because WPS is known faulty; it merrily continued offering WPS. Various other models, from more or less all the major home brands, have had instances of this with assorted potentially dangerous features(remote admin ports, uPNP, WPS, default credentials that can't be changed, etc.). Sometimes there simply isn't anything in the UI for controlling a given feature, sometimes the settings are ignored.
Unless the device is supported by a good 3rd party firmware, or you exploit the vulnerability to go in yourself and do some surgery, even 'doing the right thing' can sometimes be purely ceremonial.
It's news not because of OS(I don't know if they bothered; but exploits at the 'just use the default password against the external telnet interface' level would work against basically any OS, and the only real obstacle to executing a payload with the functions described would be that some of the really nasty VXworks-based devices are so RAM-starved that they can barely do their job, much less run malware at the same time); but because the security of nearly all 'consumer', and a disturbing number of more expensive, embedded devices is still utter shit.
It is bad enough that such plastic-box devices typically are shipping software well behind the curve(2.6X kernels, http servers with vulnerabilities that were closed upstream months before the device in question was released, that sort of thing); but 'default configuration leaves telnet listening on the WAN port, with weak credentials for root login' goes well beyond 'bug' and right into 'We Just Don't Care' territory. Even better, the same damn story has been true for at least the past decade, probably longer(though its importance has increased as the cost has fallen and number of little embedded boxes lurking around has skyrocketed).
At least on the desktop and server, some of the worst insecure-by-default atrocities have been ironed out, so attackers are now moderately likely to need to use vaguely clever vulnerabilities(even if they can often get away with ones that were patched months ago) or social engineering; but embedded crap hasn't even reached that level of security.
The fact that telnet is even there(outside of 'recovery' scenarios, where the emergency nature of the situation and availability of only the most limited resources make super-simple protocols like telnet and TFTP valuable) when OpenSSH has been available for the last 15 years, and less liberally licensed versions a bit longer, is disgusting in itself. Having it on the WAN, much less by default, is just depraved.
Unfortunately, the procedure for data recovery is effectively impossible with that particular vendor. You probably need clearances you don't have to even get a straight answer about why your request is being refused.
"Everything important to you should roam across the products you already own"; by which we mean "please, do us the favor of selecting the consumer data most worth collecting about you and sending it to us".
Slashdot Mirror
Isn't a corporation a robot that exists specifically to hold assets? Some of them are better at being rich than others; but surely a corporation that owns the expert system that runs the corporation would be a rich robot; were it successful...
Mental health and substance abuse social work looks to be doubly golden. Because the takeover by machines will surely increase the number of unemployed people with mental health and substance abuse problems.
Depends on the political climate: if some bleeding heart is calling the shots, sure; but if it's tough-on-crime time, then the rapidly maturing world of combat robotics will be tapped to provide low-cost 'treatment' solutions to these populations.
'Real' empathy would require a strong AI, more or less by definition(and a relatively human-like strong AI at that). Conveniently, though, there's no externally visible difference between real and fake empathy, and faking it is on the level of passing a Turing test, which is hardly trivial; but likely to actually happen in the comparatively near future.
The best diagnosticians might actually be the ones who see the chopping block sooner. Traversing decision trees, crunching patient statistics, and doing machine vision on whatever comes back from radiology and histology are all things that computers are either already good at or improving and plausibly expected to continue to do so at a reasonable clip. "Getting a patient's report of their symptoms and making them feel as though they've been duly listened to" or "calming some screaming brat long enough to innoculate it" are not things computers are terribly promising at. However, they are things that can be done, even done well, by basically the cheapest category of went-to-less-school-than-the-doctor-or-some-of-the-fancier-types-of-nurse medical workers you can legally get away with using for the task. Somebody will still have to do medical research; and it'll likely take a while for the public to accept that ResectXact(tm) software is a better candidate than some well-reputed surgeon to chop them open and do some maintenance; but attrition is likely to be brutal among the relatively expensive people whose specialized skills are amenable to expert systems and whose bedside manner and basic patient interaction are no better than a much, much, cheaper nurse or tech of some flavor.
Lawyers, in the same way, are going to require some people who are sharp enough to not fail during oral argument, who know how to work a jury, who can project a besuited air of consummate professionalism when dealing with clients who are paying well for the services of Somebody, Somebody, and That Other Guy; but it's hard to imagine that humans are going to last long against glorified search engines when it comes to "Traverse the entire law code and case law, give me the top hits, flag anything from things that the presiding judge has cited in decisions he has written in the past". Until computer generated text stops sounding so much like markov chain word salad, they'll probably still need some peons to stitch things together; but that will be a dead-end, unbearably soul crushing paralegal sweatshop of misery, not even an entry level job.
The one major complication to keep in mind is that robots/automation almost never literally 'replace' you. Rather, they allow for a different way of doing things that no longer requires you.
Robots built to replicate human capabilities are, despite continued effort, relatively pitiful. Competent bipedal locomotion, a couple of dexterous hands, fallible but very, very, adaptable image recognition, etc. are a fairly tricky package to put together on a reasonable budget. Outside of tech demos, that's why you don't bother to build the robot to resemble the worker, you restructure the task to play to the strengths of the robot(see basically all contemporary manufacturing processes). This task restructuring can also involve the user: replacing a telephone operator, say, would have been impossible until relatively recently; you need speech recognition software good enough to do the job and computers cheap enough to run it. So we didn't: Pulse code dialing allows line switching to be done with relatively simple electromechanical devices, which is why operators were on their way toward the exit more than a century ago, despite AVR 'agents' still being considered lousy and terrible to work with today.
You will almost always be misled if you try to predict odds of replacement based on 'what the job requires' rather than 'what the job produces'. Beating the people currently doing a job at the skills that the job requires is difficult, frequently impossible or uneconomic. Achieving whatever goal their job exists to fulfill(or achieving something else that eliminates that goal); is almost always how it gets done.
What I'd be interested to see is if, and how aggressively, they take action against image collections that are not of any use for their desired purposes.
/dev/random just needs a dash of formatting information to be as many bitmaps as you could possibly desire.)
They obviously can't be too capricious and unpredictable, or they'll spook users; but you can't offer 'unlimited' storage without making some provision for 'that guy who hacks together a FUSE filesystem that uses images uploaded to Google Photos as a storage medium' or the 'Cool, this will make my next time-lapse video project way easier' cases.(and, of course, if you are feeling particularly uncreative,
Are they just going to go with the ISP-style 'I said unlimited; but I actually meant X photos or Y GB of traffic per month; apparently I'm allowed to get away with that, so STFU', are they going to have peons manually examine accounts whose size gets out of hand and decide what to do?
We can only hope that Uber's notoriously...risk tolerant...approach to just ignoring regulations that they don't like will result in a lot of spam that is actually 'spam' for the purposes of the CAN-SPAM Act of 2003 being sent out.
That particular law is more or less a dead letter, given how easy covert or extraterritorial spamming is(and, of course, it's assorted gaping loopholes); but there are theoretical penalties that could stack up fast if you actually fuck up.
In this case, if grabbing people's contact lists doesn't count as 'email address harvesting' in the context of the prohibition on sending to harvested addresses, I'm not sure what would.
Honestly, it's downright impressive. Uber has managed to get markedly sleazier since they did their "Oh, 'god view' and threatening to stalk reporters who piss us off was naughty; we promise to be good..." charm offensive bullshit.
Given that the store doing the advertising presumably stocks the banned goods, and it's a lot harder to hide physical merchandise in a hurry; I'd assume that the plan depends on the costs of being discovered being less than the value of the advertising, with the cute little trick being there to make it newsworthy, not to fool the cops(even if there were somehow zero machine vision errors or plainclothes cops in Russia; it can't be that uncommon for off-duty cops to wear street clothes; or for the families of police to talk to them).
There is probably a small but nonzero risk that, thanks to the buzz, some humorless enforcer will throw the book at them; but barring that the plan would appear to depend on the actual penalties for 'banned' goods being pretty toothless.
This article seems(somewhat bizarrely) to be written from the perspective of Google, Inc. but purporting to be talking about "android" and its prospects.
There is certainly a place for analysis of "So, did this 'android' stuff pay off for Google? Was it roughly break-even? A strategic failure?"; but that's quite different than "How is Android doing? What are its prospects?". Conflating the two, though, is confused at best and outright nonsense at worst(especially when examining the 'running Android, possibly even developing it in some way; but not running "Android+Google Play Services"' slice of the market'.
So, is Apple the one actually making money on smartphones? Hell yeah. Has Android been tepid in terms of actually making Google any money? At best; it may well be directly losing money and only appearing to pull its weight as a strategic play. Are the margins for most Android handset manufacturers pretty unexciting compared to Apple? Also hell yeah. However(much like the PC OEMs), that may not actually affect Android: None of the Android OEMs gets the option of joining Apple in making iPhones(except the ones that happen to also have divisions that manufacture components for Apple, like Samsung). Apple has zero interest in letting them do that. So, they can either ship Android handsets with Google, ship AOSP+their own or somebody else's stuff; ship Windows Phone, attempt to build their own OS entirely, or leave the market. Shipping Android handsets with Google isn't a terribly high-margin strategy; but it is so far unclear whether any of the other options are any higher margin.
It is very likely that Google isn't getting nearly as much of what they want from Android as they would like; and Android OEMs certainly aren't earning terribly exciting margins on their devices; but that's their problem. It only becomes Android's problem if Google decides to pull the plug, or if OEMs abandon it in favor of WP or one of the assorted linux-with-stuff-on-top-but-not-android options. So far, WP has gotten fairly good reviews; but struggled for marketshare, and the not-Android Linux derivatives are all writhing around near the noise floor. This isn't obviously a good thing, Android is a pile of mediocrity in quite a few respects, even if some of Google's applications and services for it are pretty good; but it is still the case: Since nobody gets to be an iOS vendor except Apple, and Nokia is MS' special buddy, with other OEMs allowed but sharing a very small pond; 'Android' is a fight over some pretty unexciting margins; but unless a company simply wishes to stop manufacturing smartphones and tablets, it's a fight they'll probably remain in for some time to come.
Sure, I'd love the second coming of WebOS to sweep away the unbelievers and deliver us; but that doesn't appear to be in the cards.
In Qatar, substantially by letting impoverished migrant laborers handle the outdoor stuff, under more and less voluntary conditions, and air conditioning.
While the people in this video are utter morons(even if you have actually verified the existence of a safety cut-off on a dangerous piece of hardware; Why would you test it on yourself?); Volvo's response seems...tactically unwise.
There may be good reasons for the 'pedestrian detection' feature to be an extra purchase(more sensors, more DSP, recouped development costs, etc.) or it may just be a single bit in the firmware waiting to be flipped in a magic screwdriver upgrade; but either way, "Yeah, we have a feature that would have prevented that accident; but it didn't because we prefer to charge more for it." seems like the sort of statement that is likely to attract the wrong sort of scrutiny.
If you admit to having the mature capability; how long before failing to include it is negligence? Will you be able to keep it as an add-on, rather than a standard feature like antilock braking? Are you absolutely sure that your sales people didn't misrepresent the capabilities of what they sold? and so on.
It seems as though they'd be much better off just issuing a flat 'don't do stupid irresponsible things' and quietly dropped the matter.
In thinking about it, and how much of a clusterfuck this is likely to be; it struck me that there might actually be a way to restructure the incentives to provide some kind of hope:
Historically, 'retail' insurance, for individuals and little stuff, was mostly statistical with a side of adversarial: Aside from a few token offers of a free fitbit or whatever, the insurer basically calculates your expected cost as best they can based on your demographics and history and charges you accordingly, and tries to weasel out of anything too unexpectedly expensive.
However, for larger endeavors, (the ones I'm most familiar with are utility and public works projects, there may well be others), sometimes a more collaborative model reigned: the insurer would agree to pay out in the event of accidents, jobsite deaths, and so on, as usual, and the client would pay them for that; but the insurer would also provide guidance to the project, best practices, risk management, specialist expertise on how to minimize the number of expensive fuckups on a given type of project, expertise that the customer might not have, or have at the same level. This was mutually beneficial, since the customer didn't want accidents, the insurer didn't want to pay for accidents, and everyone was happiest if the project went smoothly.
In a case like this; the incentives might align better if the contractor were were delivering both the security and the breach insurance: this would immediately resolve the argument over whether the policyholder was negligent or the insurer needs to pay up: if the IT contractor got the systems hacked through neligence, that's their fault; and if they secured the systems; but a hack was still pulled off, that's where the insurance policy comes in.
This scheme would run the risk of encouraging the vendor to attempt to hide breaches small enough to sweep under the rug; but it would otherwise align incentives reasonably neatly: an IT management/insurance hybrid entity would internalize the cost of the level of security it manages to provide(more secure presumably means greater expenditures on good IT people; but more secure also means lower effective cost of providing insurance, since you can expect fewer, smaller, breaches; and fewer, smaller, claims). If the equilibrium turns out to be 'slack off, pay the claims', that suggests that the fines for shoddy data protection need to be larger; but the arrangement would induce the vendor to keep investing in security until the marginal cost of extra work on IT was higher than the marginal gain from lower expected costs in claims; so the knob to turn to get better security is relatively accessible.
Not that real world IT systems often ascend to this level of security; but the issue is not going to be clarified by the fact that the analogy to physical security is only partially accurate: everyone accepts that (for a given purpose; bank vaults and nuclear installations get judged differently than houses) there is some level of 'reasonable security', which reflects appropriate caution on the policyholder's part; but is known to be breakable. Materials have limited strength, police have nonzero response time, sensors generate false negatives.
With IT systems(at least at the level of software attacks, if they break in at the silicon level it's another story), there is a platonic essence of 'the secure' floating out there, though generally far, far, far, too expensive, cumbersome, and slow to build to ever see the light of day; and there really isn't the same degree of agreement about what counts as 'secure enough for X' or 'incompetent'. Gross incompetence is something you can identify, and there are various formally proven systems in existence, mostly for the constrained use cases of cost-insensitive customers; but the stuff in the middle is very much up in the air.
For one brief shining moment, I thought that this story was about a health insurance company being dragged into court and beaten on by their insurance company; and my heart leapt and sang with the unalloyed joy of a Norman Rockwell puppy; because that would just be so beautiful.
Alas, 'Cottage Health' is a medical provider of some sort, so such feelings swiftly evaporated.
That aside, this seems like a situation that is simultaneously common sense(Obviously you won't be able to buy 'cyber insurance' that covers egregious negligence, at least not for any price that doesn't reflect an essentially 100% chance of payout, plus the insurer's profit margins and transaction cost); and likely to be an endless nightmare of quibbling about what 'security' is.
We've all seen the long, long, history of attempts to do security-by-checklist, most of which allow you to say that you 'followed industry best practices' by closing the barn door after the horse is long gone, so long as the barn door was constructed with galvanized nails of suitable gauge and is running any antivirus product, efficacy irrelevant. It's not as though 'security' is fundamentally unknowable and intersubjective, man; but it sure isn't something you'd want a lawyer or a layman attempting to boil down into a chunk of contractual language. Barring some miracle of clarity, I suspect that we'll see quite a few dustups that basically involve the insurer's expert witnesses smearing the policyholder's security measures(if they did it by the checklist, the expert witnesses will be snide grey hats who eat 'best practices' for lunch, if they deviated from the checklist, it'll be hardasses on loan from the PCI compliance auditing process, if they implemented a mathematically proven exotic microkernel it'll be somebody asking why Windows Updates weren't being applied in a timely manner); and the policyholder's expert witnesses puffing like salesmen about how strong the security was; and how it must have been an 'advanced persistent threat' to have hacked through such durable code walls.
The fundamental question of 'did you fail to lock the door, or did somebody take a crowbar to it?' is sensible enough in the context of an insurance claim; but rigorously defining what 'locking the door' means in a complex IT operation; and where the boundary between 'incompetence' and 'unavoidable imperfection' lies, is not going to be pretty. My only hope is that if any of these go to jury, the lawyers decide to strike anyone who sounds like they might know something about computers; because it's going to be a long, boring, slugging match of a case.
If I had the slightest confidence that this would actually involve a 'top to bottom' cleaning; I might be more optimistic(though with the caveat that 'top to bottom' purges have the unfortunate side effect of causing massive attrition among your skilled labor, even the stuff not in position to do anything more corrupt than take an extra long lunch break; which could be pretty brutal for an entity that is supposed to do rocket science). As it is, this sounds a lot more like some deck-chair shuffling.
If that is the case, our very own 'Department of Homeland Security' represents a reshuffling at least as large, absorbing as it did various departments under the vague theory that they hadn't been anti-terrorist enough. It...hasn't really been much to write home about.
I think that you could bodge together a proof of concept with basically any router and either a smartcard reader that supports CAC-style behavior, or any of the fobs that can do keypair auth(I know yubikeys can, I haven't done much poking around); but the one snag is that, to my knowledge, there's nothing (at least nothing remotely standard) that does both robust crypto token and just enough writeable storage for the little bit of configuration data that would allow a user without much technical aptitude to autoconfigure a VPN, or trust of a given certificate, or any other use case that requires both the transmission of a small amount of data and robust authentication.
For myself, I'm interested just because hardware crypto tokens are so strong compared to passwords of any remotely tractable-to-humans complexity, and less vulnerable to untrustworthy clients than doing keypair auth with a private key that lives on a relatively vulnerable computer, rather than never leaving dedicated hardware; but for it to be something useful outside geeks and IT-managed environments, the extra bit of configuration data capability seems like it would be necessary.
Maybe if I were feeling entrepreneurial...
I'll have to check again. It wasn't when I pulled it; but that may have changed, and it is still in my reserve drawer.
So, let me get this straight: your public-sector space program is a fucked-up labyrinth of corruption, fraud, and mismanagement.
You propose to replace it with a sole-source, crony capitalist, 'state corporation', to take advantage of the important synergies between the public sector's capabilities in corruption and mediocrity and the private sector's sophistication in financial and organizational malfeasance?
Christ, guys, if you keep this up I'll start feeling good about US mil/aero procurement practices by comparison...
You can argue about the relative virtues of public sector and private sector agents for various purposes; but there is no lower form of life than the crony capitalist entity when it comes to corruption.
Two-factor auth is so far ahead of the current situation that the risk of 'what if they try to configure the router from a compromised PC?' probably isn't on the radar.
What I would love to see, though, would be a router that uses some USB or NFC security fob for idiot-proof and robust VPN setups: just imagine: plug the fob into the router, or set it on the NFC pad, press the 'bless' button; and the router would perform the appropriate cryptographic handshaking with the fob, and provide the configuration information for setting up the VPN(url, VPN type, etc.).
Then you bring the fob over to a computer or mobile device, hit 'make it so', and the VPN client reads out the config data, makes the appropriate configuration changes, and the fob authenticates the connection. Quick, trivially easy, much more secure than a password or even a certificate file on a USB drive; and you are neatly tunneled back to your home network regardless of the hostile and untrusted networks you may encounter during the day.
Should you lose the fob; hit the 'unbless all' button and all fobs need to be re-blessed before they can be used(obviously, web or other interfaces to the router could allow more granular and advanced control; but having to re-bless a few fobs is likely to be easier than having to understand a more complex interface for many unsophisticated users, who probably only have a small number of active fobs anyway).
The fact that there are telnet services listening on WAN ports 15 years after OpenSSH became available makes me suspect that nothing short of a vigorous scourging with nuclear fire could solve the utterly lax approach to even rudimentary security in consumer electronics.
Well, that and DRM. Tell 'em that the pirates will steal their precious 'premium content' and suddenly they get real interested in security, albeit more in the 'building prisons' than 'building fortresses' sense of the word.
Cable modems are a bit of a special case, and not in a good way. By design, they do what is called "DOCSIS Provisioning". As you might imagine, given that the 'Data over Cable Service Interface Specification' is produced by CableLabs, an industry R&D and standards organization operated by cable companies; the process is designed for the convenience of the service provider, not for the user.
Most cable modems do have some sort of web interface, config settings to fiddle with, etc.; but when you connect one to a cable network, after performing the low-level analog black magic required to get a working digital channel up, the modem makes a DHCP request, which the operator CMTS responds to with an IP and a TFTP server address from which the modem downloads a configuration file. The modem then applies that config file, ignoring any manual configuration made, and operates accordingly.
If you fancy a look at the gory details, Here are some links; and there is a software package for playing with being the party doing the provisioning. Punchline is, though, that a successful cable modem connection more or less implies that the cable modem will be operating according to the provider's configuration for the duration of the connection. Depending on whether or not your ISP is a dick about it, you may or may not lose access to http status pages, SNMP, and any other features the modem possesses; but that's all their call. A disconnected cable modem isn't much use; but it will generally show you whatever its firmware has to offer.
It doesn't help that more than a few router firmwares, whether out of malice or incompetence, simply ignore configuration changes made through their configuration interface. The checkbox may even be there, and may even stay checked or unchecked correctly across reboots; but the actual status of the device just doesn't change.
I had to retire a POS Netgear unit(WNDR3400, in case anyone cares); because it simply ignored the 'Enable Wireless Protected Setup' option. I chose 'hell no'; because WPS is known faulty; it merrily continued offering WPS. Various other models, from more or less all the major home brands, have had instances of this with assorted potentially dangerous features(remote admin ports, uPNP, WPS, default credentials that can't be changed, etc.). Sometimes there simply isn't anything in the UI for controlling a given feature, sometimes the settings are ignored.
Unless the device is supported by a good 3rd party firmware, or you exploit the vulnerability to go in yourself and do some surgery, even 'doing the right thing' can sometimes be purely ceremonial.
It's news not because of OS(I don't know if they bothered; but exploits at the 'just use the default password against the external telnet interface' level would work against basically any OS, and the only real obstacle to executing a payload with the functions described would be that some of the really nasty VXworks-based devices are so RAM-starved that they can barely do their job, much less run malware at the same time); but because the security of nearly all 'consumer', and a disturbing number of more expensive, embedded devices is still utter shit.
It is bad enough that such plastic-box devices typically are shipping software well behind the curve(2.6X kernels, http servers with vulnerabilities that were closed upstream months before the device in question was released, that sort of thing); but 'default configuration leaves telnet listening on the WAN port, with weak credentials for root login' goes well beyond 'bug' and right into 'We Just Don't Care' territory. Even better, the same damn story has been true for at least the past decade, probably longer(though its importance has increased as the cost has fallen and number of little embedded boxes lurking around has skyrocketed).
At least on the desktop and server, some of the worst insecure-by-default atrocities have been ironed out, so attackers are now moderately likely to need to use vaguely clever vulnerabilities(even if they can often get away with ones that were patched months ago) or social engineering; but embedded crap hasn't even reached that level of security.
The fact that telnet is even there(outside of 'recovery' scenarios, where the emergency nature of the situation and availability of only the most limited resources make super-simple protocols like telnet and TFTP valuable) when OpenSSH has been available for the last 15 years, and less liberally licensed versions a bit longer, is disgusting in itself. Having it on the WAN, much less by default, is just depraved.
Unfortunately, the procedure for data recovery is effectively impossible with that particular vendor. You probably need clearances you don't have to even get a straight answer about why your request is being refused.
"Everything important to you should roam across the products you already own"; by which we mean "please, do us the favor of selecting the consumer data most worth collecting about you and sending it to us".