Google has an interest in proper encryption. They can only sell your data if the potential buyer cannot acquire it without paying them.
Sigh.
Google does not sell data, at least not in any form other than anonymized and aggregated, and not very much even that way. Google makes money from using your data itself (to target ads to you), not from selling it to others.
FWIW, I work for Google, on crypto security stuff, and Google does have a strong interest in proper encryption, because it's the right thing to do. It allows people to control their data. With respect to Google's business, Google would like you to choose to provide your data because you think it's a good trade for Google's services, but wants you to have the ability to make the choice not to provide your data. To anyone, if that's what you want.
Wow. With one single contract, RSA just destroyed their whole business. A company in the trust business cannot allow themselves to lose their customers' trust.
No RSA product can ever be trusted again.
Except that RSA destroyed their whole business a couple of years ago when it was found that they'd left the root keys for their SecureID tokens on an unsecured, network-connected machine. After that no one could trust them again.
But people did, and they'll continue doing so after this, watch and see.
However, I don't think allowing users to control individual permissions will fix it. Users will just continue authorizing the kitchen sink. If some of them start exercising more control over specific permissions, app developers will simply respond by refusing to show the dancing pigs if SMS isn't actually working.
And I don't think shutting off the APIs entirely is an acceptable solution, even if it arguably works for Apple.
I don't think that analogy is useful. If you leave your door open, you're the one that stands to lose, but if vulnerabilities exist the software company (generally) isn't the loser, which is why it makes sense to impose some method of bringing the societal costs to bear on the company. In economic terms, vulnerability costs are largely a negative externality, while security costs are internalized. That's a recipe for incenting people to ignore security, and the general solution is to internalize the externality.
I think a better analogy would be leaving something dangerous to others unsecured. Say, explosives. If you have a license to handle explosives and you don't follow the rules for securing them appropriately, you will get fined (if your'e caught). The other twist with software vulnerabilities is that the risk associated with a given bug is much harder to pin down, whereas it's pretty easy to quantify with a given type and quantity of explosives. This proposal attempts to use market forces to quantify the risk and determine the dollar amount of the "fine". It further tries to use the fine to actually motivate and therefore fund the security research. In the case of explosives, the government pays people to audit licensees and the value of the fines go to the government. I suspect if we looked a bit we could find some situations like this proposal, where the government essentially outsources the auditing operation to a third party who is compensated by collecting the fines.
This "arm race" wouldn't ever occur. Apple and MS are considerably more hostile towards developers and the developers just accept it. Making the OS, Hardware and Store owner mad at you is not a recipe for success if you want to be an app developer.
I suppose Google could institute a policy of banning apps that try to circumvent ad-hoc user permission restrictions. Yeah, that would cut the arms race off at the knees. Good point.
Some did raise hell. They're prohibited from talking about it because of gag orders and "national security".
Prohibited ? What exactly does that mean?
In this case it means that company officials who decided to violate the gag orders could be held personally and criminally liable for their decisions. By some readings of the law, they could even be charged with treason, which is a capital offense. It's unlikely that it would go that far, but these aren't laws that can be violated with impunity.
When was the last "Massive iOS Mobile Botnet Hijacking SMS Data" headline?
When was the last maximum security prisoner getting run over by a bus headline? Sometimes freedom has its own risks, which includes idiots making poor decisions over where to get their software from. Does that mean everyone should be locked up in a cage to prevent that from happening?
No, not at all, but there are parts of this story that expose one of the weaknesses of the Android permissions model; namely that an app requests a set of permissions (that are overly broad to cut down on the number of permissions groups) and you have to either accept or deny those permissions wholesale.
Because the people who download dodgy apps and sideload them, then click past the permissions list without even looking at it would selectively disable the permissions they didn't really want to grant?
The permissions problem you refer to is a really difficult one to solve. Oh, it could be solved for you, by giving you the ability to selectively disable permissions (which, BTW, you can actually do with a small amount of one-time effort), but face it, less than 1% of Android users would carefully vet and individually select the permissions. Probably much less than 1%.
Then there's also the problem that individual permission selection would just cause app developers to test to see if they got all the permissions they wanted, and refuse to function at all if they didn't. Google could respond by trying to make it appear that the apps did get permission, perhaps by serving up fake data, but that would just create an arms race between app developers and Google, and apps have a much shorter release cycle. In fact, for power users the status quo is probably better, because they can root their phones and use an app to selectively disable permissions, but there aren't enough of them (far less than 1%) to motivate app developers to try to work around it.
I don't know what the solution is, but I don't think that's it. I lean more towards finding ways, at least in the official app store, to shame apps that request broader permissions than they should. Maybe Google should develop some sort of a "risk rating", based on the permissions requested and the trustworthiness of the publisher and tag every app in the store with it, perhaps even adding an additional warning dialog if the risk is over some threshold, and probably artificially lowering "risky" apps in the search results. Of course, the really problematic apps aren't on the Play store, and adding an additional warning on an app that a user has already chosen to get from some dodgy site is unlikely to help. But Google might be able to dissuade publishers of apps on Play from requesting more permissions than absolutely required.
(Disclaimer: I work for Google, but not on Android. My relationship with Android is that of a user.)
NG engines are easy to do and well understood, but the infrastructure issue means it's a fleet-use only item.
An inexpensive home CNG compressor could fix that. A very large percentage of the US has CNG piped to the home; if that could be leveraged for safe and convenient in-home refueling, then the infrastructure problem is mostly solved.
Note that I have no idea how difficult it is to build a small, safe, inexpensive CNG compressor. It doesn't seem like it should be too difficult, though.
Yeah, heres an idea, create a company, get insurance, create bug riddled code, get someone else to turn them in and profit...
Which is no different from "get an old building, buy fire insurance, have someone set it on fire and profit". Insurance fraud scams exist with every type of insurance in existence, and it doesn't prevent insurance from working.
It's not Steamboat Willy their making a profit from, it's the Mickey Mouse character. He's been around so long he's become a part of the American social heritage, and Disney Corp. is the only entity allowed to make money from that. I agree that people should have a right to be compensated for their creations, but when you're still raking it in after 70 years somethings messed up.
Red herring. Keeping Steamboat Willy under copyright does nothing to maintain Disney's hold on Mickey Mouse. In fact, Disney doesn't need copyright law at all to maintain ownership of Mickey Mouse... the character's name and likeness are trademarks, and Disney can prevent any unauthorized use with trademark law.
This is silly. Allit would do it force black markey prices up and push smaller companies out of business. It would probably also raise insurance rates for software companies and the cost of software in general. Of course, it would laso probably push up the rates for competent software developers.
I disagree, in part.
I do agree that it would increase insurance rates for software companies and increase the cost of software. But I don't think that's a bad thing. We have a serious problem today with the amount of shoddy software being pushed out and placed in critical positions where defects can result in huge losses. Software that is an attractive target for attack should cost more, because the maker should invest more into it, in the form of the appropriate security due diligence.
The only way the insurance would be reasonable would be if the bug bounty was not a fixed price.
Yes, that's the idea. Bug bounties would be set by the value of the vulnerabilities on the black market, so the prices would vary depending on the nature of the bug and the target. I'm doubtful that such a market would work, but if you assume that part of it does, then insuring against it would work well.
That's probably worse than just waiting and letting it happen which is never going to be 100% and has
at least some chance of recovering or mitigating the loss.
Yes, that's the nature of insurance. If the actuaries do their jobs right, insurance is always, in aggregate and in the long run, a losing proposition. If you can afford the potential hit, you should not buy insurance. But insurance makes a lot of sense in cases where the probability of catastrophic loss is relatively low but the impact is, well, catastrophic.
How is the price of this insurance going to be determined for a company that just came into existence? There's no track record that can be used to establish the relative risk for producing bugs.
The nature of the software should provide a good basis for estimating potential damage (e.g. avionics control system vs twitterbot), and the tools and development processes used should provide a good basis for estimating risk of vulnerabilities. Indeed, much as I hate to admit it, the software industry could probably benefit from the level of rigor that insurance actuaries would apply, to both damage estimation and development methodology evaluation.
I don't think this would be so problematic for startups. They'd just end up buying insurance, the same way they insure a lot of other things. And the insurance companies would not only spread the risk, but they'd also actively require companies to mitigate the risk, by doing the right kinds of security reviews. Further, they'd almost certainly end up pricing the premiums differently based on the degree of risk posed by the software. If a startup is building a product that, if exploited, could lead to billions of dollars in damages, then the premiums will be higher and the security practices required to bring them down will be much stiffer. On the other hand, if your startup is building the latest twitterbot, the risks are pretty low.
The bigger impact to startups would be in agility, not financial, I think. Particularly for startups building software that could be used to compromise high-value targets (or large numbers of low-value targets). But I don't think that's actually a bad thing. Some areas should innovate more slowly and cautiously, because they're risky.
I think the bigger problem is how to combine white and black markets in a reliable and trustworthy way.
With one big practical issue, this idea seems fundamentally sound, from an economic perspective. Presumably the black market values the vulnerabilities according to their exploitation potential, which should be related to the value of the software. Currently that may not always be the case, but it should be, even in cases of cyber warfare where the attacker's interest is in doing damage, not stealing money.
Consider, for example, a control system that is used to manage a large electrical power grid. Right now, economics will price the value of that software based on the cost of production, plus sales expenses, transaction costs and a profit margin. If the company buying the software (or its regulators) to run its grid is very conscientious, it may recognize that vulnerabilities could wreak havoc and require some additional security auditing, etc., in which case the necessary security effort would get factored into the price. However, that also may not happen -- especially if the software is some apparently minor, peripheral piece, whose ability to destroy the grid isn't obvious.
But if the maker of the software is responsible for purchasing vulnerabilities, and the value of the vulnerabilities becomes clear to, say, Chinese government hackers looking for ways to attack the power grid, then the security due diligence is likely to be factored in up front. I imagine what will really happen is that software companies will buy insurance against potential vulnerability costs, and insurance companies will quickly become savvy analysts of security risk potentials and secure development process evaluation. Security code reviews may become the equivalent of installing fire suppression systems and building with flame-retardant materials, something everyone does to keep their premiums down.
However, I see one big problem with it: The black market is, by definition, black. Can you get reliable vulnerability valuations out of it? It seems to me that if I have a potentially-serious vulnerability to sell, the first thing I'm going to do is to get some buddies to help bid up the price, with an agreement that we'll split the take. They can bid as much as they like because we all know the company will be required to buy the vulnerability for a slightly higher price. For that matter I can simply claim I have a bidder willing to pay $X, for any X I choose. Given that real black market bidders are going to be very hard to identify, how can anyone say I'm wrong? And if the software company claims I'm lying and refuses to buy, what if they're wrong? And what's to stop them from claiming that all of the other bids are fabrications?
Making this work seems to require an auditable, high-trust marketplace that traffics in illicit goods and has a lot of criminal participants, who are somehow comfortable participating. That seems... rather difficult to achieve. Not impossible, perhaps, but definitely very difficult.
Last time I checked Disney was still raking in the cash and redefining copyright length to ensure their cash flow.
Yeah, just look at the billions Disney is raking in from sales of Steamboat Willie.
</sarcasm>
Disney makes lots of money, and has been instrumental in extending copyright terms, but I see no evidence that the latter has anything to do with the former. Oh, they occasionally make a few millions by re-releasing one of their older films (Bambi, Snow White, etc.), and then pulling it off the shelf again, but that's a pittance compared to the money they make from new releases and all of the other media they produce.
Slashdot Mirror
Google doesn't give the NSA access.
Google has an interest in proper encryption. They can only sell your data if the potential buyer cannot acquire it without paying them.
Sigh.
Google does not sell data, at least not in any form other than anonymized and aggregated, and not very much even that way. Google makes money from using your data itself (to target ads to you), not from selling it to others.
FWIW, I work for Google, on crypto security stuff, and Google does have a strong interest in proper encryption, because it's the right thing to do. It allows people to control their data. With respect to Google's business, Google would like you to choose to provide your data because you think it's a good trade for Google's services, but wants you to have the ability to make the choice not to provide your data. To anyone, if that's what you want.
Wow. With one single contract, RSA just destroyed their whole business. A company in the trust business cannot allow themselves to lose their customers' trust.
No RSA product can ever be trusted again.
Except that RSA destroyed their whole business a couple of years ago when it was found that they'd left the root keys for their SecureID tokens on an unsecured, network-connected machine. After that no one could trust them again.
But people did, and they'll continue doing so after this, watch and see.
Interesting, you solution seems relatively fair, and reasonable. Prediction it will ever be implemented: 0.05%
Optimist.
We would also appreciate a few ovums from a selection of healthy, attractive ladies aged 18-25. For research purposes of course!
Blue-eyed blondes with no Jewish contamination, er, ancestry, please.
Interesting (and well-stated) points.
However, I don't think allowing users to control individual permissions will fix it. Users will just continue authorizing the kitchen sink. If some of them start exercising more control over specific permissions, app developers will simply respond by refusing to show the dancing pigs if SMS isn't actually working.
And I don't think shutting off the APIs entirely is an acceptable solution, even if it arguably works for Apple.
I don't think that analogy is useful. If you leave your door open, you're the one that stands to lose, but if vulnerabilities exist the software company (generally) isn't the loser, which is why it makes sense to impose some method of bringing the societal costs to bear on the company. In economic terms, vulnerability costs are largely a negative externality, while security costs are internalized. That's a recipe for incenting people to ignore security, and the general solution is to internalize the externality.
I think a better analogy would be leaving something dangerous to others unsecured. Say, explosives. If you have a license to handle explosives and you don't follow the rules for securing them appropriately, you will get fined (if your'e caught). The other twist with software vulnerabilities is that the risk associated with a given bug is much harder to pin down, whereas it's pretty easy to quantify with a given type and quantity of explosives. This proposal attempts to use market forces to quantify the risk and determine the dollar amount of the "fine". It further tries to use the fine to actually motivate and therefore fund the security research. In the case of explosives, the government pays people to audit licensees and the value of the fines go to the government. I suspect if we looked a bit we could find some situations like this proposal, where the government essentially outsources the auditing operation to a third party who is compensated by collecting the fines.
I think you're drawing an artificial distinction. Given a regulatory requirement to pay a bug bounty, there would be an actual loss to be covered.
This "arm race" wouldn't ever occur. Apple and MS are considerably more hostile towards developers and the developers just accept it. Making the OS, Hardware and Store owner mad at you is not a recipe for success if you want to be an app developer.
I suppose Google could institute a policy of banning apps that try to circumvent ad-hoc user permission restrictions. Yeah, that would cut the arms race off at the knees. Good point.
Some did raise hell. They're prohibited from talking about it because of gag orders and "national security".
Prohibited ? What exactly does that mean?
In this case it means that company officials who decided to violate the gag orders could be held personally and criminally liable for their decisions. By some readings of the law, they could even be charged with treason, which is a capital offense. It's unlikely that it would go that far, but these aren't laws that can be violated with impunity.
When was the last "Massive iOS Mobile Botnet Hijacking SMS Data" headline?
When was the last maximum security prisoner getting run over by a bus headline? Sometimes freedom has its own risks, which includes idiots making poor decisions over where to get their software from. Does that mean everyone should be locked up in a cage to prevent that from happening?
No, not at all, but there are parts of this story that expose one of the weaknesses of the Android permissions model; namely that an app requests a set of permissions (that are overly broad to cut down on the number of permissions groups) and you have to either accept or deny those permissions wholesale.
Because the people who download dodgy apps and sideload them, then click past the permissions list without even looking at it would selectively disable the permissions they didn't really want to grant?
The permissions problem you refer to is a really difficult one to solve. Oh, it could be solved for you, by giving you the ability to selectively disable permissions (which, BTW, you can actually do with a small amount of one-time effort), but face it, less than 1% of Android users would carefully vet and individually select the permissions. Probably much less than 1%.
Then there's also the problem that individual permission selection would just cause app developers to test to see if they got all the permissions they wanted, and refuse to function at all if they didn't. Google could respond by trying to make it appear that the apps did get permission, perhaps by serving up fake data, but that would just create an arms race between app developers and Google, and apps have a much shorter release cycle. In fact, for power users the status quo is probably better, because they can root their phones and use an app to selectively disable permissions, but there aren't enough of them (far less than 1%) to motivate app developers to try to work around it.
I don't know what the solution is, but I don't think that's it. I lean more towards finding ways, at least in the official app store, to shame apps that request broader permissions than they should. Maybe Google should develop some sort of a "risk rating", based on the permissions requested and the trustworthiness of the publisher and tag every app in the store with it, perhaps even adding an additional warning dialog if the risk is over some threshold, and probably artificially lowering "risky" apps in the search results. Of course, the really problematic apps aren't on the Play store, and adding an additional warning on an app that a user has already chosen to get from some dodgy site is unlikely to help. But Google might be able to dissuade publishers of apps on Play from requesting more permissions than absolutely required.
(Disclaimer: I work for Google, but not on Android. My relationship with Android is that of a user.)
NG engines are easy to do and well understood, but the infrastructure issue means it's a fleet-use only item.
An inexpensive home CNG compressor could fix that. A very large percentage of the US has CNG piped to the home; if that could be leveraged for safe and convenient in-home refueling, then the infrastructure problem is mostly solved.
Note that I have no idea how difficult it is to build a small, safe, inexpensive CNG compressor. It doesn't seem like it should be too difficult, though.
Yeah, heres an idea, create a company, get insurance, create bug riddled code, get someone else to turn them in and profit...
Which is no different from "get an old building, buy fire insurance, have someone set it on fire and profit". Insurance fraud scams exist with every type of insurance in existence, and it doesn't prevent insurance from working.
It's not Steamboat Willy their making a profit from, it's the Mickey Mouse character. He's been around so long he's become a part of the American social heritage, and Disney Corp. is the only entity allowed to make money from that. I agree that people should have a right to be compensated for their creations, but when you're still raking it in after 70 years somethings messed up.
Red herring. Keeping Steamboat Willy under copyright does nothing to maintain Disney's hold on Mickey Mouse. In fact, Disney doesn't need copyright law at all to maintain ownership of Mickey Mouse... the character's name and likeness are trademarks, and Disney can prevent any unauthorized use with trademark law.
+1
This is silly. Allit would do it force black markey prices up and push smaller companies out of business. It would probably also raise insurance rates for software companies and the cost of software in general. Of course, it would laso probably push up the rates for competent software developers.
I disagree, in part.
I do agree that it would increase insurance rates for software companies and increase the cost of software. But I don't think that's a bad thing. We have a serious problem today with the amount of shoddy software being pushed out and placed in critical positions where defects can result in huge losses. Software that is an attractive target for attack should cost more, because the maker should invest more into it, in the form of the appropriate security due diligence.
This idea is so ridiculous, I can't imagine it's not simply clickbait. And thanks to Slashdot editors, it worked.
I don't think it's at all ridiculous. I don't see how to make it practical, but it's definitely not ridiculous.
The only way the insurance would be reasonable would be if the bug bounty was not a fixed price.
Yes, that's the idea. Bug bounties would be set by the value of the vulnerabilities on the black market, so the prices would vary depending on the nature of the bug and the target. I'm doubtful that such a market would work, but if you assume that part of it does, then insuring against it would work well.
That's probably worse than just waiting and letting it happen which is never going to be 100% and has at least some chance of recovering or mitigating the loss.
Yes, that's the nature of insurance. If the actuaries do their jobs right, insurance is always, in aggregate and in the long run, a losing proposition. If you can afford the potential hit, you should not buy insurance. But insurance makes a lot of sense in cases where the probability of catastrophic loss is relatively low but the impact is, well, catastrophic.
How is the price of this insurance going to be determined for a company that just came into existence? There's no track record that can be used to establish the relative risk for producing bugs.
The nature of the software should provide a good basis for estimating potential damage (e.g. avionics control system vs twitterbot), and the tools and development processes used should provide a good basis for estimating risk of vulnerabilities. Indeed, much as I hate to admit it, the software industry could probably benefit from the level of rigor that insurance actuaries would apply, to both damage estimation and development methodology evaluation.
I don't think this would be so problematic for startups. They'd just end up buying insurance, the same way they insure a lot of other things. And the insurance companies would not only spread the risk, but they'd also actively require companies to mitigate the risk, by doing the right kinds of security reviews. Further, they'd almost certainly end up pricing the premiums differently based on the degree of risk posed by the software. If a startup is building a product that, if exploited, could lead to billions of dollars in damages, then the premiums will be higher and the security practices required to bring them down will be much stiffer. On the other hand, if your startup is building the latest twitterbot, the risks are pretty low.
The bigger impact to startups would be in agility, not financial, I think. Particularly for startups building software that could be used to compromise high-value targets (or large numbers of low-value targets). But I don't think that's actually a bad thing. Some areas should innovate more slowly and cautiously, because they're risky.
I think the bigger problem is how to combine white and black markets in a reliable and trustworthy way.
With one big practical issue, this idea seems fundamentally sound, from an economic perspective. Presumably the black market values the vulnerabilities according to their exploitation potential, which should be related to the value of the software. Currently that may not always be the case, but it should be, even in cases of cyber warfare where the attacker's interest is in doing damage, not stealing money.
Consider, for example, a control system that is used to manage a large electrical power grid. Right now, economics will price the value of that software based on the cost of production, plus sales expenses, transaction costs and a profit margin. If the company buying the software (or its regulators) to run its grid is very conscientious, it may recognize that vulnerabilities could wreak havoc and require some additional security auditing, etc., in which case the necessary security effort would get factored into the price. However, that also may not happen -- especially if the software is some apparently minor, peripheral piece, whose ability to destroy the grid isn't obvious.
But if the maker of the software is responsible for purchasing vulnerabilities, and the value of the vulnerabilities becomes clear to, say, Chinese government hackers looking for ways to attack the power grid, then the security due diligence is likely to be factored in up front. I imagine what will really happen is that software companies will buy insurance against potential vulnerability costs, and insurance companies will quickly become savvy analysts of security risk potentials and secure development process evaluation. Security code reviews may become the equivalent of installing fire suppression systems and building with flame-retardant materials, something everyone does to keep their premiums down.
However, I see one big problem with it: The black market is, by definition, black. Can you get reliable vulnerability valuations out of it? It seems to me that if I have a potentially-serious vulnerability to sell, the first thing I'm going to do is to get some buddies to help bid up the price, with an agreement that we'll split the take. They can bid as much as they like because we all know the company will be required to buy the vulnerability for a slightly higher price. For that matter I can simply claim I have a bidder willing to pay $X, for any X I choose. Given that real black market bidders are going to be very hard to identify, how can anyone say I'm wrong? And if the software company claims I'm lying and refuses to buy, what if they're wrong? And what's to stop them from claiming that all of the other bids are fabrications?
Making this work seems to require an auditable, high-trust marketplace that traffics in illicit goods and has a lot of criminal participants, who are somehow comfortable participating. That seems... rather difficult to achieve. Not impossible, perhaps, but definitely very difficult.
Last time I checked Disney was still raking in the cash and redefining copyright length to ensure their cash flow.
Yeah, just look at the billions Disney is raking in from sales of Steamboat Willie.
</sarcasm>
Disney makes lots of money, and has been instrumental in extending copyright terms, but I see no evidence that the latter has anything to do with the former. Oh, they occasionally make a few millions by re-releasing one of their older films (Bambi, Snow White, etc.), and then pulling it off the shelf again, but that's a pittance compared to the money they make from new releases and all of the other media they produce.
Mounting evidence at Baen Books.
http://baen.ghostwheel.com/#RIAA
The more stuff they give away, the more money they make. Rest in peace, Jim Baen.
The set of CD images at that ghostwheel site is out of date this site has all of them.
Depends on the updraft.
I've seen dents in the leading edges of the wings just from hitting grasshoppers...
If pilots are doing 500+kts at altitudes reachable by grasshoppers, I'd be worried about the dents caused by trees. And small children.