Initially we'll just fetch this and then throw away the results. Later, when more sophisticated bidding algorithms are supported (see #20), they may use the results.

In the spec, this is currently characterized by lots of handwaving and uncertainty, so for the moment we won't implement until a more solid plan for it is in place.

I just checked and Chrome does enforce this.

There's a bit of an open question as to how this API will work, since decision_logic_url won't work exactly as described in the spec. Options include:

• Add a separate field that callers have to pass
• Have decision_logic_url just do reporting and use trusted signals to choose the scoring algorithm
• Have decision_logic_url do reporting and also make the choice of scoring algorithm in the global scope

See WICG/turtledove#188.

Deferred for now due to uncertainty and complexity; may be picked back up later if it proves to be needed.

I've got an implementation on my machine, but it fails because Karma's uncaught exception handling catches the failure and fails the test, and I haven't figured out how to make this not happen.

In turledove:#154 we proposed a way to move some of the JavaScript out of the browser and into a trusted server instead, using this technology. Would it be possible to extend the Fledge Shim so that it supports running experiments around this idea?

We’re thinking of two related experiments, both of which look like relatively minor changes to the Shim and which build on top of each other:

1. Have JavaScript be pre-registered in the trusted server via a separate channel and assigned an id. Rather than send the full JS code from the browser to the trusted server, send just the function id and the arguments to call it with. The server runs the registered function and returns the results.
2. Move the execution of a group of JS bidding functions, a scoring function, and the final auction to the trusted server.
   • The network overhead and browser compute would be further reduced here. We don’t yet know whether that will be required compared to (1).
   • In this setup either the FLEDGE Shim requests trusted signals from the client, or the server performs those calls given the keys from the client.

Note that we’re not yet sure what the trust model will be for the trusted server. That’s being explored here and so out of scope for these experiments.

Thanks,
Phil

Currently, the only supported bidding algorithm is "bid a static price associated with the creative". Once others are suggested, we will need a way to allow bidders to choose between them. This will be the FLEDGE bidding_logic_url parameter, except that it will be a URI of the form fledge-shim:algorithm-name.

Follow-up to #20.

Right now, we do allow them, and we convert them to absolute URLs in the calling page, but I'm realizing that I'm actually not sure whether it's supposed to work that way.

This should apply both to fetching the worklet script and to running it. Follow-up to #20.

I don't think Karma can do this, so we'd need WebDriver.

Chrome seems undecided on this too.

This makes debugging annoying.

For the moment I'm not planning to implement this because it seems to be redundant, but filing an issue so this is on our radar in case the spec changes later.

Feature-Policy will not be supported; the top-level site's permission will not be needed to join an interest group (since we have no way to enforce this). Group owner permission will simply be a domain check for now, without support for delegation. The FLEDGE proposal is ambiguous as to whether we're supposed to support public suffixes; for now, we won't.

This could be a good way to find and fix behavioral divergences if we can find a way to make it work.

Looking through https://source.chromium.org/chromium/chromium/src/+/main:content/services/auction_worklet/trusted_bidding_signals.cc, there are two apparent differences with how we fetch trusted signals:

1. FLEDGE Shim appends the hostname and keys parameters after any existing query parameters in the provided URL. Chrome appears to require that the provided URL have no query parameters.
2. FLEDGE Shim escapes each key, joins them with ,, then escapes them again. Chrome appears to do only one layer of escaping, which means that keys may be ambiguous if there's a , in one of them.

We should find out whether these are bugs in Chrome's implementation or whether the intent is for the feature to be specified this way.

IndexedDB requires users to be careful about database versioning, or else code can crash or deadlock. We should figure out some form of this before FLEDGE Shim is deployed into production, to avoid having a problem that can't be fixed later.

If you're writing a worklet script in TypeScript, TypeScript should know what type generateBid is supposed to be and should yell at you if you get it wrong. There's an open question as to how exactly to distribute these typings, e.g., whether they should be a separate package, or what. Follow-up to #20.

Without this, browser_signals.top_window_hostname may not be accurate.

We got a question offline on whether the shim will function for users who have disabled third party cookies. It is not intended to, but we should check.

Currently, we allow embedded credentials in URLs, because I haven't put in a check to explicitly disallow them. There's a comment to the effect that they're not supposed to be allowed in the Chrome codebase, and I could swear at one point I saw the code that actually implemented this check, but I can't find it now.

I think this might be security-relevant but am not super clear on the details. I wish there was an actual spec...

For the reasons described in README.md, this won't be implemented for now.

Would be good for parties hosting the frame to be able to know if something is going wrong with it. (E.g., if there's a bug that they might want to tell us about.)

In particular we want to make sure that there aren't any undesirable borders or margins or anything and that the inner iframe's width and height are the same as the outer one's.

I tried Intersection Observer but that doesn't seem to be able to look through the iframe viewport to see the position relative to the actual browser window. I looked at the WebDriver documentation but didn't see any way to do this. I suppose I could try just measuring each iframe relative to its parent but that seems like a place where mistakes could get in. Still trying to think of other options.

Using a same-origin ad creative might be necessary or at least convenient. The API doesn't currently allow srcdoc and data: URIs are cross-origin, so this might require a change on the build-tooling side.

Chrome's in-progress implementation is using camelCase, so we should too. See WICG/turtledove#156

Probably via https://github.com/google/safevalues.

Hi @jeffkaufman @taymonbeal 👋🏼 ,

@iamnewton and I have been working on a similar project to provide a pure JS implementation of the fledge spec. I don't see any value in having two versions of what will eventually be a throwaway library. Do. you want to collaborate together on this effort?

Either the whole thing or just error messages, depending on how paranoid we want to be about being wrong about assert failures being impossible.

Currently, the only supported scoring algorithm is "pass through the bid verbatim". Once others are suggested, we will need a way to allow sellers to choose between them. This will be the FLEDGE decision_logic_url parameter, except that it will be a URI of the form fledge-shim:algorithm-name.

We'll add this when there are bidding algorithms that need it (see #20).

This isn't an immediate priority, but noting for completeness.

There's a bit of an open question as to how this API will work, since bidding_logic_url won't work exactly as described in the spec. Options include:

• Add a separate field that callers have to pass
• Have bidding_logic_url just do reporting and use trusted signals to choose the bidding algorithm
• Have bidding_logic_url do reporting and also make the choice of bidding algorithm in the global scope

Helps avoid leaks, just in case.

There's been some ambiguity on this.

We can't auto-expire the actual storage (whatwg/storage#11), so this'll have to work by simply storing the expiration date, and deleting interest groups after reading them if they're expired.

Initially we'll just fetch this and then throw away the results. Later, when more sophisticated scoring algorithms are supported (see #21), they may use the results.

Follow-up to #20.

As of #20, if n interest groups in a single auction all use the same biddingLogicUrl, we fetch it n times. This is clearly undesirable.

This requires figuring out how to serve the compiled (or at least transpiled) frame into a Karma test.

Chrome's M91 implementation of FLEDGE doesn't include [1] interest_group_buyers=*; the interaction of "allow all buyers" and "byos 'trusted' server" isn't great. I think the same reasoning applies to the shim, and we should require sellers to explicitly list what buyers they want to allow to participate.

[1] https://chromium-review.googlesource.com/c/chromium/src/+/2786738/51/content/browser/interest_group/ad_auction_service_impl.cc#209

Follow-up to #20.

This won't support any k-anonymity restrictions, and it will only trigger on frame load, not in the background.

Not totally clear on whether this is needed, since if you're vendoring this code and you've got logic that you don't want to open source, you can just put it in your local copy. But if you're using npm then that might be trickier. There are various implications to the different possible API shapes here, so will wait to investigate further until we know what users need.

As of #20, the source code is just included verbatim as a string in the binary, with no minification or anything. This is clearly undesirable. To fix it we're going to have to figure out some Webpack stuff.

So we have to restart the test server every time a change is made.

After #20, we fetch trustedBiddingSignalsUrl and we run a worklet, but we don't plumb the two together. This needs to be added.