You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is that literally the case, that this is existing code on existing servers running in existing datacenters (caveat that code changes to accommodate SellerFrontEnd flow)? Or are there restrictions such as, this is expected to run in the cloud in a Nitro Enclave, or the types of communication out of the server (log processing, requests in hot path to other systems, creative serving)?
Would Chrome browser attempt to restrict the request/response structure to/from Seller Ad Service, other than the encrypted Protected Audience Data portion as described here.
Would there be any audit expectation?
Event Level Reporting (for now)
I'd like to understand the "for now" part better. Is the expectation that some level of Event Level Reporting will continue just with more restricted data (i.e. no or less Interest Group data, more noise, etc), or that there will be no Event Level Reporting at all? I ask for a few reasons:
Sellers and buyers have a strong claim to event level data that exists now that is not specific to the user who the impression was served to, and that data is used for many purposes outside of targeting.
Perhaps not the Seller, but the Buyer who is creating and using the Interest Groups has a less-strong-but-still-reasonable claim on wanting to analyze the usefulness of their Interest Groups at a detailed level, and to see "landscape" data showing them how they might adjust their buying structures and settings.
Ad Techs, at the least the one I've been working for for 11 years, often need Event Level Data for operational purposes such as debugging.
Also, even in the "for now" times, will SellerFrontEnd and BuyerFrontEnd service be able to log event level data and phone home?
TEEs
I am no security expert, so if there's something very obvious here than apologies, but has any consideration been given to TEEs running in non-public-cloud environments but providing the necessary constraints, attestations, etc, through some combination of technical and audit requirements? I ask because one of the twix-inesses I see here is that Ad Techs (at least one I work for) will likely continue to have to support some set of existing use cases outside of a Fledge/Parakeet context, and those use cases are of size anywhere between non-trivial and quite substantial. Having to setup a TEE inside of a non-public-dc with some set of even relatively "intrusive" requirements could be preferable to forcing network and system topologies.
The text was updated successfully, but these errors were encountered:
Hey fwends, getting caught up and have a few clarifications and questions:
Seller Ad Service
Trying to understand what restrictions might be envisioned here. I saw "The seller's ad service is the existing stack of the seller that facilitates real-time bidding auctions" so want to dig in on that more:
Event Level Reporting (for now)
I'd like to understand the "for now" part better. Is the expectation that some level of Event Level Reporting will continue just with more restricted data (i.e. no or less Interest Group data, more noise, etc), or that there will be no Event Level Reporting at all? I ask for a few reasons:
Also, even in the "for now" times, will SellerFrontEnd and BuyerFrontEnd service be able to log event level data and phone home?
TEEs
I am no security expert, so if there's something very obvious here than apologies, but has any consideration been given to TEEs running in non-public-cloud environments but providing the necessary constraints, attestations, etc, through some combination of technical and audit requirements? I ask because one of the twix-inesses I see here is that Ad Techs (at least one I work for) will likely continue to have to support some set of existing use cases outside of a Fledge/Parakeet context, and those use cases are of size anywhere between non-trivial and quite substantial. Having to setup a TEE inside of a non-public-dc with some set of even relatively "intrusive" requirements could be preferable to forcing network and system topologies.
The text was updated successfully, but these errors were encountered: