(Hi @TheMaskMaker, could you please add your name and affiliation to your GitHub profile? To make contributions to WICG incubations, you'll need to be covered by the W3C Community Contributor License Agreement.)

The way the browser treats people's data is indeed a crucial part of privacy. Publications like the Google Chrome Privacy Whitepaper, for example, discusses in great detail what information the Chrome browser sends to any Google server.

But that isn't part of any spec, because standards describe how features of the web work, not how browsers implement them. Indeed different browsers have a wide range of implementations, even as they expose the same standardized behavior. So statements like "Browsers must commit specifically to not send any data, in any type of request, for any reason if another player is unable to send the same data home for the same reason" doesn't really make any sense. Consider a browser like Opera Mini, in which part of rendering happens on a server, not the in the user's device — what would your statement even mean?

For the k-anonymity parts of FLEDGE and other Privacy Sandbox APIs, please take a look at the Multi-Browser Aggregation Service Explainer. This is indeed all built on infrastructure such that everyone (browser vendors, privacy researchers, etc) can get cryptographically solid proof that information is not leaking to unintended parties — even the parties who run the server-side components..

This comment raises interesting points worth discussing.

If I understand the author correctly, there are (at least) three key issues being raised:

1. Whether the browser will allow for open competition or preference its parent organization's servers

2. If the browser sends a browser identifier for the various marketer and publisher use cases that require server-side processing to control, measure or optimize digital advertising, then such identifiers should be available to open market competition

3. How can publishers and marketers audit the processes occurring in the browser to ensure the publishers' control of the content on their website is not interfered with by the browser and by that same token that the marketers' control, measurement or optimization of their cross-publisher media effectiveness is not impaired

Again, not sure if I understood the original post, but it seems to suggest that if the browser is operating independently of other organizations that offer advertising solutions, then given the general lack of people's understanding of complex data processing involved with algorithmic matching of content online, the browser should not preference the sending of personal data to any particular organization's server-side processing, but instead allow for open competition to process such data.

@joshuakoran The fundamental design property of the whole TURTLEDOVE family of proposals is that the browser does not send "personal data to any particular organization's server-side processing" at all!

(Hi @TheMaskMaker, could you please add your name and affiliation to your GitHub profile? To make contributions to WICG incubations, you'll need to be covered by the W3C Community Contributor License Agreement.)

The way the browser treats people's data is indeed a crucial part of privacy. Publications like the Google Chrome Privacy Whitepaper, for example, discusses in great detail what information the Chrome browser sends to any Google server.

But that isn't part of any spec, because standards describe how features of the web work, not how browsers implement them. Indeed different browsers have a wide range of implementations, even as they expose the same standardized behavior. So statements like "Browsers must commit specifically to not send any data, in any type of request, for any reason if another player is unable to send the same data home for the same reason" doesn't really make any sense. Consider a browser like Opera Mini, in which part of rendering happens on a server, not the in the user's device — what would your statement even mean?

For the k-anonymity parts of FLEDGE and other Privacy Sandbox APIs, please take a look at the Multi-Browser Aggregation Service Explainer. This is indeed all built on infrastructure such that everyone (browser vendors, privacy researchers, etc) can get cryptographically solid proof that information is not leaking to unintended parties — even the parties who run the server-side components..

Hello Michael, worry not, I am a member of WICG and actually I've spoken to you in both meeting so far! I am the other Michael. I am happy to send you a confirmation e-mail from my registered e-mail so there is no confusion or concern there. Actually we have so little time to talk on the calls, I was wondering if I could speak to you and the community at large more at length about this over voice, though you had said to discuss via github issues, so here I am.

Thank you for linking the explainers. They are very helpful, but they do not address my main point. I think Joshua above hits on some of it, but I will clarify.

In the last meeting you yourself said that certain features and calls should be restricted in Fledge because of even a small chance of some party (usually a third partner helped or dsp/ssp) being able to theoretically obtain a piece of private information, and that Fledge should design to prevent that. Forgive me I don't recall the exact argument you made as it was very in depth; I think it was in relation to Neilson's question about data companies and before that earlier in relation to a question about events being able to send certain event level packets out of the sandbox. In any case you had said (forgive me for heavy paraphrasing) that a sandbox leak could occur if certain event level information were made available, and for this reason even if it restricted existing use cases of various companies, it could not be allowed. Restricting event level information is quite damaging to several companies that use it for legitimate use cases that do not violate privacy (and by this I mean comply with opt-in/out etc, as well as those that use events that have nothing to do with user information). I am not at the moment saying this is good or bad, but merely that the philosophy of fledge seems to be 'large change for the greater good of privacy. '

It occurred to me that applying the same logic to the browser itself gives cause for concern as a much larger leak. I am aware that use cases such as Opera Mini exist, but that is my point; they are leaks that are either being ignored, or treated differently than other leaks. This critical individual user information the fledge protocol is designed to sandbox can escape via browser calls. Even if there is a whitepaper going through all of the calls of chrome and they are safe, without a standard rule preventing changes they could occur later. Also chrome is just 1 of the browsers. Other (non chrome) browsers implementing sandbox (as naturally it would become the defacto standard if used in chrome for integration reasons) would have different calls. The risk of a leak is higher than any other component we have discussed unless I am missing something in which case please let me know.

You said this was a discussion of the standard not implementation, however I am indeed speaking of standards in this case. In fact, I don't even know at the moment how it would be implemented. The standard exists to create a framework to prevent private information from leaking. How can it not address the player that has the most data with the least visible scrutiny? Is this not the very point of fledge? (Incidentally I rather dislike text sometimes as tone is hard to convey, I am intending Socratic here :) )

In fact, the concept of a 'trusted server' is already slated to be part of the existing paradigm, so this is not something alien to fledge at all. But it does not currently apply to browsers at all, and it (as mentioned in #114 ) gives preference to dsps/ssps in terms of information.

I think this is a large flaw in the standard we should address before origin trials for it to be successful. All players in the ecosystem should be put under the same scrutiny or privacy leaks can occur, and individual players will be shut out.

To use a very odd example, consider the penal system. Successful jail breaks most often occur not because of some hollywood style master plan, but merely due to an irregular event, such as a change in staff. Right now there is a big spotlight shining on publishers, their partners, ssps, and dsps, but each has access to different info, and this means that each one could leak in different ways. But worst of all the browser is a dark area fledge does not address with the most information, where information can leak.

I hope we can discuss this further as I think this is critical to the success of fledge as a privacy measure and I don't think we have even scratched the surface yet.

I see this issue has started to gain traction. I'm glad about that, and I also want to keep it on track. Rather than just point out a problem I'd like to suggest a solution.

1. Browser-sent server calls should be restricted to information available to 'the most restricted player.' The exact mechanism can be fleshed out later but I think this is a good starting point. The 'most restricted player' is likely the ad creative, or a third party on a website not authorized by the site owner. This will 100% ensure that the browser cannot be used to leak the sandbox.

However since some server calls are needed to do fledge (i.e. k-anonomity) we need a way to handle those as well:

2. Fledge-necessary calls (such as K-anonymity calls) must be open sourced and audited to ensure honorable play. They should also be beholden to the 'trusted server' paradigm.

3. I think we need a chart of the data accessible by each party. Its difficult to account for every case but Website owner, Third Party Authorized by website owner, Third Partner Not Authorized by website owner, DSP, SSP, Browser are certainly main ones we should consider. We should take a close look at what data each player can access.

I'm afraid I can't get behind the sort of broad, sweeping statements you're trying to make, here or in the linked PR. There is a big difference between the web platform, which is the stuff of specs and standards bodies, and the browser as an app, in which different browsers can and do have extremely different behaviors and implementations.

The browser-app does, inherently, have a larger set of capabilities than are possible on the web platform. To draw a parallel example, browsers can store and auto-fill passwords. Certainly no party on the web should have the ability to see all the passwords that you enter into any site; the web platform would be completely broken if that were possible. But the browser-app can see whatever you type into the browser, can ask if you want to save the password, etc. The site you're typing the password into could offer a related sort of service — but the browser-app here is on par with the most-privileged party, not least-privileged.

I fully agree that browsers should offer lots of transparency into what they do; the whitepaper is part of that. I think @joshuakoran lists some interesting questions worth further discussion. But when you start with sweeping statements like "All Trusted Players should be able to access any data ANY OTHER trusted player should be allowed to access", I don't see a way to reconcile your goals with the entire history of the web.