Firefox/Features/Web Payments/Privacy & Security Considerations

Introduction

The web payments feature enables a faster, more secure payment process for online commerce by loading a standardized checkout flow in the browser. This page describes the privacy and security characteristics of the initial release in Firefox, as well as a roadmap of future enhancements.

Storage of User Data

If the user opts in to storage of user data (e.g., credit card numbers and shipping addresses) for convenience in future payment flows, Firefox stores that data on behalf of the user.

This data is not stored "in the cloud" but only on the user's own device (e.g., the user's laptop computer).

Depending on what the user enters and asks to be retained for future use, Firefox will store the following data locally:

• credit card number
• billing address
• shipping address

Note: Firefox _never_ stores the credit card security code (CVV/CCV). If requested by a merchant, the user always needs to provide this information in order to complete a payment.

How Data is Secured on Device

For release in Firefox Nightly (planned in Q3 2018), user data is stored as it currently is in form autofill (see the privacy and security considerations for form autofill). In parallel with development of the web payments feature, the Firefox team is building a new secure storage method that will use native operating system services to generate a device-specific key and then encrypt data at rest using that key. Further details will be added to this section once this new method is implemented.

Data Exchange with Merchant Websites

The Payment Request API establishes a standardized payment flow, which is invoked by the merchant website and launched in the browser. This approach has several security advantages over existing payment flows:

• First, the payment request from merchant to browser and the payment response from browser to merchant are always protected by Transport Layer Security (HTTPS) because the Payment Request API can be used only in secure contexts.

• Second, because the user's form input (credit card, shipping address, etc.) is handled by trusted browser code instead of code (often third-party code) on a merchant website, it is much more difficult for unwanted data exfiltration to occur (e.g., via form tracking and session replay scripts).

Information Leakage

We have instituted several policies to ensure that user data is not leaked:

• Firefox does not share the user's full shipping address until the user approves the payment at the very end of the process (see Bug 1443735).

• Although a merchant website could gather the user's partial shipping address (country and postal code) by calling the Payment Request .show() and .abort() functions in quick succession, to prevent abuse we are implementing a minimum amount of time to display the payment sheet (thus making it impossible for a website to trick a user into sharing this information).

Fingerprinting

During an early privacy review of the Payment Request API, Lukasz Olejnik raised concerns about the ability of website scripts to "fingerprint" a user by repeatedly using the .canMakePayment() call to determine which payment methods and payment instruments the user has installed. To mitigate this risk, Firefox allows the .canMakePayment() call only in top-level browsing contexts and only after the user "gestures" to allow .show() from the website. Furthermore, Firefox matches only on installed payment handlers or supported payment methods (e.g., basic-card or Apple Pay), not on card networks (e.g., Visa or Amex).

Private Browsing Mode

In Private_Browsing private browsing mode, several additional protections are in place:

• By default, Firefox does not save credit card data, shipping and billing addresses, etc.
• Firefox does not remember the last credit card and shipping address used at this website.
• Firefox does not send user data to the website without user consent.
• Firefox does not update storage metadata.
• Firefox does not allow the website to discover whether private browsing mode is enabled.

Process Separation

To help mitigate against cross-site scripting attacks and Spectre-related vulnerabilities, care has been taken to implement the Payment Request dialog in a separate process from the process that handles credit card data (see Bug 1460425).

Data Validation

As part of the Payment Request API, the merchant website can provide certain untrusted strings to the browser; these include:

• PaymentItem label values (e.g., products in a shopping cart)
• The web origin of the merchant website (which could include mixed scripts or bidirectional domain labels)
• Error strings, especially generic error message

Firefox should validate and sanitize all untrusted strings, for instance by limiting the display length (e.g., truncate to 64 bytes or fewer, as is done for relying part names in the Web Authentication API).

User Interaction

Navigations away from a page showing a Payment Request dialog either should be prevented or the dialog should abort.

We should prevent attacks where the user is tricked into interacting with the Payment Request dialog (e.g., clickjacking), probably by implementing a security delay on the "pay" button (i.e., the button that invokes the .show() call).

An abusive website could repeatedly invoke the payment request dialog and thus hold the user hostage until they pay. To prevent this, the proposed design will allow the user to close the whole tab while the Payment Request dialog is open.

Open Issues

• What happens if the dialog appears during DOM or UI fullscreen?
• What happens if the dialog appears in different variants of popup windows? (consider window.open features)

Privacy and Security Roadmap

Future features will likely include:

• Support for tokenized credit card data (e.g., via the W3C Tokenized Card Payment Method) so that credit card numbers are not sent from the browser to the merchant; instead, the browser sends a payment authorization token.

• Support for stronger encryption of payment requests and responses using a standardized approach such as the emerging W3C Payment Method Encryption proposal.

• Reliance on underlying adjustments in Firefox to address issues such as timing-related side channel attacks (e.g., using process-per-origin separation).