Closed Bug 1492668 Opened 2 years ago Closed 1 year ago
html5 notification permission spam/bomb
Bug 1492668 - Store temporary site permissions by base domain to mitigate permission notification spam r=johannh
47 bytes, text/x-phabricator-request
|Details | Review|
User Agent: Mozilla/5.0 (Android 7.0; Mobile; rv:62.0) Gecko/62.0 Firefox/62.0 Build ID: 20180906142540 Steps to reproduce: I stumbled across https://es-novosti.com/index.php?click_id=3714563925&wmi=1356&lp=5&custom_bg=https://s7.wampi.ru/2018/09/13/PUSLEND.jpg during the dark funnel campaign. be careful with the link! Actual results: it spams asking for the permission to send html5 notifications (Probably until you press yes, I haven't tested that because it's a hassle afterwards to delete such a permission) every time you deny, it redirects to the next subdomain Expected results: maybe some kind of spam protection (only once a page reload/once a minute per domain (not just Subdomains))
it happens, when you press download on this page: http://www.updownload.com/mozilla-firefox/
found a second page that tries to pull of the same... http://downloads.info/windows/internet/browsers/mozilla-firefox.html
This is reproducible for both desktop and mobile versions of FF, don't know if there is anything that can be done about it. For Chrome desktop, it automatically blocks the notification and changes from one page to another. The mobile version does the same as FF, displays a notification and the user has to tap on the Block option. @Susheel do you know anyone who could look at this or if there is anything that can be done in this case?
NI'ing Andreas to see if this is something we care to fix.
Flags: needinfo?(sdaswani) → needinfo?(abovens)
Yeah, I believe this is something that should be fixed, both on desktop and mobile. Possible options include: - make "Never" have a domain-level impact (unsure if this is per spec though) - detect a redirect happening straight after a permission prompt dismissal, and block subsequent non-user-gesture-invoked permission prompts for that session (I noticed that the notification permission is subdomain-specific, while the (mobile) doorhanger indicates its a domain-level setting ("example.com Would you like to receive notifications from this site?"). The desktop doorhanger is more precise, and lists the subdomain as well.) I think we need to loop in a permission specialist from the DOM team.
Flags: needinfo?(abovens) → needinfo?(overholt)
This is more in Wennie's team's area.
Flags: needinfo?(overholt) → needinfo?(wleung)
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Unspecified → Android
Hardware: Unspecified → ARM
Flags: needinfo?(wleung) → needinfo?(jhofmann)
Component: General → Site Identity and Permission Panels
Priority: -- → P2
Product: Firefox for Android → Firefox
2 years ago
OS: Android → Unspecified
Hardware: ARM → All
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/1839a68aea95 Store temporary site permissions by base domain to mitigate permission notification spam r=johannh
Backout by email@example.com: https://hg.mozilla.org/integration/autoland/rev/2b272977a1e5 Backed out changeset 1839a68aea95 for assertion failures on GMPParent.cpp. CLOSED TREE
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/6db3e21f8901 Store temporary site permissions by base domain to mitigate permission notification spam r=johannh
Flags: needinfo?(jhofmann) → needinfo?(pzuhlcke)
Attachment #9056896 - Flags: approval-mozilla-beta?
Flags: qe-verify? → qe-verify+
Attachment #9056896 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
You need to log in before you can comment on or make changes to this bug.