michaelkleber
commented
2 years ago It's worth noting that k-anonymity has a bootstrapping problem: How can a URL end up used by at least k different browsers, if it can never render for the first time?
In FLEDGE we're handling this via a two-attempts design: the on-device auction first runs over all candidate ads, and then if the winner is below the threshold, we run it again but only allowing the over-threshold candidates to participate. When we update the k-anonymity state afterwards, we give a +1 to the ad that won, and also to the ad that would have one if it had been over-threshold.
I like this approach, because it means a FLEDGE Interest Group can come with both a more-specific and a more-general ad, and can bid using the more-specific one, falling back cleanly to the more-general one until the more-specific one is able to be shown.
jkarlin
runURLSelectionOperation() allows the caller to choose arbitrary URLs to put into the resulting Fenced Frame. Those urls might include 1p identifiers. Which would then mean the fenced frame has a 1p identifier plus a few bits of cross-site data (from the selection operation). If the Fenced Frame has unrestricted network access, then the Fenced Frame can trivially leak the combination of the 1p identifier and those few bits of information.
So, either we don't allow the FF (fenced frame) to have unrestricted network access, or we make sure that the input data to the fenced frame isn't 1p identifying. It seems like it might be easier to make the data not be user identifying, and an approach for that would be to make sure the input is k-anonymous, as is done for FLEDGE.
Note that the notion of using k-anonymity for input urls is also discussed #14.