html5 notification permission spam/bomb

VERIFIED FIXED in Firefox 67

Status

()

defect
P2
normal
VERIFIED FIXED
9 months ago
2 months ago

People

(Reporter: felix.bau, Assigned: pbz)

Tracking

(Blocks 1 bug)

Trunk
Firefox 68
All
Unspecified
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox66 wontfix, firefox67 verified, firefox68 verified)

Details

Attachments

(1 attachment, 1 obsolete attachment)

Reporter

Description

9 months ago
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))
Reporter

Comment 1

9 months ago
it happens, when you press download on this page:
http://www.updownload.com/mozilla-firefox/
Reporter

Comment 2

9 months ago
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?
Flags: needinfo?(sdaswani)

Comment 4

8 months ago
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

Comment 7

5 months ago

Hi Johann, please comment on this. thanks!

Flags: needinfo?(wleung) → needinfo?(jhofmann)

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.

Blocks: eviltraps
Component: General → Site Identity and Permission Panels
Flags: needinfo?(jhofmann)
Priority: -- → P2
Product: Firefox for Android → Firefox
OS: Android → Unspecified
Hardware: ARM → All
Assignee

Updated

3 months ago
Assignee: nobody → pzuhlcke

Comment 11

3 months 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

3 months 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

3 months 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

3 months ago
bugherder
Status: NEW → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 68

We should consider uplifting after this had some bake time. Maybe in a week?

(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?

Flags: needinfo?(jhofmann)

Yes, thank you for the reminder, though maybe Paul wants to do the uplift request? :)

Flags: needinfo?(jhofmann) → needinfo?(pzuhlcke)
Attachment #9055896 - Attachment is obsolete: true
Assignee

Comment 18

2 months 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:
Flags: needinfo?(pzuhlcke)
Attachment #9056896 - Flags: approval-mozilla-beta?
Assignee

Updated

2 months ago
Flags: qe-verify?

Let's get it verified on Nightly before uplifting to beta.

Flags: qe-verify? → qe-verify+
QA Whiteboard: [qa-triaged]

Comment 20

2 months 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/:

Please let me know if there is anything else that should be checked out.

Status: RESOLVED → VERIFIED
Flags: qe-verify+

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

Attachment #9056896 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

Setting QE-verify+ flag back as I want it verified on Beta as well.

Flags: qe-verify+

Comment 24

2 months ago

Verified - fixed on latest Beta 67.0b13 (64-bit) on Windows 7/10, Mac OS 10.13 and Ubuntu 16.04

QA Whiteboard: [qa-triaged]
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.