Motivation
It’s observed that Payment Service Providers decorate their buttons with card info to increase conversion rate. This card info often includes the network icon and a part of the card number. This depends on the 3p cookie which will get deprecated under the Privacy Sandbox. In order to retain the feature, this issue proposes using Fenced Frame as a work around, and proposes a read-only mode to Fenced Frame to support this use case.
Fig: Example payment button structure
Use outside of payments
The proposal described here does not need to be restricted to payments. Any form of third-party button that wishes to show personalized information to a user, without leaking that information to the host site, could use it. Other examples may include login buttons (e.g., 'Login as Alice') or social media buttons.
High level
A typical design of the button involves:
- the merchant page of origin A, which has the payment button to capture the click.
- an iframe of origin B, shown under the button, displaying the card information.
- the 3p cookie, which provides the iframe with the user id.
- a server of origin B, where the iframe requests the user’s card info.
Since the 3p cookie will be deprecated, this design will lose a place to store the user id, and thus break the flow.
This issue proposes a new read-only mode for the Fenced Frame and a new design for the button depending on this mode. In our new design, the iframe on the merchant page is replaced with a Fenced Frame in a read-only mode. The read-only mode has a two-state design, which allows Fenced Frame to read 3p cookies without the risk of the cookie leaking out of the frame.
Upon creation, the Fenced Frame starts its life in state one, where the Fenced Frame has network access but no cookie access. The browser requests the main document and the subresources. After the load is finished, the Fenced Frame transitions to state two, where the access to the network is revoked but the 3p cookie is available to read. The Fenced Frame then reads the card info from the cookie and displays it.
Fig: Comparison of two payment button implementations.
Details
How to allow the button to display card numbers only on trusted merchants?
In the past, this was often achieved by attaching the merchant’s url as the “referrer” header to the payment server. Since the Fenced Frame doesn’t have the “referrer”(TODO: quote needed), we propose attaching the “eTLD+1” of the top level (in the frame hierarchy) page as a new “top-level-site” header to the navigation request. Upon receiving this header, the payment server can decide whether to display the card number to this top-level site.
Fenced Frame has no cookie access in state one.
In order to prevent the cookie from leaking to the payment server, the fenced frame’s navigation request should not carry the “Cookie” header.
Fenced Frame should close all output channels in state two.
The fenced frame in state two is allowed to take input from the unpartitioned cookie (read CHIP to distinguish between partitioned and unpartitioned cookie), and its url parameters, but its output channels are revoked to prevent the cookie from being exfiltrated. These channels include:
- write cookie
- send network requests
- postMessage
How the embedder can pass information into the Fenced Frame.
The embedder can pass info into the Fenced Frame through URL parameters. This enables the use cases that the embedder may want to style the payment button to make it consistent with the embedder. Note that postMessage between the Fenced Frame and the embedder in both directions is not allowed.
How the Fenced Frame can display different network icons based on the card.
The payment server can send all of the network icons as subresources of the page, setting them to hidden by default. The 3p cookie should record the card network id. The Fenced Frame can then use the network id to decide which network icon to show.
Known issues
The card info data in the cookie may get stale.
Once the card info data gets written into the unpartitioned cookie, it will need to wait until the user revisits the payment page in 1st party context to be able to update it. This poses the issue that the card info in the cookie may get stale in the meantime. For example, if the user has removed the card from their account somehow, the button would still show the removed card’s info. Users could visit the payment page in 1st party context when they visit the payment page directly, or when they click the button to open the payment popup / payment handler.