8. Security Considerations
8. Security Considerations
Il protocollo MUST usare HTTP su TLS [RFC2818] secondo [RFC7525], tra user agent e push service e tra server applicativo e push service. Tutti gli URI usano https per riservatezza e integrità rispetto a terzi.
8.1. Confidentiality from Push Service Access
TLS non protegge il contenuto dal push service. Senza ulteriori misure, il servizio può ispezionare e modificare il messaggio.
Le applicazioni MUST usare meccanismi con riservatezza, integrità e autenticazione dell'origine end-to-end. Spesso server e client sono istanze della stessa applicazione; la distribuzione dell'abbonamento aiuta lo scambio di chiavi.
La Push API del W3C [API] adotta [ENCRYPT] per proteggere il contenuto dal servizio.
Il campo Topic espone informazioni per correlare messaggi sullo stesso argomento e può aiutare analisi del traffico.
8.2. Privacy Considerations
La riservatezza del messaggio non protegge chi comunica e quando; si può comunque limitare ciò che è esposto.
Le URI push MUST NOT permettere di correlare le comunicazioni di un dato user agent. Due URI push MUST NOT essere correlabili solo dal contenuto.
Le URI dei messaggi MUST NOT permettere correlazione tra abbonamenti; per lo stesso abbonamento MAY contenere informazioni correlabili con l'abbonamento o altri messaggi dello stesso abbonamento.
Informazioni su utente e dispositivo MUST NOT essere esposte tramite URI push o messaggio.
Inoltre, URI push dello stesso user agent o URI messaggio dello stesso abbonamento MUST NOT includere informazioni che permettano correlazione con l'user agent.
Nota: non serve perfezione se l'insieme di anonimato ([RFC6973], 6.1.1) è sufficientemente grande.
L'user agent MUST poter creare nuovi abbonamenti con nuovi identificatori in qualsiasi momento.
8.3. Authorization
Il protocollo non definisce come il servizio autorizza creazione o consegna. Il servizio MAY usare qualsiasi metodo di autorizzazione compatibile con HTTP. Il processo è configurato nell'user agent insieme all'URL del servizio.
L'autorizzazione usa capability URL [CAP-URI] per abbonamento messaggi, push e receipt subscription: l'accesso si basa sulla conoscenza dell'URL.
Consentono condivisione semplice e API client semplici senza relazioni predefinite aggiuntive.
Si comportano come bearer token: conoscenza dell'URI di abbonamento implica ricezione o cancellazione; dell'URI push invio; dell'URI messaggio lettura e ack; dell'URI receipt subscription ricezione ricevute.
Almeno 120 bit di entropia casuale nel percorso rende difficile indovinare URL validi.
8.4. Denial-of-Service Considerations
Limitando la diffusione delle URI push ai server autorizzati si controlla l'origine. URI difficili da indovinare limitano l'abuso.
Messaggi non autenticati dall'user agent non sono consegnati, ma anche pochi messaggi possono scaricare batterie.
La Push API adotta [VAPID] per vincolare l'abbonamento a un server; il servizio può rifiutare spam senza contattare l'user agent.
Un'applicazione malevola con URI push valida può sfruttare le risorse del servizio. Il servizio SHOULD limitare la frequenza verso singoli user agent.
Il servizio MAY restituire 429 [RFC6585] e SHOULD includere Retry-After [RFC7231].
Servizio o user agent MAY terminare abbonamenti (7.3) che ricevono troppi messaggi.
Il servizio può anche negare servizio agli user agent; il mancato recapito intenzionale è difficile da distinguere da guasti.
8.5. Logging Risks
I log possono rivelare URI di abbonamento o relazioni tra essi. Limiti di conservazione e controlli di accesso riducono l'esposizione.