Are ad interactions in the threat model?

[martinthomson]

See https://varun.ch/history for the shape of the attack that I'm thinking about. That specific attack has an expiration date now that browsers seem likely to partition :visited. However, Protected Audience specifically creates cross-origin signals that might be exploited in a similar way.

[michaelkleber]

We should indeed consider this part of the threat model, though of course at lower priority than privacy leaks that don't depend on a bunch of user interactions.

In a world with Fenced Frame rendering, we break the ability to associate clicks inside a rendered creative with the surrounding page. The "Ads Composed of Multiple Pieces" feature does offer a way to push more information into the rendered ad CAPTCHA-style, but again Fenced Frames on the components still prevent the various clicks from interacting with each other. (It's possible that timing attacks could circumvent this.)

[martinthomson]

What if these weren't items shown in a single frame, but multiple ads? An ad target could be the current page, plus '#clicked_ad_4' (or what amounts to that in if you don't block fragments for some reason). Worst case, the effect is navigation for every click, but with caching and view transitions, maybe that's not so much of a barrier.

I guess the reason to mention this is to challenge the assumption that interaction justifies release of information.

[michaelkleber]

Hey @shivanigithub and @jkarlin, please join in this interesting conversation on the isolation properties of Fenced Frames post-click.

I believe that an ad rendered inside a Fenced Frame cannot navigate to a fragment — within the Fenced Frame the "top URL" would be the FF's render URL, and its DOM tree is broken off from that of the surrounding page.

When we initially conceived of it, the FF would not be able to navigate to the current page either, because it would not know the current page's URL at all — it's supposed to be this k-anonymous thing that renders without any access to the surrounding context. The templating capability of deprecatedReplaceInURN function violates this, and that information-flowing-in leakage certainly would allow attaching a publisher-domain identifier to the sort of information-extraction click attack here. So depending on what we design in the next few years, we might well have ways to limit multiple-click-based exfiltration.

But I don't think that remedy would help with the other CAPTCHA-style exfiltration attack, "Please type into this box the sequence of characters you see above" 😞

[martinthomson]

Oh, I didn't think of that attack, it's a good one 😬 It's a different one, in that it relies on a similar "social engineering" approach, but it doesn't involve direct interaction.

Or another one: have buttons with labels that are "ads". The "ads" tell you what an adjacent button does, but the ad itself does nothing on interaction. The buttons are not fenced and record which one was clicked. "(ad: next page) ➡️" and "(ad: blank) ➡️" That specific example is a bit weird, in that people might click either button, but I'm guessing that you could correct for that. And that's the stupid version; I'm sure someone could find a context where that style of attack makes more sense. Like maybe having fenced ads beside checkboxes. "🔳 (ad: Include discount (-$100))" "🔳 (ad: Include option nobody wants ($lots))".

Or another: frame each "ad" inside an element that puts a border around the image. Watch for which of those elements last had a mouse-related event. The attack really only works for people who use a mouse, but it suggests that there is a trove of interesting options for attacks.

So if you can't manage a top-level navigation, what can the result of an interaction be? Is it just a new tab/window? In that case, if the target is on the same site as the top-level page, the information leaks just as effectively. The window/tab could be shown with similar content (maybe with the fenced content replaced with something else as though it were thinking), but then closed as soon as the information is harvested.

You could try to fully isolate the target site, but I'm not sure that the effect of that is very desirable. It's not like you can do any of the things you might do for ads either, you always have this problem. It's not like you can preload the target of all ads an expect them to be happy with no communication with the outside world.

[martinthomson]

Just as a note about bad assumptions on my behalf. You claim that fenced content cannot perform top-level navigations, but I had a really hard time working out how that is supposed to fit together. The explainer never really mentions this as a constraint on rendering.

There is talk about the addition of _unfencedTop here. But the fenced frames specification, for all its talk about traversibles, doesn't include a single mention of that string. Nor does the Protected Audience specification seem to mention setting any policy that might govern the availability of that capability when it constructs a fenced frame config.

All that said, I don't think that attempting to restrict navigation - at least in the way I think you are saying it is restricted - is an effective protection against this sort of leak.

[shivanigithub]

IIUC, the visited styling attack goes away if any navigation initiated from a FF is not reflected as visited in any other context, and vice versa, correct? If so, this is something we are planning to address as an extension of visited styles partitioning work

Just as a note about bad assumptions on my behalf. You claim that fenced content cannot perform top-level navigations, but I had a really hard time working out how that is supposed to fit together. The explainer never really mentions this as a constraint on rendering.

There is talk about the addition of _unfencedTop here. But the fenced frames specification, for all its talk about traversibles, doesn't include a single mention of that string. Nor does the Protected Audience specification seem to mention setting any policy that might govern the availability of that capability when it constructs a fenced frame config.

All that said, I don't think that attempting to restrict navigation - at least in the way I think you are saying it is restricted - is an effective protection against this sort of leak.

fenced frames can initiate top-level navigations on user activation, yes. The _unfencedTop target is in progress of being added to the spec.

[kyraseevers]

Hey all - I wanted to give an update here that we have decided to remove :visited-ness in Fenced Frames (and ensured that no navigations coming from or happening inside Fenced Frames are being stored in the :visited hashtable). This functionality is currently behind the blink::features::PartitionVisitedLinkDatabase feature flag beginning in Chrome M130. This feature flag is currently disabled by default but is a part of active Chrome experiments encompassed by our Intent to Experiment for Partitioning :visited Link History Phase 2. Feel free to reach out with any additional questions!

[shivanigithub]

There are a few categories of attacks being discussed in this issue. To summarize:

1. visited links : this will be mitigated as per the comment above.
2. clicking on a given frame out of a grid of frames: This is in our threat model and we are working on a solution to this, as part of the new window.fence.notifyEvent API. Rate limiting the number of related fenced frames that the user can see will help these kind of attacks and we will update the explainer (and here), once the design is more fleshed out with the details of those rate limits.
3. Captcha style attack: Making the user copy content from within the FF to outside or making the user click at a given time, etc. We are thinking through UX considerations that might help with these, but don't have a good insight yet into what UX, if any, will be helpful here.