I look forward to having this service cancel right after I start using it. So to help all Hangouts Chat users I won’t be using it.
This is a service for enterprise customers, who pay real money for their services. Unless it's a total flop, it will stick around for a very long time. Even if it is a total flop, it will have a long sunset period for any companies that decide to use it.
So, you get a fare to drive 40 miles to the airport. Then what? Wait around for another - unpaid? Drive back with no fare - unpaid?
I haven't read the MIT study but unless they're including that waiting/empty driving time in the hourly calculations then they're overstating income.
Uber will quote pay per hour with a passenger in the car, but that's not the actual time worked.
The Stanford gender pay gap study did this (and lots more) correctly. They were very careful, and used a very large amount of data. They found that average pay was about $18 per hour, less about $5 per hour in fuel and maintenance costs, for a net of about $13 per hour.
Total pay wasn't really their focus, though, they were looking to see if there was a gender gap -- and found there was. Women make about 7% less than men. They were able to identify the specific causes of this discrepancy, and how much each contributed, which is a first. FWIW, 50% of the difference was caused by the men driving faster, 20% by women choosing to avoid areas that might be dangerous and 30% caused by women having less experience as Uber drivers, because women tend to take fewer fares per week and to quit driving for Uber sooner. Experience turns out to have a pretty significant effect on driver income, because the experienced drivers learn when and where to work.
Many Android phones use a four digit code, which has a 1:10,000 chance of being cracked on each attempt, assuming that codes are selected randomly. They are not, with codes representing dates being far more prevalent. That is far less secure than FaceID, but still "good enough" for most people.
Those raw numbers are pretty meaningless without taking into account brute force mitigation strategies.
In the case of Android passcodes (which includes PIN, pattern or password), there's an exponentially-increasing delay after failed attempts. It's basically impossible to get more than a couple hundred attempts[*], even if you're very dedicated and persistent. So, assuming the PIN is random and you don't have any information about it (e.g. didn't shoulder surf part of it), the probability of getting into a device is about 2% -- and that will take you a year or so.
I'm not sure what brute force mitigation is in place for FaceID, but I'm sure there is some and that like TouchID it falls back to requiring a PIN.
As a practical matter, I don't think brute force is a viable attack strategy for either. It's such an obvious attack that it will have been mitigated. What's more concerning about FaceID is the level of effort required to make a mask of the owner that will do the job. Note that fake fingerprints can absolutely be used to fake out every fingerprint scanner in existence, so as long as the difficulty of making a fake face is comparable to that of making a fake finger, overall security is probably about the same. Actually, face has a small advantage over fingerprint in that if you find a lost phone you may not be able to get a scan of the owner's face, but you can almost certainly find a copy of their fingerprint on the device.
[*] I'm not particularly happy with how slowly the Android delays grow, or with the fact that they're capped at one day per attempt. I've argued hard for a more aggressive delay schedule, but got shut down by UX. Note that device makers are free to use a more aggressive schedule, and some do. The Android Compliance Definition Document just says they can't use a less aggressive one.
I think OP's point is, nobody _should_ like it (even if they think they do). Because it's completely insecure by default.
It has a false positive rate of 1 in 50,000. That is plenty good enough for most people. I don't store nuclear launch codes on my cell phone, and I am not too worried about the NSA seeing my grocery list.
That's the false accept rate (FAR) when presented with another person's face. Several people have demonstrated that if you show it a 3D mask of the owner's face that is approximately the right temperature, the FAR is very high.
The issue is that your code only documents what the code is doing, not what it is supposed to be doing.
You can document that with good names. No need to add comments that are likely to become actively misleading.
Javadoc-style comments are useful (and, actually, if you're writing appropriately-small functions provide all the space you should ever need for documenting the rationale), but inline comments are a code smell. If you feel the need to type a comment explaining what a small block of code does, that's a hint that the block should be factored out so that you can name it something that documents its purpose. Then the function call will be self-explanatory -- and your code will be more modular and probably more testable as well.
You wouldn’t believe how many subtle issues I’ve come across over the decades where on the face of it everything should have been good, but in reality the code was behaving slightly differently than what was intended.
I would absolutely believe that because I've been there more times than I can count... and most of them were cases where the code was commented but the comments were wrong. This has happened to me so many times that when wading into complex new code I often make a pass first and delete all of the inline comments. And I treat those that remain with skepticism and never believe them without double-checking the code.
The problem with comments is that they bitrot more than the code does, because code often gets changed without careful updates of the comments.
Note, however, that when I'm teaching beginning programmers, I teach them to comment the hell out of the code. Beginners forget that their primary audience isn't the compiler, it's other programmers. Once a programmer has a few years of experience under his or her belt, though, it's time to start treating comments as a hint that the code needs to be improved until the comment is unnecessary.
If they acknowledge that the school guard's reaction was anything besides extraordinary (and extraordinarily unusual) cowardice then it exposes the ridiculousness or arming teachers.
The one thing has nothing to do with the other,
They are related because in both cases you're expecting ordinary people to transform into action heroes.
Nonsense. Look up any of the plethora of news stories about ordinary citizens carrying concealed weapons who successfully defended themselves or others. There have even been some cases where this happened at schools (Pearl High School, Appalachian School of Law, etc.).
Also, there's a deterrent effect to consider. Mass murderers don't choose their venues at random, and part of the thing that makes schools so attractive is that there is generally no one present capable of fighting back. Note that that is not the case in Utah, where I live, and where teachers have had the legal right to carry on the job for nearly 20 years. Since that law was passed there has been no case of a school shooter in the state (there have been a couple of kids who were caught with guns at school, and one who accidentally shot and injured another), and it's possible that the fact that there are concealed guns in every school may have contributed to that. Everyone knows that the schools are not soft targets. There's no way to know for sure, of course. What we can say with certainty is that the horror stories about kids "finding" their teachers' guns has not happened at all.
Getting people to kill is a lot harder than you think it is
Yes, yes, I've read On Killing. Getting people to kill is hard... getting people to defend, even with deadly force, is much, much less so. Grossman makes this point quite clearly. Assuming you've actually read the seminal work on this topic, you should re-read it.
And if your armed teacher is only protecting their individual physical classroom you might do better with just having a locked door.
Locks are good, in fact locks are an excellent idea. But having several people capable of actually responding on-site, in addition to locks, is even better.
after the bells start ringing and the company becomes rich and successful, a different sort of people climb aboard
When a company grows enough, every sort of person climbs aboard. You can't hire tens of thousands of people without getting all sorts. You can weed out some of the obvious problems in the hiring process (e.g. the AC who replied to you would probably "out" himself pretty quickly), but some will get through.
If they acknowledge that the school guard's reaction was anything besides extraordinary (and extraordinarily unusual) cowardice then it exposes the ridiculousness or arming teachers.
The one thing has nothing to do with the other, unless you believe that the argument for arming teachers is that you expect them to transform into an impromptu SWAT team. That would be ridiculous. If, on the other hand, you expect them to hunker down with their students, but now with the ability to respond effectively if the shooter comes to them, then it makes a lot more sense.
The NRA is the lobby for gun manufacturers. Nothing more nothing less
This is a very common error, but the fact that it's so common does not make it less of an error. Even the most rudimentary analysis of NRA funding shows that it's false.
The overlords will never learn that they'll never be able to produce legions of cheap engineers, programmers, or whatever else.
I don't think this has anything to do with that. It makes perfect sense to me. In this computer-driven society, it makes sense that everyone should have exposure to basic concepts in information theory and programming for the same reasons everyone should be exposed to algebra, grammar, basic physics, biology, the rudiments of some foreign language, etc.
Until they find a half-dozen patents in their portfolio that you have also infringed. Sure, they're all obvious and none of them should have been patented at all, and for a few million dollars each you can prove that in court. At least, that's how it works in software.
Yes, and it has nothing whatsoever to do with my argument. You're describing some technical aspects of the payment process, and some history. This is irrelevant to the thread's subject, which is Google's tracking of your offline purchases.
Okay, after reading it, also engage your brain. Note that if you're purchasing stuff using Google's app (or Apple's) they don't need to actually be part of the financial transaction to track your purchase. It would be silly for Google to spend money just to get data they can already get.
Some part of human advancing far more than the rest of the world ? Be it Atlantis or Wancanda or whatever ? Nan. See most tech is based on advanced from earlier tech. This is why the world advanced more or less by period, the WHOLE world. But having par utterly isolated and having such advanced tech ? Difficult to swallow
Meh. Wakanda had access to a very flexible and easy-to-use energy source that the rest of the world didn't have. This enabled them to become relatively advanced early on and convinced them that they needed to hide themselves. They were also in a position to coopt all of the advances made by the rest of the world while keeping their own secrets. Works for me.
Now, the fact that they seemed to have only a single research scientist in the entire nation, that was hard to swallow.
Google Wallet was based on a debit card - you paid, Google was told about the transaction and Google then charged you. This double-billing meant it was easy to get funding sources (Google even ate the transaction fees), but it required retailer support.
Google wanted to insert themselves into every transaction. Apple Pay was a more secure credit card.
Google didn't want to insert themselves; it was the only technically feasible option at the time that wasn't impossible to scale.
The debit card thing was the second implementation of Google Wallet, not the first. Being involved in every transaction that way cost Google money, because they were doing a "card present" (low fee) transaction with the merchant and a "card not present" (high fee) transaction with the backing credit card. So on every transaction Google collected a small fee from the merchant and paid a larger fee to the backing credit card issuer.
Why did Google do that? Could they not do the math and realize that losing money on every transaction was a bad idea? No, they knew that perfectly well, and budgeted for it, because it seemed to be what was necessary to drive adoption.
The problem with the very first implementation of Google Wallet (before the debit card workaround) was that it was a direct implementation of the EMV specifications, which required that the transaction be performed by an embedded secure element chip (eSE) in the phone, and that the credit card issuer have systems in place to provision the card data into the secure element. This meant that in order to use Google Wallet you had to have the right phone (Nexus S or Galaxy Nexus), the right credit card (IIRC, Citibank was the only bank that was set up for it) and you had to find a retailer with a terminal that could do it.
That worked great for prototyping and small scale testing, but it clearly was never going to scale quickly. Google worked with various retailers to get them set up for NFC payment, but the other two parts of the problem -- getting eSEs in a wide variety of phones and getting permission to install the necessary code on them, plus getting all of the banks set up to deal with NFC provisioning, those were harder.
The solution to the first problem was to abandon the eSE and create a new approach called "Host Card Emulation". The idea was to move the crucial cryptographic secrets out of the phone entirely and keep them in a Google server (secured in a data center, etc.). That enabled Google Wallet to work on any Android device, not just devices with an eSE. In addition Verizon, AT&T and T-Mobile had been fighting for ownership and control of the eSE, and ultimately launched their own competitor to Google Wallet, originally called ISIS and later renamed SoftCard (after the name acquired unpleasant connotations). Abandoning the eSE solved that problem, too.
The solution to the second problem was the debit card thing. With that setup, any credit card or debit card could be used, and the issuing bank didn't have to lift a finger. In fact, even better, they made more money because Google way paying them higher fees, *and* Google was taking all of the fraud risk.
Note that there was another solution waiting in the wings, which had been in development for some time: Network tokenization. That allowed the networks to provision payment credentials into devices, so only a small number of systems had to be NFC-enabled, not every single bank in the world (as had been envisioned in the original EMV design). The networks were dragging their feet on that and it wasn't clear when it would actually be implemented, and Google didn't want to wait.
Apple waited for tokenization, and when it was ready launched with typical Apple marketing flair. Shortly afterwards, Google completed its own transition to network tokenization, and at the same time as the technology change was launched, also rebranded the tap-and-pay part of Google Wallet as Android Pay.
This is what? The 5th attempt from Google on the digital payment market?
Not really. There's really only been one attempt, that has been rebranded twice (Google Wallet -> Android Pay -> Google Pay) and changed the underlying technology twice -- the first time because they were using an embedded secure element which the carriers wanted to control, and the second time because network tokenization was finally ready (Apple waited until it was before launching).
However, there is a lot of confusion because Google Wallet included a bunch of other stuff under the same name, and that set of stuff has changed several times. But the tap-and-pay story has been pretty consistent and with only minor variations in user experience since it launched seven years ago.
Why can't I use my Apple Device to send Cash to an Android User?
Because that would require the Android device receiving the payment to be a payment card acceptance device, with a contract with a merchant acquiring bank. There are both technical and contractual limitations in the NFC/EMV world that make this difficult. Same story if you wanted to do this with the phones reversed, or with two Apple devices or two Android devices.
Why do stores need to support each device separately?
They don't. Both systems use small variants of the standard protocols, and both are well-supported by all major card acceptance devices. If stores accept one and not the other, that's the store's choice. I'm not sure what would motivate them to do that, and I've never seen one that does, but I guess some must do it.
While I ask the question, the answer is relatively simple. Each company wants to be the leader in the area, and wants their technology to win, so they don't need to pay royalties to the other.
No, both use the same technology and neither are due any royalties.
Sometimes competition is good, other times it steps on each other and creates problems for the consumers that most just don't want to deal with.
Obviously not. But, at some point it will become easier to build some things in space, especially things that can't be built in a gravity well at all. Automated orbital factories are a long way off, but an orbiting 3D printer is a big first step down that long road.
Just like living on Mars. It is so much easier than living on Earth.
Now you're just making shit up. No one with half a brain has ever made that claim.
And now we have AI which makes it even easier.
The sort of AI we have now probably does make some things easier, though I don't claim to know what. The sort of AI we will eventually build will definitely make things easier.
Your entire premise seems to be that what we know how to do now is approximately all we'll ever know how to do. You should really rethink that.
Give it up. AI nutters don't really understand computers. They just think it is magic and that AI is going to appear.
I deeply understand computers, don't think it is magic, and do think that AI is going to appear.
It won't appear magically, but through experimental research into how cognition works. I don't expect strong AI to come until we understand how to build it, but anyone who says that's never going to happen is engaging in supernatural thinking. There's nothing magical about our brains, therefore there's nothing -- other than lack of knowledge -- preventing us from building strong AI.
And it is abundantly clear that once we do figure out how to build strong AI, we will give that knowledge to the AI for use in designing its successor. The AI Singularity is inevitable. How far we are from it is unknowable, because we won't build strong AI until we have developed a good theory of cognition, and we cannot know whether that breakthrough is minutes or centuries away.
My hope is that this will not devolve to the point of what is going in the Rust community (just look at some of the comments posted here everytime a rust-related story pops up)
Note that the comments on slashdot are not a good yardstick for measuring the state of the Rust community. If you want to do that, spend some time in it. What you'll find is that it's a friendly, helpful place that is respectful and generous to everyone. Also, quite effective.
Slashdot Mirror
I look forward to having this service cancel right after I start using it. So to help all Hangouts Chat users I won’t be using it.
This is a service for enterprise customers, who pay real money for their services. Unless it's a total flop, it will stick around for a very long time. Even if it is a total flop, it will have a long sunset period for any companies that decide to use it.
So, you get a fare to drive 40 miles to the airport. Then what? Wait around for another - unpaid? Drive back with no fare - unpaid?
I haven't read the MIT study but unless they're including that waiting/empty driving time in the hourly calculations then they're overstating income.
Uber will quote pay per hour with a passenger in the car, but that's not the actual time worked.
The Stanford gender pay gap study did this (and lots more) correctly. They were very careful, and used a very large amount of data. They found that average pay was about $18 per hour, less about $5 per hour in fuel and maintenance costs, for a net of about $13 per hour.
Total pay wasn't really their focus, though, they were looking to see if there was a gender gap -- and found there was. Women make about 7% less than men. They were able to identify the specific causes of this discrepancy, and how much each contributed, which is a first. FWIW, 50% of the difference was caused by the men driving faster, 20% by women choosing to avoid areas that might be dangerous and 30% caused by women having less experience as Uber drivers, because women tend to take fewer fares per week and to quit driving for Uber sooner. Experience turns out to have a pretty significant effect on driver income, because the experienced drivers learn when and where to work.
Many Android phones use a four digit code, which has a 1:10,000 chance of being cracked on each attempt, assuming that codes are selected randomly. They are not, with codes representing dates being far more prevalent. That is far less secure than FaceID, but still "good enough" for most people.
Those raw numbers are pretty meaningless without taking into account brute force mitigation strategies.
In the case of Android passcodes (which includes PIN, pattern or password), there's an exponentially-increasing delay after failed attempts. It's basically impossible to get more than a couple hundred attempts[*], even if you're very dedicated and persistent. So, assuming the PIN is random and you don't have any information about it (e.g. didn't shoulder surf part of it), the probability of getting into a device is about 2% -- and that will take you a year or so.
I'm not sure what brute force mitigation is in place for FaceID, but I'm sure there is some and that like TouchID it falls back to requiring a PIN.
As a practical matter, I don't think brute force is a viable attack strategy for either. It's such an obvious attack that it will have been mitigated. What's more concerning about FaceID is the level of effort required to make a mask of the owner that will do the job. Note that fake fingerprints can absolutely be used to fake out every fingerprint scanner in existence, so as long as the difficulty of making a fake face is comparable to that of making a fake finger, overall security is probably about the same. Actually, face has a small advantage over fingerprint in that if you find a lost phone you may not be able to get a scan of the owner's face, but you can almost certainly find a copy of their fingerprint on the device.
[*] I'm not particularly happy with how slowly the Android delays grow, or with the fact that they're capped at one day per attempt. I've argued hard for a more aggressive delay schedule, but got shut down by UX. Note that device makers are free to use a more aggressive schedule, and some do. The Android Compliance Definition Document just says they can't use a less aggressive one.
I think OP's point is, nobody _should_ like it (even if they think they do). Because it's completely insecure by default.
It has a false positive rate of 1 in 50,000. That is plenty good enough for most people. I don't store nuclear launch codes on my cell phone, and I am not too worried about the NSA seeing my grocery list.
That's the false accept rate (FAR) when presented with another person's face. Several people have demonstrated that if you show it a 3D mask of the owner's face that is approximately the right temperature, the FAR is very high.
I'm sure some folks at Google for example use Windows products despite it being from a competitor (Microsoft).
Very, very few. OTOH, MacBooks are everywhere.
The issue is that your code only documents what the code is doing, not what it is supposed to be doing.
You can document that with good names. No need to add comments that are likely to become actively misleading.
Javadoc-style comments are useful (and, actually, if you're writing appropriately-small functions provide all the space you should ever need for documenting the rationale), but inline comments are a code smell. If you feel the need to type a comment explaining what a small block of code does, that's a hint that the block should be factored out so that you can name it something that documents its purpose. Then the function call will be self-explanatory -- and your code will be more modular and probably more testable as well.
You wouldn’t believe how many subtle issues I’ve come across over the decades where on the face of it everything should have been good, but in reality the code was behaving slightly differently than what was intended.
I would absolutely believe that because I've been there more times than I can count... and most of them were cases where the code was commented but the comments were wrong. This has happened to me so many times that when wading into complex new code I often make a pass first and delete all of the inline comments. And I treat those that remain with skepticism and never believe them without double-checking the code.
The problem with comments is that they bitrot more than the code does, because code often gets changed without careful updates of the comments.
Note, however, that when I'm teaching beginning programmers, I teach them to comment the hell out of the code. Beginners forget that their primary audience isn't the compiler, it's other programmers. Once a programmer has a few years of experience under his or her belt, though, it's time to start treating comments as a hint that the code needs to be improved until the comment is unnecessary.
If they acknowledge that the school guard's reaction was anything besides extraordinary (and extraordinarily unusual) cowardice then it exposes the ridiculousness or arming teachers.
The one thing has nothing to do with the other,
They are related because in both cases you're expecting ordinary people to transform into action heroes.
Nonsense. Look up any of the plethora of news stories about ordinary citizens carrying concealed weapons who successfully defended themselves or others. There have even been some cases where this happened at schools (Pearl High School, Appalachian School of Law, etc.).
Also, there's a deterrent effect to consider. Mass murderers don't choose their venues at random, and part of the thing that makes schools so attractive is that there is generally no one present capable of fighting back. Note that that is not the case in Utah, where I live, and where teachers have had the legal right to carry on the job for nearly 20 years. Since that law was passed there has been no case of a school shooter in the state (there have been a couple of kids who were caught with guns at school, and one who accidentally shot and injured another), and it's possible that the fact that there are concealed guns in every school may have contributed to that. Everyone knows that the schools are not soft targets. There's no way to know for sure, of course. What we can say with certainty is that the horror stories about kids "finding" their teachers' guns has not happened at all.
Getting people to kill is a lot harder than you think it is
Yes, yes, I've read On Killing. Getting people to kill is hard... getting people to defend, even with deadly force, is much, much less so. Grossman makes this point quite clearly. Assuming you've actually read the seminal work on this topic, you should re-read it.
And if your armed teacher is only protecting their individual physical classroom you might do better with just having a locked door.
Locks are good, in fact locks are an excellent idea. But having several people capable of actually responding on-site, in addition to locks, is even better.
after the bells start ringing and the company becomes rich and successful, a different sort of people climb aboard
When a company grows enough, every sort of person climbs aboard. You can't hire tens of thousands of people without getting all sorts. You can weed out some of the obvious problems in the hiring process (e.g. the AC who replied to you would probably "out" himself pretty quickly), but some will get through.
If they acknowledge that the school guard's reaction was anything besides extraordinary (and extraordinarily unusual) cowardice then it exposes the ridiculousness or arming teachers.
The one thing has nothing to do with the other, unless you believe that the argument for arming teachers is that you expect them to transform into an impromptu SWAT team. That would be ridiculous. If, on the other hand, you expect them to hunker down with their students, but now with the ability to respond effectively if the shooter comes to them, then it makes a lot more sense.
The NRA is the lobby for gun manufacturers. Nothing more nothing less
This is a very common error, but the fact that it's so common does not make it less of an error. Even the most rudimentary analysis of NRA funding shows that it's false.
The overlords will never learn that they'll never be able to produce legions of cheap engineers, programmers, or whatever else.
I don't think this has anything to do with that. It makes perfect sense to me. In this computer-driven society, it makes sense that everyone should have exposure to basic concepts in information theory and programming for the same reasons everyone should be exposed to algebra, grammar, basic physics, biology, the rudiments of some foreign language, etc.
No, let a parent get on and settled faster so the kid can get their food and go to sleep.
Every airline I've ever flown already does this. Parents with kids get to board before anyone else, including first class.
Nope/ I don't know why people woth so much hate for large corporations want to give them so much more power.
Not sure what you're talking about. I neither hate large corporations nor want to give them more power.
Not if you have the patent. Been there before.
Until they find a half-dozen patents in their portfolio that you have also infringed. Sure, they're all obvious and none of them should have been patented at all, and for a few million dollars each you can prove that in court. At least, that's how it works in software.
Did you even read the rest of the post?
Yes, and it has nothing whatsoever to do with my argument. You're describing some technical aspects of the payment process, and some history. This is irrelevant to the thread's subject, which is Google's tracking of your offline purchases.
Okay, after reading it, also engage your brain. Note that if you're purchasing stuff using Google's app (or Apple's) they don't need to actually be part of the financial transaction to track your purchase. It would be silly for Google to spend money just to get data they can already get.
Did you even read the rest of the post?
Some part of human advancing far more than the rest of the world ? Be it Atlantis or Wancanda or whatever ? Nan. See most tech is based on advanced from earlier tech. This is why the world advanced more or less by period, the WHOLE world. But having par utterly isolated and having such advanced tech ? Difficult to swallow
Meh. Wakanda had access to a very flexible and easy-to-use energy source that the rest of the world didn't have. This enabled them to become relatively advanced early on and convinced them that they needed to hide themselves. They were also in a position to coopt all of the advances made by the rest of the world while keeping their own secrets. Works for me.
Now, the fact that they seemed to have only a single research scientist in the entire nation, that was hard to swallow.
Google Wallet was based on a debit card - you paid, Google was told about the transaction and Google then charged you. This double-billing meant it was easy to get funding sources (Google even ate the transaction fees), but it required retailer support.
Google wanted to insert themselves into every transaction. Apple Pay was a more secure credit card.
Google didn't want to insert themselves; it was the only technically feasible option at the time that wasn't impossible to scale.
The debit card thing was the second implementation of Google Wallet, not the first. Being involved in every transaction that way cost Google money, because they were doing a "card present" (low fee) transaction with the merchant and a "card not present" (high fee) transaction with the backing credit card. So on every transaction Google collected a small fee from the merchant and paid a larger fee to the backing credit card issuer.
Why did Google do that? Could they not do the math and realize that losing money on every transaction was a bad idea? No, they knew that perfectly well, and budgeted for it, because it seemed to be what was necessary to drive adoption.
The problem with the very first implementation of Google Wallet (before the debit card workaround) was that it was a direct implementation of the EMV specifications, which required that the transaction be performed by an embedded secure element chip (eSE) in the phone, and that the credit card issuer have systems in place to provision the card data into the secure element. This meant that in order to use Google Wallet you had to have the right phone (Nexus S or Galaxy Nexus), the right credit card (IIRC, Citibank was the only bank that was set up for it) and you had to find a retailer with a terminal that could do it.
That worked great for prototyping and small scale testing, but it clearly was never going to scale quickly. Google worked with various retailers to get them set up for NFC payment, but the other two parts of the problem -- getting eSEs in a wide variety of phones and getting permission to install the necessary code on them, plus getting all of the banks set up to deal with NFC provisioning, those were harder.
The solution to the first problem was to abandon the eSE and create a new approach called "Host Card Emulation". The idea was to move the crucial cryptographic secrets out of the phone entirely and keep them in a Google server (secured in a data center, etc.). That enabled Google Wallet to work on any Android device, not just devices with an eSE. In addition Verizon, AT&T and T-Mobile had been fighting for ownership and control of the eSE, and ultimately launched their own competitor to Google Wallet, originally called ISIS and later renamed SoftCard (after the name acquired unpleasant connotations). Abandoning the eSE solved that problem, too.
The solution to the second problem was the debit card thing. With that setup, any credit card or debit card could be used, and the issuing bank didn't have to lift a finger. In fact, even better, they made more money because Google way paying them higher fees, *and* Google was taking all of the fraud risk.
Note that there was another solution waiting in the wings, which had been in development for some time: Network tokenization. That allowed the networks to provision payment credentials into devices, so only a small number of systems had to be NFC-enabled, not every single bank in the world (as had been envisioned in the original EMV design). The networks were dragging their feet on that and it wasn't clear when it would actually be implemented, and Google didn't want to wait.
Apple waited for tokenization, and when it was ready launched with typical Apple marketing flair. Shortly afterwards, Google completed its own transition to network tokenization, and at the same time as the technology change was launched, also rebranded the tap-and-pay part of Google Wallet as Android Pay.
This is what? The 5th attempt from Google on the digital payment market?
Not really. There's really only been one attempt, that has been rebranded twice (Google Wallet -> Android Pay -> Google Pay) and changed the underlying technology twice -- the first time because they were using an embedded secure element which the carriers wanted to control, and the second time because network tokenization was finally ready (Apple waited until it was before launching).
However, there is a lot of confusion because Google Wallet included a bunch of other stuff under the same name, and that set of stuff has changed several times. But the tap-and-pay story has been pretty consistent and with only minor variations in user experience since it launched seven years ago.
Why can't I use my Apple Device to send Cash to an Android User?
Because that would require the Android device receiving the payment to be a payment card acceptance device, with a contract with a merchant acquiring bank. There are both technical and contractual limitations in the NFC/EMV world that make this difficult. Same story if you wanted to do this with the phones reversed, or with two Apple devices or two Android devices.
Why do stores need to support each device separately?
They don't. Both systems use small variants of the standard protocols, and both are well-supported by all major card acceptance devices. If stores accept one and not the other, that's the store's choice. I'm not sure what would motivate them to do that, and I've never seen one that does, but I guess some must do it.
While I ask the question, the answer is relatively simple. Each company wants to be the leader in the area, and wants their technology to win, so they don't need to pay royalties to the other.
No, both use the same technology and neither are due any royalties.
Sometimes competition is good, other times it steps on each other and creates problems for the consumers that most just don't want to deal with.
Sometimes, but not in this case.
It is always easier to build things in space.
Obviously not. But, at some point it will become easier to build some things in space, especially things that can't be built in a gravity well at all. Automated orbital factories are a long way off, but an orbiting 3D printer is a big first step down that long road.
Just like living on Mars. It is so much easier than living on Earth.
Now you're just making shit up. No one with half a brain has ever made that claim.
And now we have AI which makes it even easier.
The sort of AI we have now probably does make some things easier, though I don't claim to know what. The sort of AI we will eventually build will definitely make things easier.
Your entire premise seems to be that what we know how to do now is approximately all we'll ever know how to do. You should really rethink that.
Give it up. AI nutters don't really understand computers. They just think it is magic and that AI is going to appear.
I deeply understand computers, don't think it is magic, and do think that AI is going to appear.
It won't appear magically, but through experimental research into how cognition works. I don't expect strong AI to come until we understand how to build it, but anyone who says that's never going to happen is engaging in supernatural thinking. There's nothing magical about our brains, therefore there's nothing -- other than lack of knowledge -- preventing us from building strong AI.
And it is abundantly clear that once we do figure out how to build strong AI, we will give that knowledge to the AI for use in designing its successor. The AI Singularity is inevitable. How far we are from it is unknowable, because we won't build strong AI until we have developed a good theory of cognition, and we cannot know whether that breakthrough is minutes or centuries away.
The candidate selection processes are not democratic. That's not a criticism, just a fact.
codes of conduct are known for being extremely toxic.
Cite?
My hope is that this will not devolve to the point of what is going in the Rust community (just look at some of the comments posted here everytime a rust-related story pops up)
Note that the comments on slashdot are not a good yardstick for measuring the state of the Rust community. If you want to do that, spend some time in it. What you'll find is that it's a friendly, helpful place that is respectful and generous to everyone. Also, quite effective.