html5 notification permission spam/bomb
Categories
(Firefox :: Site Identity, defect, P2)
Tracking
()
People
(Reporter: felix.bau, Assigned: pbz)
References
(Blocks 1 open bug)
Details
Attachments
(1 file, 1 obsolete file)
47 bytes,
text/x-phabricator-request
|
pascalc
:
approval-mozilla-beta+
|
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
Comment 3•6 years ago
|
||
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.
Comment 5•5 years ago
|
||
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.
Comment 6•5 years ago
|
||
This is more in Wennie's team's area.
Updated•5 years ago
|
Hi Johann, please comment on this. thanks!
Comment 8•5 years ago
|
||
I don't think this should be changed in DOM land. Extending only the "Never" permission to domain level is a bit ... unprecedented and I'm not sure I have a full grasp of the privacy and compatibility implications at the moment. There are technical challenges with being sub-domain specific for "allow" and domain-specific for "deny" that I personally don't want to shake up at the moment.
"Not Now" is a client-side feature that should prevent the site from asking again immediately until Firefox deems it appropriate. In this case I think we can simply extend the temporary permission check to cover sub-domains, which is much easier.
Considering that Fennec probably won't take this anymore based on its maintenance state I'll claim it for desktop to work on. I'm happy to clone the bug if you'd like to keep it in Fennec land, though.
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 9•5 years ago
|
||
Assignee | ||
Comment 10•5 years ago
|
||
Comment 11•5 years ago
|
||
Pushed by jhofmann@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/1839a68aea95 Store temporary site permissions by base domain to mitigate permission notification spam r=johannh
Comment 12•5 years ago
|
||
Backout by csabou@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/2b272977a1e5 Backed out changeset 1839a68aea95 for assertion failures on GMPParent.cpp. CLOSED TREE
Comment 13•5 years ago
|
||
Pushed by csabou@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/6db3e21f8901 Store temporary site permissions by base domain to mitigate permission notification spam r=johannh
Comment 14•5 years ago
|
||
bugherder |
Comment 15•5 years ago
|
||
We should consider uplifting after this had some bake time. Maybe in a week?
Comment 16•5 years ago
|
||
(In reply to Johann Hofmann [:johannh] from comment #15)
We should consider uplifting after this had some bake time. Maybe in a week?
Johann, do you still want to uplift this?
Comment 17•5 years ago
|
||
Yes, thank you for the reminder, though maybe Paul wants to do the uplift request? :)
Updated•5 years ago
|
Assignee | ||
Comment 18•5 years ago
|
||
Comment on attachment 9056896 [details]
Bug 1492668 - Store temporary site permissions by base domain to mitigate permission notification spam r=johannh
Beta/Release Uplift Approval Request
- Feature/Bug causing the regression: none
- User impact if declined: Websites can abuse notification permission prompts to spam the user.
- Is this code covered by automated tests?: Yes
- Has the fix been verified in Nightly?: No
- Needs manual test from QE?: Yes
- If yes, steps to reproduce: Test website: https://evil.pbz.pw/spam/notification-perm-prompt/
- List of other uplifts needed: None
- Risk to taking this patch: Medium
- Why is the change risky/not risky? (and alternatives if risky): Patch is tested and had baketime in nightly.
Medium risk because site permissions has many consumers and there could be side effects we haven't noticed yet. - String changes made/needed:
Assignee | ||
Updated•5 years ago
|
Comment 19•5 years ago
|
||
Let's get it verified on Nightly before uplifting to beta.
Updated•5 years ago
|
Comment 20•5 years ago
|
||
Verified - fixed on latest Nightly 68.0a1 (2019-04-17) (64-bit) on Windows 7/10, Mac OS 10.13 and Ubuntu 16.04
On the https://evil.pbz.pw/spam/notification-perm-prompt/:
- on the notification permission is set to Never Allow, the notification prompt will not be displayed regardless of restarting Nightly, reloading the page in a new or the same tab
- on the https://es-novosti.com/index.php?click_id=3714563925&wmi=1356&lp=5&custom_bg=https://s7.wampi.ru/2018/09/13/PUSLEND.jpg site the notification prompt is instantly blocked and all the sub-domains start loading one by one.
Please let me know if there is anything else that should be checked out.
Comment 21•5 years ago
|
||
Comment on attachment 9056896 [details]
Bug 1492668 - Store temporary site permissions by base domain to mitigate permission notification spam r=johannh
Patch with tests and verified by QA on Nightly, uplift approved for 67 beta 12, thanks
Updated•5 years ago
|
Comment 22•5 years ago
|
||
Setting QE-verify+ flag back as I want it verified on Beta as well.
Comment 23•5 years ago
|
||
bugherder uplift |
Comment 24•5 years ago
|
||
Verified - fixed on latest Beta 67.0b13 (64-bit) on Windows 7/10, Mac OS 10.13 and Ubuntu 16.04
Description
•