Web push doručí zprávu i zavřené stránce, aniž by prostředník znal její obsah

Kartu s webem jste zavřeli před hodinou a přesto se ozve: na telefonu vyjede lišta, na počítači bublina v rohu. Stránka přitom nikde tiše neběží. Doručení má na starost web push, trojice norem IETF a k nim rozhraní Push API od W3C. Poslední dvě normy vyšly v listopadu 2017.

V řetězu jsou tři strany, ne dvě

Norma RFC 8030 z prosince 2016 je pojmenovává takhle. Prohlížeč (v normě „user agent“) drží jedno jediné spojení s doručovací službou („push service“), kterou má nastavenou od svého výrobce. Server webu („application server“) do toho spojení nevidí; když chce něco poslat, zavolá doručovací službu obyčejným HTTP požadavkem.

Proč to takhle vzniklo, stojí v normě hned v úvodu: kvůli rádiu. Každá aplikace s vlastním trvalým spojením budí bezdrátový modul zvlášť a provoz posílaný jen proto, aby spojení nespadlo, podle normy dlouhodobě převáží nad samotnými událostmi. Jedno sdílené spojení pro všechny weby ušetří baterii.

Odběr vzniká tak, že si stránka u prohlížeče vyžádá subscription a dostane zpátky adresu (endpoint) a klíče. Adresa je podle dokumentace MDN takzvaná capability URL: kdo ji zná, může na ni poslat zprávu. Ven se dostat nesmí.

Obsah zprávy doručovatel nepřečte

Že mezi webem a čtenářem sedí cizí firma, řeší RFC 8291. Prohlížeč si ke každému odběru vyrobí pár klíčů na eliptické křivce P-256 a k tomu šestnáct náhodných bajtů, kterým norma říká autentizační tajemství. Veřejnou část pošle serveru webu. Ten při odesílání vygeneruje vlastní pár klíčů, obě strany si přes ECDH spočítají totéž sdílené tajemství, protáhnou ho odvozovací funkcí HKDF se SHA-256 a výsledkem se text zašifruje kódováním aes128gcm. Doručovací služba veze zapečetěnou obálku.

Opačným směrem řeší důvěru RFC 8292, zkráceně VAPID: server webu se doručovací službě představí podepsaným tokenem JWT. Prohlížeč si při zakládání odběru vyžádá veřejný klíč serveru a služba pak přijme jen zprávy podepsané tím soukromým.

Šifrování chrání text, ne okolnosti

Oddíl o soukromí v RFC 8030 to přiznává natvrdo: důvěrnost zprávy nezaručuje, že zůstane skryté, kdo s kým komunikuje a kdy. Doručovací služba zná adresu odběru, adresu zařízení, čas doručení a velikost každé zprávy.

Jedno pravidlo proti spojování údajů tam je: ze samotného obsahu dvou adres odběru nesmí jít poznat, že patří témuž prohlížeči. Vedle toho ale norma zavádí hlavičku Topic, kterou se dá starší nedoručená zpráva nahradit novější, a u ní rovnou píše, že umožňuje jemnější přiřazování zpráv ke stejnému námětu a dá se použít k analýze provozu. Kapitola o bezpečnosti končí připomínkou, že adresy odběrů a vztahy mezi nimi se v serverových záznamech objeví samy od sebe.

Odesílatel přidává dvě hlavičky. TTL říká, jak dlouho má služba zprávu schovávat, když je zařízení offline; nula znamená doručit hned, jinak nikdy. Urgency má čtyři stupně (very-low, low, normal, high) a norma u nich uvádí příklady: nejnižší je reklama, nejvyšší příchozí hovor. Prohlížeč si smí říct, od kterého stupně výš chce být rušen, ale samotnou hlavičku mu služba předat nesmí.

Tichá zpráva je v praxi zakázaná

Teoreticky by šel web push použít, aniž by uživatel cokoli viděl, třeba na tiché stažení dat na pozadí. Chrome a Edge to nedovolí: podle MDN odmítnou odběr založit, pokud stránka nenastaví userVisibleOnly: true, tedy neslíbí, že z každé došlé zprávy udělá viditelné upozornění.

Firefox na totéž jde jinak: počet zpráv omezuje kvótou, do níž se nepočítají ty, ze kterých vznikne upozornění, a která se obnoví při každé návštěvě webu. Chrome podle téže stránky MDN žádný strop nemá.

Kdy zvonek dává smysl

MDN má na to samostatnou stránku doporučení a její zkouška je krátká: čeká někdo v reálném čase na odpověď a je ta informace časově citlivá? To odděluje zprávu z chatu od upozornění na slevu.

Jak vypadá první případ, ukazuje chatujme.cz: v seznamu změn stojí u funkce Halo, že zazvoněním upozorníte odběratele místnosti, že se něco děje, a že upozornění dorazí i mimo web. Jakou cestou, seznam změn neuvádí.

Prohlížeče se zvonění brání samy

O povolení se nesmí žádat jen tak. Safari to od verze 12.1 podmiňuje tím, že návštěvník se stránkou nejdřív něco udělá; Firefox totéž doplnil ve verzi 68, zprvu vypnuté za předvolbou, a od verze 72 vyžaduje gesto i pro samotné založení odběru. Bez toho se dotaz objevil dřív, než čtenář stihl první odstavec.

Nejdál zašel Chrome. V říjnu 2025 oznámil, že bude povolení sám odebírat webům, se kterými uživatel nedávno nic nedělal a které přitom posílají hodně zpráv. Zdůvodnil to číslem: na méně než jedno procento všech upozornění někdo zareaguje. Odebrání se netýká webových aplikací nainstalovaných do systému, Chrome o něm dá vědět, povolení jde vrátit a celou automatiku vypnout. Podle vlastních zkoušek Googlu přitom weby, které posílají méně zpráv, na prokliknutí naopak získaly.

Na iPhonu to chce ikonu na ploše

Do Safari na macOS pustil Apple web push ve verzi 16.1, na telefonu a tabletu to trvalo déle a má to podmínku. Oznámení WebKitu z 16. února 2023, vydané s první betou iOS a iPadOS 16.4, ji popisuje jasně: upozornění dostane jen web přidaný na plochu, a i pak musí o povolení požádat v přímé reakci na dotek. Odtud se chová jako každá jiná aplikace, tedy ukáže se na zamčené obrazovce, respektuje režim Soustředění a vypíná se v systémovém nastavení oznámení. Doručuje to Apple Push Notification service a placený vývojářský účet k tomu není potřeba.

Kde se to vypíná

Povolení je vázané na doménu a má tři stavy: uděleno, zamítnuto a nerozhodnuto. To poslední se pro web chová jako zamítnuto, jen se prohlížeč smí zeptat znovu. Na počítači se stav mění v nastavení konkrétní stránky (ikona vedle adresy) nebo v seznamu povolení. Na Androidu je k tomu navíc systémový přehled oznámení a na iPhonu jenom on, protože povolení tam patří k ikoně na ploše, ne ke kartě prohlížeče.

Rozhodování o tom, co smí zvonit, se rozdrobilo mezi tři místa: norma řekla, co smí doručovatel vidět, prohlížeč, kdy se web smí ptát, a zbytek zůstal na čtenáři – od loňského podzimu i s pomocí, o kterou nežádal.

Zdroje

• RFC 8030, Generic Event Delivery Using HTTP Push (IETF, prosinec 2016) – tři role v řetězu, hlavičky TTL, Urgency a Topic, oddíl o soukromí.
• RFC 8291, Message Encryption for Web Push (IETF, listopad 2017) – ECDH na křivce P-256, HKDF se SHA-256, kódování aes128gcm.
• RFC 8292, VAPID for Web Push (IETF, listopad 2017) – jak se server webu představí doručovací službě.
• MDN, Push API – endpoint jako capability URL a kvóta zpráv ve Firefoxu.
• MDN, PushManager.subscribe() – povinné userVisibleOnly v Chromu a Edgi a gesto od Firefoxu 72.
• MDN, Web Push API Notifications best practices – požadavek Safari 12.1 na interakci.
• Chromium Blog, Reducing notification overload… (10. října 2025) – odebírání povolení a podíl upozornění s reakcí.
• WebKit, Web Push for Web Apps on iOS and iPadOS (16. února 2023) – podmínka ikony na ploše a Safari 16.1 na macOS.
• chatujme.cz, Co je nového – znění záznamu o funkci Halo.