New service proposal for services/aution_worklet

[Paul Jensen]

Hello services-dev,

I'd like to create a top-level service directory, services/auction_worklet. This will contain a single public mojom with a single method: auction_worklet_service.mojom (WIP changes 1, 2).

Background:
As our intent-to-prototype stated, we're developing a prototype implementation for FLEDGE.  A central part of running on-device ad auctions is execution of bidding and bid scoring worklets.  These worklets execute JavaScript functions that do not have access to networking, storage, or any other part of a web page (e.g. DOM).  Due to the execution of downloaded code and these isolation requirements we're proposing running them in a separate process.  The auction_worklet service would orchestrate and control the execution of these auction worklets in the separate process.

Why services/:
The purpose and needs of the auction_worklet service meets the Service Development Guidelines requirements for a Chrome Foundational Service:

• Focuses on a subset of functionality which is functionally related in a way that makes sense given the auction_worklet service name.
• Should logically run in an isolated process for security isolation, depending on the constraints of the host OS.  Initial plans are for experimenting on desktop.

More:
Googlers, see design at go/fledge-impl-dd.

Thanks for your help!

[Colin Blundell]

Hi Paul,

In addition to //services, //chrome/services and //components/services exist. This service seems like it could be a good fit for either the former (if the vision is to use this service only as part of Chrome) or the latter (if the vision is to use this service in the context of multiple embedders, i.e., top-level Chromium directories corresponding to distinct products). WDYT?

Thanks,

Colin

--
You received this message because you are subscribed to the Google Groups "services-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to services-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/services-dev/CABQTWr%3DtHU6_SwuaZPZOAYD0tHWNOmOeZRsy%3DDpThyDkSqHYYg%40mail.gmail.com.

[Paul Jensen]

I'm not sure //chrome/services makes sense as I could envision this service being used by multiple embedders.  The readme for //components/services says it's for services "Not considered part of Chrome's foundation (i.e., //services) or they have dependencies which we don't allow in /services (such as content or Blink)" which doesn't seem like this service (which seems to meet the foundational requirements and doesn't seem to have disallowed deps)?  I trust your judgement here though as I'm not experienced in these classifications.

[Colin Blundell]

Thanks! I think of foundational services as roughly "the services that are necessary for core //content-level browser operation". On-device ad auctions to me seems more of a higher-level feature than that. Curious if any other //services owners want to weigh in though, as I realize that this is a matter of opinion.

[Matt Menke]

The intention is for this to become a web standard.  The WPT cross-browser tests are run through content-shell, so I don't think //chrome/services works here.

It will likely need to depend on blink's mojom files.

[Paul Jensen]

I chatted with Colin a little and in helping decide between services/ and components/services/ it might be helpful to see more pointers to work-in-progress CLs that illustrate that FLEDGE is a feature implemented in content/ that depends on this new service.  I think these CLs, along with the design doc linked previously, illustrates that this service is necessary for content/-level browser operation:

Plumbing of API from Blink through content/browser/: https://chromium-review.googlesource.com/c/chromium/src/+/2745538

Interest group store in content/browser/: https://chromium-review.googlesource.com/c/chromium/src/+/2757425/

Interest group store connected to content/browser/storage_partition: https://chromium-review.googlesource.com/c/chromium/src/+/2772758

Auction orchestration in content/browser/: https://chromium-review.googlesource.com/c/chromium/src/+/2786738

Implementation of this service: https://chromium-review.googlesource.com/c/chromium/src/+/2761320 https://chromium-review.googlesource.com/c/chromium/src/+/2756928

[Colin Blundell]

Thanks, this context really helps. It does seem to me that //services is likely the best location. One other possibility, however, is //content/services. Will this service be entirely consumed by //content?

A related question: From looking at your CLs, I'm curious what marks the distinction between mojoms added to Blink and mojoms added to the service itself. One reason that I could imagine having the service in //services rather than //content/services is if the plan is for Blink to talk directly to/consume its interfaces.

Thanks,

Colin

[Paul Jensen]

There's mojom types that are shared between Blink and service/auction_worklet/.  Today they're simply duplicated in Blink (here) and in service/auction_worklet/ (here), but I imagine deduplicating them once we pick a location for the service.  Seems like having Blink include them from service/auction_worklet/ makes sense?

[Colin Blundell]

Gotcha, thanks. I see two possibilities:

1. Put the service along with all its mojoms in //services, and have both //content and Blink talk to those mojoms.

2. Put the mojoms that are used by Blink in Blink and put the service along with the mojoms used only by //content/browser in //content/services. Note that the service impl and/or //content/browser could consume the mojoms put in Blink as necessary, so there would be no need for any duplication in mojoms.

If the service will have a consumer outside of //content then (2) is a non-option. If not then I personally would be inclined to do (2), as it would then seem to me like the service is really part of the content layer and the fact that its implementation runs in a utility process is basically a technical detail.

I think that +John Abd-El-Malek should weigh in as the only person who's an OWNER of both //services and //content.

Best,

Colin

[Matt Menke]

I believe only content/ will need to call into the service.  The shared mojom files are only for shared structs used in blink->content/browser and content/browser -> <new service> mojo APIs, so I think //content/services is a viable option.

[Maksim Orlovich]

Pretty sure blink would be calling interest group store and auction
manager directly, unless we want to go via a bunch of indirection via
content?
OTOH auction runner would only be called by content and not blink.

[Matt Menke]

Given that adding interest groups is origin restricted and needs to go through a .well-known check, I don't think blink can call to the interest group store directly, unless it has network access as well?

[Maksim Orlovich]

On Tue, Mar 30, 2021 at 11:45 AM Matt Menke <mme...@chromium.org> wrote:
>
> Given that adding interest groups is origin restricted and needs to go through a .well-known check, I don't think blink can call to the interest group store directly, unless it has network access as well?

Well, the check has to be in the implementation/browser anyway,
regardless of whether blink gets to it directly via mojo or via some
interfaces that are then implemented in content/renderer only to call
mojo anyway.

You can see the RestrictedInterestGroupStore type in Caleb's CL and its use:
See https://chromium-review.googlesource.com/c/chromium/src/+/2745538/27/third_party/blink/public/mojom/interest_group/interest_group.mojom
and https://chromium-review.googlesource.com/c/chromium/src/+/2745538/27/third_party/blink/renderer/modules/ad_auction/navigator_auction.h
in Caleb's CL.

Also I guess this means that the general nterestGroupStore type is
also only content-usable, not blink-usable.

(Doing it this way avoids going through a bunch of interface and
WebWhatever wrapper types when talking blink <-> content, and mojo
takes care of type conversions between
different URL/origin/etc. types).

[John Abd-El-Malek]

I agree with Colin's assessment. It's a web standard and therefore we want all Chromium embedders to get it automatically (ruling out chrome/services). Since only content/ should call this, content/services is the best place.