Ok, here is the problem. Yes, they are rating the trustworthiness of the transaction, but in order to do that they are holding and computing vast amounts of heuristic data about you and your shopping/card usage patterns. That type of data is HIGHLY sensitive and can reveal a vast amount about a person, and there is literally nothing governing their usage of that data. They could sell it to almost anyone (probably including sanctioned governments if they get creative enough) and it would have serious implications with virtually no legal liability. Imagine a spy agency having a financial vulnerability list of who to target for recruiting. Think about the fact that they are essentially able to predict your movements and purchases with probably terrifying accuracy. This is a digital gold mine and we have no idea who might entice/force them to give them access.
Fraud prevention is important, but this type of data collection is fucking scary.
No. Granted, working in a dev environment is a bit of a corner case, but there is no reason this can't be a configuration option. I am not generating a bunch of certs for staging servers or other environments that are highly volatile and constantly built and torn down. Google is getting pretty draconian with their policies and changes.
Recidivism rates are highly impacted by the inmates support and contact with family and friends. This is likely a secondary factor of why the prisons want to move to no in person visits. Private prisons have a serious issue in, the companies actually benefit from increased crime and greater offenses (ensuring a longer stay). It's pretty sad, we really need to regulate the prison system or just nationalize it, but way too many would fight the idea because they feel the tax payers shouldn't shoulder the burden (even though we already do simply because we are paying the prison companies' contracts) or fight any laws regulating businesses...
Pretty much the nail on the head. The main reason that something will have to change is that all these companies that are having these thoughts will have to realize (and quite quickly) that if a large portion of the work force is jobless, they are also going to have no money, ergo no one will be able to purchase from the company. Now, one could argue that this creates an oppressive loop where they give out and take back the money in just such a way as to keep the world turning, but not allow anyone a way to the upper class. However, that is a bit hyperbolic. It would also require a lot of other things to go awry before that situation would come to fruition, and I would hope the people of the world would see if before it happens.
To illustrate how quick it would have to change, remember when unemployment was at 8 and 9%? Imagine if it suddenly jumped to 15% how much it would crush some of the these industries. There is a vested interest in keeping the system running the way it does now. It would require some very radical things to create the dystopian future that so many fear AI will bring about. Remember, only a few of those stories with such a terrible future actually even show or explain in any real depth how it got to that point, and even then the writers can literally control for everything.
While I subscribe to a lot of that school of thought (i.e. I love learning to work on stuff and being able to do things myself) there are two flaws. One, time. I know how to do a whole lot of stuff, but the time it takes me to do it can often be better spent elsewhere. I know how to mow my yard just fine for instance, but it is nothing more than a chore in my eyes hence why I pay someone to do that for me. Another example is I have firesticks throughout my house with, we will say special software, loaded onto them. I can easily do that work myself if I were so inclined, but I paid a friend to do it for me because he already had everything set up to do it quickly and cheaply. It is absolute insanity to try and do all of that work yourself because then you never have time for anything EXCEPT work.
Two, the entire point of our economy currently is specialization and selling services/products that are supposed to be better than what a person gets on their own/at home. I can do pretty good carpentry work, and do on the regular because it saves me money in the long run. I actually enjoy cooking a lot, and can make some fairly superb meals (or at least I'm told). That does not mean that I will produce the quality of work that Nick Offerman or Gordon Ramsay can do in their respective fields. Sometimes, it makes more sense to have someone else do it who is more highly skilled than you are at that job.
Not to mention, if I am not planning to do something repeatedly and don't just have an interest in learning it, it would save time and probably money to just pay for it from a professional. For instance, I can work on my own car and do from time to time if the fixes or maintenance is not overly time consuming (thermostat replacement, air filter changes, etc.). However, I do not own many of the more advanced automotive specific tools that would cost a lot of money and time to learn so certain repairs like replacing my catalytic converter I took to my trusted mechanic.
Same principle applies here, many of these people might even be able to figure out how to work on their own computer (Google/DuckDuckGo is quite valuable), but they don't have the time to learn something they are not going to do on the regular. Even those that do know how, they may not have the tools to do so effectively/legally and it is perfectly reasonable that they expect an entity such as Office Depot could provide at least basic service and not be essentially running a large scale phone scam.
We've seen it for a long time, these are just the most recent examples of it. I've respected many of these engineering companies for years, but truth be told their upper management is no different than the other industries' executives. I question what unscrupulous developer/person put the tool together knowing damn well it could not even detect malware. It is probably some basic as hell WCF, but anyone doing it knew how unethical their actions were. It's just like whoever developed the emissions cheat software at VW. They knew it was wrong, there was no way they didn't, and they should have stepped up and said no. I like my job too, but if they ask me to do something unethical I don't care if I get fired on the spot, not happening.
Yes, we should also demand they pay for all of the malware they the allowed to infect their system right (although apparently not in these instances!)? The OS vendor doesn't control what is written for their system outside of, here is the system APIs, do what you will. Apple and Linux can have the same things done to them. Anyone running Linux would likely say, 'eh, if true I'll fix it myself.' and Apple users are already getting scammed by the markup they pay for that hardware...
That is a complete crock. The same digital monitoring and care can be done with a modular battery if they take the time to engineer it (which really isn't that much effort). In fact there are a number of modular batteries that have on-board status monitoring that merely feeds the device that information.
Beyond that a contact connection vs a soldered connection has very minimal difference from a safety perspective. Even then, at the voltages/currents these batteries are typically running the contact connection will never arc therefore eliminating the one real risk. Most of the fires have come from the actual construction of the cells being far too dense and/or the battery getting punctured. The galaxy incident for instance was traced to exactly that.
The other issues that I'm familiar with mostly concern gas expansion inside the sealed battery compartment. My Razer Mamba mouse's battery over time would bloat so much with gas that the compartment stopped being able to close. After some research I discovered it was fairly common and a little dangerous if punctured because it was highly flammable. Bottom line, don't buy into that bunk crap, they could and have made them modular for years and it would still be plenty safe.
Well yea that was generally my point, although one could argue if the CTO knew he was not qualified to hold that position he shouldn't have taken it. If the CTO was in that position without at least a reasonable amount of experience and qualification then he could be in the wrong too. Hubris does not excuse someone from an action that harms or could potentially harm millions of people.
I would be in the wrong to take a CFO position if offered because I don't have anywhere near the experience in financials to qualify me for that. Just because I do play around in the markets and probably have a higher than average knowledge concerning financials doesn't mean it wouldn't be irresponsible.
If this is willfully ignored, then the jail time option needs to become available.
It was not willfully ignored. The CTO was a music major. All the evidence points to oblivious incompetence. There was no decision to be evil and greedy by trading security for profit, because they were too dumb to realize such a tradeoff even existed.
If we are going to incarcerate people for incompetence, we are going to need a lot more prisons.
Not really sure that is an excuse here though. This is a company that literally makes billions off of holding people's information in IT infrastructure. Don't you think that it should be obvious that they need to have a CTO and CIO at the very least educated on what the hell they are doing/in charge of? If they are not then that in and of itself constitutes willful negligence on the part of the board and those responsible for hiring them. If I hire an incompetent engineer to work on my team, knowing they do not have the background necessary to do the job, don't you think those above me are going to hold me accountable?
Why make excuses for company's failings at the most basic levels. It would be different if they had a state of the art system and it was still breached. Hell, it would be different if they were in the process of bringing an ancient system up to date, but they were running on horribly outdated systems and those in charge of making the decision to upgrade didn't even possess enough knowledge to know they should upgrade? That isn't an excuse, it is just being irresponsible.
Or, you know, they could obey the laws like the rest of the country? I don't get how that is an excuse at all. Unless a person is planning to commit illegal acts they really shouldn't have an issue with some laws that mean they need to protect people. The only argument is they just don't like the risk, but we all have to take on risk proportionate to the reward and when you are making fuck-you levels of money it should be understood to have greater risk.
The argument, "ok, define it then" doesn't really hold up well either. We define what negligence and best efforts are all the time, why exactly do you think computer security can't have the same standards applied? Just because a person fails to define something on the spot, by themselves, without a law degree, doesn't mean we simply can't do it or shouldn't do it. Civil engineers get sued all the friggin time. When they are criminally negligent the charge(s) become criminal and not just civil. The person ultimately responsible for making the decisions should be held accountable
People still have this idea that software/IT is somehow so magically different from everything else in the eyes of the law, but it can be regulated in basically the same ways. Bring in some experts, talk to some damn congressional representatives, do the due diligence, and stop letting these ass holes skate the responsibility. Literally the only people that benefit from no liability are the C-suite execs. If you think it is acceptable to just let people's lives get destroyed to make a couple extra bucks then you need to examine your own morality and ethics.
Knowing Google, they will offer a magic sync through the Google account. However, their standard is supposed to be device agnostic from what I understand. I think you are supposed to be able to transfer it through some type of data import/export mechanism typically, but I'm sure the details of that would be handled by the company implementing the standard in their own application(s).
I'm not sure what you mean? FIDO is a standard, they aren't actually selling anything. It also actually removes some of a user's information from being under the control/protection of the online services...
You do bring up a solid point that them being able to issue root certificates is a significant problem if abused, but I don't think they can impersonate a user that has registered to the service with their own keys. The certificate is merely to certify they are who they say they are for whatever purpose.
The problem is that since the FIDO challenge contains a challenge question that must be answered to authenticate (and it is encrypted and can only be decrypted using the user's private key), even a root CA can't answer it without the user's private key. They could impersonate that they are the ones that are supposed to be receiving the challenge without issue, but they would be unable to answer the challenge because they can't read it. Now this assumes the implementation does not key off of the certificate itself, but everything I read says the user has control of whatever secret they want to use to lock their key(s).
Technically, if I understand how the standard is intended to be used, this actually solves some of the CA abuse cases simply because without access to the user's secret no one can actually impersonate them. Whereas under the current system a CA could easily spoof the login page of popular services, issue a valid certificate and harvest all those secrets as people trust them. Under the FIDO standard they can't obtain the secret, the private key for the service, or much of anything beyond possibly the unique service ID for a user.
I imagine one of the mechanisms for FIDO authentications retrieval of a private key is actually entering a password. The difference is the password never leaves the device nor does the private key itself. This is also a standard not necessarily a specific device/ecosystem/vendor/ etc. which we are already extremely dependent on thousands of standards to do anything with technology.
I mean, that was already the case though? Same with Windows really. The attack surface of breaching user devices to steal secret information isn't miraculously materializing from this standard, it was already there. If one's phone were compromised then the keylogger on it is already stealing all your credentials and what site they go to.
At least with this type of standard the user device HAS to be hit in order for the private key to be compromised. This actually decreases the attack surface and makes remote exploitation more difficult since now breaching the site doesn't actually get you full access to user credentials. Not only that, it would at least allow for a larger portion of the security levels and status to be determined by the user rather than a service just forcing them on their users with varying levels of success/caring.
Hell with some additions to the standard you could actually restrict data access on the server to a private key held on a local device that is given only while the data needs to be accessed. The user would have to trust the service to discard the key after actions have completed, but the user's now are having to trust the service to safeguard their data. Some services would never do it either simply because then they can't access the user's data for harvesting, but if a service wanted to offer really high security this is a possibility. It would render stealing databases effectively useless for attackers because there is no way they would be able to break every single encryption key for every user.
I think it does from what I was reading. It may have the option to do it without the interaction, but it looks like it is setup such that the user needs to consent to unlocking the private key for that service.
It kind of is nothing actually. At least to the service, some of this depends on how sketchy Google or whomever implements the client side portion wants it to be I suppose. The user still only has to input their secret one time and the service and client systems handle the rest. The main difference is the user now handles their own secret information and doesn't have to trust the service with it. I read up on the standard and this is how it works:
User creates a local registration public/private key pair with whatever secret they want to use to restrict access on the client side. Then transmit ONLY the public key to the service which then associates this public key with a unique user ID on their system which is then sent to the client for storage and retrieval.
When the user wishes to login to the service they go to the publicly known location of said service which at 'login' sends their client a challenge first. The challenge consists of the user's unique ID and some type of one-time use question or internal payload that the client has to be able to read in order to answer. The challenge is encrypted by the service using the stored public key and then transmitted to the client to start the process.
Once the client receives the challenge, it uses the known service association to locate the expected key/value pair association and decrypt that information with the private key that only the local device has access to with the user's permission/interaction (scan your fingerprint, hit your smart card button, etc.). The client system can then validate the internal payload contains the expected unique ID (validating the service is who they say they are) and answer/sign the challenge since it can now be read. Using the internal ID or some other mechanism (some type of session key for a modified diffie-helman I think) the client then encrypts the challenge response and returns it to the service for verification.
At that point the service validates the payload matches what the client response to what it should be and authentication is complete.
There are two attack vectors I see and neither are easy to do at scale. One, compromise the registration such that when the service sets up the user with their Unique ID that was created on the service side the user associates it to the attacker's unique ID instead. An attacker could then impersonate the service and attempt to harvest information that way. It wouldn't enable a full MITM attack still simply because without access to the private key there is no way for the attacker to impersonate the client and authenticate properly with the service.
The second, obviously, is breaching the local device. As I have pointed out in a couple other posts though, attackers have to breach every device individually now though creating scaling issues. Not only that, if the authentication methods used are separated per service, it only gets the attacker access to the private key of that single service assuming they don't have persistent access and can wait for the user to use all secrets over time (essentially individual encryption on the keys themselves makes this even more difficult with minimal user interaction required still, but unlikely many users would do this without having very high security needs). Separating devices that store the private keys would also create at least segmented security as well such that the user would not lose everything if one device is persistently breached.
Generally I like the standard. I may not have everything correct, and I think some of my understanding may actually be assumed internals. If anyone has any corrections or sees issues, feel free to chime in. The service would still be able to uniquely fingerprint an individual for tracking purposes, but I don't see a way around that for single user authentication anyway. Kind of difficult to let a user be anonymous when they have a unique account on the service anyway...
Technically yes, but with this method attackers have to compromise each device locally in order to get that kind of data. I could also see authentication 'partitions' being used such that if there were a compromise it takes multiple points of knowledge to unlock different partitions. If one were so inclined you could also use an external device as the authentication method that would also need to be compromised and even hold some of this information on different devices so that in no instance are all eggs in one basket.
After reading up on the standard I am actually a fan of the design. Lets face facts, passwords have been outdated for some time.
While true, doesn't actually matter entirely in this case. Since FIDO allows you to use whatever you want on your side for authentication (Key card, biometric, password probably, etc.) you can change it or not use it at all. The challenging party doesn't even get access to what method you used for authentication locally, that never leaves the device. The difficulty to steal that data then becomes all of the hidden juicy bits are on user devices that an attacker would need to compromise individually.
Sort of at least. Depending on the agreements the company has in place they sometimes offer the inventor the patent still but the employer has rights in perpetuity. I think my employer does that for senior staff (one grade above me), but I haven't looked too deeply into it. My grandfather had a few navy patents too that he got the benefit from for a while, but I don't know the exact extent (he didn't go into much detail before he passed).
Pretty spot on point. When the market is so large why should they even compete with one another? They don't even have to directly communicate for this type of collusion to occur either. Pretty simple for all of them to just watch what the others are investing in and move on to one of the other diseases for their money making cure.
Ethically yes you are correct, but legally you are not correct. What if they argue they didn't want to take the risk of releasing the drug because of some benign side effect? There are a lot of loopholes that let them get away with this they shouldn't...
There is no guarantee your improvement on a table saw, will be wanted by anyone.
There is a significantly better chance however. That is the root issue here. Medical science is a much riskier investment than something like manufacturing table saws. The market and solution for that table saw is more well understood, can be better defined as to what people need and want, and incremental improvements can yield large profits for minimal investment.
Medical research on the other hand has very little certainty with all three of those things without manipulating what they give to the market. The market is highly volatile simply because it is difficult to predict who will have what disease/condition especially when it gets to one of the rare ones. Understanding that particular disease takes a lot of effort if you do it ethically. A table saw doesn't feel and can be poked and prodded or even ripped a part whenever needed. You can't do that with a person and you also need several persons to even have a chance at understanding the problem generally instead of on an individual level. Then trying to isolate that problem is hell because symptoms overlap so much. Finally incremental improvements may not even be possible. If they cure a genetic condition there may actually be only one genuinely effective way to do that.
You are correct that there is an issue with the business model, but I feel the solution is to stop applying a business model at all to something that really doesn't fit within that model at all.
Slashdot Mirror
Ok, here is the problem. Yes, they are rating the trustworthiness of the transaction, but in order to do that they are holding and computing vast amounts of heuristic data about you and your shopping/card usage patterns. That type of data is HIGHLY sensitive and can reveal a vast amount about a person, and there is literally nothing governing their usage of that data. They could sell it to almost anyone (probably including sanctioned governments if they get creative enough) and it would have serious implications with virtually no legal liability. Imagine a spy agency having a financial vulnerability list of who to target for recruiting. Think about the fact that they are essentially able to predict your movements and purchases with probably terrifying accuracy. This is a digital gold mine and we have no idea who might entice/force them to give them access.
Fraud prevention is important, but this type of data collection is fucking scary.
No. Granted, working in a dev environment is a bit of a corner case, but there is no reason this can't be a configuration option. I am not generating a bunch of certs for staging servers or other environments that are highly volatile and constantly built and torn down. Google is getting pretty draconian with their policies and changes.
Recidivism rates are highly impacted by the inmates support and contact with family and friends. This is likely a secondary factor of why the prisons want to move to no in person visits. Private prisons have a serious issue in, the companies actually benefit from increased crime and greater offenses (ensuring a longer stay). It's pretty sad, we really need to regulate the prison system or just nationalize it, but way too many would fight the idea because they feel the tax payers shouldn't shoulder the burden (even though we already do simply because we are paying the prison companies' contracts) or fight any laws regulating businesses...
Pretty much the nail on the head. The main reason that something will have to change is that all these companies that are having these thoughts will have to realize (and quite quickly) that if a large portion of the work force is jobless, they are also going to have no money, ergo no one will be able to purchase from the company. Now, one could argue that this creates an oppressive loop where they give out and take back the money in just such a way as to keep the world turning, but not allow anyone a way to the upper class. However, that is a bit hyperbolic. It would also require a lot of other things to go awry before that situation would come to fruition, and I would hope the people of the world would see if before it happens.
To illustrate how quick it would have to change, remember when unemployment was at 8 and 9%? Imagine if it suddenly jumped to 15% how much it would crush some of the these industries. There is a vested interest in keeping the system running the way it does now. It would require some very radical things to create the dystopian future that so many fear AI will bring about. Remember, only a few of those stories with such a terrible future actually even show or explain in any real depth how it got to that point, and even then the writers can literally control for everything.
While I subscribe to a lot of that school of thought (i.e. I love learning to work on stuff and being able to do things myself) there are two flaws. One, time. I know how to do a whole lot of stuff, but the time it takes me to do it can often be better spent elsewhere. I know how to mow my yard just fine for instance, but it is nothing more than a chore in my eyes hence why I pay someone to do that for me. Another example is I have firesticks throughout my house with, we will say special software, loaded onto them. I can easily do that work myself if I were so inclined, but I paid a friend to do it for me because he already had everything set up to do it quickly and cheaply. It is absolute insanity to try and do all of that work yourself because then you never have time for anything EXCEPT work.
Two, the entire point of our economy currently is specialization and selling services/products that are supposed to be better than what a person gets on their own/at home. I can do pretty good carpentry work, and do on the regular because it saves me money in the long run. I actually enjoy cooking a lot, and can make some fairly superb meals (or at least I'm told). That does not mean that I will produce the quality of work that Nick Offerman or Gordon Ramsay can do in their respective fields. Sometimes, it makes more sense to have someone else do it who is more highly skilled than you are at that job.
Not to mention, if I am not planning to do something repeatedly and don't just have an interest in learning it, it would save time and probably money to just pay for it from a professional. For instance, I can work on my own car and do from time to time if the fixes or maintenance is not overly time consuming (thermostat replacement, air filter changes, etc.). However, I do not own many of the more advanced automotive specific tools that would cost a lot of money and time to learn so certain repairs like replacing my catalytic converter I took to my trusted mechanic.
Same principle applies here, many of these people might even be able to figure out how to work on their own computer (Google/DuckDuckGo is quite valuable), but they don't have the time to learn something they are not going to do on the regular. Even those that do know how, they may not have the tools to do so effectively/legally and it is perfectly reasonable that they expect an entity such as Office Depot could provide at least basic service and not be essentially running a large scale phone scam.
We've seen it for a long time, these are just the most recent examples of it. I've respected many of these engineering companies for years, but truth be told their upper management is no different than the other industries' executives. I question what unscrupulous developer/person put the tool together knowing damn well it could not even detect malware. It is probably some basic as hell WCF, but anyone doing it knew how unethical their actions were. It's just like whoever developed the emissions cheat software at VW. They knew it was wrong, there was no way they didn't, and they should have stepped up and said no. I like my job too, but if they ask me to do something unethical I don't care if I get fired on the spot, not happening.
Given a plane is orders of magnitude more complex than a car, not really sure your strawman is going to hold up well.
Yes, we should also demand they pay for all of the malware they the allowed to infect their system right (although apparently not in these instances!)? The OS vendor doesn't control what is written for their system outside of, here is the system APIs, do what you will. Apple and Linux can have the same things done to them. Anyone running Linux would likely say, 'eh, if true I'll fix it myself.' and Apple users are already getting scammed by the markup they pay for that hardware...
That is a complete crock. The same digital monitoring and care can be done with a modular battery if they take the time to engineer it (which really isn't that much effort). In fact there are a number of modular batteries that have on-board status monitoring that merely feeds the device that information.
Beyond that a contact connection vs a soldered connection has very minimal difference from a safety perspective. Even then, at the voltages/currents these batteries are typically running the contact connection will never arc therefore eliminating the one real risk. Most of the fires have come from the actual construction of the cells being far too dense and/or the battery getting punctured. The galaxy incident for instance was traced to exactly that.
The other issues that I'm familiar with mostly concern gas expansion inside the sealed battery compartment. My Razer Mamba mouse's battery over time would bloat so much with gas that the compartment stopped being able to close. After some research I discovered it was fairly common and a little dangerous if punctured because it was highly flammable. Bottom line, don't buy into that bunk crap, they could and have made them modular for years and it would still be plenty safe.
Well yea that was generally my point, although one could argue if the CTO knew he was not qualified to hold that position he shouldn't have taken it. If the CTO was in that position without at least a reasonable amount of experience and qualification then he could be in the wrong too. Hubris does not excuse someone from an action that harms or could potentially harm millions of people.
I would be in the wrong to take a CFO position if offered because I don't have anywhere near the experience in financials to qualify me for that. Just because I do play around in the markets and probably have a higher than average knowledge concerning financials doesn't mean it wouldn't be irresponsible.
If this is willfully ignored, then the jail time option needs to become available.
It was not willfully ignored. The CTO was a music major. All the evidence points to oblivious incompetence. There was no decision to be evil and greedy by trading security for profit, because they were too dumb to realize such a tradeoff even existed.
If we are going to incarcerate people for incompetence, we are going to need a lot more prisons.
Not really sure that is an excuse here though. This is a company that literally makes billions off of holding people's information in IT infrastructure. Don't you think that it should be obvious that they need to have a CTO and CIO at the very least educated on what the hell they are doing/in charge of? If they are not then that in and of itself constitutes willful negligence on the part of the board and those responsible for hiring them. If I hire an incompetent engineer to work on my team, knowing they do not have the background necessary to do the job, don't you think those above me are going to hold me accountable?
Why make excuses for company's failings at the most basic levels. It would be different if they had a state of the art system and it was still breached. Hell, it would be different if they were in the process of bringing an ancient system up to date, but they were running on horribly outdated systems and those in charge of making the decision to upgrade didn't even possess enough knowledge to know they should upgrade? That isn't an excuse, it is just being irresponsible.
Or, you know, they could obey the laws like the rest of the country? I don't get how that is an excuse at all. Unless a person is planning to commit illegal acts they really shouldn't have an issue with some laws that mean they need to protect people. The only argument is they just don't like the risk, but we all have to take on risk proportionate to the reward and when you are making fuck-you levels of money it should be understood to have greater risk.
The argument, "ok, define it then" doesn't really hold up well either. We define what negligence and best efforts are all the time, why exactly do you think computer security can't have the same standards applied? Just because a person fails to define something on the spot, by themselves, without a law degree, doesn't mean we simply can't do it or shouldn't do it. Civil engineers get sued all the friggin time. When they are criminally negligent the charge(s) become criminal and not just civil. The person ultimately responsible for making the decisions should be held accountable
People still have this idea that software/IT is somehow so magically different from everything else in the eyes of the law, but it can be regulated in basically the same ways. Bring in some experts, talk to some damn congressional representatives, do the due diligence, and stop letting these ass holes skate the responsibility. Literally the only people that benefit from no liability are the C-suite execs. If you think it is acceptable to just let people's lives get destroyed to make a couple extra bucks then you need to examine your own morality and ethics.
Knowing Google, they will offer a magic sync through the Google account. However, their standard is supposed to be device agnostic from what I understand. I think you are supposed to be able to transfer it through some type of data import/export mechanism typically, but I'm sure the details of that would be handled by the company implementing the standard in their own application(s).
I'm not sure what you mean? FIDO is a standard, they aren't actually selling anything. It also actually removes some of a user's information from being under the control/protection of the online services...
You do bring up a solid point that them being able to issue root certificates is a significant problem if abused, but I don't think they can impersonate a user that has registered to the service with their own keys. The certificate is merely to certify they are who they say they are for whatever purpose.
The problem is that since the FIDO challenge contains a challenge question that must be answered to authenticate (and it is encrypted and can only be decrypted using the user's private key), even a root CA can't answer it without the user's private key. They could impersonate that they are the ones that are supposed to be receiving the challenge without issue, but they would be unable to answer the challenge because they can't read it. Now this assumes the implementation does not key off of the certificate itself, but everything I read says the user has control of whatever secret they want to use to lock their key(s).
Technically, if I understand how the standard is intended to be used, this actually solves some of the CA abuse cases simply because without access to the user's secret no one can actually impersonate them. Whereas under the current system a CA could easily spoof the login page of popular services, issue a valid certificate and harvest all those secrets as people trust them. Under the FIDO standard they can't obtain the secret, the private key for the service, or much of anything beyond possibly the unique service ID for a user.
I imagine one of the mechanisms for FIDO authentications retrieval of a private key is actually entering a password. The difference is the password never leaves the device nor does the private key itself. This is also a standard not necessarily a specific device/ecosystem/vendor/ etc. which we are already extremely dependent on thousands of standards to do anything with technology.
I mean, that was already the case though? Same with Windows really. The attack surface of breaching user devices to steal secret information isn't miraculously materializing from this standard, it was already there. If one's phone were compromised then the keylogger on it is already stealing all your credentials and what site they go to.
At least with this type of standard the user device HAS to be hit in order for the private key to be compromised. This actually decreases the attack surface and makes remote exploitation more difficult since now breaching the site doesn't actually get you full access to user credentials. Not only that, it would at least allow for a larger portion of the security levels and status to be determined by the user rather than a service just forcing them on their users with varying levels of success/caring.
Hell with some additions to the standard you could actually restrict data access on the server to a private key held on a local device that is given only while the data needs to be accessed. The user would have to trust the service to discard the key after actions have completed, but the user's now are having to trust the service to safeguard their data. Some services would never do it either simply because then they can't access the user's data for harvesting, but if a service wanted to offer really high security this is a possibility. It would render stealing databases effectively useless for attackers because there is no way they would be able to break every single encryption key for every user.
I think it does from what I was reading. It may have the option to do it without the interaction, but it looks like it is setup such that the user needs to consent to unlocking the private key for that service.
It kind of is nothing actually. At least to the service, some of this depends on how sketchy Google or whomever implements the client side portion wants it to be I suppose. The user still only has to input their secret one time and the service and client systems handle the rest. The main difference is the user now handles their own secret information and doesn't have to trust the service with it. I read up on the standard and this is how it works:
User creates a local registration public/private key pair with whatever secret they want to use to restrict access on the client side. Then transmit ONLY the public key to the service which then associates this public key with a unique user ID on their system which is then sent to the client for storage and retrieval.
When the user wishes to login to the service they go to the publicly known location of said service which at 'login' sends their client a challenge first. The challenge consists of the user's unique ID and some type of one-time use question or internal payload that the client has to be able to read in order to answer. The challenge is encrypted by the service using the stored public key and then transmitted to the client to start the process.
Once the client receives the challenge, it uses the known service association to locate the expected key/value pair association and decrypt that information with the private key that only the local device has access to with the user's permission/interaction (scan your fingerprint, hit your smart card button, etc.). The client system can then validate the internal payload contains the expected unique ID (validating the service is who they say they are) and answer/sign the challenge since it can now be read. Using the internal ID or some other mechanism (some type of session key for a modified diffie-helman I think) the client then encrypts the challenge response and returns it to the service for verification.
At that point the service validates the payload matches what the client response to what it should be and authentication is complete.
There are two attack vectors I see and neither are easy to do at scale. One, compromise the registration such that when the service sets up the user with their Unique ID that was created on the service side the user associates it to the attacker's unique ID instead. An attacker could then impersonate the service and attempt to harvest information that way. It wouldn't enable a full MITM attack still simply because without access to the private key there is no way for the attacker to impersonate the client and authenticate properly with the service.
The second, obviously, is breaching the local device. As I have pointed out in a couple other posts though, attackers have to breach every device individually now though creating scaling issues. Not only that, if the authentication methods used are separated per service, it only gets the attacker access to the private key of that single service assuming they don't have persistent access and can wait for the user to use all secrets over time (essentially individual encryption on the keys themselves makes this even more difficult with minimal user interaction required still, but unlikely many users would do this without having very high security needs). Separating devices that store the private keys would also create at least segmented security as well such that the user would not lose everything if one device is persistently breached.
Generally I like the standard. I may not have everything correct, and I think some of my understanding may actually be assumed internals. If anyone has any corrections or sees issues, feel free to chime in. The service would still be able to uniquely fingerprint an individual for tracking purposes, but I don't see a way around that for single user authentication anyway. Kind of difficult to let a user be anonymous when they have a unique account on the service anyway...
Technically yes, but with this method attackers have to compromise each device locally in order to get that kind of data. I could also see authentication 'partitions' being used such that if there were a compromise it takes multiple points of knowledge to unlock different partitions. If one were so inclined you could also use an external device as the authentication method that would also need to be compromised and even hold some of this information on different devices so that in no instance are all eggs in one basket.
After reading up on the standard I am actually a fan of the design. Lets face facts, passwords have been outdated for some time.
While true, doesn't actually matter entirely in this case. Since FIDO allows you to use whatever you want on your side for authentication (Key card, biometric, password probably, etc.) you can change it or not use it at all. The challenging party doesn't even get access to what method you used for authentication locally, that never leaves the device. The difficulty to steal that data then becomes all of the hidden juicy bits are on user devices that an attacker would need to compromise individually.
Sort of at least. Depending on the agreements the company has in place they sometimes offer the inventor the patent still but the employer has rights in perpetuity. I think my employer does that for senior staff (one grade above me), but I haven't looked too deeply into it. My grandfather had a few navy patents too that he got the benefit from for a while, but I don't know the exact extent (he didn't go into much detail before he passed).
Pretty spot on point. When the market is so large why should they even compete with one another? They don't even have to directly communicate for this type of collusion to occur either. Pretty simple for all of them to just watch what the others are investing in and move on to one of the other diseases for their money making cure.
Ethically yes you are correct, but legally you are not correct. What if they argue they didn't want to take the risk of releasing the drug because of some benign side effect? There are a lot of loopholes that let them get away with this they shouldn't...
There is no guarantee your improvement on a table saw, will be wanted by anyone.
There is a significantly better chance however. That is the root issue here. Medical science is a much riskier investment than something like manufacturing table saws. The market and solution for that table saw is more well understood, can be better defined as to what people need and want, and incremental improvements can yield large profits for minimal investment.
Medical research on the other hand has very little certainty with all three of those things without manipulating what they give to the market. The market is highly volatile simply because it is difficult to predict who will have what disease/condition especially when it gets to one of the rare ones. Understanding that particular disease takes a lot of effort if you do it ethically. A table saw doesn't feel and can be poked and prodded or even ripped a part whenever needed. You can't do that with a person and you also need several persons to even have a chance at understanding the problem generally instead of on an individual level. Then trying to isolate that problem is hell because symptoms overlap so much. Finally incremental improvements may not even be possible. If they cure a genetic condition there may actually be only one genuinely effective way to do that.
You are correct that there is an issue with the business model, but I feel the solution is to stop applying a business model at all to something that really doesn't fit within that model at all.