Mozilla past Firefox-useragent aan vanwege verwarring met Internet Explorer

Mozilla gaat de useragent van Firefox veranderen omdat websites de browser soms aanzien voor Internet Explorer 11. Dat gebeurt door foute configuraties op sommige sites, maar Mozilla vindt het probleem dusdanig groot dat het de useragent helemaal aanpast.

De browserontwikkelaars hebben voor een verandering gestemd waarmee de useragent in Firefox tijdelijk wordt veranderd. In de huidige versies van de browser wordt die useragent nog aangemerkt als rv:110.0 voor Firefox 110 of rv:119 voor Firefox 119. Dat levert problemen op sommige websites, schrijven de ontwikkelaars. Die websites doen een controle op de useragent van een bezoeker en passen de site daar mogelijk op aan. Dat doen die websites voor Internet Explorer-gebruikers, waar zij dan een alternatieve UI voor inladen.

Internet Explorer 11 heeft echter een useragent die lijkt op die van Firefox. Voor IE11 is dat rv:11.0. Websites die op useragents controleren, zien het rv:110.0 van Firefox in sommige gevallen aan voor het rv:11.0 van IE11. Ze schotelen dan een 'verkeerde' versie van de website voor.

Om die reden komt het probleem ook alleen voor bij Firefox-versies 110 tot 119. De ontwikkelaars hebben besloten om voor die versies de useragent tijdelijk stop te zetten. Versies rv:110 tot en met rv:119 maken voortaan gebruik van de useragent rv:109. De originele useragent wordt weer hersteld als Firefox aan versie 120 toe is. Die staat op de planning voor november van dit jaar.

Reacties (125)

Het internet is kapot.

Mensen zouden bv. dit eens moeten lezen:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Browser_detection_using_the_user_agent

Mooi stukje. Daar wil ik alleen aan toevoegen dat nadat microsoft internet-eploder had ontwikkeld voor de 'compatibiliteit' de user-agent van mosaic had hergebruikt en alleen op versie nummer verschilde.... Dat is voor zover ik mij herinner bij ie-4 aangepast/verbeterd. Maar toegegeven, dit meld ik uit mijn hoofd, het is al meer dan 25 jaar geleden dat het passeerde.

[update (I stand corrected)]: IE gebruikte niet mosaic, maar mozilla: https://developers.whatis...e_name/internet-explorer/
of toch niet???
https://developers.whatis...ore/software_name/mosaic/

[Reactie gewijzigd door beerse op 4 januari 2023 15:23]

Als zo'n website zo makkelijk voor de gek te houden is, geeft dit dan geen beveiligingsrisico's?

Het user agent veld is nooit bedoeld om op enige wijze geverifieerd te worden. Het is een manier voor de browser om aan de webserver te vertellen welke browser wordt gebruikt, zodat de website hier, indien nodig, rekening mee kan houden.

Zo kan een oude browser een beperktere versie van de website voorgeschoteld worden waarbij de nieuwste functies ontbreken, of een browser die speciaal bedoeld is voor mensen met een beperking (denk aan een braille-browser) kan hierdoor een aangepaste versie van de website ontvangen.

Maar er wordt niet gecontroleerd of de user agent ook klopt. Sterker nog, er zijn situaties waarin een browser een "valse" user agent can doorgeven. In de tijd dat Internet Explorer nog de allergrootste was, waren er websites die bij niet-IE browsers simpelweg een foutmelding teruggaven. Als je dan Firefox gebruikte kon je met een extensie de browser net laten doen of het IE was, waardoor je de goede versie van de website terug kreeg (die gewoon prima werkte).

Sowieso is de hele user agent gewoon 1 grote afvalbak van legacy rommel.

Elke browser inclusief Chrome en Internet Explorer identificeert zich bijvoorbeeld als "Mozilla". Het is echt een gore puinbak die in verloop van tijd zonder enige sturing is ontstaan, die in een moderne web omgeving niet meer thuishoort.

Met die string wordt het gebruikt om nieuwe features te testen. Stel ik wil weten of ik een nieuw dom element kan testen, dan kan ik weten dat dat geldt vanaf versie ... aan de hand van de user agent kan dan de keuze zijn van de server iets te laden/retourneren.

Ja ik weet waar het voor is, maar de opbouw van die string is legacy shit op shit gestapeld.

Bovendien zijn er tegenwoordig betere manieren voor om dat soort dingen te checken, via javascript.

Dat was zo in de tijd dat websites nog voornamelijk op de server opgebouwd werden. Als je tegenwoordig op nieuwe features wil testen, dan test je gewoon de feature zelf met een klein beetje Javascript. Hoeft je ook geen database bij te houden van welke browser versie welke features heeft.

Er bestaat al heel lang het concept van feature detection wat zonder UserAgent werkt. Die hele UserAgent string kan zo de prullenbak in wat al een paar keer is voorgesteld. Ik weet niet of het plan van Chrome nog doorgaat, maar daar was het idee om binnenkort de UserAgent nooit meer aan te passen of zelfs leeg te laten. Het maakt de communicatie ook sneller, want dan hoeft die string aan willekeurige karakters niet meer bij elke connectie over de lijn.

Zo te zien start de test bij Chrome 110 om met een feature flag te testen wat de impact gaat zijn.

[Reactie gewijzigd door army op 4 januari 2023 12:31]

Je kan ook de User-Agent weglaten... (Dat mag volgens de specificatie!)
Dat had ik gister gedaan, om wat bytes up te besparen...

Echter, dat vond StackExchange niet leuk, ze weigerden mij toegang.
(Maar een User-Agent van "none" word wel geaccepteerd)

En dat heeft mogelijk weer te maken met botdetectie. Een belangrijke en eenvoudige 'red flag' bij het detecteren van bots is, naast de hoeveelheid traffic, het ontbreken van of hebben van een rare user agent.

Het is gewoon good practice voor bots en crawlers om zich als dusdanig te identificeren; de meeste searchengines hebben daar gewoon documentatie voor:
https://developers.google.../overview-google-crawlers
https://www.bing.com/webm...rs-does-bing-use-8c184ec0
https://support.apple.com/nl-nl/HT204683
etc.

Problematischer zijn bots die zich juist proberen te vermommen als een gewone browser, maar zich niet netjes gedragen (robots.txt negeren, veels te veel requests doen, scraping tegen de TOS in etc.)

Maar toch vind ik het een beetje raar. StackExchange is een open platform en een gebruikersagent is een soort identificatiecode. Stel je voor dat je de bibliotheek, eveneens een open platform, niet binnen mag zonder je id-kaart te tonen… (Let wel: ik heb het dus alleen over het binnengaan, niet over het lenen van boeken of, in het geval van SE, berichten mogen plaatsen.)

Als je met zo'n witte stok de bibliotheek binnenkomt, heb je kans dat iemand je komt helpen en je de brailleboeken of audioboeken voorstelt. Dan kan je heel hard roepen "Gefopt! Ik ben helemaal niet blind!" maar wat win je dan?
Een user agent is nu ook weer niet zo uniek als een id-kaart en véél makkelijker en legaal te faken. Elke standaard browser stuurt die info mee, dan weet de website welke fantasietjes ze al dan niet kan doorsturen en ook aan welke browsers ze in de toekomst het meeste developmentbudget kan besteden.

Dat laatste lijkt me niet meer zo aan de orde nu dat het leeuwendeel van de meestgebruikte browsers op Blink of WebKit gebaseerd is en dus overal hetzelfde werkt. En het zou me niks verbazen als Firefox ook een keer overstapt op een fork van een van die twee; ze hebben immers al een stap in de richting van Chromium gezet met WebExtensions.

[Reactie gewijzigd door TheVivaldi op 3 januari 2023 11:57]

Mwah het mogelijk maken van webextensions is gewoon extra functionaliteit. Ik denk dat Mozilla niet graag de overstap maakt naar Blink of Webkit. Er is al zo weinig concurrentie in de browser space en ik denk dat niemand blij wordt dat een enkele partij de dienst uitmaakt.
Het zal zeker praktischer zijn voor webdesign maar het voelt toch ongemakkelijk om DE standaard voor browsers te laten bepalen door zo een kleine groep. Gecko heeft al geen groot aandeel meer gezien chromium zo veel wordt overgenomen maar het eet wel in de vrijheid van eigen browserervaring (zoals Google die dealtjes sluit met ad-blockers)
Nu is daar ook nog een hele discussie over of het wel of niet ethisch is om advertenties te blokkeren maar ik zie niet graag dat Mozilla niet meer hun eigen engine heeft gewoon om zo veel afstand als op dit moment in tijd mogelijk is om monopolies te voorkomen.

- geschreven vanaf mijn werk-chrome die geen webportals kan bouwen voor andere browsers

Een useragent kan je niet vergelijken met een ID kaart, amar eerder met je naam. Niemand bij een bibliotheek interesseert het hoe je heet, maar bij een koffiebar of dergelijke misschien wel om je bestelling op te roepen en daar kan je dus ook een valse naam gebruiken en dat zal dan ook geen consequenties hebben.

[Reactie gewijzigd door Remzi1993 op 3 januari 2023 23:51]

Ik zou het eerder vergelijken met het merk schoenen dat je aan hebt.

Hoezo vind je een useragent een soort identificatiecode? Een gebruiker is er niet mee te identificeren en het doel is niet identificatie.

Je kan als open platform best eisen stellen aan hoe je platform gebruikt wordt. Net als dat als ik de openbare bibliotheek hier in de stad in m'n nakie binnenloop, ik waarschijnlijk heel snel gesommeerd zal worden te vertrekken.

[Reactie gewijzigd door ZinloosGeweldig op 3 januari 2023 14:11]

Hoezo vind je een useragent een soort identificatiecode? Een gebruiker is er niet mee te identificeren

Een gebruiker niet, maar een browser+besturingssysteem wel.

Een ID kaart is ook iets heel anders dan een user agent string. Er is altijd wel iets mis met dit soort vergelijkingen, maar ik ga er toch eens zelf aan mee doen: in dit geval kan je dit dus vergelijken als een bibliotheek die je niet binnen laat als je geen kleren draagt. Iedereen kan aan kleren komen zonder privacy schending, net zoals iedere webbrowser voor gebruik door een mens een user agent string kan verzinnen. Het meesturen van een lege user agent string lijkt me enkel nuttig om de botdetectie van websites om de tuin te leiden. Als sysadmin is dat ook de enige use case die ik daarvoor al gezien heb. Waarschijnlijk hebben de sysadmins van StackExchange dezelfde ervaring.

Klinkt alsof botdetectie nogal... botte bijl werk (pun intended) is. Kun je beter kijken of er 'curl' in de user-agent staat oid en niet plat gaan bij geen user-agent. Een user-agent-loos internet lijkt me beter dan de rommel men nu uitstuurt om zo veel mogelijk websites om te tuin te leiden (en inderdaad nog wat data te besparen op de koop toe).

Curl is wel een nuttige user agent die sommige sysadmins soms zelf gebruiken. Fijt is dat de meeste attackers niet curl gebruiken (of toch niet de user agent string ongewijzigd laten), en curl soms wel door de system administrator en developers gebruikt wordt.

User-agent is gewoon weer een datapunt waar bots op nat kunnen gaan. En geen slechte.
Als er plots veel verkeer komt van allerlei richtingen waarvan de user-agent niet de op dat moment gebruikelijke versie is voor die site, is er wat aan de hand.
Is nog best lastig te faken ook, want wat is de browsermix bij Stackexchange? En hoe up to date zijn de browsers daar precies?
En falen bij een ontbrekende user-agent lijkt me een bug.

Maar dat is hem het dus:
Een bot kan super makkelijk een browser's user agent faken.
En de User-Agent "none" word wel gewoon geslikt...
Dat betekent dus:

Attention hackers,
Know that StackExchange's bot detection is faulty!
Analyse, Verify, Exploit, Claim!

Natuurlijk is het geen perfecte beveiliging tegen bots, maar als je met een paar regeltjes code (en requests zonder user agent weigeren zal niet veel meer zijn dan dat) al een boel luie bot-makers kunt buitensluiten, dan is dat de moeite waard.

Algoritmes die bots detecteren baseren zich niet alleen op de useragent. Zelfs al zouden ze die compleet negeren, kunnen ze nog prima een adequate beveiliging tegen bots hebben.

De beveiliging (of 'misbruik preventie' in het geval van bots) van een site volgt doorgaans een gelaagd model. Je hebt meerdere lagen, die telkens andere soorten aanvallen filteren. Dit is een van de eerste (en goedkoopste) lagen. Hier worden domweg alle luie botmakers mee gefilterd.

Elk request dat je vervolgens niets meer verder mee hoeft te analyseren, scheelt je een hoop rekenkracht.

Ik denk dat niemand bij StackExchange de illusie heeft dat ze hiermee klaar zijn. Maar ze zullen ongetwijfeld wel in hun statistieken zien wat het scheelt als ze dit aan/uit zetten.

[Reactie gewijzigd door Keypunchie op 3 januari 2023 13:26]

Hoe verander ik die in none? Ik bedoel: je hebt dus die tekenreeks met Chrome dit, Safari dat, Windows/Linux zus, etc. Kan ik dan gewoon alle tekst uit de gebruikersagentregel halen en daar none zetten?

[Reactie gewijzigd door TheVivaldi op 3 januari 2023 12:02]

Ik gebruik Firefox, en heb de User-Agent aangepast via about:config.

Hoe: Zet de "general.useragent.override" preference op String, klik de +, en druk enter. (een lege string dus)
Als je de Ontwikkelaarsconsole op de networking tab opent, kan je dan in een request naar example.com zien dat de "User-Agent" request header ontbreekt.

Ik raad het af om dit zo te doen, want er zijn dus een aantal sites die dit niet leuk vinden.
Zelf heb ik mijn user agent op enkel "Firefox" gezet, en dat is dus alles wat ze van mij hoeven te weten.

Zelf heb ik mijn user agent op enkel "Firefox" gezet, en dat is dus alles wat ze van mij hoeven te weten.

Daarmee heb je jezelf in een kleinere sample pool gezet dan de normale volledige user agent; en maak je het juist makkelijker voor adverteerders en profilers om met extra andere gegevens er naast tot een (vrijwel) unieke fingerprint te komen...

Hoe moet je het anders doen?
Welke User-Agent en/of settings zou ik moeten gebruiken om zo min mogenlijk op te vallen?

De User-Agent gewoon op de standaard laten staan, verbergt je in de menigte.
Aanpassen naar iets anders wat je zelf verzint maakt je vrij uniek, zeker als een adverteerder andere aspecten daarnaast kan pakken waar de daadwerkelijke browser versie die je gebruikt toch nog uit af te leiden is.

Aanpassen naar de UA-string van een andere browser is zo mogelijk nog slechter. De mismatch in browser features tussen wat die heel specifieke UA-string aangeeft en wat je browser daadwerkelijk ondersteunt maakt wss. voor een nog veel meer unieke combinatie.

Er zijn extensies voor browsers om die te kunnen aanpassen. Ik heb die vroeger nog wel eens gebruikt om te testen. https://chrome.google.com...bgkdhkhhcedjiklpkjnoahfmg deze bv. Je kan het ondertussen blijkbaar in de development tools ook.

Het user agent veld is nooit bedoeld om op enige wijze geverifieerd te worden. Het is een manier voor de browser om aan de webserver te vertellen welke browser wordt gebruikt, zodat de website hier, indien nodig, rekening mee kan houden.

Maar als het een manier is voor de browser om aan de webserver te vertellen welke browser wordt gebruikt, is het toch een manier om geverifieerd te worden?

Nee, het is een manier om de server te vertellen welke versie van de website je voorgeschoteld wil krijgen. Het was nooit bedoeld als verificatiemethode of een andere beveiligingsgerelateerde factor.

Maar als je botverkeer wil identificeren kijk je naar alle parameters die je kan vinden. Je weigert niet de toegang, maar je kan wel zien als er wat raars gebeurt.

Ja, sorry, ik was de eerste comment vergeten waarop gereageerd werd. Ik vatte verificatiemethode op als manier om te verifiëren welke browser je hebt. My bad.

Het is een optioneel veld waar de client (browser of andersoortige applicatie) zelf kan kiezen wat het invult. De server kan dus niet verifieren dat de inhoud van het user agent veld klopt. Een Chrome browser kan zich voordoen als Firefox en Firefox kan zich voordoen als Edge, enz... Het veld is vooral een hulpmiddel om compatibiliteit te verbeteren.

Snap ik. Maar het veld is ook niet voor de sier gemaakt, dus de bedoeling is denk ik toch echt wel geweest om te kunnen 'zien' welke browser is aanklopt en zo eea aan te kunnen passen.
Maar het is een min of meer quick & dirty manier om dit te zien. Er zijn uitgebreide browsercapability tests om vast te stellen wat wel en niet kan op een client.

Het is niet voor de sier... Vergelijk het met dat ik je vertel dat ik Vlaams spreek. Nu ben ik zelf geen Vlaming, maar ik denk zelf dat ik het dusdanig beheers, dat ik prima een conversatie in het Vlaams kan houden. Jij gaat dus in het Vlaams tegen me praten (want dat gaf ik aan), maar de kans is dus aanwezig (heel groot zelfs) dat er delen zijn die ik niet goed beheers. Daardoor zeg jij dingen tegen mij die ik verkeerd interpreteer en andersom.

Is dat dan jouw fout? Nee, want ik gaf willens en wetens aan dat ik Vlaams beheers.Ik ben al best wel oud, en heb de opkomst (en ondergang) van IE meegemaakt. Wat je vroeger dus heel erg merkte was dat hele simpele, platte HTML (zonder toeters en bellen) in IE er toch echt heel anders uitzag dan in Netscape of Mozilla. En andersom had IE heel veel "foefjes" (via VB-script als ik me goed herinner) om bepaalde dingen te kunnen doen, die de andere browsers niet geimplementeerd hadden, waardoor een site voor IE niet werkte onder een andere browser. (en toen IE de de facto standaard werd, werden opeens alle sites alleen voor IE ontwikkeld... een vervelende tijd) En dan merk je dat het wel heel handig is als een browser aangeeft welke engine er gebruikt zou moeten worden (zodat de site de compatable versie voor kan schotelen)

Precies wat ik zeg dus:

Maar het veld is ook niet voor de sier gemaakt, dus de bedoeling is denk ik toch echt wel geweest om te kunnen 'zien' welke browser is aanklopt en zo eea aan te kunnen passen.

excuus; ik las je reactie iets anders...

Dat kan wel maar het systeem geeft enorm veel informatie over zichzelf weg waardoor het simpel is je te volgen/tracken. En dat zou wat mij betreft moeten gaan veranderen.

De client moet eigenlijk aan een server vragen, kun jij dit op deze manier leveren ipv hallo ik ben xxxxx, dit is mijn scherm resolutie, dit heb ik ter beschikking, etc. Ook moeten we cookies laten vallen, niet meer alles in de client browser uitvoeren maar op de servers.

Basicly moet een client anoniem kunnen zijn, dan zijn we van heel hedendaagse problemen verlost.

Een cookie heb je nodig voor de sessie, en een cookie heb je dan nodig voor authenticatie.

niet noodzakelijkerwijs, je kunt de ID ook in de url embedden. Of je daar nu gelukkig van moet worden dat laat ik even in het midden. Maar technisch gezien is een cookie niet noodzakelijk.

Maar ze smaken wel een heel stuk beter.

Nee, want via die manier ben ik een keer binnengekomen via de statistieken pagina van mijn website in een belangrijke portal. Php3 was net uit

technisch gezien is het om het even, er zijn overal methodes voor. Punt blijft dat we af moeten van alles maar standaard client-side afhandelen en bergen met info over jezelf weg geven. Dat is een onveilige en achterhaalde methode.

De hele geschiedenis van user agents is jezelf voordoen als een ander. Internet Explorer doet volgens mij vanaf versie 3 zich al voor als Netscape (Mozilla met een MSIE stukje erachter)

Nee want er worden geen belangrijke zaken veranderd op basis van de user agent, doet een website dit wel dan is dit een ontzettend domme keuze en een fout van de web developer. Iedereen kan zijn user agent zelf instellen met een extensie en welke browser dan ook spoofen.

Het gaat er in dit geval om dat IE vaak niet voldoet aan dezelfde standaarden als Firefox, Chrome, etc. en dus bepaalde dingen niet/anders werken. Detecteert zo'n website dan dus IE dan word een alternatieve versie van de website geserveerd die dan zorgt dat alles wel naar behoren werkt.

geen belangrijke zaken veranderd op basis van de user agent, doet een website dit wel dan is dit een ontzettend domme keuze en een fout van de web developer.

Natuurlijk doet b.v. een nieuws website dit wel. Als je b.v. onderstaande voorbij ziet komen weet je dat Google kijkt. Op dat moment maak je alle nieuws berichten volledig beschikbaar, zodat ze op Google vindbaar zijn. Zie je een normale gebruiker dan laat je de headlines zien en moeten ze betalen voor het hele artikel.

Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html

Oftewel als je jou user-agent aanpast van je browser (b.v. met een extensie), dan kan je soms meer zien op een website dan normaal. Sommige sites zullen een "revese dns lookup" doen op je IP, en dan kijken of ze "google" in de url zien, maar meeste niet.

In Chrome heb je niet eens een extensie nodig toch? In je dev-tools heb je bij je "Network Conditions" gewoon de optie om 1 van de vele user-agents te gebruiken, of om zelf een user-agent in te vullen.

Dit was tot een tijd terug zelfs nodig als je een foto op instagram wilde plaatsen via je pc. Want daar ontbraken de functionaliteiten voor het uploaden van een foto. Maar als je je user-agent aanpaste naar bijvoorbeeld "Safari - iPad iOS 13.2" ofzo, kreeg je keurig de upload knoppen en functionaliteit als je naar instagram ging.

Hmm. reverse DNS met als resultaat google.mijndomein.nl zou dan wellicht weer werken ;-)

Het is mij soms een raadsel waar ze nu precies naar kijken in de gebruikersagent. Ik gebruik op zowel desktop als telefoon een QtWebEngine-browser en QtWebEngine is een Blink-wrapper, dus eigenlijk gewoon Chromium. Op desktop is dat eigenlijk nooit een probleem, maar op mijn telefoon wordt er nog wel eens gezeurd dat ik geen Chrome gebruik. Maar de gebruikersagent geeft wél keurig door dat er sprake is van een Chromium-browser d.m.v. wat jij ook hebt staan (Chrome/W.X.Y.Z. en al die reutemeteut), omdat, zoals ik al zei, QtWebEngine niks anders is dan een Blink-wrapper. Dus ze zullen toch ook andere manieren hebben om je browser vast te stellen.

Oftewel als je jou user-agent aanpast van je browser (b.v. met een extensie), dan kan je soms meer zien op een website dan normaal. Sommige sites zullen een "revese dns lookup" doen op je IP, en dan kijken of ze "google" in de url zien, maar meeste niet.

Dit is waar, ik heb zo'n extensie en dat scheelt verrekte veel paywall gedoe

Dit heeft niks met beveiliging te maken, FF 110 adverteert zich als rv:110.0 en websites denken dan iemand IE11 (rv:11.0) gebruikt en geven dan een meldingen dat de site niet werkt op IE11.

m.a.w. iemand heeft niet op zitten letten aan de website kant.

Klopt maar degene die deze useragent string bedacht heeft kon er natuurlijk op rekenen dat dit verwarring ging geven.

Dat lijkt me niet. De useragent is een lange tekst, zoals eentje van IE

Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0) like Gecko

En een Firefox

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:108.0) Gecko/20100101 Firefox/108.0

De brakke websites kijken dus alleen naar het stukje rv:11 en negeren voor het gemak het detecteren van (het ontbreken van) de naam van de browser.

De brakke websites kijken dus alleen naar het stukje rv:11 en negeren voor het gemak het detecteren van (het ontbreken van) de naam van de browser.

'Trident' geeft indirect aan dat het Internet Explorer is, want dat is de naam van de engine. Daarop zou men kunnen filteren om expliciet IE te herkennen.

[Reactie gewijzigd door The Zep Man op 3 januari 2023 15:18]

Als je zonder technische voorkennis naar die useragents kijkt kan je bij de 1e er niet duidelijk uithalen welke browser het nou was. Was het nou echt zo moeilijk om er gewoon Internet Explorer bij te zetten?

Het is natuurlijk nog steeds een fout van de developers van de website. Die hadden die technische kennis wel moeten hebben en niet puur moeten kijken naar een revisie nummer.

Maar we moeten het ook weer niet moeilijker maken dan het is. Iets ogenschijnlijk simpels als naamgeving blijft gewoon belangrijk. Je kan wel vingertje wijzen naar de devs van die websites maar als je dit soort fouten meer wilt voorkomen zul je ook naar het geheel moeten kijken. Mensen maken altijd fouten en ze alleen de schuld geven gaat dat niet oplossen.

En natuurlijk handig dat Internet Explorer zich primair identifieert als Mozilla

Dan heb je die van Chrome nog nooit gezien:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36

Wel logisch, want Chrome is gebaseerd op Webkit (Safari/Apple), wat weer gebaseerd is op KHTML (KDE), wat lijkt op Gecko (de engine van Firefox).

[Reactie gewijzigd door MarnickS op 3 januari 2023 12:47]

Achteraf natuurlijk gemakkelijk gezegd. Waarom komen we er dan nu pas achter?

ja en nee. het oerwoud van browsers uit elkaar houden is jarenlang een vervelend taakje gewest voor veeld webdevelopers. StartsWith("rv: 11") is jarenlang een zeer redelijke check geweest om te zien of je de IE11 versie nodig had, en ik vind het daarom zeer onhandig van FireFox om in december 2022 een user agent uit te brengen die zo sterk op een andere, reeds bestaande lijkt, dat je met miljoenen sites in omloop wel kunt rekenen op een paar miljoen bugs.
dus Ja, de sites zijn niet perfect, maar in browserland heeft (in)compatibiliteit dermate grote gevolgen dat ik het bijzonder onverstandig vind van FireFox om op deze manier de grens op te zoeken.

Tegen windmolens kan je niet vechten, egen luie programmeurs ook niet, maar het blijft een omgekeerde wereld....
Overigens kun je dit probleem prima afvangen via whatismybrowser.com, zeker als je commercieel afhankelijk bent van een goed werkende site

Inderdaad, het is een nulletje verschil van 110.0 naar 11.0, maar toch met "grote" gevolgen....

Het enige risico is dat een bezoeker een verkeerde website voorgeschoteld krijgt. Hooguit is daarmee beschikbaarheid in het geding, omdat Firefox mogelijk niet goed om kan gaan met een site aangeboden voor IE11.

[Reactie gewijzigd door The Zep Man op 3 januari 2023 09:47]

nee, het gaat puur om het valideren van het device,
ik heb deze ooit misbruikt voor bijvoorbeeld www.youtube.com/tv
met een browser wordt je geforward naar de home, maar als je de useragent aanpast naar die van een tv(deze kun je gewoon googlen)
gebeurt dat niet en kun je een kiosk brower openen met tv interface en een addblocker.

Als je de User Agent van de Google Bot gebruikt, gaan er soms wel eens leuke deuren open.
Maar uiteindelijk zijn dat geen beveiligingsrisico's. Wat Google mag lezen, mag iedereen lezen.

Vivaldi gebruikt een user agent die zich voordoet als chrome
Vivaldi had initieel zijn eigen user agent, maar werd vaak geblokkeerd of een minder goeie website getoond, zoals de IE versie en andere problemen want ze werden of niet serieus genomen of bedrijven (zoals microsoft bijvoorbeeld) probeerden de ervaring minder prettig te maken zodat je zou overstappen naar chrome.

Aangezien vivaldi chromium based is zoals chrome, zijn er weinig verschillen, dus vivaldi doet zich voor als chrome om niet gediscrimineerd te worden.

https://vivaldi.com/blog/user-agent-changes/

Neuh, dat gaat alleen om sites die een subtiel andere versie van de pagina voorschotelen aan verschillende browsers (waarbij IE meestal als de uitzondering geldt) omwille van compatibiliteit met Javascript en CSS e.d.

IMO geen enorm probleem aangezien geen enkele webbouwer nog legacy-IE ondersteunt (en op die manier onderscheid maken was sowieso al geen best practice), maar mogelijk kom je 't op iets oudere, waarschijnlijk niet meer onderhouden, sites nog tegen. Dat is waarom Firefox die beslissing genomen heeft, want die oude sites aanpassen gaat 'm niet worden.

Op zich niet, maar een ontwikkelaar die tegenwoordig nog op de useragent vertrouwd, zou ik niet vertrouwen met beveiliging. Het zou voor mij een indicatie zijn dat er waarschijnlijk op meer punten de code niet is onderhouden en waarschijnlijk beveiligingslekken heeft.

Eigenlijk te zot dat Firefox met een workaround moet komen, maar fijn dat ze het doen. Het marktaandeel van Firefox is al niet zo groot meer en dit kan je gebruikers kosten.

Overigens, als van vroeger uit nou 's de browsers zich op een normale manier identificeerden hadden we nu misschien ook normale User-Agent strings. Dit is Chrome op MacOS met een M1 Max: User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36

Maar Safari is overigens niet veel beter: User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.2 Safari/605.1.15

En Firefox: User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:108.0) Gecko/20100101 Firefox/108.0

Los van dat ze allemaal de architectuur verkeerd hebben wel interessant om te zien dat Firefox niet Safari in de user-agent gooit. Geen idee eigenlijk waarom ze dit doet. Wellicht om historische redenen zodat de browser bouwers niet hoefden te wachten totdat websites hun browser goed gingen ondersteunen?

Los van dat ze allemaal de architectuur verkeerd hebben

Moet je voor de grap eens console.log(navigator.appName) in je developer console draaien, dan krijg je Netscape (in zowel Firefox, Chrome als Safari). Firefox gebruikt ook alleen maar de oude arch omdat Safari daar mee begon, ze vonden het beter om dan de bijbehorende OS-bouwer te volgen i.p.v. toch af te wijken. En grote kans dat Apple dat bepaalde doordat veel sites nog steeds lekker naïef kijken naar Intel Mac OS X of zelfs Intel Mac OS X 10., ook al heet het OS tegenwoordig officieel al een tijdje macOS en zijn we ruim voorbij versie 10.

Mozilla/5.0 komt vanuit de eerste browser war volgens mij, omdat sites alleen geavanceerde features gebruikten als de client herkend werd als iets "Mozilla". Als ze zelfs dat al niet aangepast krijgen na bijna 30 jaar, kleine kans dat je dan iets van macOS arm64 12. op korte termijn gaat zien. Je kon vroegah ook nog de waardes MacPPC en Mac68K hebben voor navigator.platform, maar weet zo ff niet hoe lang het geduurd heeft voordat browsers dat echt gingen doorgeven. Chrome zit ook alweer een behoorlijke tijd op de Blink-engine maar toch krijg je nog WebKit als platform.

Eigenlijk bestaat de UA uit meerdere "tokens" gescheiden door spaties, waarbij 1 token het format product (comment/details) heeft (waarbij de comment optioneel is). Het meest significante product komt eerst, dus als ik een eigen browser zou maken gebaseerd op Gecko dan zou mijn UA moeten zijn: BaconBrowsert/1.2.3 (Macintosh; ARM64 macOS 12.5.1) Gecko/106.0.5. De browser is een specifieke implementatie van de Gecko-engine, dus dat is het meest significant. Daarna natuurlijk de engine zelf. Chrome gebruikt verdere tokens bijvoorbeeld om zich ook een beetje voor te doen als Safari, zodat sites die expliciet zoeken naar "Safari" i.p.v. "AppleWebKit" ook fatsoenlijk werken. Safari en AppleWebKit zijn natuurlijk in principe uitwisselbaar met elkaar, maar Gecko niet met die 2 dus wel logisch dat Firefox alleen Gecko doorgeeft.

tl;dr: browsers doen het constant verkeerd vanwege vraagstukken rond compatibiliteit en web devs die geen fatsoenlijke feature detection (kunnen) doen.

Onder andere daarom wordt nu dus ook de Navigator.userAgent API afgerangeerd ten faveure van de navigator.userAgentData API.
Google heeft in Chrome hiervoor al een heel deprecation traject opgezet. In eerste instantie gaan ontwikkelaars waarschuwingen in de developer console van de browser zien dat ze over moeten gaan schakelen naar de nieuwe API als ze complete versie informatie etc. willen behouden. In een later stadium
gaat de knop om en wordt de Navigator.userAgent ook daadwerkelijk kaalgeslagen van de meeste informatie die er nu nog inzit, maar blijft er een opt-out beschikbaar. Nog later verdwijnt ook die opt-out.

Onder andere daarom wordt nu dus ook de Navigator.userAgent API afgerangeerd ten faveure van de navigator.userAgentData API.

Alleen in Chromium-based browsers ja. ;] Wat ik zo kan vinden lijkt het ook (nog) niet eens een "officiële" specificatie, dus waarom Google schijnbaar nu al een geaccepteerde standaard gaat vervangen met hun eigen concept? Gaan we weer dezelfde geintjes krijgen als met IE?

Maar goed, zelfs als alle browsers straks userAgentData ondersteunen: hoe lang gaat het duren voordat alle sites hun checks hebben aangepast? We hebben al gezien dat dingen decennialang hetzelfde kunnen blijven. Als er geen significant voordeel aan zit om het om te bouwen verwacht ik niet dat veel sites over gaan en zit je dus zoveel jaar met een "deprecated" feature in je browsert. Dat userAgentData alleen over HTTPS werkt/kan werken is leuk, maar als je al een redirect hebt van HTTP naar HTTPS, waar heb je dan die extra zekerheid voor nodig? Als iemand je verkeer onderschept en toch een HTTP-site weet te serveren i.p.v. HTTPS heb je wel meer problemen dan dat ze je browser kunnen fingerprinten.

Of dat ze het exacte model van je computer kunnen opvragen, een site heeft daar helemaal niks mee te maken. Als je voor één specifieke merk + model combinatie hacks moet gaan bouwen in je website, dan is dat toch echt een probleem van dat apparaat/de bijbehorende browser en niet je site. Ik kan me zo geen case bedenken waarvoor je echt zou moeten weten wat voor model iets is; een probleem met bijvoorbeeld WebGL-rendering zou ergens binnenin de browser afgevangen en "vertaald" moeten worden, zodat de render er vergelijkbaar uit ziet als op een wel correct werkende browser in plaats van te crashen o.i.d. Driversites zoals die van HP en Dell zouden met de modelinformatie wel meteen de goeie drivers kunnen tonen, maar de spec gaat volgens mij voornamelijk over dat sites überhaupt correct kunnen functioneren met die informatie. Je kan nog steeds prima "XPS zus en zoveel" intikken om bij je drivers te komen, het is niet alsof de hele site niet eens laadt als je op een HP ding zit, bijvoorbeeld.

En aangezien het opt-in zou moeten worden, zullen browsers waarschijnlijk iets van een popup moeten tonen om toestemming te vragen. Grote kans dat mensen steeds vaker gewoon op "doorgaan" klikken en het hele idee van meer privacy geen nut meer heeft. En niet te vergeten dat het alleen passieve fingerprinting zou tegenhouden, de hele functie is er juist op gebouwd om actief fingerprinting toe te staan. Mozilla heeft later toch ook besloten dat ze het "harmful" vinden: 1, 2, 3. Ik verwacht er niet veel van in ieder geval.

Dit is allemaal historisch inderdaad. Toen Apple met Safari (en dus WebKit kwam) leek de rendering meer op Firefox (Gecko) dan op IE. Zeker vroeger deden websites veel aan user-agent sniffing. Zeker de laatste 10 jaar is dat eigenlijk al niet meer nodig, maar die hele rommel is van de jaren ‘00. Apple heeft de user-agent volgens mij laten hangen om zo fingerprinting moeilijker te maken.

Wat mij betreft kunnen alle user-agents veel simpeler tegenwoordig: <browsernaam> <browserversie> <platform> <platformversie>. Misschien moet dat ook maar per 1 januari 2024 ingevoerd worden. Werkt een site of web applicatie dan niet dan hebben mensen maar gewoon pech en mailen ze maar met de beheerder van een site. Als je nog op deze manier snift dan loopt je site echt teveel achter.

Het een hoop legacy in die paar tekens.

Oef. Dat moet heel erg vervelend zijn voor de Firefox devs en gebruikers. Worden ineens moderne webtechnologieën voor niets uitgeschakeld!

Terecht dat ze hier voor een harde workaround gaan.

Ik vind het wel belachelijk dat je er voor jou word bepaald dat je bepaalde features niet voorgeschoteld krijgt op het (verkeerd) uitlezen van de useragent. Hier is toch feature detection voor?

Voor backwards compatibility is het simpel om te kijken naar de user agent. In een webapplicatie blijven neiuwe features komen. Dat een antieke browser moet blijven werken is eigenlijk meer een gunst dan een vereiste.
Anders zit je overal met feature detection in je code voor zaken die al meerdere jaren vrijwel in alle browsers geimplementeerd zijn.

Zit wat in. Maar ik snap het volgende niet; als je toch al de moeite hebt gedaan om een versie te schrijven die werkt op antieke browsers, waarom triggert dat op useragent, en niet op feature detection?

User agents is niet meer dan een stukje tekst wat de client aangeeft dat ie is. Maar dat hoeft helemaal niet zo te zijn. Hell, de standaard user agent van verschillende browers, bevatten verwijzingen naar andere browsers, omdat er dingen werden geserveerd op basis van user agent.

Er is een reden dat bijvoorbeeld Google kijkt naar het uitfaseren van user agents. Dat is vast niet alleen omdat het een grote rommelpot is geworden, maar het maakt het wel aantrekkelijker.

Nou ja het is een last resort redmiddel om toch een aantal browsers toch te ondersteunen. Het is aan de ontwikkelaar om hier een potje van te maken.

Features worden in mijn ervaring vaak geschreven voor ondersteunde moderne browsers. Voor legacy browsers hanteer je dan een whitelist om essentiële functionaliteit werkend te houden.

Het gaat over Internet Explorer. Vaak is dan de alternatieve versie van de website een HTML met de tekst: "Deze browser wordt niet ondersteund. Upgrade naar een moderne browser."

Als 99% van je website werkt op alle browsers en slechts een klein onderdeel niet dan kan je wel werken met feature detection.

Nou, zo heel erg blij word ik nou ook weer niet van Google's voorstel.

In plaats van dat een browser via de user-agent verteld van "Hoi, dit ben ik, dat ondersteun ik". Wil Google het dus omgooien en dat de website maar de browser gaat uitlezen.

Het is nu al compleet geschift hoeveel een website standaard al kan uitlezen van een browser. Google wil dit nog breder gaan maken. Voor nog betere browser fingerprinting. Maar Google beweert dat de Hints heel privacy bewust zijn

Anders zit je overal met feature detection in je code voor zaken die al meerdere jaren vrijwel in alle browsers geimplementeerd zijn.

En? Anders zit je met code die de UA interpreteert.

isIE11() is makkelijker op te ruimen is dan supportsFetch(). Voor legacy browsers hanteer je vaak een whitelist aan legacy browsers. Anders zal je een wildgroei krijgen aan combinaties van features die gecontroleerd moeten worden.
Of gaan we voor ieder fetch() een feature check maken of er misschien iemand met een 5 jaar oude browser zit?

isIE11() is makkelijker op te ruimen is dan supportsFetch()

Nee?

Of gaan we voor ieder fetch() een feature check maken of er misschien iemand met een 5 jaar oude browser zit?

Nee hoor, dat doe je gewoon eenmalig: if (!supportsFetch()) window.fetch = …;

Kan, maar in wat complexere applicaties waar je libraries, components deelt of meerdere teams aan werken dan ga je niet zomaar rommelen aan globals.

Het polyfillen van globals is compleet normaal en geen probleem maar ik ben benieuwd waar jij tegen aan gelopen bent.

Het polyfillen van globals is compleet normaal en geen probleem

Ik heb minstens 5 gevallen gehad waar het problemen met integratie van 'widgets' en andere ongein van derde partijen opleverde.

Wat veel beter werkt is een transpiler die referenties naar APIs die mogelijk gepolyfilled moeten worden (adhv bijv. het opgestelde browserslist profiel) compile-time vervangt door referenties naar poyfills die of de polyfilled API exporteren, of een passthrough naar de native API.

Prima — ponyfillen kan ook natuurlijk, is slechts een klein beetje extra code. Hoe dan ook, geen reden om niet voor feature detection te gaan wat mij betreft.

Inderdaad; in essentie ben je nog steeds per feature bezig. Alleen het aanspreekpunt ligt iets anders in elkaar.

Je hebt ook de zgn. 'cutting the mustard' aanpak. Dat is waar je een familie representatieve browser features gebruikt om te bepalen; "ok; jij bent een moderne browser. Jij niet." Dat is een redelijk goede aanpak als je moderne browsers een light-weight JavaScript implementatie zonder allerlei polyfills wilt bieden; en 'down-level' browsers de grotere build met alle polyfills serveert. (Die ze daarna nog steeds selectief kunnen activeren adhv feature-detectie; uiteraard.)

[Reactie gewijzigd door R4gnax op 3 januari 2023 14:29]

Maar voor oude browsers kunnen ze toch aanraden dat mensen Browservice gebruiken?
https://github.com/ttalvitie/browservice

Mijn ervaring is dat er niet voor alles feature detection bestaat.

Zo is er helaas geen feature detection voor nieuwe syntax bij de laatstste JavaScript versies, zoals bijvoorbeeld de nullish coalescing operator ?? en de optional chaining operator .?

Om dat op te lossen moet er daarvoor helaas aan user agent sniffing worden gedaan.

Om dat op te lossen moet er daarvoor helaas aan user agent sniffing worden gedaan.

Nee hoor.
Gewoon window.eval gebruiken en als dat een SyntaxError geeft, weet je dat de operator niet ondersteund is, en laadt je een alternatieve bundel JS in. Vereist wel weer dat je van een bootstrapping loader voor je JS bundels gebruikt maakt, die dat ook kan.

Misschien is dit geen optie voor Mozilla voor een of andere reden, maar kunnen ze niet de versie nummer gewoon overslaan, zodat de volgende versie na 109 direct naar 120 gaan?

Dat zou dit probleem dan toch verhelpen?

Of zouden een heleboel kritieke systemen en web software in de war raken dat absoluut die oplopende versie nummers nodig hebben?

[Reactie gewijzigd door TweetCu op 3 januari 2023 10:30]

Eigenlijk precies wat Microsoft gedaan heeft met Windows 10 . Windows 9 bestaat niet omdat veel brakke software kijkt of de OS-naam begint met 'Windows 9" voor detectie van Windows 95 en 98.

[Reactie gewijzigd door .oisyn op 3 januari 2023 09:57]

Dat lijkt me nogal sterk, want dan zouden ze Windows 11 ook hebben overgeslagen i.v.m. software die naar de 1 kijkt en Windows 1.0 detecteert. En Windows 2000 i.v.m. Windows 2.0.

[Reactie gewijzigd door TheVivaldi op 3 januari 2023 11:46]

Je argument gaat mank, Windows 1 en 2 software runt niet op Windows 10 en 2k.

Toch wel: https://www.youtube.com/watch?v=XvpkYENZhrM
Misschien niet alle, maar vanaf ongeveer het midden van de video kun je zien dat er wel wat software werkt.

Dan is het nog steeds geen valide argument. Hoe vaak denk je dat men Windows 1 en 2 software draaien? . Hetzelfde gaat niet op voor nieuwere software die nog steeds Windows 9x checks doen.

Windows 1 software draaide niet in 2; 1 en 2 software werkte niet in 3. 16bits Windows 3 software heeft gewerkt in tot Windows XP. De 32bits Windows 3 software (Win32s) heeft nog wel gewerkt in de 32bits versie van Windows, maar niet meer in de 64bits versies.
De Windows API die met 95 uitkwam (Win32c, vergelijkbaar met de Win32 van NT3) wordt nog steeds gebruikt in Windows, ook voor moderne applicaties. Dus veel software gemaakt voor Windows 9x werkt nog in Windows 11. Zo lang ze maar geen specifieke hardware checks uitvoeren (e.g. free diskspace/RAM, ...) of hardware drivers nodig hebben.
m.a.w. slechte Windows 1 en Windows 2 detectie is geen probleem waar Microsoft last van heeft.

[Reactie gewijzigd door elmuerte op 3 januari 2023 12:18]

https://www.youtube.com/watch?v=XvpkYENZhrM

Vanaf ongeveer het midden van de video zie ik toch echt wat 1.0-apps die gewoon werken op Windows 10.

Klinkt als een hoop onzin om eerlijk te zijn. Als je naar versies kijkt in windows als programma kijk je naar de interne versie. Die is 4 voor 95, en 4.10 voor windows 96), 5.0 voor 2000 en 6.0 voor xp. Vista 6.1, windows 7 is 6.2 , en 8 is 6.3. 10 is 10.

Ik vermoed dat er een andere reden voor is, 9 word wel vaker overgeslagen, er is immers ook een iphone 9.

Pas nu je argument eens toe op dit artikel.

"Klinkt als een hoop onzin eerlijk gezegd. Als je naar versies kijkt dan interpreteer je het hele nummer, en kijk je niet alleen waarmee hij begint".

Zoals ik al zei, brakke software. Die doen dus niet wat de bedoeling is . De verklaring komt van een Microsoft developer, maar is nooit officieel bevestigt. Hier een voorbeeld van code die het dus echt fout doet:
boolean isWindows9x = OS_NAME.startsWith("windows 9") || OS_NAME.startsWith("windows me");

[Reactie gewijzigd door .oisyn op 3 januari 2023 10:47]

Welke kritieke systemen kan jij bedenken, die een moderne browser nodig hebben, specifiek firefox, en geen feature detection toepassen, maar zich nog steeds baseren op een user agent, en bovendien een oplopend versienummer?

Voor die systemen blijft Firefox een jaar lang dezelfde (relatief recente) versie.

[Reactie gewijzigd door gorgi_19 op 3 januari 2023 09:53]

Persoonlijk geen enkele, maar dacht dat het interresant zou zijn als mensen zouden vertellen als ze bekend waren met wat belangrijke systemen of web software welk hierdoor negatief beinvloed zou worden.

Sommige oude sites die (vaak middels php) javascript/html uit serveert op basis van de useragent. Je kunt helaas niet veel anders in php, je zit niet in de browser. Gelukkig staat de backend en de frontend meer los van elkaar dan vroeger

Een goede en terechte workaround met een duidelijke einddatum, gezien Mozilla (voor die tijd) nooit een oneindigheid aan fout geconfigureerde websites kan laten corrigeren.

[Reactie gewijzigd door The Zep Man op 3 januari 2023 09:55]

Nu maar hopen dat Microsoft niet voor augustus/september 2024 met IE12 komt (er vanuitgaande dat Firefox zijn 1x per 4-weken schema aanhoudt.)
Anders gaat het weer fout.

IE bestaat niet meer.

Internet Explorer 11 has retired as of June 15, 2022

--https://www.microsoft.com...ad/internet-explorer.aspx

Ja en nee.

Er zijn nog genoeg versies van Windows in de omloop, welke niet met Edge, maar met IE 11 zijn uitgerust. En Microsoft geeft aan dat 2029 het laatste jaar is waar Microsoft support bied voor sommige LTSC versies.

Dus ja, Microsoft heeft 2022 als einde support IE 11 aangegeven. Maar tot 2029 zal het een zorgenkindje blijven.

Nou ben ikzelf niet zo onder de indruk van de Edge browser, maar het is wel beter dan IE 11.

Mijn reactie was mbt

Nu maar hopen dat Microsoft niet voor augustus/september 2024 met IE12 komt

Off-topic: Ik ben wel zeer enthousiast over Edge

Is IE niet gewoon vervangen door Edge?

IE is end of life, dus dat zal niet gebeuren. Support is al opgehouden voor de normale Windows OS'en. Edge is de standaard browser van Microsoft.

[Reactie gewijzigd door .oisyn op 3 januari 2023 09:54]

Sowieso checken voor User-Agent is niet de manier om dit tegenwoordig te doen. Veel browsers hebben UA spoofing.

Waarom zou dat een probleem zijn? Als je UA spoofing gebruikt weet je heel goed waar je mee bezig bent.

Ik heb hier zeker wat van gemerkt en vond dat ook raar gezien ik Firefox normaal gezien uiterst stabiel ervaar. Goed om te weten. Ga nu wel even kijken hoe onze useragent lib ermee omgaat

Daarom moet je als webbouwer dus aan feature detectie doen i.p.v. user agents parsen. Je weet nooit wat er in de toekomst gebeurd (welke browser, welke features etc.).

if "11" in useragent:
print("het is Internet Explorer 11 zeker weten!!")