Mozilla verwijdert aanbevolen veiligheidsextensie uit blogpost na kritiek

Firefox heeft de beveiligingsextensie Web Security uit een eigen blogpost verwijderd, nadat het deze daarin had aanbevolen. Na de publicatie kwam er kritiek, omdat de extensie de browsegeschiedenis van gebruikers zou bijhouden. De ontwikkelaar van de extensie bestrijdt dit.

De desbetreffende blogpost van Mozilla ging over het verbeteren van de privacybescherming van de Firefox-browser door het installeren van verschillende extensies. De organisatie noemt bekende namen als Privacy Badger, Disconnect en Decentraleyes, maar de vermelding van Web Security, een add-on met ongeveer 222.000 gebruikers, is inmiddels verdwenen. Dat gebeurde volgens Bleeping Computer nadat Raymond Hill, de ontwikkelaar van de extensie uBlock Origin, op Reddit te kennen had gegeven dat Web Security elke keer een POST-verzoek naar een externe server doet als een gebruiker een website bezoekt.

Vervolgens verschenen op het blog van de Duitse pentester Mike Kuketz soortgelijke berichten, waarin hij stelde dat de extensie inderdaad gevoelige gegevens over het surfgedrag van gebruikers via een onversleutelde verbinding doorstuurt. Zo zou de extensie een bezochte pagina doorsturen, samen met de daarvoor bezochte pagina. Die gegevens zelf zouden wel versleuteld zijn.

De ontwikkelaar van de extensie, Creative Software Solutions, laat in een reactie aan Bleeping Computer weten dat het de sites die een gebruiker bezoekt, controleert aan de hand van een zwarte lijst, waardoor 'communicatie tussen de cliënt en de server onvermijdbaar is'. Het bedrijf zou de datacollectie zo klein mogelijk houden en niet in logs vastleggen. Het wijst erop dat zijn servers in Duitsland staan en dat de bescherming van de AVG van toepassing is. In een reactie aan The Register laat de ontwikkelaar bovendien weten aan een nieuwe versie van de extensie te werken om te bewijzen dat alles naar behoren werkt.

Het bedrijf claimt verder dat Mozilla zijn extensie heeft geverifieerd. Een Mozilla-woordvoerder laat aan de site weten dat het de 'bezwaren uit de community' onderzoekt. De verwijzing naar de extensie zou als onderdeel van dit onderzoek zijn verwijderd. Soortgelijke gevallen deden zich eerder voor met extensies als Web of Trust en Stylish.

Beschrijving van de extensie, via Mozilla-add-ons

Reacties (59)

[Rob Wu]

Deze add-on en negentien anderen worden nu verwijderd uit AMO en spoedig uitgeschakeld bij de gebruikers die ze hebben geïnstalleerd.

https://bugzilla.mozilla.org/show_bug.cgi?id=1483995

Ik had naar aanleiding van de melding van Raymond de broncode geanalyseerd, en vervolgens naar vergelijkbare add-ons gezocht op AMO. Daaruit bleek dat er meerdere extensies waren die gegevens doorstuurden naar externe sites en ook in sommige gevallen de mogelijkheid had om op afstand code uit te voeren ("RCE").
In het specifieke geval die hier wordt genoemd (Web Security) werkte RCE niet omdat de makers fouten hadden gemaakt in de implementatie.
De makers lijken de moeite te hebben genomen om de daadwerkelijke functionaliteit te verhullen.

De blogpost corrigeren was relatief makkelijk, het zorgvuldig beoordelen van de situatie en de vervolgacties hadden iets meer tijd nodig.

[Reactie gewijzigd door Rob Wu op 22 juli 2024 21:15]

[The Zep Man]

De ontwikkelaar van de extensie, Creative Software Solutions, laat in een reactie aan Bleeping Computer weten dat het de sites die een gebruiker bezoekt, controleert aan de hand van een zwarte lijst, waardoor 'communicatie tussen de cliënt en de server onvermijdbaar is'.

Een grote rode vlag. Je kan natuurlijk ook die zwarte lijst distribueren. Dan heb je ook geen aparte add-on nodig, maar gooi je hem gewoon uBlock Origin in.

Even negerend dat een onveilige verbinding wordt gebruikt (dom, dom, dom) wordt hier echt geen rekening gehouden met het beperken van informatiestromen. Deze add-on zou ik met een grote boog vermijden.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 21:15]

[Blokker_1999]

Maar dan loop je achter de feiten aan, tenzij je computer elke 5 minuten gaat vragen of de lijst is bijgewerkt. Het feit dat ze geen https gebruiken is waar ik zelf meer over val.

[Xanaroth]

Elke 5min een update checken is anders (potentieel, surf-gedrag verschilt per persoon) een stuk minder frequent dan bij elke site een verzoek heen en weer te sturen. Minus de noodzaak om privacy gevoelige informatie heen en weer te sturen, en alle daarbij komende risico's.

Zowiezo verklaard dat niet waarom de *vorige* site ook bekend gemaakt dient te worden, enkel waar je heen gaat zou relevant moeten zijn voor de werking. Of waarom ze een nieuwe versie moeten maken om de veiligheid aan te tonen - als het echt veilig is dan hoeven ze ook geen nieuwe versie te maken na deze berichtgeving.

Dus zowel kwa werking als berichtgeving schreeuwt alles dat er iets niet klopt onder de motorkap.

[Reactie gewijzigd door Xanaroth op 22 juli 2024 21:15]

[mae-t.net]

De vorige site lijkt relevant omdat sommige fraude gebaseerd zou kunnen zijn op doorklikken.

[--Andre--]

Wat dacht je van cross site scripting attacks?

[Kenhas]

Kan me voorstellen dat het doorsturen van de vorige site, een extra controle is. Je wordt misschien van een wel kwaadaardige site doorgestuurd naar een site die (nog) niet op een lijst staat. Of omgekeerd, als ze vaststellen dat er honderden keren wordt doorgestuurd naar een kwaardige site vanop een niet gekend domein, kunnen ze controleren of de originele zelf kwaadaardig is

[3raser]

Dit is eenvoudig en snel te regelen door middel van een hash van de daadwerkelijk blacklist. Laat die hash iedere 5 minuten (of eventueel vaker) controleren en je hoeft de daadwerkelijke lijst alleen te downloaden als de hash wijzigt. Privacy gewaarborgd en dataverkeer geminimaliseerd. Win-win.

[Heidistein]

Of, als je geen zin hebt het wiel opnieuw te bouwen, kan je met de http Headers en een HEAD request even vragen hoe oud het bestand is

[3raser]

Er zijn ongetwijfeld vele manieren om tot dezelfde oplossing te komen. Het ging mij erom dat je eenvoudig en snel de lijst kan updaten zonder dat je hier enorm veel dataverkeer voor nodig hebt.

[jimshatt]

De Etag header is hier nuttig voor, maar het precieze mechanisme is niet belangrijk. Punt is dat ze dit anders hadden moeten oplossen.

[Phyxion]

Of gewoon gebruik maken van HTTP headers, daar zijn ze namelijk voor (en scheelt ook enorm aan bandwidth)

[Maurits van Baerle]

Dat is precies hoe Firefox het nu ook al doet met de standaard Phishing and Malware Protection. Tenzij deze extensie een betere manier gebruikt is die extra check dus overbodig.

[Henrikop]

Ik zeg, Bloom filter... prachtige methode.

[MSalters]

Nou ben je het wiel opnieuw aan het uitvinden. HTTP(S) heeft een "If-Modified-Since' optie. Dat voorkomt bovendien een roundtrip voor de hash value, dus je oplossing was niet eens minimaal.

[OddesE]

if-modified-since heeft ook zo zijn problemen want zowel servers als clients hebben nogal eens klokken die niet gelijk lopen etc. Een hash is een betrouwbaarder methode om te controleren of iets gewijzigd is, maar nog steeds niet waterdicht (hash collisions zijn onwaarschijnlijk, maar wel mogelijk). Maar in dit geval zou het wel goed genoeg zijn ja.

Anyway, de moraal is simpelweg: gebruik tried and tested spul dat goed genoeg is voor het doel. En specifiek hier: gebruik lokale validatie in plaats van centrale validatie zodat niet elk web bezoek naar een centrale server gestuurd hoeft te worden. Een blacklist is mogelijk maar we weten niet wat de server achter de plugin nu voor een algoritme gebruikt. Zou mooi zijn als hij de server ook open source zou maken (doch geen garantie).

[Reactie gewijzigd door OddesE op 22 juli 2024 21:15]

[MSalters]

Dan gebruik je eTag. Precies wat je zegt: gebruik "tried and tested", in plaats van zoals 3raser doet het wiel opnieuw uitvinden.

[OddesE]

Merk op dat 3raser nergens specificeert hoe die hash gecontroleerd moet worden. En etag wordt in de regel gegenereerd door een hash van de content te nemen. etag is dus gewoon een van de middelen die je kunt gebruiken om 3raser zijn idee uit te voeren. Er staat nergens dat hij het wiel opnieuw gaat uitvinden.

[tinustate]

Weet de beheerder van de blacklist niet welke hash bij welke url/domein hoort...
Dan is het makkelijk om bij te houden voor de beheerder welke sites iedereen bezoekt.
Weg privacy?
Whoops, de client gecontroleerd hier de blacklist natuurlijk lokaal.
Privacy is goed!

[Reactie gewijzigd door tinustate op 22 juli 2024 21:15]

[Jaerie]

@3raser had het in dit geval over een hash van de volledige lijst, die de server dan ook bijhoudt, zodat je snel kan controleren of de lijst is veranderd of niet. Dit gaat niet om gehashte entries van domein of iets dergelijks, heeft dus niet te maken met privacygevoelige informatie.

[tinustate]

Ik zou juist wel de entries/domeinen hashen, zodoende kan niemand zien welke url er op de lijst staat. Want anders veranderd iemand die kwaad wil gewoon z'n url en word hij niet meer geblacklist.
Google en andere doen dit ook en werkt prima zolang je je beperkt tot controleren domeinen/subdomeinen.

[Patriot]

Dat lijkt me weinig zin hebben, de gebruikers moeten de url die ze bezoeken kunnen vergelijken dus kan een kwaadwillende dat ook doen voor url's die ze beheren. Dat kun je niet voorkomen.

[OddesE]

Precies: eenmalig je eigen domein hashen met hetzelfde algoritme en je kunt eenvoudig met Ctrl+F een tekst search doen om te checken of jouw hash ook in de lijst staat.

Echter het helpt wel dat je niet zomaar kan zien welke andere domeinen er in staan. Dit kun je alleen ontdekken door ze allemaal te gaan checken. Dus in die zin is het netjes om het zo te doen, dan maak je misbruik van de lijst onwaarschijnlijker.

Vervolgens geef je elke client een eigen variant van de lijst (door per file een andere salt te gebruiken die ook in de file staat) en dan kun je ook niet zomaar onderling vergelijken.

[ImaPseudonym]

Ik zie het probleem niet zo van elke 5 minuten (of bij elke pageview) vragen of de lijst is bijgewerkt. Het alternatief is namelijk om bij elke pageview te vragen of de pagina die je gaat bezoeken wel okay is.

[casberrypi]

Omdat de lijst te lang is waarschijnlijk?

[Mijzelf]

Maakt niet uit. Je hoeft alleen de het versienummer of de hash van de lijst te vragen. Dat is genoeg om te weten of hij nog up-to-date is.

[Ed Vertijsment]

Daar heb ik een cron voor die elke x minuten een hostsfile download.

[stresstak]

Ook als die niet veranderd is ? Wat zonde.

[Ed Vertijsment]

Meh, die paar MB lig ik niet zo wakker van.

[GekkePrutser]

Nou zo vaak hoeft het ook weer niet. Met uBlock Origin werkt dit ook prima. Ik zie echt zelden reclame.

[casberrypi]

De enige correcte manier is niet de URL van de bezochte pagina sturen, maar een hash van die pagina.

Deze techniek wordt ook toegepast in de messaging apps. In grote telefoonboek van Whatsapp, Signal en Telegram staan geen telefoonnummers, maar hashes van telefoonnummers.

[mindcrash]

De ontwikkelaar van de extensie, Creative Software Solutions, laat in een reactie aan Bleeping Computer weten dat het de sites die een gebruiker bezoekt, controleert aan de hand van een zwarte lijst, waardoor 'communicatie tussen de cliënt en de server onvermijdbaar is'.

Een grote rode vlag. Je kan natuurlijk ook die zwarte lijst distribueren.

En Creative Software Solutions heeft daarbij blijkbaar ook niet helemaal stilgestaan dat de bedachte creatieve oplossing in strijd is met de huidige privacywetgeving in praktisch heel Europa.

[Reactie gewijzigd door mindcrash op 22 juli 2024 21:15]

[MSalters]

URL's zijn geen persoonsgegevens. Dus nee, dat is niet privacy-gevoelig.

De GDPR wordt door onbegrip regelmatig te breed uitgelegd . Zo is er de populaire gedachte "IP adressen zijn persoonsgegevens". Nee. IP adressen van gebruikers zijn persoonsgegevens. IP adressen van servers mogen gewoon openbaar in het DNS systeem staan.

[OddesE]

urls bevatten soms persoonsgegevens. Denk aan identificatienummers in de querystring. tel-nummers, mailto urls etc.

[MSalters]

Inderdaad, dat kan. Maar omdat het een uitzondering is hoef je generieke URL's niet als persoonsgegevens te behandelen. Uiteindelijk bevat de binaire representatie van pi ook alle denkbare persoonsgegevens

[OddesE]

Echter gaan er in de analytics wereld nu dus scripts rond die dingen die op persoonsgegevens lijken ([e-mail], user=iets, password=iets etc) uit de analytics data scrubben omdat niemand precies weet waar de rechter de grens gaat leggen. Je voorbeeld met Pi is grappig maar ik ben bang dat de rechter er wellicht anders tegenaan kijkt als blijkt dat er allemaal e-mail adressen in je database staan. De straffen op overtreding kunnen fiks oplossen dus de meesten willen gewoon geen risico nemen.

[Origin64]

IP adressen die tot persoonsgegevens te herleiden zijn zijn persoonsgegevens. Het hangt dus oa ook af van welke aanvullende informatie je hebt, naast die lijst IPs, of je de GDPR overtreedt of niet. (althans zo heb ik het begrepen)

[GekkePrutser]

Iets hoeft toch geen persoonsgegevens te bevatten om privacygevoelig te zijn?

Ik zou het ook niet prettig vinden als een bedrijf all mijn bezochte URLs mee krijgt. Immers is het herleiden tot een persoon erg eenvoudig met alle tracking shit van tegenwoordig.

[Blokker_1999]

Dat hoeft helemaal niet in strijd te zijn met AVG. Ik ken de extensie niet maar als deze om de jusite toestemmingen komt vragen en de eindgebruiker voldoende informeerd dan is er geen enkel probleem met de AVG.

[kodak]

Als je die stelling doet, kom dan ook met een onderbouwing. Hoe is het verboden? Want ik lees te weinig informatie om dat te kunnen suggereren of ontkrachten.

[YangWenli]

Als de extensie niet op GitHub staat niet installeren. Die regel werkt tot nu toe goed. Zodra mensen centjes willen verdienen gaat het vaak mis.

[jimshatt]

De client-code is waarschijnlijk wel open, maar wat er op de server gebeurt wanneer er data naartoe gestuurd wordt is niet te controleren. Daarom is communicatie met derde partijen altijd verdacht en moet je dit proberen te minimaliseren.

[62696e617279]

Dat is natuurlijk een leuk idee, maar zo zal het in de praktijk niet werken. De gemiddelde Chrome / Firefox / etc gebruiker gaat niet zijn of haar eigen extensies compileren. Een bedrijf kan altijd nog een sloot aan 'bonus' features in een extensie hangen in de store.

[OddesE]

Daarom zou een goede betrouwbare store een directe koppeling moeten hebben met de achterliggende repository.

Continous Delivery werkt al zo: je checked je code in die dan door een pipeline aan tools gaat die het linten, trans/compileren, unit tests uitvoeren, image bouwen, uitrollen op een kubernetes cluster etc. Wat we hier willen is iets vergelijkbaars waarbij de store afdwingt dat de code inzichtelijk is. Dat hoeft niet te betekenen Open Source (=== free) maar wel publiekelijk inzichtelijk. Dan heb je een betrouwbaar traject met auditing van alle wijziging etc.

Ik verbaas me er over dat overheden voor hun eigen software dit niet allang zo afdwingen.

[Raventhorn]

De ontwikkelaar van de extensie, Creative Software Solutions, laat in een reactie aan Bleeping Computer weten dat het de sites die een gebruiker bezoekt, controleert aan de hand van een zwarte lijst, waardoor 'communicatie tussen de cliënt en de server onvermijdbaar is'.

Communicatie tussen een cliënt en server is inderdaad onvermijdbaar, ergens moet de zwarte lijst vandaan komen. Je kan echter ook gewoon de zwarte lijst van de server ophalen, lokaal inladen en lokaal checken of de site die bezocht wordt daar in voorkomt... Daar is geen server voor nodig en hoeven ze ook je surfgedrag niet voor te weten.

Ik kan me voorstellen dat dat voor lichte apparaten met weinig opslag, geheugen of rekenvermogen wat lastiger wordt, zeker als de lijst groot is. Maar daar zijn ook wel weer oplossingen voor te vinden waar geen server voor nodig is...

[Zoop]

Ja, het enige voordeel wat ik kan zien in deze constructie is dat de cpu-load en opslag serverside zal zitten (is dat trouwens zo? als het alsnog lokaal processed wordt, dan slaat deze constructie helemaal nergens op), maar betwijfel me of dat tegenwoordig nog iets uitmaakt, hier staat wel meer dataverkeer en mogelijk een privacy leak tegenover.

[EraYaN]

Een lijst look-up is een stuk goedkoper dan een volledig HTTP verzoek opzetten. En schijnbaar dus ook nog de data door een "encryptie" halen. Nou dan is een lijstje doorzoeken vele malen sneller.

[Zoop]

Ik snap je niet helemaal, om die look-up te kunnen doen heb je toch minstens een http request nodig, hetzij om een lijst op te halen en zelf lokaal door te zoeken, of om een request te sturen zodat dit serverside gebeurt en simpelweg de lookup teruggeeft, hoe dan ook, in beiden gevallen zit je met een http request.

En of een lijstje doorzoeken velen malen sneller is, ligt natuurlijk sterk aan hoe groot die lijst is en wat er per lookup aan functies uitgevoerd wordt.

[EraYaN]

Die lijst veranderd echt niet iedere paar seconden. Dus die kun je gewoon eens in het kwartier bijvoorbeeld verversen.

En je moet wel een HEEEEEL grote lijst hebben om het langer te laten duren van een HTTP request. Zeg neem een EasyList bijvoorbeeld, vrij interessante en uitgebreide list, maar een lookup daarin kost niet bar veel, zelfs met alle wildcards er dergelijke. Als dat het wel zou doen waren alle adblockers onbruikbaar en die checken op een pagina een stuk meer dan alleen de URL.

[rctgamer3]

Even ter verduidelijking, alleen de verwijziging naar de add-on is verwijderd uit de blogpost omdat er een onderzoek gaande is, de add-on(s) in kwestie zijn nog beschikbaar op AMO (addons.mozilla.org) maar er zal vast snel actie ondernomen worden.

"Het bedrijf claimt verder dat Mozilla zijn extensie heeft geverifieerd." -- Hier is niets van waar. Er gebeuren wel automatische checks, maar dat staat niet gelijk aan goedkeuring.

[Reactie gewijzigd door rctgamer3 op 22 juli 2024 21:15]

[Giesber]

"Het bedrijf claimt verder dat Mozilla zijn extensie heeft geverifieerd." -- Hier is niets van waar.

Dat is wel waar, want een extensie wordt bij het uploaden naar Mozilla automatisch gereviewed. Dat wordt echter niet door mensen gedaan, en zal ook nog veel malware doorlaten, maar het is wel degelijk een simpele vorm van verificatie.

Kortom, die zin is geen leugen, maar er staat eigenlijk ook niets van betekenis in.

[rctgamer3]

Add-ons worden inderdaad automatisch gesigned en gepubliceerd, dat klopt. Maar neemt niet weg dat add-ons na publicatie gewoon alsnog worden gereviewed op code-kwaliteit (o.a. door mij). Er is alleen sinds dit nieuwe systeem live is zo ongelofelijk veel meuk-add-ons gesubmit dat dat proces een beetje onoverzichtelijk begint te worden qua aantallen.

[Reactie gewijzigd door rctgamer3 op 22 juli 2024 21:15]

[imqqmi]

Daar gebruik ik een firewall voor: pfsense met ngblocker.

Bovendien is het nu met extensies zo dat deze opgekocht kunnen worden door (advertentie) bedrijven die het minder goed met je voor hebben.
Tegen de tijd dat het bekent wordt is het kwaad al geschied en zijn je gegevens allang doorverkocht. Ik minimaliseer het aantal extensies totdat firefox of welke browser bouwer kan garanderen dat extensies betrouwbaar zijn en blijven. Hetzelfde geldt voor apps.

[Origin64]

Sommige van die beveiligings extensies zoals ublock origin zijn zo gebouwd dat hij een blacklist opbouwt vanuit meerdere publieke bronnen en op jouw pc verbindingen blokkeert. Het is technisch gezien niet nodig om jouw surfgedrag naar een server te uploaden. Zolang je automatische updates voor extensions niet aan hebt staan, kan iemand die een goed gebouwde extension opkoopt, niets van jou inzien, behalve bijv. wanneer je de extension hebt geinstalleerd.

Uiteraard kun je dit alleen 100% garanderen door ook echt de source code door te lezen, maar die gast van ublock origin lijkt wel te vertrouwen.

Anders kun je ook altijd nog een pi-hole neerzetten.

[Reactie gewijzigd door Origin64 op 22 juli 2024 21:15]

[kodak]

Als je niets wil aanraden waar twijfel over is, waarom is er dan geen twijfel over de andere extenties die ze ook promoten? Blijkbaar is er pas voldoende twijfel als iemand beweringen doet? Dat is vreemd. Want waarom is er dan genoeg vertrouwen als niemand twijfel uit? Zoals al werd opgemerkt, de extentie voldeed bijvoorbeeld aan voorwaarden om het te kunnen publiceren.

edit:
ik stel een paar hele normale vragen en kritische opmerkingen bij hoe hier wordt omgegaan met vertrouwen in de software en deze veiligheidsextensie. Aan diegene die het daar niet mee eens zijn de vraag om kenbaar te maken waarom dat ongewenst is of niet relevant. Als we met zijn allen klakkeloos software betrouwbaar achten en als zo sterk gaan twijfelen bij het minste of geringste belangstellende opmerking wat bepaalde communicatie betekend dat het meteen maar niet meer genoemd mag worden dan lijkt me dat geen gezonde vorm van beveiligen. En wie meent dat dit een klacht is tegen onderzoek of vragen: nee dus. Dit heeft en groot Hyacint Bucket gehalte. Iedere voetganger die in zicht was was al een excuus om maar heel voorzichtig te gaan doen.

[Reactie gewijzigd door kodak op 22 juli 2024 21:15]

[jimshatt]

dat Web Security elke keer een POST-verzoek naar een externe server doet

Daarom?

[kodak]

Ik hoor Hyacint Bucket: pas op een voetganger, rij voorzichtig! Ondertussen stond de voetganger een paar honderd meter verderop in de straat stil en was met iemand aan het praten. Pas op gevaar, de situatie is meteen onbetrouwbaar omdat er misschien iets kan gebeuren. En omdat iemand die mening heeft is het ook meteen reden om uit te gaan van het ergste en dus heel voorzichtig te gaan doen.

Bijna iedere app bijna iedere website en bijna ieder stuk software doet wel opvallende communicatie waar de gebruiker niet snapt waar het voor bedoeld is. Zelfs beveiligingstools. Meestal beschouwen we dat als volkomen normaal gedrag, maar een enkeling zet er vraagtekens bij. Prima, heel goed als we ons eens wat meer gaan afvragen waar het allemaal voor nodig is! Juich ik graag toe om inhoudelijk kritisch te zijn en vragen te stellen. Maar het is behoorlijk hypocriet om software waarover niemand opmerkingen plaatst dan maar als aanbevelingswaardig en betrouwbaar te beschouwen en wel aan te bevelen en software waarover wel kritische vragen worden gesteld omdat er iets niet duidelijk is dan maar meteen te bestempelen als onbetrouwbaar en niet aanbeveligswaardig tot onderzoek is afgerond. Dat is willekeur en meten met verschillende maten. Want die software waarover geen kritiek is zie ik niemand bewijs leveren dat die daardoor wel betrouwbaar is. Als je zo makkelijk ergens vertrouwen in hebt of wantrouwig van wordt dan lijkt me iets grondig mis met de wijze waarop we vertrouwen of wantrouwen. Maar o wee als er kritiek is op hoe makkelijk we iets vertrouwen en in twijfel lijken te trekken dat iemand software aan het wantrouwen is.

[Reactie gewijzigd door kodak op 22 juli 2024 21:15]

[jimshatt]

Het verschil met de extensies waarop geen kritiek is, in deze set aanbevelingen, is dat deze extensies geen data versturen. Daarnaast is de broncode voor al deze extensies open, voor zover ik kan zien (ook voor degene die bekritiseerd wordt). Het is dus geen kwestie van niet vertrouwen omdat ergens kritiek is geleverd en de rest per definitie wel.

Wijzen op andere software die ook opvallende communicatie hebben is geen reden om deze software dan ook te vertrouwen (whataboutism). Betekent ook niet automatisch dat deze software malafide intenties heeft, maar het lijkt mij heel gezond om even kritisch te kijken of die communicatie wel echt nodig is.

[kodak]

Dat de andere extensies geen data versturen heb ik nog nergens uit kunnen opmaken. Dus tenzij daar bewijs voor is kan ik dat niet meetellen als valide argument om die extensies wel te vertouwen. Daarbij gaat het vertrouwen niet om wat de software specifiek niet doet maar of het in het alleen doet wat acceptabel is. En ook daar heb ik nog geen onderzoek van gezien. En daar komt dan open source als afgument. Ben ik het mee eens dat het kan helpen. Maar helaas, dat de broncode van al de extensies open source is is hier geen houdbare verdediging. Die extensie waar nu geen vertrouwen in is was ook open source. Stellen dat je met opensource minder risico kan lopen is slechts hoop. Maar hoop wijzigt niets aan het risico. De kans neemt alleen af als iemand er daadwerkelijk naar gekeken heeft en ook dat blijkt uit niets. Sterker nog, waarschijnlijk is die extensie waar nu geen vertrouwen meer in is straks als enige zeker bekeken op fouten.

De verwijzing naar andere software die bijvoorbeeld ook aan call home doet is in de context dat men dat in het algemeen ook om onduidelijke redenen maar lijkt te vertrouwen. Ik stel niet dat dergelijk vertrouwen goed is of dat de extensie waar kritiek op is dan ook maar vertrouwd moet worden. In tegendeel.

Als iemand software wil vertrouwen dan verwacht ik daarvoor goede argumenten en als iemand software niet wil vertrouwen ook. Maar die argumenten zijn er vaak niet. Dat je ergens moet beginnen, prima. Zonder risico nemen is er stilstand. Maar die situatie moet niet verward worden met vertrouwen, die situatie is eigenlijk slechts hoop dat het te vertrouwen is en dat er niets mis is. Dus op een moment als deze waarin weer lijkt dat het vertrouwen op weinig tot niets gebaseerd is vind ik het gepast om daar kritiek op te geven. Hoop is geen goed uitgangspunt om maar te denken dat je die software kan aanbevelen. Daar is deze extensie het voorbeeld van.