Open pehuen-rodriguez opened 1 year ago
That could constitute a fingerprinting vector, unless the precision granted by the Date object is not trimmed.
Hi @pehuen-rodriguez: Can you say more about how you plan to use the Date()? For example:
I don't think there would be any problem in principle with bidding functions having access to, say, minute-level granularity of the time at which the auction started. But because of implementation issues, it would take some gymnastics to offer that without offering the millisecond-granularity current time, which (as @lknik points out) does have privacy risks.
@michaelkleber As another possibility, could a buyer in principle encode the current time into perBuyerSignals
(available in generateBid
), which a buyer could, perhaps, generate server-side, while having access to the current server-side time?
Would that present privacy risks from the FLEDGE privacy model perspective?
Certainly — with the way FLEDGE works today, the current time could be passed in through lots of channels:
auctionSignals
, making it available to all the workletsperBuyerSignals
, making it available to all the bidding worklets of one particular buyer"time"
for all of their IGs, and had a KV server that returned the current time as the corresponding valuePersonally I think number 1 here is the most natural. But some of the questions I asked @pehuen-rodriguez might give more indication of whether or not this is good enough for their needs.
Thank you all for your comments. The need to avoid indiscriminate access to the Date object in worklets is clear to me now.
I will fill in with details about the way we would have used the js Date object in the candidates selection process. While signals usage flowing from server-side options as suggested by @michaelkleber are also reasonable solutions and we could explore their implementations.
Date.now()
which as mentioned could be trimmed to the minute level. And also the instance method date.getDay()
to get the current day of the week.Thanks for the information. Just to point out the subtleties whenever you deal with time, you mentioned both Date.getDay()
and date.now()
, and one of those gives information local to the user's timezone while the other gives information in UTC.
My instinct is that the most natural answer is to let buyers and sellers handle this however they find best, and that it's not necessary to add something new to the browser to support it. But if you see a reason that a browser-built-in version is clearly better, then please let us know.
Hi @michaelkleber, considering that the solution of passing the timestamp in the auction signals is viable, we believe that having the function within the worklet makes everything simpler and cleaner. We understand that granularity in milliseconds may pose a privacy risk. Instead, is it feasible to have the Date.now() function with a granularity in seconds?
Thank you in advance
I'm afraid it would be very difficult — for the browser, but also for web developers writing code to run inside the worklets! — to create a new kind of Date object that sometimes behaves like the "real" Date and other times has surprising and different semantics. That approach would mean that every JS library in the world might have subtle bugs if it ran inside a worklet, for example.
Our implementation of the generate bid function used during the "simulation" phase of the Fledge experiment, included date-based candidate filters, ported from our server bidding code to run on the on-device auction. That way we used up-to-date information from trusted-server signals.
While conducting origin trial tests, we encountered the javascript Date object is not available on the Chrome's bidding logic worklets. We've asked the AdX team about it and they confirmed Date object and constructor don't seem to be available, and suggested we should open up an issue about it.
Think date-based decisions on the bidding function is a common enough use case for the worklets to support the Date object. Is it possible and are there any plans of implementing it? And maybe there's a workaround you might suggest in the meantime?