This doesn't seem to be an iOS specific issue. Removing assignment until triaged and re-assigned.

These are the standard semantics of Clear Browsing Data. Entities which have both creation and modification timestamps are deleted according to the motification timestamp.

Consider a timeline t1 < t2 < t3 where:
t1: Entity was created.
t3: Entity was modified.
And the user chose deletion for the time interval [t2, now).

The correct way to interpret the user's intention is that they want to return their data back in time to t2. Which means that we would have to revert the state of the entity to the latest version before t2, but that would require us to keep to detailed history of all changes.

Apart from that, we have two possibilites - simply respect the creation or modification timestamp.

If the user is deleting data for [t2, now), we must assume that it's because they are trying to get rid of some sensitive data added in that time interval. This could be precisely the modification that happened at t3. Therefore, we respect the modification timestamp.

In other words, we have the choice to over-delete or under-delete. Since data deletion is likely motivated by privacy reasons, we err on the side of over-deleting.

Note that Clear Browsing Data always shows the amount of data to be deleted. The number of credit cards is explicitly spelled out under the "Autofill" checkbox. I think this greatly mitigates the possibility of users accidentally shooting themselves in the foot by deleting recently edited cards.

Unless there are any special considerations for credit cards, I would close this as WAI.

msramek and mahmadi: Can you identify an assignee for this bug?

I agree with the interpretation of the user's intention.

I also agree with the rationale to prefer over-deletion to under-deletion, given:

  * keeping detailed history seems like undue complexity
  * the data can be manually or implicitly recreated during subsequent usage

There's a special consideration for credit cards saved to Google Payments:

  * we currently don't have a way to push a deletion event up to payments
    (locally deleted cards would, iiuc, just be re-synced down at the moment)

This bug has an owner, thus, it's been triaged. Changing status to "assigned".