Re: Browser Payments API proposal

[Elliott Sprehn]

I'm not sure this is a problem worth solving in the platform. In 5-10 years
I doubt we'll be typing our card numbers into pages. You'll tap your phone
to your laptop or use some kind of payment service like paypal/wallet/etc.

There's so many security/privacy issues with exposing your payment
information behind an infobar to any page that requests it.

On Tue, Jun 19, 2012 at 10:15 AM, Yaar Schnitman  wrote:

> Nice idea Alex!
>
> I have done some work on this in the past, but it didn't go very far. A
> few tips:
> 1. As long as many users don't have this, websites would still have to do
> form-based credit-card forms. But browsers and extensions are getting
> pretty good at auto-filling these forms. So you have a tough competition
> from the entrenched technology and there are ways websites can help the
> auto-complete work even better (e.g. proper element names).
>
> 2. The permissions dialog needs to be more visible and proactive. Users
> (even advanced ones) often miss the permissions prompts.
>
> 3. Requiring the user to type a security code / pin every time you give a
> site your credit card info might increase awareness and security.
>
> 4. Can we do something that doesn't require scripting? Maybe a new tag?
> The motivation for that is embedding one click payments in emails where
> scripting is disabled.
>
> 5. Minor things: How to deal with multiple credit cards? What if a site
> only suports AmEx but not Visa?
>
>
> On Sun, Jun 17, 2012 at 5:34 AM, Arthur Barstow wrote:
>
>> On 6/16/12 8:16 PM, ext Alex MacCaw wrote:
>>
>>> The blog article link has changed to: http://blog.alexmaccaw.com/**
>>> preview/**Pc1LYBw4xDT95OPWZGihod7z8Whrnf**AdXMjQxMDg3MTc5NDIaXNjA1p
>>>
>>
>> Alex - perhaps this API will be of interest to the Web Payments Community
>> Group 
>> >.
>> -AB
>>
>>
>

Re: Browser Payments API proposal

[Yaar Schnitman]

Nice idea Alex!

I have done some work on this in the past, but it didn't go very far. A few
tips:
1. As long as many users don't have this, websites would still have to do
form-based credit-card forms. But browsers and extensions are getting
pretty good at auto-filling these forms. So you have a tough competition
from the entrenched technology and there are ways websites can help the
auto-complete work even better (e.g. proper element names).

2. The permissions dialog needs to be more visible and proactive. Users
(even advanced ones) often miss the permissions prompts.

3. Requiring the user to type a security code / pin every time you give a
site your credit card info might increase awareness and security.

4. Can we do something that doesn't require scripting? Maybe a new tag? The
motivation for that is embedding one click payments in emails where
scripting is disabled.

5. Minor things: How to deal with multiple credit cards? What if a site
only suports AmEx but not Visa?


On Sun, Jun 17, 2012 at 5:34 AM, Arthur Barstow wrote:

> On 6/16/12 8:16 PM, ext Alex MacCaw wrote:
>
>> The blog article link has changed to: http://blog.alexmaccaw.com/**
>> preview/**Pc1LYBw4xDT95OPWZGihod7z8Whrnf**AdXMjQxMDg3MTc5NDIaXNjA1p
>>
>
> Alex - perhaps this API will be of interest to the Web Payments Community
> Group 
> >.
> -AB
>
>

Re: Browser Payments API proposal

[Charles McCathieNevile]

On Sat, 16 Jun 2012 06:05:35 +0200, Alex MacCaw  wrote:


I've been working on a way of integrating one-click payments (and signup)
into the browser, and I wanted to put it in front of a few people to get
some feedback.

The API I was playing about with was pretty simple, and is documented  
here:


http://blog.alexmaccaw.com/preview/MjQxMDcwOTcwNjAYz14YvbdZWrrVg


(that link seems to go nowhere except the front of your blog)


It's basically an API to autocomplete data, already stored in the browser
and containing things like credit card number and name.

For example:

navigator.requestProfile(['firstName', 'email', 'cardNumber'], function(
profile){ console.log('Your name is:', profile.firstName); /* ... */ });


So it seems you are just using an API to support autocomplete, but with  
magic tokens as well as the browser heuristics that are normally used.


This seems to introduce a lot of UI security issues (asking for data for  
hidden form fields or fields that are out of the rendering view, ...).


cheers

Chaals


I've also created a Chrome
extension demonstrating
the API. I think the key thing to getting adoption for something like  
this

is to keep it really simple.

Cheers,
Alex




--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan noen norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com

Re: Browser Payments API proposal

[Arthur Barstow]

On 6/16/12 8:16 PM, ext Alex MacCaw wrote:
The blog article link has changed to: 
http://blog.alexmaccaw.com/preview/Pc1LYBw4xDT95OPWZGihod7z8WhrnfAdXMjQxMDg3MTc5NDIaXNjA1p


Alex - perhaps this API will be of interest to the Web Payments 
Community Group . -AB

Re: Browser Payments API proposal

[Alex MacCaw]

The blog article link has changed to:
http://blog.alexmaccaw.com/preview/Pc1LYBw4xDT95OPWZGihod7z8WhrnfAdXMjQxMDg3MTc5NDIaXNjA1p

A few people have raised (rightfully) security considerations. From the
article:

Getting the security considerations right is key to making this work. As
browsers already store (and encrypt) credit card data, I feel that aspect
is less of an issue. Rather, it's more of a usability concern, as people
tend to blindly authorize permissions. Perhaps the answer is requiring the
card's CVC, or a countdown forcing users to read the infobar.

Alex

On Fri, Jun 15, 2012 at 6:05 PM, Alex MacCaw  wrote:

> I've been working on a way of integrating one-click payments (and signup)
> into the browser, and I wanted to put it in front of a few people to get
> some feedback.
>
> The API I was playing about with was pretty simple, and is documented here:
>
> http://blog.alexmaccaw.com/preview/MjQxMDcwOTcwNjAYz14YvbdZWrrVg
>
> It's basically an API to autocomplete data, already stored in the browser
> and containing things like credit card number and name.
>
> For example:
>
> navigator.requestProfile(['firstName', 'email', 'cardNumber'], function(
> profile){ console.log('Your name is:', profile.firstName); /* ... */ });
>
> I've also created a Chrome 
> extension demonstrating
> the API. I think the key thing to getting adoption for something like this
> is to keep it really simple.
>
> Cheers,
> Alex
>
> --
> Alex MacCaw
>
> +12147175129
> @maccman
>
> http://alexmaccaw.com
>



-- 
Alex MacCaw

+12147175129
@maccman

http://alexmaccaw.com

Browser Payments API proposal

[Alex MacCaw]

I've been working on a way of integrating one-click payments (and signup)
into the browser, and I wanted to put it in front of a few people to get
some feedback.

The API I was playing about with was pretty simple, and is documented here:

http://blog.alexmaccaw.com/preview/MjQxMDcwOTcwNjAYz14YvbdZWrrVg

It's basically an API to autocomplete data, already stored in the browser
and containing things like credit card number and name.

For example:

navigator.requestProfile(['firstName', 'email', 'cardNumber'], function(
profile){ console.log('Your name is:', profile.firstName); /* ... */ });

I've also created a Chrome
extension demonstrating
the API. I think the key thing to getting adoption for something like this
is to keep it really simple.

Cheers,
Alex

-- 
Alex MacCaw

+12147175129
@maccman

http://alexmaccaw.com