From 7d098dbaeab2774d48c12feac55285502b80826a Mon Sep 17 00:00:00 2001 From: anitawoodruff Date: Tue, 10 Jul 2018 10:33:45 +0100 Subject: [PATCH] Rephrase Potential for Abuse section As pointed out in TAG review[1], the fact that notifications are https-only strengthens the 'clear attribution' mitigation argument, rather than being a separate mitigation on its own. [1] https://github.com/w3ctag/design-reviews/issues/284 --- README.md | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/README.md b/README.md index 718048d..69a5ef5 100644 --- a/README.md +++ b/README.md @@ -84,14 +84,10 @@ for the same information. - **This can be mitigated by clear attribution** - all major implementations already do this, and a note will be added to the spec to make it clear that notifications should be clearly attributed to the origin of the service worker -or document which showed them. +or document which showed them. This attribution can be considered reliable since notifications may only be shown by secure +origins. -There's two other factors which help here: - -- **requires a permission** - A spoof site would first need to gain notification permission from the user -before it could show a notification abusing this feature. - -- **notifications are https-only** - Notifications can only be sent from secure origins. +- A further mitigation is that showing notifications **requires a permission** - a spoof site would first need to gain notification permission from the user before it could show a notification abusing this feature. ## Appendix: alternatives considered