WIP API #1
WIP API #1
Conversation
| When an [=impression=] occurs, information about the impression is saved by the | ||
| browser in a write-only store. This includes an identifier for the impression | ||
| and some metadata about the impression, such as whether the impression was an | ||
| ad view or an ad click. |
There was a problem hiding this comment.
| ad view or an ad click. | |
| ad view or an ad click. |
The write-only piece is negotiable. I can see why a site couldn't modify its store of impressions, but it's also not really necessary if the reading by other sites is controlled properly.
The whole business with "what does the e-Privacy Directive say about storing information" is silly. It matters, of course, but not every regulatory system will grow a PECR-like piece of baggage.
There was a problem hiding this comment.
The write-only term was actually in the original and I also had some doubts about it. I think it's an oversimplification. We should discuss the characteristics of the store somewhere (I think I added a section for that), but it takes more than just saying "write only" to capture the important characteristics.
api.bs
Outdated
| required unsigned long histogramSize; | ||
|
|
||
| unsigned long lookbackDays = Infinity; | ||
| PrivateAttributionImpressionType impression; |
There was a problem hiding this comment.
| PrivateAttributionImpressionType impression; | |
| required DOMString aggregationSystemId; |
Now, I don't think that this is a string that someone will be happy typing often:
let whatsit = await privateAttribution.measureConversion({aggregationSystemId: "joe", ...});That's already unwieldy.
There was a problem hiding this comment.
How about shortening it to aggregator?
| # Implementation Considerations # {#implementation-considerations} | ||
|
|
||
| * Management and distribution of values for the following: | ||
| * Histogram size |
There was a problem hiding this comment.
Two things on this that are somewhat in tension:
- When it comes down to it, the browser should really care how big histograms are. Sites get to do basically whatever with CPU and network resources and it's hardly going to be that bad if a site wants a really big histogram.
- I don't like the idea of really big histograms that basically make a mockery of our aggregation aspirations.
However, I think that the resolution of that tension is in the MPC (DAP specifically). We might want to ask aggregation service operators to limit histogram size as some function of the number of reports they aggregate. (I still somewhat like the idea of refusing to return a value if an aggregate is smaller than some threshold, even though it is perverse from a strictly DP interpretation perspective.) If the aggregator supports more, then the API should not be where limits are applied. Also, different browsers will have different views on this.
There was a problem hiding this comment.
If we're using DAP, then doesn't the browser need to know the histogram size to construct the report?
There was a problem hiding this comment.
Yes, we'll need to know what size to make. We'll ask the site to give us the size they want.
But we don't need to validate or limit that. If it is the wrong size, that's their problem.
Co-authored-by: Martin Thomson <[email protected]>
|
I pushed some additional edits here: https://github.com/andyleiserson/api/compare/api...andyleiserson:api:api-2?expand=1 (will open a new PR after this one is merged, or I can add the changes to this one). |
|
Generally, I'd be OK with iterating on this. But given its current state, I'm inclined to merge this one and then you are targeting |
No description provided.