Originally reported by Konark Modi in bug 1545605.

+++ This bug was initially created as a clone of Bug #1545605 +++

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.103 Safari/537.36

Steps to reproduce:

Firefox Version: 66.0.3
BuildID: 20190409155332
OS: macOS 10.14.4

Visit the following pages:

1. https://cdn.cliqz.com/browser-f/fun-demo/sw-test.html
2. https://cdn.cliqz.com/browser-f/fun-demo/worker-test/index.html
   • Prompts for permission for notification. Allow it.
3. https://independent.co.uk

Now:
History => Show All History => One by one right click on three sites above and select the option forget about this site.

Site is removed from this history.

Actual results:

Link 1. Service workers are not removed:
- about:debugging -> workers -> https://cdn.cliqz.com/browser-f/fun-demo/pwn.js
- On file system:
- serviceworker.txt:https://cdn.cliqz.com/browser-f/fun-demo/
- serviceworker.txt:https://cdn.cliqz.com/browser-f/fun-demo/pwn.js

Link 2: Notification data is not deleted
- Even after forget about this site, the filenotificationstore.json contains this entry:
notificationstore.json:{"https://cdn.cliqz.com":{"{6f28d939-daaf-cf45-ade2-cd2e4106421c}":{"id":"{6f28d939-daaf-cf45-ade2-cd2e4106421c}","title":"Hi there!","dir":"auto","lang":"","body":"","tag":"","icon":"","alertName":"https://cdn.cliqz.com#notag:{6f28d939-daaf-cf45-ade2-cd2e4106421c}","timestamp":1555623703582,"origin":"https://cdn.cliqz.com","data":"","mozbehavior":"{\"noclear\":false,\"noscreen\":false,\"showOnlyOnce\":false,\"soundFile\":\"\"}","serviceWorkerRegistrationScope":""},"{7691e4f8-7577-d14e-ade9-8234697931ee}":{"id":"{7691e4f8-7577-d14e-ade9-8234697931ee}","title":"Hi there!","dir":"auto","lang":"","body":"","tag":"","icon":"","alertName":"https://cdn.cliqz.com#notag:{7691e4f8-7577-d14e-ade9-8234697931ee}","timestamp":1555623703583,"origin":"https://cdn.cliqz.com","data":"","mozbehavior":"{\"noclear\":false,\"noscreen\":false,\"showOnlyOnce\":false,\"soundFile\":\"\"}","serviceWorkerRegistrationScope":""}}}

Link 3:
- serviceworker.txt:https://www.independent.co.uk/
- serviceworker.txt:https://www.independent.co.uk/sw.js
- Binary file storage/default/https+++www.independent.co.uk/.metadata matches
- Binary file storage/default/https+++www.independent.co.uk/.metadata-v2 matches
- Binary file storage/default/https+++www.independent.co.uk/ls/data.sqlite matches

If the user has first party isolation enabled, then after visiting link3 and forget about this site, these are the footprints on the disk. SiteSecurityServiceState.txt:www.google-analytics.com^firstPartyDomain=independent.co.uk:HSTS 0 18004 1566510996706,1,1,2
SiteSecurityServiceState.txt:fonts.googleapis.com^firstPartyDomain=independent.co.uk:HSTS 0 18004 1587160596528,1,0,2
SiteSecurityServiceState.txt:cdn.ampproject.org^firstPartyDomain=independent.co.uk:HSTS 0 18004 1587160595739,1,1,2
SiteSecurityServiceState.txt:stats.g.doubleclick.net^firstPartyDomain=independent.co.uk:HSTS 0 18004 1566510998402,1,1,2
Binary file cookies.sqlite matches
Binary file places.sqlite matches
serviceworker.txt:^firstPartyDomain=independent.co.uk
serviceworker.txt:https://www.independent.co.uk/
serviceworker.txt:https://www.independent.co.uk/sw.js
Binary file storage/default/https+++www.independent.co.uk^firstPartyDomain=independent.co.uk/.metadata matches
Binary file storage/default/https+++www.independent.co.uk^firstPartyDomain=independent.co.uk/.metadata-v2 matches
Binary file storage/default/https+++www.independent.co.uk^firstPartyDomain=independent.co.uk/ls/data.sqlite matches
Binary file webappsstore.sqlite matches

Expected results:

• In all these scenarios, the expectation is that there is no footprint of the domain visited by the user. But in scenarios mentioned above it seems that's not the case.

• Additionally, third-parties loaded on the webpage are not removed. Which seem like a known behaviour when first-party isolation is not enabled.

But if first party isolation is enabled, the user visits independent.co.uk and a third-party like google.com set's a key. On doing forget about this site, cookies for Google keyed with independent.co.uk are not removed, allowing Google to track the next time user visits independent.co.uk.

Hi Myk, Lina,

I'm trying to investigate this issue, however due to bug 1515094 I'm not sure how to inspect notification data anymore. Are there any JS-accessible APIs for looking at kvstore data that I can use for local inspection and writing tests?

Thanks!

Hi Johann! It makes sense to add an API to NotificationDB.jsm to clear out all notifications for an origin. I think you can import it now, use taskGetAll({ origin: "..." }) to get all notification IDs for that origin, then call taskDelete({ origin, id }) on each one, but we can be more efficient. Does that work for now?

(In reply to Lina Cambridge (she/her) [:lina] from comment #2)

Hi Johann! It makes sense to add an API to NotificationDB.jsm to clear out all notifications for an origin. I think you can import it now, use taskGetAll({ origin: "..." }) to get all notification IDs for that origin, then call taskDelete({ origin, id }) on each one, but we can be more efficient. Does that work for now?

We already have the functionality to clear Notifications in ClearDataService (though clearing by origin would be a nice addition). My question was more about how do I inspect the notifications database to make sure that this has been successful and to write automated tests?

Thanks!

(In reply to Johann Hofmann [:johannh] from comment #3)

We already have the functionality to clear Notifications in ClearDataService (though clearing by origin would be a nice addition).

That's different. PushNotificationsCleaner cleans push subscriptions, not notification data.

My question was more about how do I inspect the notifications database to make sure that this has been successful and to write automated tests?

Thanks!

For testing, you could also import NotificationDB.jsm and use taskGetAll to fetch all notifications, and verify the array is empty. If you'd prefer to avoid that, it's a bit trickier, because we ship both the old JSON and new rkv implementations now behind a MOZ_NEW_NOTIFICATION_STORE flag (bug 1547877). You'd need to read the file or use kvstore.jsm to open the database yourself, then copy what taskGetAll does for each one.

Oops, sorry, I meant to ni? you! 😄 Did I understand your question, Johann?

(In reply to Lina Cambridge (she/her) [:lina] from comment #4)

(In reply to Johann Hofmann [:johannh] from comment #3)

We already have the functionality to clear Notifications in ClearDataService (though clearing by origin would be a nice addition).

That's different. PushNotificationsCleaner cleans push subscriptions, not notification data.

Oooh, very interesting. That's our bug then, I suppose...

My question was more about how do I inspect the notifications database to make sure that this has been successful and to write automated tests?

Thanks!

For testing, you could also import NotificationDB.jsm and use taskGetAll to fetch all notifications, and verify the array is empty. If you'd prefer to avoid that, it's a bit trickier, because we ship both the old JSON and new rkv implementations now behind a MOZ_NEW_NOTIFICATION_STORE flag (bug 1547877). You'd need to read the file or use kvstore.jsm to open the database yourself, then copy what taskGetAll does for each one.

Ah, yeah, that former suggestion seems like it would do the trick, thank you, I'll try to look into it.

I can still partially reproduce this. Looks like the service worker registrations are deleted properly, but Notification data persists in data.safe.bin.