Ghostery causing PWA install prompt spam

[dmurph]

Hello,

Sites that are promotable and use the beforeinstallprompt API can spam ghostery users with install prompts. They just have to specify this as their beforeinstallprompt event handler:

window.addEventListener('beforeinstallprompt', (e)=>{
  e.prompt();
});

Example: https://parkseed.com/, click on any link from their menu bar.

During normal operation, this should simply print the following to the console:

Uncaught (in promise) DOMException: Failed to execute 'prompt' on 'BeforeInstallPromptEvent': The prompt() method must be called with a user gesture
    at [https://parkseed.com/Javascript/HomePageJS.bundle.js?v=65:495:7](https://www.google.com/url?q=https://parkseed.com/Javascript/HomePageJS.bundle.js?v%3D65:495:7&sa=D&source=buganizer&usg=AOvVaw14de6MRVAw-FT3r8ppE_Rk)

With ghostery installed, it does this, AND somehow the 'prompt()' call here is activated, meaning that ghostery has somehow caused this event handler to be fired again with the 'user gesture' flag set.

So the simple test case is:

• Install Ghostery
• Visit parkseed.com
• Click on any link from their menu bar

Expected:

• Simple navigation

Actual:

• PWA install prompt shown
• Navigation occurs

As a separate note.... it's pretty concerning that Ghostery is triggering javascript even listener code and pretends to be a user gesture. This user gesture flag is used to prevent malicious API usage that at a minimum spams the user, like the PWA install prompt. Can whatever functionality that needs to do this be redesigned, or at least locked down so it doesn't call any random even listener again? This is pretty scary.

Corresponding chromium issue: https://crbug.com/338254614

Test site: https://motley-petite-friday.glitch.me/

[dmurph]

Maybe this isn't scary and caused by something else - but it does seem to only repro with ghostery.

[dmurph]

There is definitely a Chromium bug, but this extension seems to make everything worse.... might be a bug here too.

[chrmod]

@dmurph Thank you for your report!

When reproducing I was able to crash Chromium, so something is definitely off.
Also, Firefox and Safari don't look to be affected (Probably have no support for PWA install prompts at all?)

Was able to identify that it is one of Ghostery core features - the Never-Consent that triggers the Chromium bug. As you have correctly noticed, this feature emulates user gestures to interact with Consent Managers to opt-out from all tracking on users behalf. So Ghostery the functionality works as expected.

For your information, this feature is implemented by the autoconsent library. I've notified their authors as more user, beyond Ghostery may be affected.

Will look into this deeper, maybe we can identify a rule that is responsible and implement it differently.

[dmurph]

I believe this has to do with the beforeinstallprompt catching a 'user gesture' when it really should never catch one. I guess user gestures are kind of 'on for some amount of time' for every js event? I would love to disable this for this specific event handler call, not sure how to do that yet.

[dmurph]

Circling back here - I don't see an obvious way to prevent user activation detection on a specific event listener. It does seem like having the ghostery extension installed with the autoconsent library causes more events to have the 'user activation' gesture active. This is a dangerous thing to do, and I hope something else can be implemented instead. By doing this you're opening up the user to dangerous stuff - one example is that website can spam permission requests. Example, various dangerous APIs use this to prevent spamming the user and malicious behavior. WebUSB is another, I believe bluetooth as well?

[dmurph]

More things that can happen:

• audio autoplay is blocked until user activation. This allows sites to auto-play music or videos with audio.
• fullscreen is blocked on user activation. This allows sites to make themselves fullscreen.

See more APIs that reference sticky activation here and user activation here. That means something in that spec is guarded on user activation. there may be more terms, I'm not sure (hard to look up list of all things that use user activation).

[philipp-classen]

Needs more testing, but it looks like it is only an issue on Ghostery 8 (on Chrome). But I think it is not the autoconsent library, and also the upcoming Ghostery 10 version seems to be unaffected. (For details, see duckduckgo/autoconsent#443 (comment))

To simplify testing, we can use the test site that @dmurph has created:

1. Go to https://motley-petite-friday.glitch.me/
2. Click on "Click me"

With Ghostery 8 (on Chrome), I get the "install app" popup. However, with Ghostery 10 (built locally following the steps in https://github.com/ghostery/ghostery-extension/tree/main/extension-manifest-v3), I cannot reproduce any longer.

[philipp-classen]

Can also be reproduced with Ghostery 8 on Edge, but again not with Ghostery 10. Same with Opera, which is already using Ghostery 10.

Since we submitted Ghostery 10 to review on Edge, it will show if it solves the problem. For now, I will update the tags: removing NeverConsent, but adding Ghostery 8.

[dmurph]

Thanks so much for the debugging!

[philipp-classen]

Removing the "edge" label, since Ghostery 10 has been released on Edge.

[htalat]

@philipp-classen I am able to repro in Edge Canary 127.0.2599.0 with Ghostery 10.3.2 though this time the spamming has stopped. The prompt shows up once ~5 clicks with @dmurph's example site https://motley-petite-friday.glitch.me/

[dmurph]

That behavior is unfortunately the chromium bug, so currently that is WAI according to spec