-
Notifications
You must be signed in to change notification settings - Fork 238
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
Spec multibid #1055
Spec multibid #1055
Conversation
With multiple bids and renderURLs to score, sellers' trusted fetches will have more opportunities to hit limits. |
Should a bidder exceed the seller's |
Oh, adding a reject reason is a good idea... though not sure what's the story on spec'ing of that. |
I saw your PR for existing "automatic" rejection reasons: #1064 |
I've just submitted the implementation; explainer will need to wait till I get approval to land the above, and as for spec'ing the reject reason... I suppose I will need to patch private aggregation spec around here: ... but we probably should have something since forDebuggingOnly keywords can use it, too, and that's in our spec entirely. |
The spec does not have post auction signals yet (so no reject reason). It's planned but just need to find some time to add that. Just created an issue #1079 for that. If you'd like, you can add a todo and link to the issue where you'd like to add the reject reason. |
... This is a prereq to specing how it works with targetNumAdComponents.
...into new type =bid debug reporting info=. This is in preparation for multibid, since that would have multiple bids corresponding to a single struct of debug reporting URLs [1]. As a bonus, this permits the removal of slightly awkward "no bid" field on generated bid. [1] So =bid debug reporting info= will ultimately have a /set/ of generated bid ids, rather than id-or-null.
3b9c625
to
8a9e916
Compare
Note: this is now based on #1080 and morlovich#1 so maybe hard to read before that lands. |
The #1088 discussion noted that |
scoreAd is called one at a time even with multi-bid, so I think that issue is orthogonal? I honestly don't know what's up, though it does look like we indeed don't set it, unlike what the explainer says. |
Ah, ok. Yes, it would be orthogonal. GTK. |
...into new type =bid debug reporting info=. This is in preparation for multibid, since that would have multiple bids corresponding to a single struct of debug reporting URLs [1]. As a bonus, this permits the removal of slightly awkward "no bid" field on generated bid. [1] So =bid debug reporting info= will ultimately have a /set/ of generated bid ids, rather than id-or-null.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some initial comments (mostly nits for now), still reviewing the logic.
Many steps don't have an ending ".", please add those.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Feedback applied...
@@ -5326,7 +5382,7 @@ result of [=evaluating a bidding script=], or an [=additional bid=] provided by | |||
|
|||
<dl dfn-for="generated bid"> | |||
: <dfn>id</dfn> | |||
:: An {{unsigned long}}. Used to identify a [=generated bid=]. | |||
:: A pair of {{unsigned long}}s. Used to identify a [=generated bid=]. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It'll be useful to add a brief explaination about what each element of the pair is about
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe use [=tuple=]? A [=tuple=] consisting of two {{unsigned longs}}, one for xxx and one for xxx
See the example in https://infra.spec.whatwg.org/#tuples.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I think something is broken in compiling it (it complains about not finding chrome?), so I might need to do something to poke it to get it to try again...
Yeah I got the same error on my local main branch check as well after I synced. |
@domfarolino I think it's ready for you to review. Thanks! |
It's a pretty big PR! Can you please update the OP way from:
... to something more descriptive that can help get up to speed. |
Description updated |
This reverts commit 850b2ff.
SHA: 850b2ff Reason: push, by JensenPaul Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Drats, I accidentally merged this PR when I meant to merge #1048. I reverted this PR, but I'm not sure how to reopen this one :/ |
You cannot; you'll have to open it again fresh. |
Probably easiest to hit the revert button on my #1137 to essentially reopen a similar PR. Again, I apologize for merging the wrong PR. |
Created #1138 using sophisticated high-reliability technology (diff/patch) |
This permits generateBid() to return (and setBid to take) a sequence of bids as an alternative to a single one.
A k-anon rerun, still limited to producing a single bid, will now happen when none of the returned bids are k-anonymous (which is equivalent to current behavior when one bid is produced).
To make it easier to produce k-anonymous bids when component ads are involved without relying on a re-run,
this also adds optional targetNumAdComponents and numMandatoryAdComponents fields to bid to request implementations to drop some component ads in order to make a bid k-anonymous.
See #595
Preview | Diff