Hacker News Reader

Comment by B-Con | Hacker News Reader

How is this going to be handled, as a money exchange system ("yo, here's for covering lunch for me yesterday"), or like a payment system ("send your payment to shop@gmail.com")?

It seems presented as the former:

> you can securely send money to friends and family in the U.S. - without leaving your Gmail inbox

but people will assuredly try to use it as the latter. When that happens, how will Google address fraud claims?

Edit: Specifically, I mean, how will they investigate fraud claims? Will all transactions be final (easiest), or will they try to refund people who make mistakes (harder)? And what happens when a GMail account gets hacked?

View on HN

> "When that happens, how will Google address fraud claims?"

Presumably the same way PayPal handles "personal" funds transfers - they don't.

They've specifically flagged this as between friends and family only, which is to say it comes with no warranties. PayPal also has a lower-fee version of their service for the same use case - you get the lower rate in exchange for giving up purchase protection.

This is also why when buying things online anyone who asks you to mark the payment as "PayPal gift" should be given a very stern sober second look.

If I'd be Google - I'd force senders to have 2-step authentication configured before sending money.

Google's 2 step authentication is completely useless to some of us because they don't have actual per application passwords. For example if you use an IMAP client to read gmail, then you can get an "application specific" password for it. But Google then allow that password to be used for anything. Essentially you've used 2 step authentication in order to setup 1 step authentication.

Considering Google's accounts aren't segmented by activity (there would be hundreds of activities with many added and removed all the time) that sounds like it would be a nightmare.

Google's app specific passwords are revokable which is the important part. They also can't access sensitive account operations which means you can't reset the master password if you just have an ASP.

If you lose control of your email password you can revoke it and generate a new one. The passwords are long and secure,

But that password gives you restricted access, right? It can't be used, for example, to change your account password or view your search history, etc? At least that's how I understood it?

Obviously there's nothing Google can do about the fact that people want to access their email over things like imap that aren't built with Google 2-factor in mind.

I don't know which APIs get access to the passwords. In my case I would need app specific passwords for IMAP and XMAPP and that constitutes the majority of my interaction with Google.

Yes, but they must first guess that password (which is ostensibly longer and more random than the typical passwords people choose.

> Yes, but they must first guess that password ...

My chat client, IMAP client etc all save the password. Guessing the password is the least likely avenue of attack.

> Google's 2 step authentication is completely useless to some of us because they don't have actual per application passwords.

App-specific passwords are one-factor in any case (they are "something you know" just like any other password), and are an alternative to two-factor auth for certain places where Google's two-factor auth isn't supported for one reason or another. Google's 2-factor auth requires a device (usually, smartphone app) generated code alongside your regular Google password.

Hopefully, the ASP can't be used for sending money?

Tradeoff of convenience/friction vs. security if they require it on every financial transaction, though. ACH and credit are pretty reversible.

The real issue issue is here;

> securely send money to friends and family _in the U.S._

Google Voice it's the same problem - most of the world can't use it. Instead of 80/20 this is 20/80

Money Transfer is a legal and regulatory minefield.

Telecommunication services is also a legal and regulatory minefield - one that requires less capital up-front, but just as much (if not more) bureaucratic headaches.

I'm sure they're working on it, and it's either in-progress or not worth it.

(e.g.: in the US, if you are a phone line provider, you get money for incoming calls from other providers when they call you - to the point that something like GoogleVoice could turn a profit just from those fees (unlikely, but possible - many conference call services were run like that).

In most of the world, these termination fees are not enough to provide meaningful income that makes a GoogleVoice profitable (or at the very least, not very expensive) to run.

I'm confused about how this is a "real issue". Businesses operate in certain places. I don't expect the restaurant across the street from my place to cater to the other side of the world. Why is Google required to?

It's not required, it's what Google ultimately would like to achieve, so it's a real issue for them. Being available to only a fraction of the total potential users is a real issue because if they dont manage to expand, competitors will eventually snatch the potential users.

If they're doing it wrong, let them fail.

That's just the first step, testing to a smaller set of users. If it works well, they will expand it to the rest of the world for sure.

They generally don't. Many Google services have regional restrictions and had them for years. I think they want to do these legally risky stuff within their comfort zone.

I just clicked "Get started" and didn't see anything new in Google Wallet page. But in Settings page, now there's a button to provide personal information (SSN, photo ID scan and etc.) They will probably require those for those who opt-in to use Google Wallet.

I guess they will handle it like PayPal and all the others.

Reply on news.ycombinator.com