Cloudflare gaat HTTP-verbindingen naar api standaard blokkeren

Cloudflare blokkeert voortaan alle onversleutelde verbindingen via zijn eigen api. Alleen beveiligde Https-verbindingen worden nog toegestaan via die api, zegt het bedrijf. HTTP-verbindingen lekken volgens Cloudflare soms informatie, ook als die worden omgeleid.

Cloudflare schrijft in een blogpost dat het inmiddels alle HTTP-verbindingen naar api.cloudflare.com blokkeert. Die api maakt het mogelijk voor ontwikkelaars om Cloudflare-diensten te beheren vanuit andere omgevingen. De api liet tot nu toe wel HTTP-verbindingen door, maar Cloudflare had daarvoor een instelling om alsnog een Https-verbinding af te dwingen. Daarmee werd een onversleutelde verbinding omgeleid naar de juist versleutelde verbinding.

Volgens Cloudflare zit daar echter ook een kwetsbaarheid in. Als een HTTP-request al voorafgaand aan het omleiden en dus versleutelen privacygevoelige informatie bevat, kan dat mogelijk leiden tot het lekken van gevoelige data. Dat kan bijvoorbeeld door een person-in-the-middleaanval. Cloudflare noemt als voorbeeld een verbinding waarbij een secret key in plaintext wordt meegestuurd. Daarbij is HSTS volgens Cloudflare ook geen goede oplossing; dat verkort slechts de tijd waarin een aanvaller kan toeslaan.

Zeker in het geval van api-keys en -tokens is het volgens Cloudflare belangrijk extra beveiliging toe te passen. Het bedrijf vindt dat iedere key en token die zichtbaar is geweest, gecompromitteerd en daarmee onveilig en onbruikbaar is.

Nog zo'n 2,4 procent van Cloudflares verkeer dat 'waarschijnlijk menselijk' is, loopt nog via een onbeveiligde HTTP-verbinding over de api. Het totale HTTP-verkeer, dus ook het geautomatiseerde, ligt volgens Cloudflare op zo'n 16 procent. Dat zijn bijvoorbeeld iot-apparaten die niet de mogelijkheid hebben een verbinding makkelijk te versleutelen.

Reacties (80)

[Olaf van der Spek]

Werken browsers eigenlijk goed / normaal als je alleen poort 443 gebruikt en niet-https dus helemaal dicht zet?

[CodeCaster]

Tenzij een site op de HSTS preload list staat (een in de meeste browsers ingebakken, frequent geüpdatete lijst), zal een eerste request bij het handmatig intypen van het adres eerst naar HTTP (poort 80) gaan, tenzij je de URL zelf begint met "https://". Edit: Firefox heeft sinds versie 136 de modus "HTTPS First" standaard aan, bedankt @elmuerte.

Een redirect van HTTP naar HTTPS komt vanuit de server. Als je browser niet op poort 80 naar buiten communiceert, zal die ook die redirect niet ontvangen.

Er bestaan wel browser-instellingen of -plugins die zelf het eerste request altijd al via HTTPS doen; zie Set Up HTTPS-Only Mode on Your Browser en HTTPS Everywhere.

[Reactie gewijzigd door CodeCaster op 23 maart 2025 11:46]

[elmuerte]

De meest gebruikte browsers zullen zowel HTTP als HTTPS proberen. Firefox is vanaf 136 HTTPS first, en zal dus eerst kijken voor een HTTPS website, en dan pas kijken naar HTTP. Voorheen was dit andersom. Ik weet niet of het bij Chrome al standaard is, maar de feature zit er al een behoorlijke lange tijd in.

In ieder geval hoef je al jaren niet meer een HTTP->HTTPS redirect op te zetten voor je server als je helemaal niet op poort 80 luistert.

[CodeCaster]

"Al jaren"? Firefox 136 is net drie weken uit, Chrome doet het iets langer, maar als je een public-facing site bent en nog gebruikers wil serveren die niet op de laatste versies van die browsers zitten of niet in experimentele channels of instellingen zitten, moet je nog steeds luisteren op poort 80 en redirecten.

[Reactie gewijzigd door CodeCaster op 23 maart 2025 11:32]

[Olaf van der Spek]

In 136 is blijkbaar https first geintroduceerd, maar ik kan me voorstellen dat daarvoor al https werd geprobeerd als http niet beschikbaar was.

[CodeCaster]

Dat gebeurde dus niet.

[TechSupreme]

Standaard gebeurde dat niet, maar je kon het wel aanzetten in de instellingen of een plug-in installeren.

[Firesphere]

De HTTPS-Only modus bestaat echter al redelijk lang. Deze was geloof ik origineel niet standaard aan gezet, maar nu vanaf 136 wel neem ik aan?
Het is in ieder geval al sinds 2021 standaard aan in private mode
https://blog.mozilla.org/...ault-in-private-browsing/

[MSalters]

De meest gebruikte browsers zullen zowel HTTP als HTTPS proberen

Correct. Dit idee heet "Happy Eyeballs" en is bedacht voor IPv4/IPv6 dual-stack operations. De logica is simpel: je wil de gebruiker niet lastig vallen met irrelevante technische details. De gebruiker wil de website van example.com hebben? Dan zorg je als browser ervoor dat die site op het scherm komt.

[qless]

Browsers wel, websites mogelijk niet....

[The Zep Man]

Browsers wel, websites mogelijk niet....

Klopt. Als een site met een HSTS header niet eerder bezocht is of op een HSTS preload lijst staat en de gebruiker tikt enkel "example.com" in in de adresbalk, dan maakt de browser hier een HTTP-verzoek van en niet HTTPS. Recent hebben browsers meer opties om dit gedrag te voorkomen, maar een gebruiker moet dat wel inschakelen (en accepteren dat wellicht een site soms niet (goed) werkt zonder een uitzondering te maken).

[Olaf van der Spek]

Als de browser automatisch terugvalt naar http als https niet beschikbaar is (en er niet expliciet om https gevraagd was), zou het alleen fout gaan als een server op poort 80 iets anders serveert dan op poort 443.

[The Zep Man]

Of wanneer een MitM bewust HTTPS-verbindingen blokkeert voor sites die geen HSTS kennen.

[Reactie gewijzigd door The Zep Man op 23 maart 2025 11:45]

[Olaf van der Spek]

Dat is equivalent aan eerst http proberen..

[The Zep Man]

Het resultaat is hetzelfde. Hoe de browser daartoe komt niet.

[Room42]

De meeste publieke sites werken standaard op https, is mijn ervaring. Http-verbindingen worden geredirect naar https, dus die stap kun je prima overslaan.

[HollowGamer]

Maar je kunt een API-call bijvoorbeeld doen via een JS framework. Gelukkig heb je tegenwoordig daar een verbod op (mixed protocol request - CORS dacht ik).

Voor ook developers zou ik echt aan alles te doen op HTTPS/TLS. Dus ook je lokale dev. Helaas zijn er nog genoeg die CORS en andere settings uitzetten, al heeft gelukkig Chrome die functie eruit gehaald. Dacht Firefox ook?

[robvh99]

We hebben het hier over api verbindingen.
Die zullen meestal vanuit tooling of scripts gestart worden.
Dus de browser speelt hier vaak geen grote rol.
En bv. bij powershell zie je dat onder water stond nog ie11 componenten gebruikt worden🫣

[2TheMaks]

Dus de browser speelt hier vaak geen grote rol.

Websites zijn tegenwoordig applicaties (scripts) die in de browser draaien. Deze applicaties doen requests naar de API van de backend via de browser. Browser speelt dus wel degelijk een grote rol.

[zwartpet]

Dat zou betekenen dat je cloudflare api token in de browser beschikbaar is.
Vermoedelijk zit er tussen de web applicatie en de API van cloudflare nog een eigen backend API waar onder andere de authenticatie/authorizatie is ingeregeld. In dat geval doet de browser niks rechtstreeks met de API van cloudflare.

[blinchik]

Browsers waarschijnlijk wel, er zijn echter heel wat publieke hotspots die een disclaimer laten "tekenen" en voor zover ik weet gaan de meeste telefoons nog gewoon naar http (met dan een redirect naar https door de website) om zoiets te tekenen.

[LanTao]

Moderne operating systems doen bij hotspots eerst een request naar een http URL voor de captive portal detection. De URL wisselt per OS. Op basis hiervan wordt het loginscherm getoond, niet op basis van een http URL die een gebruiker toevallig in een browser opent.

[Room42]

Firefox in HTTPS-only mode zal automatisch alle http-verzoeken upgraden naar https en dus prima werken. Ik ken weinig publieke sites die enkel nog op http draaien. Het kan dus een keuze zijn om het verlies te nemen als je er wel een tegenkomt.

[Qwerty-273]

Nee, het certificaat wat op de https staat zal ongetwijfeld een crl (certificate revocation list) hebben die alleen via http wordt aangeboden. De meeste strikte implementaties zullen zowel het certificaat zelf controleren op geldigheid als ook de crl om te zien of het certificaat niet voortijdig is ingetrokken.

[Hoicks]

Let op! Certificaat infrastructuren moeten via HTTP naar een CRL (certificate revocation list) kunnen browsen om te kunnen controleren of certificaten niet zijn ingetrokken. HTTP dichtzetten kan dus juist problemen veroorzaken!

[Mark87]

Cloudflare die klaagt over person-in-the-middle. Dit terwijl dat een groot deel van hun dienstverlening is. Eigenlijk zou je alle data die via Cloudflare loopt en door Cloudflare mogelijk even ontsleuteld is als gecompromitteerd moeten zien. Met de huidige president in de VS is dit risico er niet kleiner op geworden.

Http verkeer over veilige paden (goede VPN's of waar je het netwerk vertrouwd) is waarschijnlijk veiliger...

[CH4OS]

Hun dienstverlening is niet de aanval zelf, maar het blokkeren ervan. Dat betekent ook niet dat men niets aan preventie van aanvallen mag doen, toch?

[R4gnax]

De dienstverlening van Cloudflare is weldegelijk een man-in-the-middle. Als je van (edit: veel van) hun diensten gebruik wenst te maken moet je hen toegang geven tot HTTPS certificaten waarmee ze de verbinding uit jouw naam kunnen ontsleutelen en herversleutelen om hun ding te kunnen doen.
Dat is de definitie van man-in-the-middle.

[Reactie gewijzigd door R4gnax op 23 maart 2025 13:30]

[iLaurens]

Nee hoor, niet per se alle services vereisen dat je cloudflare toegang geeft tot de data. Ik gebruik namelijk de cloudflare tunnel om mijn services op mijn server open te stellen naar het internet. Maar al die services zitten verstopt achter een reverse proxy die op mijn server draait en die zelf de certificaten in beheer heeft en al het verkeer met die certificaten versleuteld. Het enige verkeer dat cloudflare dus ziet is encrypted data vanaf mijn server.

[Reactie gewijzigd door iLaurens op 23 maart 2025 13:24]

[R4gnax]

Nee hoor, niet per se alle services vereisen dat je cloudflare toegang geeft tot de data. Ik gebruik namelijk de cloudflare tunnel om mijn services op mijn server open te stellen naar het internet.

'Cloudflare tunnel' heeft toegang tot de hostname nodig om deze te mappen naar een tunnel.
Dwz ze moeten de HTTP Host header uitlezen. TLS afgeschermde verbindingen versleutelen ook de headers, dus Cloudflare kan die header niet uitlezen en de juiste tunnel selecteren zonder binnenkomende verzoeken te ontsleutelen. En daarmee dus ook toegang te hebben tot de data.

[iLaurens]

SNI protocol en/of de ":authority" pseudo header zijn voldoende voor cloudflare om te weten waar de data heen moet. Het werkt in ieder geval al jaren op mijn thuis server.

[pizzafried]

Niet persé. Het is wel de methode die overal wordt beschreven in veel tutorials, maar je kunt dus aangeven dat https gerouteerd moeten worden naar je https service, zonder dat Cloudflare the encryption afhandelt.

[Mark87]

De meesten gebruiken een optie waarbij Cloudflare de certificaten regelt volgens mij. Met dat Cloudflare aan de buitenkant de certificaten afhandelt. Zodra dat niet het geval is ziet Cloudflare hoogstens nog meta data. Maar is de inhoud mogelijk nog veilig.

[ramonfincken]

Netjes hoor. Gewoon poort 80 dicht, ik had gisteren hun blog gelezen en het gaat om een zeer klein aandeel, maar alsnog is er geen enkele noodzaak om poort 80 open te houden. De oplossing is die hard, maar wel echt veilig.

[Server.1968]

Ah, Cloudflare, gebruik 't al jaren om 't bereik van mijn website globaal wat meer responsief te houden. 't Werkt ook beter bij de video-buffering vanaf de website in verschillende browsers, geen idee waarom, maar 't werkt. Dit artikel slaat gelukkig niet op mijn use-case dus hoef gelukkig geen onderhoud te plegen.

[R4gnax]

Cloudflare is een hele gevaarlijke partij aangezien zowat een geschatte 50% van het voor publiek relevante internet er doorheen loopt en van afhankelijk is.

Recentelijk zijn er bijv. problemen ontstaan met 'alternatieve' browsers zoals Librewolf met scherp afgestelde privacy instellingen, die door Cloudflare's automatische bot-detectie rood gevlagd worden waarna ze niet alleen geweigerd worden maar kennelijk zelfs een destructrief alternatief geserveerd krijgen dat CPU cores op 100% doet zetten en een geheugenlek introduceert om de browser (of de hele machine) te pogen te doen crashen.

Los van het feit dat dat soort fratsen vziw nog steeds computervredebreuk zijn (mits intentioneel), illustreert dat mooi de macht van Cloudflare: je geeft straks je privacy op en je gebruikt de browser die door hen goedgekeurd is met de instellingen die door hen goedgekeurd zijn, of je kunt niet meer deelnemen aan het normale web.

[Reactie gewijzigd door R4gnax op 23 maart 2025 11:57]

[bzzzt]

maar kennelijk zelfs een destructrief alternatief geserveerd krijgen dat CPU cores op 100% doet zetten en een geheugenlek introduceert om de browser (of de hele machine) te pogen te doen crashen.

Als een browser website code uitvoert en niet in staat is CPU gebruik te beperken of geheugen lekt is dat een buggy, onveilige browser. Het kan ook onintentioneel zijn en heeft niets met computervredebreuk te maken.

Los van het feit dat dat soort fratsen vziw nog steeds computervredebreuk zijn, illustreert dat mooi de macht van Cloudflare: je geeft straks je privacy op en je gebruikt de browser die door hen goedgekeurd is met de instellingen die door hen goedgekeurd zijn, of je kunt niet meer deelnemen aan het normale web.

Uiteindelijk is dat een keuze van de eigenaar van de website, niet Cloudflare.

[R4gnax]

Het kan ook onintentioneel zijn en heeft niets met computervredebreuk te maken.

Klopt, kan inderdaad ook onintentioneel zijn. Kanttekening toegevoegd aan originele reactie. Thx.

[Reactie gewijzigd door R4gnax op 23 maart 2025 11:58]

[lamaha650]

De gratis tiers geven heel veel hosters en hobbyisten de kracht van caching en security op enterprise niveau.

Bespaart hun heel veel (data, door caching kan minder gedimensioneerde hardware afgehuurd worden).

Dat ze een paar dingen nog niet juist doen maakt heb niet de duivel. Jeezus

[CH4OS]

Heb je hier bronnen voor die jouw beweringen staven?

[R4gnax]

https://www.reddit.com/r/...rashes_pale_moon_browser/
https://community.cloudfl...s-popular-browsers/766860
https://community.cloudfl...check-broken-again/626885
https://www.reddit.com/r/...stile_issue_on_opera_air/
https://news.ycombinator.com/item?id=42953508

Om er een paar uit te halen waar blijkt dat het telkens alternatieve browsers zijn die de bok zijn.

Als je die laatste even een eindje leest, kom je er ook achter dat er problemen zijn geweest met bijv. iCloud private relay en dus ook IP-anonimiseringsdiensten niet veilig zijn voor willekeur.

[Reactie gewijzigd door R4gnax op 23 maart 2025 12:03]

[GertMenkel]

Een paar niche browsers, specifiek Palemoon, wil nog wel eens problemen hebben met Cloudflare challenges. Toen ik het laatste testte, crashte te hele broeder tijdens een Cloudflare check, dus zat er iets goed mis in de broncode van die release van die browser.

Veel van die geblokkeerde browsers hebben als doel om zo moeilijk mogelijk te maken om te bepalen wie of wat er achter de browser zit. Dat is handig voor de privacy, maar trekt ook veel botmakers aan. Hoe meer privacymaatregelen Cloudflare toestaat, hoe meer bots dat misbruiken om door de firewall heen te gaan. Het helpt ook niet dat er een aardige overlap lijkt te zijn tussen de mensen die dit soort privacybrowsers gebruiken en de mensen die VPN-servers gebruiken om hun IP te verhullen (en dus uit datacenters lijken te komen, net als bots).

Het hele computervredebreukverhaal slaat nergens op en die 100% CPU zal wel op een oude Celeron zijn, maar het per ongeluk blokkeren van nichebrowsers is moeilijk te voorkomen met een partij als Cloudflare; ze zijn statistisch moeilijk te onderscheiden van bots.

[Justice]

Ik denk dat R4gnax hier aan dacht https://forum.palemoon.org/viewtopic.php?t=32127

[Reactie gewijzigd door Justice op 23 maart 2025 12:04]

[Luchtbakker]

Moet je maar ook geen gebruikers op het web hebben die het internet anders willen gebruiken dan waar het voor bedoeld is, toch? Cloudflare probeert alle mogelijke pogingen tot misbruik te blokkeren waar ook bepaalde gedragingen bij horen.

[Ryunoru]

Dit is dus precies het probleem, een bedrijf dat voor gebruikers gaat bepalen wat normaal is en wat niet, om ongewenste gedragingen vervolgens te labelen als "misbruik" en "niet waar het internet voor bedoeld is". De arrogantie.

[GertMenkel]

Dat is geen arrogantie, dat is hun baan. Het is hard nodig, ook. Bijna al het verkeer dat mijn servers bereikt bestaat uit bots die robots.txt negeren. Je kunt ze rapporteren, maar dan kun je net zo goed tegen een muur schreeuwen. Bijvangst is bijna onmogelijk te voorkomen zonder het je fulltime baan te maken.

De Captchas van Cloudflare zijn vervelend, maar als ik je blokkeer omdat je van een VPN komt of je user agent normaal een bot is, dan krijg je helemaal niks.

[Nark0tiX]

Ach je gordel om doen is ook verplicht. Iemand moet er mee beginnen

[GertMenkel]

Computervredebreuk

Ik zie het probleem niet zo met Cloudflare. Juist door Cloudflare zijn websites gestopt met simpelweg een 403 gooien wanneer ze je client niet vertrouwen, en heeft je browser de kans te bewijzen dat er een mens achter zit. Ik gebruik geen Cloudflare en alles wat op bots lijkt krijgt een TCP timeout van mijn server.

Je kunt de Cloudflareloze wereld van mijn server terugkrijgen door de IP-adressen van Cloudflare te blokkeren in je firewall.

[emeralda]

In Europa hebben we de sleutels voor het internet aan de Amerikanen gegeven en het zal ons nog opbreken.

[HollowGamer]

Hoewel het goed is dat alles tegenwoordig over HTTPS praat, is dat toch niet voldoende als we het hebben over deep package inspection (DPI)?

Je kunt namelijk nog altijd het decrypten met de publieke key van de API (endpoint) toch? Ik snap eigenlijk niet zo goed waarom daar niemand over praat, het gebeurt namelijk veel op bedrijfsnetwerken.

[MSalters]

Ik heb geen idee waar je't over hebt. Je lijkt een security iets te bespreken, maar je actoren zijn onduidelijk.

HTTPS beschermt het verkeer tussen HTTP server en HTTP client. Het beschermt niet tegen een gecompromitteerde server of client. "Deep Packet Inspection" werkt op insecure HTTP. Met een gecompromitteerd end point is DPI niet eens nodig, dan hoef je niet diep te graven.

De publieke key van een HTTPS server is niet wat je gebruikt voor het decrypten. HTTPS encryptie gebeurt met TLS session keys.

[HollowGamer]

Ik bedoel dat dit wordt verkocht als dat alles over HTTPS per definitie veilig is, en dat het 'stelen' van credentials niet mogelijk dan zou zijn.

Het werkt zeker over TLS: https://www.quora.com/How...crypted-traffic-e-g-HTTPS

Vandaar dat ik juist meer fan lijkt te worden van HTTPS, en daar dan weer encryptie overheen tussen een sleutel die enkel bij jouw en de endpoint is.

[Reactie gewijzigd door HollowGamer op 24 maart 2025 12:25]

[MSalters]

Je zult je echt beter moeten inlezen in cryptografie. Quora is zeker niet de goede bron daarvoor. Maar alsnog, je quora bron zegt hetzelfde als wat ik al zei: DPI vereist een gecompromitteerd end point.

Encryptie bovenop HTTPS (en dus bovenop TLS), met een sleutel die gedeeld is tussen client en server helpt dus niet. Dat biedt niet meer dan alleen TLS, precies omdat TLS al doet wat jij aanneemt. DPI blijft in jouw idee mogelijk, onder precies dezelfde omstandigheden: een gecompromiteerd end point.

[HollowGamer]

Ik heb niet echt iemand die mij er meer over verteld, dus blij dat je het deelt.

Is DPI niet een soort proxy waar al je verkeer naar buiten over gaat? Je stuurt het daarna gewoon door naar het eindpunt, zonder dat die weet dat je iets heb gedaan eraan.

[MSalters]

Dat is dus precies het probleem: de computer die de DPI doet is een proxy, en daarmee twee endpoints (client endpoint vanuit server persepectiet, server endpoint vanuit client perspectief). Vanuit een non-compromised client is dit extreem duidelijk zichtbaar: die zal altijd melden dat er een man-in-the-middle attack gaande is (door de DPI proxy).

Het probleem met jouw idee is dat je veiligheid sowieso niet gegarandeerd is wanneer de client compromised is. Een extra laag encryptie helpt niet als de browser je ingetypte wachtwoorden direct doorstuurt naar de aanvaller.

[HollowGamer]

Maar hoe zien ze dat dan? Naar mijn weten blijft die checksum toch gewoon hetzelfde? KPN doen (of deden?) dat toch ook met gratis Spotify op datalimieten en in de US doen ze het ongelofelijk graag.

Ik bedoel hier niet dat de computer het probleem is, maar de firewall die het verkeer inspecteert.

[JanVQ]

Person-in-the-middle?... Tja, "man-in-the-middle" mag in deze tijden wellicht niet meer, ook al heette het vroeger wel gewoon zo.

[Bjorn89]

Het wordt steeds raarder. YouTube is al een goed voorbeeld dat het onzinnig is. Waarbij je zo krom moet gaan praten steeds. 😅😂

[Christoxz]

Person-in-the-middle wordt niet vaak gebruikt en is niet echt gangbaar, maar is niet persee ontstaan door de huidige tijden.
Hier een RFC van 2006 bijvoorbeeld, waar de term gebruikt is:
https://www.rfc-editor.org/rfc/rfc4744.html

[Powerblast]

Ik moet eerlijk zijn, ik moest het toch ook even gaan opzoeken want van person in the middle had ik nog nooit gehoord . Dit staat volgens mij bij iedereen toch wel echt bekend als man in the middle.

[Marrtijn]

Google Trends geeft ook een overweldigende meerderheid voor 'man in the middle', dus het is een beetje raar om de ongebruikelijke naam te gebruiken, vooral omdat het een bewuste keuze is aangezien het artikel over 'Monster-in-the-Middle' spreekt.

[Reactie gewijzigd door Marrtijn op 23 maart 2025 11:49]

[satya]

Wij gebruiken graylog, daar zijn de settings van master/slave gewijzigd naar leader/follower

[Christoxz]

Zo vermijden sommige partijen ook 'black/white' list, bijvoorbeeld Linux:
nieuws: Linux stapt af van master/slave- en blacklist/whitelist-terminologie

Microsoft heeft zelf een "Writing Style Guide" hier over.
https://learn.microsoft.c...m-collections/b/blacklist
Zo zijn er bijvoorbeeld ook alternatieve termen voor `Black Hat Hacker`.

Anyway, het kan (mij) allemaal geen kwaad. Master of leader, Black or block.
Als iemand daar blijer van wordt, geniet er van

[Niemand_Anders]

Benieuwd wanneer men 'mankind' gaat veranderen ;-)

Overigens moet ik zeggen dat ik AllowList/DenyList wel een goede vervanger vind dan WhiteList en BlackList...

[R4gnax]

Anyway, het kan (mij) allemaal geen kwaad.

Eigenlijk kan het weldegelijk kwaad.
Jou misschien niet- maar wel in algemene zin.

Het zijn nietszeggende wijzigingen die op geen enkel vlak zoden aan de dijk zetten of iets doen aan werkelijke discriminatie- en racisme-problematiek, wat veel dieper ligt dan een woordje aanpassen dat binnen context genomen nooit ter discussie heeft gestaan als discriminerend of racistisch.

Het is een mooie manier om met handwuiven de aandacht van deze werkelijke problematiek af te leiden en te doen alsof je toch heel erg bewogen er mee bezig bent. Een excuusbrief om niet door te hoeven pakken en naar het fundamentele te kijken.

[Reactie gewijzigd door R4gnax op 23 maart 2025 13:30]

[satya]

Het is dit wat het imho erger gemaakt heeft de afgelopen jaren in plaats van dat het wat oplost, niet tegenstaande dat men de meest bezwaarlijke varianten weg kan laten. Er zijn zelfs situaties waarbij bedrijven gecanceld zijn omdat een saas leverancier vond dat namen van medewerkers racistisch waren.

Ze kwamen nota bene uit Afrika

[Saven]

Is internationaal inderdaad gewoon bekend als “mitm” attack. Dat Tweakers meent het inclusiever te moeten maken slaat hier de plank een beetje mis ja. Gaan we straks in het leger ook spreken over persoonschappen in plaats van manschappen? Sommige termen hoef je gewoon niet aan te passen. Sowieso is het hele woke gebeuren inmiddels wel een beetje voorbij. Dus terechte kritiek wat mij betreft.

[TheVivaldi]

En wat te denken van het eiland Man?

[Niemand_Anders]

Ach, ik had die discussie 20 jaar geleden al op de universiteit waar ze algemeen geaccepteerde Engelse termen naar het Nederlands gingen vertalen. Bij een verwijs sleutel dacht ik in eerste instantie aan een foreign key (een verwijzing naar een sleutel in een andere tabel), maar het bleek dus de zelf verzonnen vertaling te zijn voor een database index... En dit is slechts een van de honderden voorbeelden die ik op dit punt heb. Ineens moet je als student twee termen voor hetzelfde phenomeen leren en zodra je klaar bent met je opleiding heb je nooit meer in je leven ook maar iets aan die Nederlandse vertaling, met andere woorden nutteloze informatie. Alleen die informatie zit nog wel in mijn hoofd en daardoor ben ik zeer waarschijnlijk wat anders vergeten...

[Draggeta]

Het is wel echt een beetje krom inderdaad. Alle oude technische termen en conventies worden langzaam aan de deur uit gegooid omdat enkele mensen denken dat andere mensen zich hier aan storen.

Voor 2010 had ik twee keer in mijn leven racisten meegemaakt. In de huidige tijd zou je bijna denken dat elke persoon uit Afrika compleet wordt neergehaald en niks kan zonder hulp.

Termen zoals master/slave, white/blacklist, MITM, Alice, Bob, Charlie, Eve etc. zijn duidelijke termen met een historie erachter dat uitlegt waarom ze gebruikt worden. Het voordeel is ook dat iedereen ze begrijpt.

[Reactie gewijzigd door Draggeta op 23 maart 2025 13:43]

[bmwgozer]

Cloudflare zelf noemt het Monster In The Middle attack. al jaren overigens. De meeste mensen noemen het machine in the middle attack.

Het is inderdaad een vreemde vertaling door het person-in-the-middle te noemen. Maar ik gok dat het niet de reden heeft die iedereen hieronder beschrijft.

[HollowGamer]

Ik weet niet of het van vorig jaar was, maar als een 1 april grap zei Tweakers toen wel alles naar Nederlandse woorden te vertalen. Zoals werkgeheugen en processor eenheid.

Dacht wel dat ze het meer deden. Voor mij hoeft het niet perse, maar het hoort bij de tijd.

[FinalLight]

het blijft man in the middle voor mij persoonlijk, ga het niet aanpassen omdat iemand op twitter erover heeft gezeikt.