Availability of the javascript Date object in the on-device bidding worklet

[pehuen-rodriguez]

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?

[lknik]

That could constitute a fingerprinting vector, unless the precision granted by the Date object is not trimmed.

[michaelkleber]

Hi @pehuen-rodriguez: Can you say more about how you plan to use the Date()? For example:

• Are you trying to make decisions based on hour-sized, minute-sized, or second-sized details about the current time?
• Are you expecting to call it one time, or call it multiple times and use the fact that it could change during the auction?
• What methods of the Date() object would you hope to use?

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.

[sbelov]

@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?

[michaelkleber]

Certainly — with the way FLEDGE works today, the current time could be passed in through lots of channels:

1. by the seller as part of auctionSignals, making it available to all the worklets
2. by the seller as part of perBuyerSignals, making it available to all the bidding worklets of one particular buyer
3. from the buyer's KV server, if a buyer included a key called "time" for all of their IGs, and had a KV server that returned the current time as the corresponding value

Personally 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.

[pehuen-rodriguez]

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.

• Granularity we'd use goes from day-sized to minutes-sized. We'd use it, for example, to identify if the candidate's campaign is active at a given day of the week. Or if the candidate's parent campaign has started or is actually ended before auction time.
• Current implementation grabs the date at different places in code. But a single instance of the date with a safe-enough granularity is good for our current purposes too.
• Example methods we're currently using are 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.

[michaelkleber]

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.

[onetag-dev]

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

[michaelkleber]

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.