-
Notifications
You must be signed in to change notification settings - Fork 17
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
Agenda Request - On premise trusted servers #122
Comments
This is precisely the concern. In this scenario the adtech is the attacker, and so physical possession of the device is a serious risk. |
Could Amazon, Microsoft or Google be considered hosting on-prem servers running in their cloud? |
I don't think I understand the question, but my view is that if (say) Amazon is the advertiser and they run a server with a TEE in AWS, then this is not a very strong defense against cheating by Amazon. By contrast if it's in Google's cloud, and Google promises not to collude with Amazon, then you have a somewhat higher level of guarantee against physical attack. How much is, I think, dependent on a lot of details not fleshed out in this discussion. |
Requiring the use of a specific business model must not be the business of standards making. |
It is prety clear that AWS, Azure and GC are on-prem servers for their respective companies. And at the same time they are 3 of the largests adversitsers. TEE has a history of secury flaws. On top of that secure enclaves decrypt the information to process it. So each cloud and company will be procesing PII. As an expert in Privacy Enhancing Technologies and GDPR regulation I don't think TEE provide the level of secury and anonymization European regulators are looking for. And all of this is desinged to comply with regulations not only with the demise of third party cookies. |
Agenda+: On premise trusted servers
Criteo would like to discuss the option of running trusted server on-premise in an adtech own infrastructure.
The current draft mandates that services running in a TEE should be deployed on a cloud platform.
We would like to understand why ?
Being required to operate on a cloud platform is likely to increase an adtech’s costs significantly.
Considering the security guarantees offered by TEE, this requirement is a little odd.
For example, remote attestation would work just as well from an adtech own infrastructure.
Unless there is a fear that side-channel attacks could be too easily exploited in the wild ?
The fact that the cloud platform is a trusted entity in the current draft is maybe a hint of that ?
In that case, what security features an infrastructure would need to provide to be allowed to host TEE and what TEE implementation would be allowed ?
Time
30 minutes to 1 hour
Links
https://github.com/privacysandbox/fledge-docs/blob/main/trusted_services_overview.md
The text was updated successfully, but these errors were encountered: