Hacker News Reader

Comment by itry | Hacker News Reader

So we want to make payments via our phones. My first thought would be to create a protocol for this. Instead we get ApplePay and GoogleWallet and whatnot.

If the internet was invented today, we would have AppleMail instead of email and GoogleTrans instead of http.

View on HN

The payments protocol is called EMV. The wireless transport protocol is ISO14443. Then we have different branding of the combination of EMV+ISO14443 for different card issuing networks (Mastercard PayPass, Visa payWave, etc.) Apple Pay and Google Wallet are further branding of the pair of standards.

A possible reason Apple might succeed where Google Wallet failed: Apple have a better track record of telling MNOs to fuck off. It's the reason the software update process is better on iPhone, it's the reason your iPhone doesn't come with carrier bloatware, and it's the reason they can put a secure element in their phone without the MNO being the root of trust.

Google doesn't cause bloatware, Carriers and Handset makers do. One of the many consequences of OSS, people can fork and bloat to their heart's content.

Also, I haven't had one issue with software updates on my Nexus 5 (which indeed comes bloatware free). If I recall correctly, wasn't the iOS7 update a shit show?

Google doesn't write the bloatware, but its actions allow bloatware to exist on android in a few ways, as far as I understand.

- Android has an open source version (that is, a version that is completely open source). Like you mentioned, this gives carriers and OEMs the freedom to do what they want, even fork and bloat.

- Android has a mixed license version, where you get the full experience of the Google Play store, Gmail, and so forth. Google has a lot more control over who it allows to use this version, since many of the components are not free software.

Silent Circle released the Blackphone it developed off a fork of Android. This policy has allowed for bloatware, yes, but it also allows for innovators to innovate unimpeded.

I have the choice to buy a phone without bloatware and I did. I don't know why others don't do the same and then blame the OS maker for allowing their open software to be open.

These policies also allow for cheaper phones to get into the hands of the less affluent. Not everyone can afford the new iPhone, and they would rather have a phone with a bit more bloatware if it cuts the cost of the phone down to something they can reasonably afford. I would consider that a noble endeavor on the part of Google. Instead of saying, "FUCK YOU CARRIERS/OEMS, YOU DO AS WE SAY!", it offered them a means of providing cheaper phones without decimating their bottom line. They can choose to strip out all the bloat and price it high or they can bloat it up and price it low, making up the cost from the recurring fees/ad rev those apps can generate.

The thing is, I have a choice as to what experience I want.

Well, I agree with most of your statement, however, in your scenario you only have a choice in what experience you want if you have the money to buy the unsubsidized phone- anyone else has the choice to buy the subsidized bloatware phone or do without (which is more choice than they would have if the subsidized phone did not exist...)

There's another option, root and load a custom Rom. Not only will the phone run leaner (and in theory faster) but it won't have the bloat. The only investment is your time. =]

There are no "two versions of Android". That's an unnecessary confusion of the situation.

There is Android, which is a complete open source operating system tailored for touchscreen devices. It is completely open source and in principle has no dependencies on any piece of propietary software to function. Android is not usually distributed with just its open source components, however.

There is Google Play Services. This a propietary set of applications and system services that interact with Google's cloud services. Since Google's cloud services are popular - most significantly the Google Play Store for Android apps - these services almost always come bundled with devices on the market. Android and Google Play Services together are also often called "Android" (even by Google itself) which is the cause of the confusion. There is a clear difference between the two, however.

Then there are further customizations in themeing, user interface components and applications made by vendors and carriers.

The problem of bloatware is that Google has only felt responsibility for Google Play Services; the other software on the system, including Android, was the responsibility of the carriers and the vendors. Android is developed by Google as an open source and popular foundation from which to provide its services - either from Android's web capabilities or from its bundled applications.

Google exercise control over the software shipped on all mainstream Android phones through Google Mobile Services licensing (GMS includes the Play Store, gmail, maps, GCM, etc.) These restrictions could include ones which prevent MNOs and OEMs from adding bloatware, but they don't.

These restrictions would stymie innovation as well as take the devices out of the hands of the less-affluent, no bueno.

Bloatware has some good it brings, this good just doesn't have an affect on me.

Similar to taxes, I pay a ton of them and don't really get anything back aside from so-so roads. Where someone who is in a bit worse spot sees a lot of benefits from those taxes. It's something I accept as necessary, but I still do everything I can to keep them as low as possible.

But I don't go around blaming the Federal gov't because California taxes me higher than Washington would. Instead of proposing the feds restrict what can and can't be taxed, I could just move to Washington. The choice is mine! FREEDOM FTW! ;P

Yea... this argument started to go south as soon as I realized it was 5pm. Surprised it is only at 0 TBH

If I recall correctly, wasn't the iOS7 update a shit show?

Not sure what you're referring to. I'm happily using iOS7 on a iPhone 4 (a 4 year old phone) to this day.

http://www.usatoday.com/story/tech/2013/10/17/apple-ios-7-pr...

Fair enough. I didn't have any of these problems. I would say that every Mac OS update ever has generated a bunch of traffic on user forums as well, though it's always difficult to say what percentage of the user base were affected.

If I recall correctly, wasn't the iOS7 update a shit show?

No, you don't recall correctly. iOS has had the ability to update via iTunes since it's very first release in 2007. iOS users have been able to update their devices regularly to the latest and the greatest without problems for many years, while on Android it's the exception rather than the rule.

This includes iOS 7, which like previous and later releases works across a variety of new and older devices.

The only thing controversial about iOS 7 was the UI was "flatter" and more colorful which some people didm't like.

So one needs a computer with iTunes installed to update an iOS device? It doesn't do it over the air?

Also, the "update shit show" reference was toward the software that was updated, not the update process itself, regardless of the hardware/software needed to pull it off.

Source for the downvoters: http://www.usatoday.com/story/tech/2013/10/17/apple-ios-7-pr...

It's updated without need for iTunes for the past several years, IIRC.

Huh. The IO7 update bricked my iPad. I had to get it replaced in store.

I would say that an update can't get worse but at least I liked IOS7 when I got to use it so I wasn't too phased. What actually makes me much more miserable is when software updates introduce new bugs, remove features and slow the device down and I can't do anything about it.

You might not remember this, but that's exactly what originally happened.

You had CompuServe mail, and Prodigy mail, and AOL mail, and any number of internal mail systems at different companies. There was not a single mail format or agreed upon address space. Getting mail from one system to another was a huge pain.

Interesting. In fact, I do not remember that. I started using the internet some time in the 90s. I never used Compuserve nor AOL. I never heard about Prodigy.

I guess technically those were separate online services. They only connected up to the internet near the end of their lifetime.

You had to dial into AOL and Compuserve?

Yep. They had long lists of phone numbers you could dial into; when you set up the software, it would set itself up to use one near you, so you wouldn't get charged long-distance fees.

Email has been around for a long, long time. Besides the major players, there were any number of mail and public post networks that ran on hobbyist bulletin board systems (FIDONet and WWIVNet are two that come to mind on the BBS end, and BITNET was a popular academic network before TCP/IP took over the world).

Toward the end, there were gateways between (almost) all of these systems that worked more or less reliably. You had to keep a text file handy to figure out how to mung an address on network #1 so that it would delivered to network #2.

For instance, a WWIVNet user could send email to foo@bar.com by sending it to foo#bar.com@5XX, where 5xx was a WWIVNet node number in the 500 range (these were reserved for gatewaying purposes). An Internet user could send email to 23@9073 on WWIVNet by sending it to 23-9073@(some site that was running the gateway software).

Similar address rewriting hacks were used for the other networks. Some were pretty straightforward -- I remember CompuServe used addresses roughly like 888,923423. To send mail from the Internet to CompuServe, you just had to change the comma to a period and tack @compuserve.com on the end. Others were pretty arcane.

Probably more than you wanted to know. :-)

Millions and millions of people did.

There's a reason that sendmail exists, and that the sendmail book was so gigantic. Because it was terrible software, yes, but also because it was routing mail across a variety of different systems with different addressing rules and what have you.

RFC 822 didn't just come into existence one day.

That's not how it "originally happened." Perhaps you're too young to remember the days before AOL and CompuServe, but email was being used more than a decade before those services. When those services started bringing messagint to consumers, yes, they had some proprietary set-ups but that was not how it "originally happened" -- that was a short-term glitch in the much longer and more open history of email.

I am old enough to remember. Actually, because my mother worked at a university in engineering while I was in another city going to university, I could email her. It was crazy!!! My bestie and I then tried to figure out how it worked, and spammed the entire college with a "Happy Holidays Laidies" email. (It was a simpler time).

That said, no one else was using it back then unless you worked military or university. Once it started to commercialize, then you had all the walled gardens. So although you're technically correct, BBS's were still the majority of the way we were connecting back then.

At first I was inclined to have the same reaction to this news, especially concerning early rumours about this. Having read some more on it however, I now realize that it is somewhat of a knee-jerk reaction.

From what I read, Apple Pay is the following things:

- A management interface to manage payment methods on your device.

- A user interface to interact with these payment methods.

- A set of APIs to interact with these payment methods from software.

- A term for hardware and software components in the iPhone that allow interaction of these payment methods with point of sale hardware.

What Apple Pay is not:

- A payment protocol.

So Apple Pay is a payment method management application. It is not a payment protocol. The payment protocol Apple Pay uses to interface with point of sale terminals is the same EMV protocol that is used for other solutions.

Any other payment method application can also use this same EMV protocol. Many do already in fact, such as Google Wallet. I would not be surprised if Wallet was able to interface with the shown POS hardware with barely any modification to the app.

I hope anyone with more knowledge of this project could confirm this interpretation is correct.

The cynic in me winces when thinking of the mess all the banks and interested companies would make trying to get together and build a payment standard. Just look at the terrible mess of stuff like OFX.

FIX

Ah, a standard protocol where nobody implements the standard in the same way. As someone who has been working with FIX for few months, I could totally feel the pain.

Don't forget defining your own custom tag for things that already exist in the set of standard tags.

Bitcoin might be a way around this.

Also it might not be necessary for the involved parties to get together. They could release different protocols. And then the lesser used will be forgotten (like gopher is forgotten today) and the more frequent used will survive (like http has survived).

Update: Why the downvotes?

Most people either haven't heard of Bitcoin or regard Bitcoins as "internet fun bux". It's not happening (at least, not in 2014).

Well, the point of those payment systems is to make money out of fees and basically control the whole system. You cannot do that with decentralized payment methods.

Google Wallet uses exactly whatever standard let's you tap a credit card to a contactless payment terminal. I assume Apple Pay is the same thing?

They use the same tech to communicate (NFC) but Apple's security features seem unique.

Which is pretty irrelevant: what matters is whether banks/payment processors will accept it, and whether it interops with the payWave/payPass readers at merchants, which in turn depends on them installing them.

We've had high penetration of contactless in Australia for a long while now, security being "happen to physically hold the card". The bar to accept contactless payments is very low - what matters is that a merchant actually accepts them.

I was just thinking about this the other day: contactless payments is the norm in Australia, having the highest adoption rate in the world[1] I would guess that between 75-90% of retailers accept it? It's always very frustrating when a retailer doesn't accept it.

100,000 contactless terminals across the country[1], the numbers for  Pay usage in Australia would be very impressive.

[1]: http://www.smartcompany.com.au/finance/42250-australia-leads...

[2]: http://www.news.com.au/finance/money/australia-hooked-on-tap...

> We've had high penetration of contactless in Australia for a long while now

The problem with credit card payments in Australia is that many merchants charge an additional fee for using it, so I often end up paying cash anyway. This is stupid -- the payment processing fee is a cost of doing business, and should not be passed on to customers (or should be built into the pricing of the products).

The security is a little more complicated than that. There are dozens of in-application checks and controls which try to guarantee that you're who you say you are, that you're authorized to make the payment, that you have funds and that the amount to pay is within certain limits. Naturally, a stolen card could be used once or twice. But never for very high amounts and never very many times: the card will request PIN and then the thief is stuffed.

And yeah, like Australia, contactless has been growing in Europe for the last few years. It's just starting in the US and these devices will help to trigger uptake (IMO).

For what it's worth, Google Wallet never actually discloses your card. It uses a virtual MasterCard to complete the transaction.

The proxy card number doesn't change so why is this considered a feature? It discloses something which is as good as your backing real card number.

Because it will only accept one charge and only be re-enabled when needed?

and i suspect you can cancel the proxy card, without impacting your normal card which may be on file for recurring payments elsewhere.

You say this like just nobody tried till now. Well, they did try. What happened after they tried?

I still don't see how replacing a credit card (that can be used for contactless payment with Visa Paywave or Mastercard contactless) by a phone that may have a dead battery brings anything to the table.

Really, what's the point?

1) One thing less to carry around

2) The credit card gives away data that can be used for fraud. Your phone does not have to do that.

> The credit card gives away data that can be used for fraud.

Not with chip and pin or contactless it doesn't

#1 only makes sense if you ignored the word battery in the question. A phone makes a dreadful credit card. It's huge, it runs out of power, and it throws stack traces at the wrong moment.

I can leave home without my wallet. Seriously, cash/card and maybe my drivers license is the only necessary thing I need on the go most days. I can free up an entire pocket.

> Really, what's the point?

Adoption. Apple brings it's users... who just seem to adopt Apple features better than competitors' similar features.

If contactless pay is a gordian knot of user vs. merchant adoption, Apple will play the part of Alexander and untie/sever the knot.

We have NFC like this in Canada, now. It works with our credit cards though, not our phones. Apple will use the same over-the-air protocol and more obfuscation to make the same transaction.

It's not a comprehensive protocol but worth noting the http does have 402 Payment Required which hasn't been used up to now, but could be implemented with BTC.

http://xkcd.com/927/

Reply on news.ycombinator.com