Skip to content
This repository has been archived by the owner on Mar 16, 2023. It is now read-only.

Adversarial attack. #38

Open
ArthurSonzogni opened this issue Feb 2, 2021 · 4 comments
Open

Adversarial attack. #38

ArthurSonzogni opened this issue Feb 2, 2021 · 4 comments

Comments

@ArthurSonzogni
Copy link

What will prevent a malicious website from abusing FLOC and force users into arbitrary cohort?

Some ideas:

  • Create iframes outside of the viewport and make them navigate many times to specific websites.
  • Create top-level document, far way from user's attention using w = window.open(); w.resizeTo(w,h); w.moveTo(x,y). Then make them navigate many times, once the popup is put into the background.
  • Periodically modify the full path of the URL using same-document navigations via the history API.
  • Periodically modify the content of the page, preferably in locations the user can't see.

It would worth documenting was is put in place for preventing this in practise.
+@arturjanc FYI.

@jkarlin
Copy link
Collaborator

jkarlin commented Feb 2, 2021

Thanks for opening the issue Arthur.

Create iframes outside of the viewport and make them navigate many times to specific websites.

We're only looking at top-level navigations, so this won't impact FLoC.

Create top-level document, far way from user's attention using w = window.open(); w.resizeTo(w,h); w.moveTo(x,y). Then make
them navigate many times, once the popup is put into the background.

Interesting. I think we can mitigate this by only including navigations which were created due to a user gesture.

Periodically modify the full path of the URL using same-document navigations via the history API.

Should be solved by the above.

Periodically modify the content of the page, preferably in locations the user can't see.

If we were to incorporate page content into the FLoC clustering algorithm, I don't think it would update over the life of the page. It'd likely be snapshotted sometime shortly after the page load. That said, we would need to be careful that the context that is fed to the algorithm is the same content that the user sees for reasons like you say here.

@csharrison
Copy link

+1 to gating floc inclusion on navigation that had user activation, though I am not sure how that will affect performance. This is a similar mechanism as scroll-to-text fragment (https://web.dev/text-fragments/#security)

@ArthurSonzogni
Copy link
Author

+1 for considering only the navigations initiated by the user.
This sounds like a really nice way to ensure the cohort really represent the user and not some malicious spamming actor.

@arturjanc
Copy link

On a related note, it seems useful for the explainer to clearly outline the kinds of information that can influence the FLoC:

  • Top-level only vs. all documents (including frames).
  • Document URL vs. site vs. origin.
  • Navigations triggered by user activation vs. all navigations, as discussed above.
  • Whether contents of the page would be taken into account or not.

I realize it's difficult to answer this because we may not know this in advance, but this is crucial for the security/privacy model because it influences what kind of information could potentially be exposed via the FLoC.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants
  翻译: