Document executionMode = groupByOrigin #339
Conversation
FLEDGE.md
Outdated
| @@ -121,6 +122,8 @@ The `biddingWasmHelperUrl` field is optional, and lets the bidder provide comput | |||
|
|
|||
| The `dailyUpdateUrl` provides a mechanism for the group's owner to periodically update the attributes of the interest group: any new values returned in this way overwrite the values previously stored (except that the `name` and `owner` cannot be changed). However, the browser will only allow daily updates when a sufficiently large number of people have the same `dailyUpdateUrl` , e.g. at least 100 browsers with the same update URL. This will not include any metadata, so data such as the interest group `name` should be included within the URL, so long as the URL exceeds the minimum count threshold. (Without this sort of limit, a single-person interest group could be used to observe that person's coarse-grained IP-Geo location over time.) | |||
|
|
|||
| The `executionMode` attribute is optional. The default value (`compatibility`) will run each invocation of `generateBid` in a totally fresh execution environment, which prevents them from directly passing data to each other, but has non-trivial execution costs. The `groupByOrigin` mode will attempt to re-use the execution environment for interest groups with the same script that were added on the same site, which saves a lot of these setup costs, but in order to avoid collusion, attempts to join the same interest group in `groupByOrigin` mode from multiple sites will result in previously joined `groupByOrigin` groups being removed. | |||
There was a problem hiding this comment.
In other words, setting 'executionMode': 'groupByOrigin' means "I promise that this domain is the only domain where people get added to this Interest Group"?
There was a problem hiding this comment.
By the way, could an alternative be that in 'executionMode': 'groupByOrigin', interest groups for the same owner are stored namespaced additionally by the origin where a browser gets added to one? In other words, interest group sneaker joined on shoes.example and interest group sneaker joined on athletics.example would be two completely distinct interest groups.
There was a problem hiding this comment.
@michaelkleber:
"I promise" is probably too strong, and makes it sound like an ethical failing of some sort to fail to follow through? It's more like "I think it's sufficiently high probability that this interest group and all others for the same owner with the groupByOrigin execMode being added right now would not be added anywhere else that reverting all those joins if that does happen is worth the resource savings". I suppose I should say something like that to, well, explain, why the knob exists?
@sbelov: This is messing with what the primary key for main APIs so I it's hard for me to think of all the implications. I am a little scared of possibility of there being more interest groups, at any rate.
There was a problem hiding this comment.
@sbelov We have already investigated using the joining origin as the namespace but rejected that approach because, among other issues, it makes leaving an interest group ambiguous since there may be multiple joining origins for an interest group (including ones that the browser doesn't know about), so the browser doesn't know which interest group to leave. It can't leave them all because that may create a side channel for cross-site information. If we know the joining origin for the interest group we're leaving (so it would not be ambiguous), then we might as well just include it in the interest group name.
There was a problem hiding this comment.
Added a note: re:intended usage
FLEDGE.md
Outdated
| @@ -121,6 +122,8 @@ The `biddingWasmHelperUrl` field is optional, and lets the bidder provide comput | |||
|
|
|||
| The `dailyUpdateUrl` provides a mechanism for the group's owner to periodically update the attributes of the interest group: any new values returned in this way overwrite the values previously stored (except that the `name` and `owner` cannot be changed). However, the browser will only allow daily updates when a sufficiently large number of people have the same `dailyUpdateUrl` , e.g. at least 100 browsers with the same update URL. This will not include any metadata, so data such as the interest group `name` should be included within the URL, so long as the URL exceeds the minimum count threshold. (Without this sort of limit, a single-person interest group could be used to observe that person's coarse-grained IP-Geo location over time.) | |||
|
|
|||
| The `executionMode` attribute is optional. The default value (`compatibility`) will run each invocation of `generateBid` in a totally fresh execution environment, which prevents them from directly passing data to each other, but has non-trivial execution costs. The `groupByOrigin` mode will attempt to re-use the execution environment for interest groups with the same script that were added on the same site, which saves a lot of these setup costs, but in order to avoid collusion, attempts to join the same interest group in `groupByOrigin` mode from multiple sites will result in previously joined `groupByOrigin` groups being removed. | |||
There was a problem hiding this comment.
This should mention that attempting to leave from multiple sites will also result in removing all interest groups, including when leaving from a fenced frame showing an ad.
Also, we should be clear about what we mean by "site" - is it origin, site, schemeful site, or what? The current implement looks to use origin, not site.
There was a problem hiding this comment.
Added leave, s/site/top-level origin
|
I was wondering, if two calls to generateBid share the execution environment, is it fine if data is passed from the first invocation to the second through global state? (Would it be considered as "supported use case" / "unspecified behavior" / "abuse"?) Such passing of data may open up additional optimization possibilities. For example, some of the computations will be identical for sameOrigin IGs, and the results could be cached in the global state. Another example would be to skip computations altogether for certain IGs, if the global state tells us that some previous generateBid returned a high bid value. |
|
Passing information further should be considered undefined behavior. The additional optimizations mentioned, caching calculations that only use common state or early return when the script knows it won't win seem like they might be promising, so we may want to look into whether adding an official path for that makes sense. Though I'm not sure how a bidding script would know it doesn't have a chance of winning, since a buyer may have a script that does something unintuitive, like always chooses the lowest bid. |
This sounds like #162 |
|
I think we do have to guarantee a form of "passing data" --- the second execution will not re-run the top-level, only function, so any state you compute there (which arguably should be a constant) will be preserved. Thank you for reminding me I need to actually write that down in the explainer. Note that, however, we can't really guarantee the re-use will happen, so having things that change if you run it more times sounds like asking for a bad time. |
SHA: 8606207 Reason: push, by JensenPaul Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
No description provided.