-
Notifications
You must be signed in to change notification settings - Fork 42
2020 3p context
One of the main goals of developing an ecosystem of payment handlers has been to streamline checkout by making it easy for users to return stored data rather than re-type similar information across the Web. Thus, by nature, payment handlers are meant to share information with different origins.
However, as was pointed out by Pete Snyder in payment handler issue 351, browsers generally are moving in a direction of reducing this sort of access to global storage. As Pete wrote:
If I'm reading [Payment Handler API\ correctly, this would enable types of tracking that other parts of the web platform are trying to address (specifically, double-keying, or partitioning, storage by 1p-3p to prevent the 3p from tracking the user across the web). If I read the spec correctly, the standard would allow the payment processor to track the user across pages that use the processor, since the processor would always have access to the same global storage, instead of different storage for each 1p it appears under.
Updating the spec so that open window doesn't create a top-level-context, but a 3p context, would solve this problem, and would be inline with the privacy protections being pursued by partitioning storage, Storage Access API, etc.