Reconsider Clear-Site-Data impression-deletion criteria

[apasel422]

While working on end-to-end tests for the clear impressions for a conversion site algorithm in the simulator, I wondered about a few possible issues:

1. Step 1 (If origin is not a tuple origin with a scheme of https, return.) is unnecessary to include in the specification, as it is simply an optimization in the case that the origin is opaque or non-HTTPS, which would need to be adjusted for Site identification and localhost #146. It would be more future-proof to remove this step.
2. As currently specified, a top-level site that registers an impression is not capable of removing it (though an intermediary site that registers one is capable of doing so). According to Clear-Site-Data integration #125 (comment) this was intentional, but I'm not sure there's a good reason to prevent it: What if an impression site registers impressions with an empty conversion sites set (allowing conversions anywhere), but realizes that they made a mistake in their other options (e.g. matchValue)? It might make sense to allow the impression site to clear out impressions with a step like "If impression's intermediary site is undefined and its impression site is equal to site, remove impression from the impression store." so that they don't get bogus conversions.
3. The algorithm is misleadingly named, precisely because of that intermediary-site check, which is unrelated to conversion sites.
4. It's unclear to me whether we should allow conversion callers to remove impressions, in addition to conversion sites, as Clear-Site-Data integration #160 was written before the conversion-callers concept was added to the spec.

[csharrison]

1. Yeah let's remove this.
2. This seems reasonable to me too.
3. Agree, let's just rename it "for a site"
4. Maybe we can outline some principles in terms of who should be allowed to delete stuff. Here's my take
   a. It makes sense that the party saving an impression can delete it (e.g. to wind back a mistake).
   b. Any conversion-side party that has permission to measure on a particular impression should be able to delete it as long as that action is isolated to affect only themselves. This is currently the case in the spec for conversion sites, but I think it is reasonable for conversion callers as well i.e. deleting the impression removes themselves from the conversionCallers sequence, or deletes the impression if they are the only caller.

[apasel422]

One thing that's tricky about the conversionCallers part is that we will only want to delete the impression if conversionSites and conversionCallers both become empty after not having been so originally. Otherwise, the matching logic will suddenly allow any conversion site / caller to match. In other words, we'll have to add two mutable boolean fields to the impression canMatchConversionSites and canMatchConversionCallers that start out true, but may be set to false during Clear-Site-Data. These fields will have to be inspected by the common matching logic.

For example, let's say an impression is registered with conversionSites=["a.example"] and conversionCallers=["b.example"]. If we get a Clear-Site-Data request for b.example, the conversion callers will become empty, but we want to retain the impression because it can still match a.example as a conversion site. But if we don't modify the common matching logic, then any conversion caller will start to match.

[apasel422]

Actually, maybe we don't need to add the boolean fields, as if the set(s) become empty, then we know nothing should be capable of matching in the future and the impression can just be removed.

[martinthomson]

My view is that we want to more deliberate about how we approach point 2. Or maybe 4.

Attaching this to the clear site data API probably isn't the right way to approach reversal.