Feature Request: Expose non-user initiated navigation to advertising

[patmmccann]

The PAAPI component auctions may be a unique place for the browser to inject some very useful metadata.

One way in which fraudulent sites with stolen or nonsense content (eg https://web.archive.org/web/20150215194109/http://cookthefood.com/baking-of-naan-bread-for-good-flavor/ ) remain profitable is via the audience data of the users that go there, often via non-user-initiated navigation. For example, a pop-under network ( eg the one described at https://www.theregister.com/2022/12/22/google_ad_popunder_scam/ ) may send non-user initiated traffic to an MFA (made for advertising) site, yet third party cookies with user interest group data makes the advertising on these nonsense sites profitable.

Getting rid of third party cookies held the very real promise of removing these drains on advertising budgets and publisher revenue from the internet. However, sandbox proposals may keep them on life support.

If PAAPI exposes to all component sellers if the navigation were user-initiated or not, or perhaps a more reliable referral source than the one reported by the fraudulent publisher, it may help solve one of the more fundamental problems in open market internet advertising; eliminating one particular dark hole of advertising budgets.

[michaelkleber]

This is a very interesting point. I don't believe the state "Did this page come from a user-initiated navigation?" is currently web-exposed, but also I don't know whether this is for good reasons or just that it has never come up. I'll need to look into the history here.

If browsers are OK with exposing the user-initiated navigation bit at all, then I fully agree that making it available as a browser signal during the on-device auction is a great addition.

[dmdabbs]

ARA navigation registrations are only permitted on transient user activations so Chrome is tracking this. Doesn't seem like a privacy leak to provide a boolean Client Hint or something.

[michaelkleber]

@dmdabbs These are quite different concepts. There are indeed some APIs that are only available in the context of a user activation — that is, you can only do thing-X based on the fact that a user just clicked. But I believe @patmmccann is asking about the ability to only do thing-X if a user clicked to cause the navigation that led to their being on this page — so a state that persists across a navigation (perhaps a cross-site navigation) and for the whole lifetime of the subsequent page.

You may be right that it's OK to use / expose this, but I'm pretty sure it is a new signal that we're talking about, so we do need to be careful.

[patmmccann]

Thanks! That's exciting news and exposing this will go a long way to solve a really pernicious concern!

[michaelkleber]

Update: It turns out that this information is already made available by the browser upon navigation, in the Sec-Fetch-User HTTP Request Header.

Which is to say, right now the first-party server can tell whether or not the navigation was initiated by a user action, by looking at the HTTP headers for the initial request for the top-level HTML. That's not going to help with your use case directly. But the fact that browsers already reveal the information should smooth the way for revealing it in additional contexts.