New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 766973 link

Starred by 2 users

Issue metadata

Status: Fixed
Closed: Oct 2017
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , iOS , Chrome , Mac , Fuchsia
Pri: 2
Type: Bug

Sign in to add a comment

canMakePayment allows information leaks/fingerprinting, invisible to the user

Reported by, Sep 20 2017

Issue description

Steps to reproduce the problem:

Chrome canMakePayment has a number of interesting properties:

- fingerprinting (enumerating payment methods such as whether one has a visa/mastercard/diner/etc saved in the browser)
- there is no UI prompt when a payment 'match' is found so it can be made invisibly to the user

A demonstration here:

Requires having a cc added, and not being in incognito mode (which means it may also be a new method of detecting incognito).

Tested on Chrome Canary, desktop/android.

What is the expected behavior?
1. There should be a prompt, at least as per "a successful match to a payment method causes a user interface to be displayed mitigates the disclosure risk"

What went wrong?
No UI display, and a site learned I included visa and/or mastercard.

Additionally, in incognito mode a site knew I had all CCs included. This is made possible by the fact that canMakeRequest should be able to only query a single card (i.e. "visa") once per quota-permitted timing (30m in Chrome). So I know that the same origin testing visa and mastercard consecutively would eventually reach an exception. No exception is raised. 

Did this work before? No 

Chrome version: <Copy from: 'about:version'>  Channel: stable
OS Version: 
Flash Version:

Comment 1 by, Sep 20 2017

Components: Blink>Payments Privacy
Status: Untriaged (was: Unconfirmed)
Thanks for the report, Lukasz!

rouslan@/zkoch@: Mind taking a look at this and triaging it to the right folks?
Components: Services>Safebrowsing
This is working as intended: one query per 30 minutes. If you find a website that's abusing the system, please report them to us. Assigning to Zach for further triage.
I don't quite follow the code in I assumed you're opening iframes in different origins, but did not see anything like that in the code. An explanation would be great, thank you.

cmp.html opens a frame

<iframe style="width:0;height:0;border:0; border:none;" allowpaymentrequest src=""></iframe>

and makes a test('visa'), test('mastercard') is done on cmp.html

Project Member

Comment 6 by, Sep 20 2017

Status: Assigned (was: Untriaged)

Comment 7 by, Sep 20 2017

Components: UI>Browser>Incognito
Labels: -Type-Bug-Security -Restrict-View-SecurityTeam Team-Security-UX Restrict-View-Google M-63 OS-Chrome OS-Fuchsia OS-iOS OS-Linux OS-Mac OS-Windows Type-Bug
I'm not sure Services>Safebrowsing is a good fit. vakh: Do you think SB can/should detect cMP-abusing sites and mark them as bad in SB, or is that not something you're likely to do?

Adding UI>Browser>Incognito, given the Incognito-detection aspect of this bug.

Adding Team-Security-UX and estark: Do you think raising a UI would help/is feasible/would not have other bad security/privacy side-effects?

I'm also not sure this is a security vulnerability; it seems like a privacy bug only. Setting labels, but keeping it Restrict-View-Google just in case. says "The fact that a successful match to a payment method causes a user interface to be displayed mitigates the disclosure risk.", but I don't see a matching MUST in Is there a matching MUST somewhere else in the spec, or does the spec have a gap?

It seems like even if we did show a UI on successful payment method match, there'd still be a privacy risk: the attacker could still enumerate what payment methods failed, and thus still learn a lot about what payment methods you have. Is that true?

Comment 8 by, Sep 20 2017

Skimming around in the spec a bit more, it sounds like perhaps the authors intended that a caller MUST first call `show` before it can start calling `canMakePayment`?

Or, if not intended, would making that change in the spec be possible, and sufficient?

Comment 9 by, Sep 20 2017

Components: -Services>Safebrowsing
Safe Browsing has no plans of doing this in the near future, so removing the SB component.

> vakh: Do you think SB can/should detect cMP-abusing sites and mark them as bad in SB?
It depends on how prevalent it is. I'll bring it up internally.
The section is about new PaymentRequest().

canMakePayment() is a bit different, as it doesn't require user interaction. See the spec for it at .

I'll file a bug on tying those two sections together to make things less confusing.

The intent is that the step 3 there is where we have the ability to punish such abuse. So if we're going to do something here it should be deciding when to implement step 3 and reject with "NotAllowedError" DOMException.
In the above comment, s/new PaymentRequest()/

I filed about that section.
Seems you're in action. Just curious - though the issue is restricted, I would like to include a small public writeup on it. Wondering - when would it be comfortable for you?

I agree with assessment of palmer@ (privacy bug, and still possible to run it even with a dialog, the issue is with quota or the perception of 'origin').
By the way, I've set up a better incognito-detection PoC here:

Comment 15 by, Sep 21 2017

Thanks Lukasz, assigning to Rouslan who implemented incognito/rate-limiting
Following some more tests.

It seems that Android version might not indeed detect incognito mode. On the other hand, payment requests with any instruments appear to always return true. If so, the fingerprinting method could then test all cards consecutively there - if all were true, one could attempt to deduce that this is in fact incognito. 

How likely is it that I have visa, mastercard, amex and diner (...) cards at the same time is a matter of personal preference of course. I won't say such settings are unlikely. Then again...  

Comment 17 by, Sep 21 2017


Comment 18 Deleted


We have a bug fix incoming for enforcing the query quota in the incognito mode. It does not solve all of your concerns, but still it would be nice if we landed this bug-fix first before you disclose your findings. Would that be OK with you? Thank you.

Can you tell a date?
Let's go with 2 weeks from now: October 13. That should give us enough time to land the patch in comment #19. Does that work for you?
Just wanted some clarity whether I could include this item, or go with something else.
It's exactly what I need. Thanks ;)
In case you decide to land the patch sooner, please ping, too. Thanks.
Project Member

Comment 23 by, Oct 3 2017

The following revision refers to this bug:

commit 16ee55201af94aa06ab450abc0fd3c39bdb31f93
Author: Rouslan Solomakhin <>
Date: Tue Oct 03 19:04:42 2017

[Payments] Enforce canMakePayment() quota in incognito mode.

Before this patch, calling canMakePayment() on desktop and iOS multiple
times with different payment method names and data in incognito mode
would always return "true" to preserve user privacy. However, this
change in behavior can be used by the website to detect incognito mode,
which conflicts with the goals of incognito mode.

This patch changes the canMakePayment() implementation to always check
the query quota first. If the query quota has been exceeded, the
canMakePayment() promise is rejected with NotAllowedError in both normal
and incognito browsing modes.

After this patch, calling canMakePayment() multiple times with different
payment methods and data in incognito mode would return NotAllowedError
after the first call. This is identical to the behavior in normal
browsing mode. A website can no longer use canMakePayment() to detect
incognito mode.

Bug:  766973 
Change-Id: Ic9bc03769e7846fc639f2a6250091aa511311c39
Commit-Queue: Rouslan Solomakhin <>
Reviewed-by: anthonyvd <>
Reviewed-by: Moe Ahmadi <>
Cr-Commit-Position: refs/heads/master@{#506130}

Happy the patch landed. We still wait until 13?
Labels: -Restrict-View-Google
Status: Fixed (was: Assigned)
We can make this public now. I'm marking this as "Fixed" because we've addressed a part of the issue.

Sign in to add a comment