Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avoid Browser Restart Delays: Ad Tech Option for Report Delayer TEE #920

Open
thegreatfatzby opened this issue Jul 31, 2023 · 2 comments
Open
Labels
possible-future-enhancement Feature request with no current decision on adoption

Comments

@thegreatfatzby
Copy link

thegreatfatzby commented Jul 31, 2023

I'm curious about this idea in the short run just for consistency and hard bounding, but especially so in the long run if we hope to one day move mission critical operations onto Aggregated Reporting, such as billing, budgeting, etc, and adopt something like the extended private agg reporting. I do see one issue with it but wanted y'alls thoughts.

Currently the browser controls and executes the delay for sending a report to the agg report TEE. Why not continue to let the browser control the delay (i.e. choose the time in seconds/minutes) but send it immediately to an additional TEE that has one job, to hang on to the report and send it out after that number of seconds. You could make it optional so that the ad tech could choose to accept the lack of bounding rather than additional TEE cost. In the case of Attribution in particular the event count is likely to be small (our attributions are 2-3 orders of magnitude smaller than our request counts).

I'd imagine one issue is that you'd in theory need to store the received reports-to-delay in a durable fashion somewhere, and storing anything opaque durably adds risk. We'd have to do some smart data partitioning and replication within a cluster, but that's doable, and if the max retention was 10 minutes + some reasonable recovery factor, I'd think it would be helpful.

Curious for your thoughts?

@csharrison
Copy link
Collaborator

Thanks for the suggestion @thegreatfatzby. We have some discussion of this in the spec https://wicg.github.io/attribution-reporting-api/#reporting-delay-concerns where the TEE would be an instantiation of the "trusted proxy server" discussed there.

In general, I like the idea of reducing delays via introducing server mediation. I'd need to think a bit harder about the TEE acting in this role but it's definitely something we can consider.

@csharrison csharrison added the possible-future-enhancement Feature request with no current decision on adoption label Jul 31, 2023
@thegreatfatzby
Copy link
Author

Ah sorry I missed that, you guys just churn out too much good stuff to keep up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
possible-future-enhancement Feature request with no current decision on adoption
Projects
None yet
Development

No branches or pull requests

2 participants