View source for Firefox/Features/Web Payments/Privacy & Security Considerations

== Introduction ==

The [[Firefox/Features/Web_Payments|web payments feature]] enables a faster, more secure payment process for online commerce by presenting a standardized checkout flow in the browser (not loading it from a merchant website). 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., on the user's laptop computer). However, if a user has enabled the [[CloudServices/Sync|Sync feature]], then data might be synchronized across devices (strictly speaking, Sync is not a way to store user data but a way to securely share data among multiple devices).

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 [[Firefox/Features/Form_Autofill|form autofill]]. In parallel with development of the [[Firefox/Features/Web_Payments|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 [https://developer.mozilla.org/en-US/docs/Web/API/Payment_Request_API 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 [https://www.w3.org/TR/secure-contexts/ secure contexts].

* Second, because the user's form input (credit card number, 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 [https://freedom-to-tinker.com/2017/11/15/no-boundaries-exfiltration-of-personal-data-by-session-replay-scripts/ 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|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 extremely difficult for a website to trick a user into sharing this information).

== Fingerprinting ==

During an [https://blog.lukaszolejnik.com/privacy-of-web-request-api/ 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), not on card networks (e.g., Visa or Amex).

Because fingerprinting attacks are extremely creative (see the EFF report [https://panopticlick.eff.org/static/browser-uniqueness.pdf How Unique Is Your Web Browser?]), it is possible that additional attack vectors might be enabled by the W3C Payment Request API, perhaps in combination with non-payment vectors; we are investigating this possibility.

== Private Browsing Mode ==

[[Private_Browsing|Private browsing mode]] is a method whereby Firefox prevents session data from being written to local storage and protects the session data from online tracking. Because this is an important privacy feature, Firefox takes several steps to prevent a website from using the Payment Request API to discover whether private browsing mode is in force. In addition, several other protections are in place:

* By default, Firefox does not save to local storage any information that the user enters (e.g., credit card data or shipping address when editing payment details). However, the user can override this default by clicking a checkbox in the appropriate screens.
* Firefox does not automatically present in the user interface the last credit card and shipping address used at this website, even if that information is known to Firefox.
* Firefox does not update storage metadata (e.g., the last-modified or last-used time for credit card data or shipping addresses).

== 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|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 [https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API 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 [https://w3c.github.io/webpayments-methods-tokenization/ 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 [https://rawgit.com/w3c/webpayments-crypto/gh-pages/ 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).