Protected App Signals Engagement Plans

[thegreatfatzby]

Fwends, I am very excited to be getting more into the Protected App Signals proposal, I see lots of good ideas I look forward to iterating on as a group.

Off the bat I'm realizing I have a few meta questions:

1. It looks like PappAPI (?) is currently only documented in the blog space rather than in Github. Will this be the case going forward, or is the intention to engage with the community in Github similarly to the other PS proposals? I definitely see pluses and minuses to Github (Microsoft obviously being a plus) but if it won't be I wonder how we'll open issues, PRs, upvote, track changes, etc.
2. Will there be a weekly/bi-weekly/some-cadence meeting?
3. Will this also be done under the auspices of W3C, PATCG, etc? Is the idea to try to develop a standard that other devices would hopefully use? (B) Related and in particular, will there be an attempt to converge PaapAPI and PAAPI?
4. Am I right that there is not yet a timeline? To the extent that there is, will be there be similar "adoption/transition" features as Protected Audience has, i.e. event level reporting, BYOS KV/Creative-Selection server, etc? Or is the idea to go cold turkey?
5. I am 99.99% but just to triple confirm, there will be no on-device Android auctions?
6. EDIT ADDITION: I'm also a bit unclear on the relationship between the BA Team and the Chrome/Android teams...I had generally understood that on the web side the Chrome team would be in charge of making decisions about how a Chrome User's data can flow, and BA would work on server side implementation(s) of that, with back and forth over whether something like the new Inference Service is "allowed for their users". Is that right? Is Android the same model, and if so is there an Android team focusing on this?

I think 3B and (5) together are interesting, b/c even though there wouldn't necessarily be client side compatibility issues, server side compatibility issues are still possible...they wouldn't necessarily be a deal breaker, but if there's significant divergence in the flows, topology, etc, it will add a lot of challenge.

[cshmerling]

1. Since Protected App Signals is an Android API, most of the on-device documentation will live on developers.google.com, as is the norm for Android proposals. Since there is a server-side component (i.e. Ad Retrieval), that will live on GitHub with the rest of the services documentation and code. We are always evaluating where we are hosting this information, so changes in the future may occur.
2. (As you may have figured out by now) There are no engagements similar to the regularly occurring meetings that appear for Chrome APIs. However, the team is interested in feedback so please feel free to raise issues on GitHub.
3. Not at the moment. For 3b, answer is in the next line.
4. Protected App Signals is a new proposal that aims to support a use case for mobile advertising that wasn't quite covered by Protected Audience. For Android, these APIs will both co-exist and have their own support for event reporting, ad retrieval, etc.
5. Protected App Signals is only supported in a B&A auction.