Steeds meer apparaten worden 'connected'. Handig, maar er kleven ook flinke veiligheidsrisico's aan het Internet of Things. PCM zoekt uit waar de pijnpunten precies zitten.

Lees ook:Intel: 'Gebruikers moeten meer verantwoordelijkheid nemen bij IoT-aankopen'

Gedurende de afgelopen jaren ontdekten steeds meer smart-home-gebruikers dat veel verbonden apparaten helemaal niet zo zaligmakend bleken. Dergelijke apparatuur verzamelt namelijk bakken aan persoonlijke data. Wie een slimme thermostaat in huis heeft, stuurt bijvoorbeeld veel meer data naar zijn energieleverancier dan je aanvankelijk zou willen. Het gaat dan niet alleen om hoeveel energie je verbruikt, maar ook wanneer je doorgaans niet thuis bent (handige informatie voor inbrekers). Een slimme koelkast weet wat je het liefst eet, en de tandenborstel weet of je wel goed poetst - informatie die voor een zorgverzekeraar wel erg interessant is.

Die privacygevoelige gegevens zijn bovendien nauw verbonden met de beveiligingsproblemen van het IoT. Dát je energiemaatschappij die gegevens verzamelt, is tot daar aan toe. Maar het is vrijwel onmogelijk te garanderen dat ze daar veilig zijn.

"De meeste bedrijven die nu slimme apparatuur aanbieden, zijn van oudsher geen techbedrijven", vertelt de man (“een Europese programmeur”) achter het bekende Twitter-account @InternetOfShit, een account dat dagelijks belachelijk maakt hoe vergezocht én onveilig veel IoT-apparaten zijn. "Databescherming is voor hen minder vanzelfsprekend, en dat leidt tot slechte beveiliging van servers waardoor privacygevoelige gegevens eerder op straat komen te liggen."

Encryptie

De fysieke grootte van IoT-apparaten wil daarnaast ook nog problemen opleveren. Dat zit bijvoorbeeld in de encryptiestandaarden die worden gebruikt om verkeer van en naar de server en binnen de groep te versleutelen. Omdat de meeste IoT-apparaten maar een beperkte rekenkracht hebben door goedkope cpu's wordt er vaak gebruik gemaakt van een zwakkere versleuteling. Die is niet persé makkelijker te breken, maar maakt het bij bruteforce-aanvallen wel makkelijker om default-wachtwoorden zoals '1234' te kraken.

Daar komt bovendien bij dat huishoudelijke apparaten worden gebruikt voor een lange periode van meerdere jaren, en dat simpele encryptiestandaarden doorgaans niet zo'n lange levensduur hebben. Vaak blijken die na korte tijd al ingehaald door het feit dat computers steeds krachtiger worden en de versleuteling sneller kunnen kraken. Encryptie waarbij dat niet het geval is (zoals AES-256) is te log voor een doorsnee IoT-apparaat.

Daar komt bij dat veel fabrikanten de wachtwoorden van een apparaat hardcoded in de firmware zetten, en dat dat juist vaak simpele default-wachtwoorden zijn. Als het al mogelijk is die wachtwoorden te veranderen, is dat voor veel gebruikers vaak te lastig of laten ze dat liggen.

IoT-apparaten zijn ook onveilig vanwege hun connectiviteit met elkaar en met je netwerk. Omdat alle apparaten aan hetzelfde netwerk hangen, wordt het veel makkelijker om een goed beveiligde computer te infecteren via een slecht beveiligde netwerkschijf.

Updates

Een ander groot probleem is de ondersteuning die apparaten ontvangen, en de API's waarop ze draaien. Fabrikanten bieden nu witgoedapparatuur aan met een levensduur van vaak wel 20 jaar (voor bijvoorbeeld een wasmachine), maar volgens @InternetOfShit is er bij voorbaat nog niet eens nagedacht over hoe lang zulke apparatuur wordt ondersteund. Hij doelt specifiek op zaken als de API's die de apparaten gebruiken, bijvoorbeeld om verbinding te maken met externe applicaties.

Zo biedt Samsung koelkasten aan met een display waarin je je Google Calendar kunt importeren - handig in een druk huishouden. Een jaar nadat één van die koelkasten op de markt was gebracht, ontdekten beveiligingsonderzoekers dat de koelkast het wachtwoord van het bijbehorende Google-account in plaintext naar de router stuurde omdat het SSL-certificaat niet juist gevalideerd werd.

Het was daarom met een man-in-the-middle-aanval kinderlijk eenvoudig het wachtwoord te onderscheppen. Het probleem zat in het feit dat Samsung een oude API voor Google Calendar gebruikte - maar de koelkasten hebben tot op heden geen update naar de nieuwe API ontvangen.

Samsungs slimme koelkast draaide altijd op 'Family Hub 1.0', maar de nieuwe lineup die dit jaar tijdens de CES werd gepresenteerd draait al op Family Hub 2.0. Het is een legitieme vraag hoe lang versie 1.0 nog ondersteund blijft...

IoT-protocollen

Te korte ondersteuning van apparaten en slecht geïmplementeerde beveiligingsmaatregelen zijn relatief makkelijk te voorkomen. Je ziet nu al dat steeds meer smart-applicaties gebruik maken van betere opsec (operations security), door penetration testing in te zetten bij hun apparaten of door speciale privacy-experts aan te nemen. Het IoT heeft echter een groter probleem dat niet zomaar is op te lossen met meer maatregelen.

Het inherente probleem van zo veel verschillende apparaten is het gebrek aan een vaste standaard, en de wirwar van verschillende protocollen waarmee de apparaten met elkaar praten. Dat levert problemen op omdat lampen van het ene merk bijvoorbeeld niet kunnen worden gekoppeld aan thermostaten van een ander, maar het is ook inherent onveilig.

Door het gebruik van zo veel verschillende standaarden is het voor fabrikanten vaak aantrekkelijker om een 'legacy' firmware aan te houden. Die kun je heel specifiek bouwen voor juist dat ene apparaat, in plaats van dat je moet voldoen aan bepaalde eisen. Die diversiteit maakt het echter ook een stuk lastiger om uniforme updates voor bijvoorbeeld de versleuteling of de connectiviteit uit te brengen.

Er zijn verschillende initiatieven om protocollen te standaardiseren. Zo is er de AllSeen Alliance, een samenwerkingsverband waar onder andere Qualcomm, Cisco, Microsoft, HTC en LG aan werken. Zij werken samen aan AllJoyn, een standaardmanier waarmee apparaten kunnen verbinden met externe diensten of cloud-applicaties. Dat gebeurt met universele manier om data over te brengen en een algemene encryptiestandaard.

Mirai-botnet

In oktober vorig jaar bleek echter dat het Internet of Things een veel groter probleem had dan enkel de slechte bescherming van persoonsgegevens, maar dat nalatige beveiliging ook grote schade aan anderen kon toebrengen.

Op 21 oktober lag een significant deel van het internet het grootste deel van de dag plat. Websites als Twitter en Reddit, én het veelgebruikte Amazon Web Services waren niet meer te bereiken door een grootschalige aanval op DynDNS, één van de grootste dns-providers van het internet. Het ging om een DDoS-aanval waarbij de servers door 650 Gb/s aan data werden bestookt.

Voor de aanval werden miljoenen IoT-apparaten van over de hele wereld gebruikt. Die werden door het botnet ingezet om de servers van DynDNS constant met data te bestoken. Mirai infecteert IoT-apparaten met malware die de data naar een centrale command & control-server sturen.

In een analyse van de broncode van Mirai komen twee belangrijke dingen naar voren. Eerst zoekt de malware naar IoT-apparaten op internet om die vervolgens over te nemen, en vervolgens worden de IP-adressen van die apparaten gebruikt om verzoeken naar een bepaalde server te sturen. Het zoeken naar apparaten gebeurt via een grootschalige scan naar IP-adressen die verbonden zijn aan apparaten die geen computers of smartphones zijn, maar bijvoorbeeld wel connected beveiligingscamera's.

Opvallend is dat Mirai niet alleen zoekt naar onbeveiligde apparaten, maar ook 'dictionary' brute-force-aanvallen inzet om simpele wachtwoorden zoals 'root', '1234', admin' of 'default' te kraken. Zoals we al eerder konden zijn veel wachtwoorden hardcoded in de firmware en worden ze door gebruikers amper vervangen. In dat geval krijg je dergelijke standaard-wachtwoorden.

Beveiligingsonderzoekers zijn dan ook van mening dat het veranderen en toepassen van default-wachtwoorden één van de beste manieren is om dergelijke botnets te stoppen.

©PXimport

Een belangrijke kanttekening is overigens wel dat het overgrote merendeel van de gebruikte apparaten in de Mirai-aanval een IP-camera was. In tegenstelling tot bijvoorbeeld slimme wasmachines zijn verbonden (beveiligings)camera's al jaren een bekend veiligheidsrisico.

Waarschuwingen over het beveiligen van zulke apparatuur gaan al terug sinds de eerste consumentenmodellen op de markt kwamen, en sinds die tijd is er maar weinig veranderd. Open videostreams van bijvoorbeeld kinder- of huiskamers zijn nog steeds eenvoudig te vinden met een paar simpele Google-zoekopdrachten.

Goede hoop

Dat wil niet zeggen dat de opkomst van nog meer slimme apparatuur geen extra risico's met zich meebrengt. Integendeel, hoe meer apparaten op internet worden aangesloten, hoe meer mogelijkheden hackers hebben om botnets te starten, computers te infecteren of persoonsgegevens te stelen.

Toch gloort er een beetje hoop aan de horizon. Steeds meer fabrikanten zien het belang van veiligheid in bij het maken van IoT-applicaties. De industrie werkt actief aan het bouwen van (open) standaarden voor domotica, en ook consumenten raken meer bewust van het nut van beveiliging.

Er zijn nog een aantal belangrijke veranderingen die in de werkwijze van fabrikanten moet komen. Die zijn grotendeels hetzelfde als bij het maken van cloudtoepassingen, websites met databases, en hardware zoals computers en smartphones. Dat draait allemaal om aandacht voor beveiliging, en om dat probleem serieus te nemen.

Als je services op je eigen thuisserver draait, wil je daar ook eenvoudig meldingen van kunnen ontvangen. Ntfy stelt je in staat om eenvoudig pushnotificaties naar je telefoon of computer te sturen. Bovendien kun je ntfy op je eigen thuisserver draaien, zodat je alles in eigen handen hebt. In dit artikel gaan we ermee aan de slag.

Netwerkmonitoringsoftware, een programma dat je Docker-containers bijwerkt, een smarthomecontroller, back-upsoftware, ze hebben allemaal één ding gemeen: ze moeten je meldingen kunnen sturen als er iets gebeurt. Dat kan op verschillende manieren: via e-mail, instant messaging of pushnotificaties naar je telefoon. Dat laatste verloopt doorgaans via een gecentraliseerde dienst zoals Firebase Cloud Messaging (voorheen Google Cloud Messaging) of Apple Push Notification service.

Pushnotificaties zijn handig omdat ze bijna onmiddellijk aankomen en omdat zowel Android als iOS toestaan om in te stellen hoe je ervan op de hoogte wordt gebracht. Wil je pushnotificaties kunnen ontvangen zonder een server onder controle van een partij zoals Google of Apple, dan moet je ook hiervoor je eigen service installeren. Een opensource-project dat dit implementeert, is ntfy.

Werking van ntfy

Je ntfy-server ontvangt meldingen van je programma's via http over een REST-API en zet deze om in pushnotificaties voor de bijbehorende Android- of iOS-app of voor een webpagina op je computer. De API is in de documentatie van het project beschreven, zodat je ook je eigen software met ntfy kunt laten praten. Het project heeft ook een command-line-interface, zodat je bijvoorbeeld shellscripts op je Linux-server eenvoudig pushnotificaties kunt laten verzenden.

Ntfy gebruikt het bekende publish/subscribe-patroon. Een zender publiceert notificaties op een specifiek onderwerp door data te sturen naar een url via een http POST- of PUT-aanvraag. Het onderwerp wordt gedefinieerd door een segment van de url dat volgt op de domeinnaam. Een ontvanger kan zich dan abonneren op dit onderwerp. Elke keer dat de zender daarna een notificatie op dit onderwerp publiceert, stuurt ntfy de data naar alle ontvangers die zich op dit onderwerp hebben geabonneerd. Door ntfy op je eigen server te installeren, heb je de volledige controle over deze notificaties.

Serververeisten

De mobiele app van ntfy moet met je server kunnen communiceren om te vragen of er notificaties zijn. Als je ntfy op een server in je lokale netwerk installeert, moet die dus van buitenaf bereikbaar zijn. Dat kun je met portforwarding in je modem regelen of door je telefoon buitenshuis automatisch met een VPN-server op je lokale netwerk te laten verbinden. Heeft je internetaansluiting thuis geen vast ip-adres, dan moet je ook een DynDNS-updater te draaien.

Een andere optie is om ntfy op een VPS (Virtual Private Server) te installeren. Hierop draai je dan ook een reverse proxy voor https-toegang, die een TLS-certificaat van Let's Encrypt opvraagt. Je hebt dan een domein nodig, waarvoor je een DNS A-record naar het ip-adres van je server laat verwijzen. In de rest van dit artikel gaan we uit van een installatie van ntfy op een lokale server met Debian 13 ("trixie") met behulp van Docker Compose.

Basisconfiguratie

Creëer eerst enkele directory's voor ntfy:

$ mkdir -p containers/ntfy/{cache,etc,lib}

Creëer dan het bestand containers/ntfy/etc/server.yml met de volgende configuratie voor ntfy:

base-url: "https://ntfy.example.com"

cache-file: "/var/cache/ntfy/cache.db"

attachment-cache-dir: "/var/cache/ntfy/attachments"

auth-file: "/var/lib/ntfy/user.db"

auth-default-access: "deny-all"

Vervang het domein achter base-url door het domein waarop je ntfy-server draait. Als je gebruikmaakt van een reverse proxy, dan moet dit de url zijn die door de proxy naar ntfy wordt doorgestuurd. Bovendien moet je dan ook een regel behind-proxy: true toevoegen. In de documentatie van ntfy staan voorbeeldconfiguraties voor nginx, Apache2 en Caddy.

Met auth-default-access: "deny-all" tot slot heeft standaard niemand toegang tot onderwerpen. Elke toegang moet dus expliciet worden toegestaan.

Account bij ntfy.sh

De ontwikkelaar van ntfy draait een publiek beschikbare ntfy-server op ntfy.sh. De webinterface daarvan is bereikbaar op https://ntfy.sh/app. Die kun je gratis gebruiken, bijvoorbeeld om ntfy uit te proberen, maar dat komt met beperkingen. Zo kun je geen onderwerpen reserveren en is er een maximum van 250 notificaties per dag en 2 MB per bijlage. Verder is er geen enkele vorm van authenticatie. De enige manier van beveiliging ligt dus in het geheimhouden van je onderwerpen. Die beperkingen heb je niet als je ntfy zelf installeert. Maar als je liever niet zelf een installatie onderhoudt, kun je een betaald plan nemen. Daarmee ondersteun je ook de ontwikkeling van het opensource-project. Dat begint met een Supporter-plan van 5 dollar per maand (circa 5 euro), waarmee je drie onderwerpen kunt reserveren en 2.500 notificaties mag sturen met maximum 25 MB per bijlage.

Betaal voor gebruik van de publieke ntfy-server en ondersteuning van het opensource-project.

Docker Compose

Definieer nu de container in het bestand docker-compose.yaml:

services:

  ntfy:

    image: binwiederhier/ntfy

    container_name: ntfy

    command: serve

    restart: always

    environment:

      - TZ=Europe/Amsterdam

    volumes:

      - ./containers/ntfy/cache:/var/cache/ntfy

      - ./containers/ntfy/etc:/etc/ntfy

      - ./containers/ntfy/lib:/var/lib/ntfy

    ports:

      - 80:80

Ga je voor de aanpak met een reverse proxy, dan definieer je in ditzelfde bestand ook een container voor die reverse proxy.

Start daarna de container met:

$ docker-compose up -d

Als alles goed gaat, is de webinterface van ntfy daarna bereikbaar op het ingestelde domein of ip-adres. Bovenaan links zie je een melding Notifications are disabled. Klik op Grant now om notificaties in je webbrowser toe te staan, en bevestig dit daarna in het dialoogvenster dat je webbrowser toont.

Lees ook: Docker op je NAS: zo draai je Plex, Home Assistant en meer

Notificaties testen

Omdat je ntfy zo geconfigureerd hebt dat alle toegang standaard wordt geblokkeerd, kun je nog niets doen in de webinterface. Je dient dus eerst gebruikers aan te maken en die de toelating te geven om op specifieke onderwerpen te publiceren of zich te abonneren. Open daarvoor een shell in de container van ntfy met de opdracht docker exec -ti ntfy /bin/sh. Als je daarna ntfy user list intypt, krijg je te zien dat anonieme, niet geauthenticeerde gebruikers geen enkele permissies hebben. Met de opdracht ntfy user add --role=admin admin voeg je dan een admin-gebruiker met de naam admin toe. Gebruikers met de rol admin kunnen op alle onderwerpen publiceren en zich erop abonneren. Geef de gebruiker een wachtwoord en bevestig.

Klik nu in de webinterface van ntfy links op Settings en dan onder Manage users op Add user. Vul de url van je ntfy-server in, de gebruikersnaam admin en het wachtwoord dat je zojuist hebt ingesteld. Klik dan links op Subscribe to topic. Kies een naam of klik op Generate name om ntfy een willekeurige naam te laten kiezen en abonneer je dan op het onderwerp met Subscribe. Klik dan op Publish notification en vul hetzelfde onderwerp in. Voer ook een titel en een bericht voor je notificatie in en klik op Send. Als alles goed gaat, verschijnt je testbericht nu in een 'conversatie' met de naam van het onderwerp, en wijst je webbrowser je op een notificatie.

Gebruikersrechten

De webapplicatie is leuk voor een test, maar een mobiele app is vaak handiger. De app van Ntfy voor Android en iOS stelt je in staat om op je telefoon je te abonneren op onderwerpen (publiceren is niet mogelijk) en daarvoor notificaties te ontvangen. Als je de Android-app via F-Droid installeert, is dat zonder ondersteuning voor Firebase; de versie op Google Play gebruikt wél de servers van Google. Je maakt voor je app bij voorkeur een gebruiker aan die alle onderwerpen alleen kan lezen. Dat doe je weer in de shell van de container van ntfy met ntfy user add android om de gebruiker android aan te maken (voer een wachtwoord in) en dan ntfy access android "*" read-only voor de leesrechten.

Open daarna de Android-app en tik op de drie stippen rechtsboven. Kies Settings en stel dan Default server in op het domein van je ntfy-server. Tik daarna op Manage users en Add new user en vul de url van je ntfy-server in, de gebruikersnaam android en het bijbehorende wachtwoord. Tik dan op Add user. Keer dan terug naar het hoofdscherm van de app en klik op het plusicoontje rechtsonder. Voer het onderwerp in dat je tijdens de test in stap 5 hebt gebruikt en tik op Subscribe om je erop te abonneren. Vanaf nu zal de app voor elk ontvangen bericht op dit onderwerp een notificatie tonen. Je krijgt zelfs de al verzonden berichten te zien. Overigens toont de app twee waarschuwingen. Voor betrouwbare notificaties volg je de suggesties om batterijoptimalisaties uit te schakelen en naar WebSockets over te schakelen in plaats van een http-stream.

Shellscripts

Nu je hebt getest dat je ntfy-server werkt, is het tijd om je eigen services notificaties te laten uitsturen. Hoe je dat precies configureert, hangt van de service af. Maar je zult altijd eerst een gebruiker met schrijfpermissies voor een specifiek onderwerp moeten aanmaken. Voor een back-upproces dat je op de hoogte moet houden van de status van je back-ups, maak je bijvoorbeeld een gebruiker aan met de opdracht ntfy user add backup in de container van ntfy. Geef die dan schrijfrechten op het onderwerp backup met ntfy access backup backup write-only.

Het publiceren van een bericht op een specifiek onderwerp behelst niet meer dan het sturen van een http POST-aanvraag naar de webserver. Dat kan bijvoorbeeld in een shellscript op je Linux-server met de opdracht curl:

curl -u backup:password -d "Backup successful" ntfy.example.com/backup

Als je in de ntfy-app op je telefoon je op dit onderwerp abonneert, ontvang je deze notificatie nadat het back-upscript is uitgevoerd. Op deze manier is het heel eenvoudig om je eigen shellscripts notificaties te laten verzenden.

Berichten met extra's

Ntfy ondersteunt talloze extra functies om je berichten te laten opvallen of om hun gedrag aan te passen. Je gebruikt deze allemaal door een http-header aan je aanvraag toe te voegen. Zo kun je aan de notificaties van je back-upscript een titel, prioriteit en tags toevoegen. De tags worden als pictogrammen getoond door de mobiele app. Een voorbeeld:

curl -u backup:password -H "Title: Backup failure" -H "Priority: urgent" -H "Tags: warning,skull" -d "Backup unsuccessful" ntfy.example.com/backup

Als de Android-app een bericht met standaardprioriteit ontvangt, doet ze je telefoon kort vibreren en speelt ze een kort geluidje af. Door de prioriteit op urgent te zetten, wordt het standaardnotificatiegeluidje vergezeld van een langer getril van je telefoon, waardoor je onmiddellijk merkt dat dit dringend je aandacht vereist.

Plaatjes en lay-out

Ntfy kan ook plaatjes sturen, bijvoorbeeld een foto van een ip-camera die beweging detecteert, maar niet in combinatie met een tekstbericht. Om een bestand naar ntfy te uploaden met curl in een http PUT-aanvraag gebruik je de optie -T en de bestandsnaam. Met de header Filename voeg je de bestandsnaam toe die de ntfy-app je moet tonen. Dat ziet er dan als volgt uit:

curl -u admin:password -T foto.jpg -H "Filename: beweging.jpg" -H "Title: Beweging voordeur" -H "Tags: boom" ntfy.example.com/beweging

Als je een tekstbericht als Markdown opmaakt, kun je wel plaatjes in een tekst opnemen, maar dan moet je naar het bestand linken. Alleen ntfy's webinterface ondersteunt dit; de mobiele app toont gewoon de Markdown-brontekst. Een Markdown-bericht stuur je door de header Markdown: yes of Content-Type: text/markdown aan je http POST-aanvraag toe te voegen. Ntfy ondersteunt overigens alleen beperkte Markdown-functies, zoals vette en schuine tekst, lijsten, links en afbeeldingen.

Acties

Je ontvangt de notificaties van ntfy in de app in een 'conversatie' per onderwerp. Wanneer je op een notificatie tikt, kopieert dit standaard gewoon de tekst van het bericht naar het klembord. Als je de header Click: URL toevoegt, opent de app die url wanneer je op de notificatie tikt. Zo kun je in een notificatie van je back-upscript bijvoorbeeld een link naar de webinterface van je back-upserver opnemen om het gemelde probleem snel te onderzoeken.

Je kunt ook tot drie 'actieknoppen' definiëren, die dan onderaan een notificatie verschijnen. Door op een van die knoppen te tikken, open je een website of app, activeer je een Android broadcast intent waarop andere apps dan weer kunnen reageren, of zend je een http POST-, PUT- of GET-aanvraag. De manier om dit alles te definiëren is wat omslachtig, maar wordt volledig in de documentatie van ntfy uitgelegd.

Python-code

Curl is natuurlijk niet de enige tool waarmee je notificaties naar je ntfy-server kunt sturen. Sommige tools bieden rechtstreeks ondersteuning voor notificaties via ntfy. Dan hoef je alleen maar het domein van je server, het onderwerp, de gebruikersnaam en het bijbehorende wachtwoord in te vullen. Maar ook in je eigen Python-scripts kun je eenvoudig ondersteuning voor ntfy inbouwen. Dat gaat via het pakket Requests, waarmee je http POST-aanvragen naar de server stuurt. Een eenvoudig voorbeeld ziet er als volgt uit:

import requests

requests.post("http://ntfy.example.com/backup",

    data="Backup unsuccessful",

    headers={

        "Authorization": "Basic Z2VicnVpa2Vyc25hYW06d2FjaHR3b29yZA==",

        "Title": "Backup failure",

        "Priority": "urgent",

        "Tags": "warning,skull"

    })

Met de header Authorization stel je http Basic-authenticatie in. De tekenreeks die na Basic komt, is een Base64-codering van de gebruikersnaam en het wachtwoord met een dubbele punt ertussen. Je creëert die codering op je Linux-systeem met de opdracht echo "Basic $(echo -n 'gebruikersnaam:wachtwoord' | base64)".

En verder

Ntfy biedt een betrouwbare manier om notificaties van allerlei services te centraliseren, terwijl je zelf de volledige controle behoudt. Het programma blinkt uit in flexibiliteit om het overal in te integreren. Als een service bijvoorbeeld geen http POST-aanvragen ondersteunt, kun je ook http GET-aanvragen doen. En als een service je niet de mogelijkheid geeft om de headers aan te passen, laat ntfy je toe om de berichten inclusief headers in JSON-formaat door te sturen. En als een service webhooks ondersteunt maar daarvoor zijn eigen JSON-formaat gebruikt, kan ntfy die met berichtsjablonen omzetten naar leesbare berichten.

Ook via e-mail is ntfy te integreren. Je kunt bijvoorbeeld berichten die op je ntfy-server aankomen automatisch laten doorsturen naar een SMTP-server om ze ook als e-mail te ontvangen. Maar ook de andere richting is voorzien: ntfy kan dan zelf een ingebouwde SMTP-server draaien, handig voor services die alleen maar notificaties via e-mail ondersteunen. Elk onderwerp op de ntfy-server heeft dan een bijbehorend e-mailadres op je domein. De service hoeft dan alleen maar een e-mail naar dat adres te sturen om berichten op dat onderwerp te publiceren op je ntfy-server. Deze en andere geavanceerde functies zijn uitgebreid gedocumenteerd op de website van ntfy.

The Duskbloods, de nieuwe game van Elden Ring- en Dark Souls-ontwikkelaar FromSoftware, zal echt alleen op Nintendo Switch 2 uitkomen.

Dat heeft de ontwikkelaar benadrukt bij het bekendmaken van zijn kwartaalcijfers (via VGC). Daarbij werd ook nog eens benadrukt dat The Duskbloods nog altijd gepland staat om ergens dit jaar uit te komen, net zoals de Switch 2-versie van Elden Ring.

Over de exclusieve Switch 2-release van The Duskbloods: "Het wordt verkocht via een samenwerking met Nintendo, met verkoopverantwoordelijkheden verdeeld per regio. De game komt alleen voor Nintendo Switch 2 beschikbaar." Daarmee is dus duidelijk gemaakt dat Nintendo een nauwe samenwerking met FromSoftware is aangegaan voor de game en dat het spel niet zomaar op andere platforms uit zal komen.

Over The Duskbloods

The Duskbloods werd begin vorig jaar aangekondigd in een speciale Nintendo Direct waarin de eerste Switch 2-games werden getoond, maar sindsdien zijn er geen nieuwe beelden van het spel uitgebracht. Zoals gezegd is de game ontwikkeld door FromSoftware, het Japanse bedrijf dat naam voor zichzelf heeft gemaakt met enorm uitdagende spellen, waaronder de Dark Souls-serie en Bloodborne. Met de openwereldgame Elden Ring scoorde de ontwikkelaar enkele jaren geleden nog een megahit.

The Duskbloods wordt een PvPvE-game, waarbij spelers het dus tegen elkaar en tegen computergestuurde vijanden opnemen. Maximaal acht spelers doen aan potjes mee. Na het kiezen van een personage in een hub-gebied wordt men naar een gebied getransporteerd waar er met andere spelers en vijanden gevochten wordt, al kan men soms ook samenwerken om vijanden te verslaan.

Spelers besturen een 'Bloodsworn', wezens die dankzij een speciaal bloed dat in hun lichaam zit meer krachten tot hun beschikking hebben dan reguliere mensen. Ondertussen is het einde van de mensheid nabij, en bestaat de wereld uit verschillende tijdperken, wat voor een mengelmoes van stijlen zorgt.