What happens when clearing site data?

[marcoscaceres]

Given PaymentInstruments is a persistent store, what should happen when a user clears the site's data? Should the instruments and other data all get cleared?

cc'ing @annevk, as it may have some relationship to the Storage API.

[annevk]

I suspect these are similar to credentials as stored by the user agent through autocomplete or the Credentials Management API and should therefore not be cleared along with localStorage et al.

cc @mikewest

[mikewest]

Right. My thought is that this isn't "site" data, it's user data. Chrome doesn't allow the site to affect things like passwords or content settings (e.g. "do cookies work on this site?", "what zoom level do I prefer on this site?", etc), and it seems like payment instruments (and autofill data in general) would fall into the same bucket.

[annevk]

I guess at some point https://storage.spec.whatwg.org/#infrastructure needs to be formalized a bit more so specifications can use those terms and make the implications clear.

[romandev]

I hope PaymentInstrument will not be site data(more precisely, I want to keep it even if users remove site data). But current spec says that the feature is an extension of ServiceWorker and, ultimately, it have no choice but to depend on SW lifetime. So, according to the https://storage.spec.whatwg.org/#infrastructure, we can say that "it’s a site data". (might need another kind of storage?)

[annevk]

Oh, I guess if that's the model it's indeed a rather moot discussion, but maybe that model is wrong?

[dlongley]

Hmm, I don't think PaymentInstrument is actually a "payment instrument" or "payment credential" as one would traditionally think, but rather a "hint" that the site understands and can surface to help the user make a selection. When the user selects a "hint", it is passed to the payment handler where that site will determine how to act on it.

Such a hint will likely often map directly to a particular payment credential, but it need not. It could be used, for example, to inform the payment handler site that the user has selected that they want to pay using via a particular payment handler but using a new payment credential that they haven't provided to the site yet. Or it could be used to signify "pay with my default payment credential".

That being said, I think it would be frustrating for the user if clearing site data wiped their registered "hints" and required them to revisit each payment handler site to get them reregistered. Perhaps revoking permission granted to an origin to act as a payment handler should be the mechanism by which PaymentInstruments are forcibly cleared? This seems like the least surprising option to me. If the user wants to get those hints back, they would just revisit the site to grant permission again, at which point the site could reregister hints (aka PaymentInstruments).

[annevk]

@dlongley as long as you tightly couple them with service workers none of the subtleties matter.

[dlongley]

@annevk, understood. Just putting more information out there. If we're creating a bad user experience, maybe the model is indeed wrong in some way.

[marcoscaceres]

Hmm... so maybe attaching this so directly to the service worker registration is not great.

We might want the Instruments store to live independently (in the global scope), but then weakly associate it with a service worker registration, so that it can manage the incoming events in the worker global scope. The service worker would then have access to the instruments store, but the store would not be bound to the lifecycle of the service worker registration.

[mikewest]

But current spec says that the feature is an extension of ServiceWorker and, ultimately, it have no choice but to depend on SW lifetime.

I see. In that case, I'm certainly wrong. This would be considered "site data" in Chrome, and would be affected by both the user-facing interface at chrome://settings/clearBrowserData, and the Clear-Site-Data header.

In particular, the latter mechanism is something of a "reset button" for an origin. It sounds like the payment handler mechanism installs code that handles payment requests: it would be surprising if we didn't clear out code that when a site asked us to.

Likewise, if the site installs arbitrary, web-accessible code (potentially including identifiers in the source) on a user's machine, it's tough to see why we wouldn't clear it out as part of the "Clear Browsing Data" dialog.

+@msramek who might have opinions from a privacy perspective.

[marcoscaceres]

So yeah, looks like we need to change the API to make this "credential" storage. We should decouple PaymentInstruments from a SW registration, and then link them together somehow... don't know what that would be yet.. like:

await navigator.paymentInstruments.set("visa1", cardDetails);

const reg = await navigator.serviceWorker.ready;
reg.claimPaymentHandlingStuffNamingIsHard();

@rsolomakhin, thoughts?

[marcoscaceres]

Might not need to claim anything, actually... just registering the event handlers on the service worker should be sufficient... similar to how fetch works?

[annevk]

We still haven't formalized how fetch actually works there though. I would vastly prefer not adding more side effects when listeners are added. See also https://dom.spec.whatwg.org/#observing-event-listeners.

cc @jungkees @jakearchibald

[marcoscaceres]

Apologies, I was recalling something about “static event registration” or some such. I’m ok with an explicit call to hook things up too.

[annevk]

Note that perhaps that is still the plan. I have somewhat forgotten and nobody has actually followed through on all the open issues.

[romandev]

So yeah, looks like we need to change the API to make this "credential" storage. We should decouple PaymentInstruments from a SW registration, and then link them together somehow... don't know what that would be yet.. like:

await navigator.paymentInstruments.set("visa1", cardDetails);

const reg = await navigator.serviceWorker.ready;
reg.claimPaymentHandlingStuffNamingIsHard();
@rsolomakhin, thoughts?

I support your opinion, but I have a question.

As far as I know, when clearing site data, all registered SW will be removed as well. Then, even if PaymentInstruments store is independent on SW life cycle, users will still have to revisit the third-party payment site to re-register SW. (If there is no SW, how can PaymentInstruments map with SW?)

1. Visit https://hellopay.com
2. Click register button and then register SW and instruments (including asking a permission)
3. Clear all site data (At this time, all SW will be removed except instruments data)
4. Visit https://merchant.com
5. Request payment using PaymentRequest
6. Instruments will appear on payment sheet.
7. User selects one of the instruments and then click pay button
8. What happen? Who can receive PaymentRequestEvent?

If I'm missing something, please correct me.

Thank you.

[rsolomakhin]

I'm OK with setting payment instruments outside of the ServiceWorker. We should discuss this with more bandwidth at the next editors call.

[rsolomakhin]

As @romandev pointed out, the browser should show only payment handlers that have both service worker and instruments. The former receives paymentrequest events and the latter specifies such info as supported payment method identifiers.

[marcoscaceres]

As far as I know, when clearing site data, all registered SW will be removed as well. Then, even if PaymentInstruments store is independent on SW life cycle, users will still have to revisit the third-party payment site to re-register SW.

This is correct, and also fine. The point of clearing site data is to break these relationships. If the user wishes to establish the relationship with the site, then they should revisit it... and their payments instruments can be restored + the site can again ask for permission to manage them.

(If there is no SW, how can PaymentInstruments map with SW?)

Through an explicit means to do so, which is the thing we are trying to work out.

Instruments will appear on payment sheet.

You missed a step, no? That is:

5. user selects "payment method" (e.g., E.g., AmazonPay).

The payment method "Hello Pay" is no longer available, because site data was cleared.

[romandev]

This is correct, and also fine. The point of clearing site data is to break these relationships. If the user wishes to establish the relationship with the site, then they should revisit it... and their payments instruments can be restored + the site can again ask for permission to manage them.

Thank you for your reply!

I thought you would like to keep the instrument data even if the user cleared the site data. Because it might be bad UX to revisit the site to re-install the payment handler to someone who clears the site data periodically. However, in terms of privacy, I agree that we should also remove the instruments data when users clears site data.

So, what is the benefit of changing the API shape? I think that even if the PaymentInstruments are independent on the SW life cycle, it will be dependent on SW again in order to connect them. (I'm OK with setting payment instruments outside of the ServiceWorker. I'm just curious.)

Also, if there are multiple SW in the site, how it works?

• I guess the only one SW should be connected with instruments data.
• Otherwise, all registered SW should listen to PaymentRequest event.

[adrianhopebailie]

Because it might be bad UX to revisit the site to re-install the payment handler to someone who clears the site data periodically.

I don't this is as big of a problem as it may appear. If a provider installs a handler and then instruments there is a good chance they will also have a record "server side" of the instruments the user has installed. (It needs to use them at some point too...)

So when the user re-installs the handler I'd expect it to be pretty trivial for the provider to also re-add the instruments.

[dlongley]

@adrianhopebailie,

I don't this is as big of a problem as it may appear. If a provider installs a handler and then instruments there is a good chance they will also have a record "server side" of the instruments the user has installed. (It needs to use them at some point too...)

So when the user re-installs the handler I'd expect it to be pretty trivial for the provider to also re-add the instruments.

I agree that it would be probably be trivial for the provider to readd the instruments as they would usually be stored "server side". I think the frustrating experience would be having to revisit all of your various payment handler websites when you clear site data. It seems like that wouldn't be addressed by moving the PaymentInstruments outside of the SW as users would still have to revisit all of the sites from whence those PaymentInstruments came.

I'm imaging a scenario where someone builds up a list of, say, five or so payment handlers. They are then used to browsing the Web and buying things with various different payment methods and handlers for them. Then, they clear their cookies/site data, etc. Then the next time they go to pay for something, they have no payment options and are either confused or frustrated (or both). Either the in-browser sheet will load with no options or the fact that there's a problem may be hidden from them entirely because the site they are on loads a legacy checkout flow.

Where does the user go from here? A lot of users won't know what to do and they may lose relationships with certain payment handlers without some other form of mitigation. This experience seems problematic to me.

[dlongley]

I wonder if the PaymentInstruments for sites with unregistered service workers could still be shown -- but with some kind of disabled indicator and a link that would let the user get back to the site to reenable them. That's still not great, but the user would at least be less confused and lost. I know we're not specifying UI requirements, but the design (e.g. separating PaymentInstruments from SW) could enable these improvements in the UX.

[jakearchibald]

If PaymentInstruments is a persistent store, associated with the origin, that the origin can freely read/write to, surely it must be cleared along with other origin storage. Otherwise, you've just created a clear-site-data workaround.

they clear their cookies/site data, etc. Then the next time they go to pay for something, they have no payment options and are either confused or frustrated (or both).

You have to also consider the frustration/confusion of "I cleared the site data for shittyPaymentsCorp but they still know who I am when I visit! Why can't I actually clear site data?"

You need to decide what a payment instrument is. Is it:

• A general payment method owned by the user. In which case it's similar to how Chrome stores card details today. It isn't origin specific, so it's reasonable to live beyond clearing site data. However, origins must not be able to read/write to this collection. Instead, an individual entry should be offered following user permission.
• A payment method owned by the user, recorded by the origin. In which case it's similar to iDB. The origin can inspect & modify the collection, but it must be cleared along with site data.
• A payment method owned by the user, recorded by the payment handler. In which case it's similar to push message registrations, which are stored with the service worker registration. This means each payment handler has its own store, the origin can inspect & modify the collection, but it must be cleared along with service worker unregistration.

In the cases where the origin can inspect/modify the collection, it can sync the data with a server.

It's possible to have both a browser-wide store, and a site-related store. The user could transfer items from the global store to the site, similar to how card autocomplete works today.

[dlongley]

@jakearchibald,

You have to also consider the frustration/confusion of "I cleared the site data for shittyPaymentsCorp but they still know who I am when I visit! Why can't I actually clear site data?"

I agree that both situations should be considered (emphasis added on "also"); they are both important. And I understand the clarity and adherence to the model when you advocate for considering PaymentInstruments site data as that collection can be freely read/written to by the origin.

But then how do we address the UX problem where the user loses all of their payment handler associations when they only meant to clear "cookies and other site data"? Perhaps we need to recommend a separate category for these sorts of "web handler associations" that falls under the realm of site data, but is also set apart from other types of data within that realm. Each browser can then decide how to (or not how to) surface that in their respective UIs.

Even if no explicit category needs to be called out here in the model or in algorithms (i.e. if user agents can somehow already make these sorts of distinctions based on the current spec) -- it may be worth at least noting this consideration/user expectation.

[marcoscaceres]

@jakearchibald wrote:

If PaymentInstruments is a persistent store, associated with the origin, that the origin can freely read/write to, surely it must be cleared along with other origin storage. Otherwise, you've just created a clear-site-data workaround.

Pretty much, but it would be inaccessible without again getting permission to access it. Let's put that aside tho - I'm not advocating for this, just trying to rationalize the model.

A general payment method owned by the user.

I been struggling with this also over last few days. This would only work for "credit cards" and their ilk, so I don't think this works as we add new payment methods and "exotic" new instruments that are likely tied to a payment handler.

A payment method owned by the user, recorded by the origin.

This is how I've been viewing it and what brought me here. This feels like the most natural fit to me... but...

A payment method owned by the user, recorded by the payment handler.

This is close. What I want is to have the Instrument Store owned by the user, accessed by the origin, but have a service worker registration to handle events.

I see this very much like the Cache API:

I can CRUD things in the Cache(s) from the Window object same origin. I can CRUD things from the Cache(s) from the Service Worker(s). And I can have the Service Worker(s) handle "fetch" events. Caches are cleared with site data.

Thus, I want InstrumentStore to fit this story:
Given user permission, I can CRUD things in the InstrumentStore from the Window object same origin. I can CRUD things from the IntrumentsStore from the Service Worker(s). And I can have the Service Worker(s) handle "paymentrequest" events - but these requests come from same origin or foreign origins. InstrumentStore is cleared with site data or user can manage the registration independently.

[marcoscaceres]

In my head, I'm currently here:

Need to chew on this some more...

[adrianhopebailie]

@dlongley - I think the privacy issue trumps the UX issue.

From a user experience pov user's will perceive payment apps somewhat akin to browser extensions since they manifest themselves first as a selection in a payment handler list with an icon, label etc. So I can sympathize with your position but also think we should avoid taking a position on this if we can as UX is outside our scope as far as that is possible.

I'd recommend that from a spec perspective we say less and let implementations decide if they want to split out the "Clear Site Data" process to allow users to exclude payment handlers and instruments.

@rsolomakhin and @marcoscaceres is that possible?

i.e. If we leave the spec as is (instruments are registered via the SW) would you be able to persist this outside the SW lifecycle somehow?

[adrianhopebailie]

Noting also that implementors may want to be able to sync this data between devices too which we have already said we don't want to spec here.

So I see the issue of how a browser persists this data as implementation specific. Can spec the CRUD interface as being via SW and leave it at that?

[annevk]

I'd like to strongly object to declaring UX problems out-of-scope. That just leaves your mess for someone else to clean up. It's imperative that you consider workable end-to-end solutions.

I think @jakearchibald's points might have been wrong though given that the access to the store is user-mediated. Given that, you can design the API such that the existence of the store is not observable. And given that, it fits much more in the credentials bucket than the site storage bucket.

[marcoscaceres]

@annevk wrote:

I'd like to strongly object to declaring UX problems out-of-scope. That just leaves your mess for someone else to clean up. It's imperative that you consider workable end-to-end solutions.

Agree. We definitely want to be thinking about how this data could be represented - and how it can integrate with existing browser utilities. We've done a lot of mockups along the way too.

Don't read this whole bug, but just for example (UI/UX mockups of browser integration):

• Permissions dropdown: Multiple payment apps per origin #98 (comment) and Multiple payment apps per origin #98 (comment)
• Browser UI: Multiple payment apps per origin #98 (comment)
• More browser UI, how developers might use it, and "Browser Settings": Multiple payment apps per origin #98 (comment)

We've done that throughout the process.

@adrianhopebailie wrote:

Can spec the CRUD interface as being via SW and leave it at that?

We certainly could, but that makes the API unnecessarily difficult to use. I would still like to be able to use PaymentInstrument store to create parts of the UI in the web application. Conveniently, it's what I wanted to show here ("wallet.com" graphic): #98 (comment)

If the PaymentInstrument was only in the service worker, then the developer would have to do painful message-passing/data-cloning to show what's in the PaymentInstrument to the user in a nice way (better than static icons).

[adrianhopebailie]

I would still like to be able to use PaymentInstrument store to create parts of the UI in the web application. Conveniently, it's what I wanted to show here ("wallet.com" graphic): #98 (comment)

I had not considered that requirement.

@annevk don't get me wrong, I think we need to consider these things but should avoid putting UX mandates in the spec.

i.e. Does the developer have a good interface to manage instruments that works for all use cases (now also considering this one from @marcoscaceres )? If yes, then let's leave UX around persistence of the data to implementors.

Specifying the lifecycle of this data is not an interoperability concern, unless there is some desire to share that data across implementations, which I have heard strong aversion to.

[annevk]

Yes it is an interoperability concern. If navigator.storage.clear() clears the data in one implementation and not in another, you just push the pain down to developers and users and you get the kind of dialogues that encourage you to use a different browser.

[adrianhopebailie]

If navigator.storage.clear() clears the data in one implementation and not in another

Which is not what I am proposing. I said "let's leave UX around persistence of the data to implementors"

If implementors of navigator.storage.clear() wish to deviate from current behavior which is to clear all user data (including payment instruments because they are part of the SW lifecycle) then that's something they should raise as a change to navigator.storage.clear().

My proposal remains that we treat payment instruments as part of the SW lifecycle. If a browser wants to offer a user a UX that allows them to clear their data but not their payment instruments they can do that.

Any origin originated process to clear the data (headers or API) should assume that the payment instruments are cleared. But... Since they were put there in the first place by the origin it can quickly restore them if it chooses.

[rsolomakhin]

IMHO, clearing site data in your browser is equivalent to resetting your phone: all apps and their data should be wiped.

[marcoscaceres]

IMHO, clearing site data in your browser is equivalent to resetting your phone: all apps and their data should be wiped.

Ok, but we need to work out what the hooks are from the Storage spec (or other specs that deal with credential management) for this, if any.

[annevk]

@rsolomakhin the UI is far more granular than that though, or are you saying Chrome will only offer full reset going forward? E.g., it's not clear to me that removing an individual app means that the credentials will be removed too.

[ianbjacobs]

@annevk wrote: " it's not clear to me that removing an individual app means that the credentials will be removed too."

What does "remove" mean? (Not meant to sound facetious. :)

In my mind, the app manages the credentials, and if the app is removed, the credentials go with it.

Ian

[annevk]

Something akin to "clear site data". At least in Chrome and Firefox, it was my understanding that such an action would not remove credentials. Note that a site can also trigger this itself to some extent through the Clear-Site-Data header. Again, that shouldn't affect credentials the user might have stored/generated for the site.

[ianbjacobs]

@annevk,

I think I need a more detailed understanding of what happens to the service worker code. It seems to me that clearing the browser should remove the browser's knowledge of the payment handler. But clearing the browser would not dip into the handler itself and change anything inside of the handler.
Are the "credentials the user might have stored/generated for the site" controlled by the handler?
Ian

[annevk]

E.g., user passwords would be stored separately from service workers and Indexed DB et al: https://storage.spec.whatwg.org/#infrastructure (we need to formalize this more still, but it's a start). This issue is about how payment handlers fit into that model.

[rsolomakhin]

A payment handler is a service worker that stores payment instruments on user's computer. These instruments are used to determine which payment method the handler supports, for example. Without the instruments, a service worker is not a payment handler.

On the other side of the coin, an instrument without a service worker is not a payment handler, because the browser would not have anywhere to fire a CanMakePaymentEvent or a PaymentRequestEvent.

Service workers and instruments are two required parts for a payment handler, therefore. Removing the instruments or unregistering the service worker is equivalent to removing the payment handler. From looking at https://storage.spec.whatwg.org/#infrastructure, it appears that payment instruments are "site data," because they most closely resemble Indexed DB and Cache API and are closely tied to service worker registration, all of which are under the "site data" category.

Does that answer the question?

[annevk]

The question is whether we want that API/model, see the replies to OP...

[rsolomakhin]

whether we want that API/model

I prefer to use the "site data" model.