Google komt met fork van OpenSSL genaamd BoringSSL

Google is gestart met de ontwikkeling van een fork van OpenSSL, onder de naam BoringSSL. De internetgigant stelt dat het een aangepaste versie nodig heeft van de cryptografische software voor zijn eigen producten, zoals Android en Chrome.

De start van het BoringSSL-project werd door Google-ontwikkelaar Adam Langley aangekondigd op zijn blog. Inmiddels heeft het bedrijf al broncode online gezet. Op termijn moet de ontwikkelde code worden verwerkt in het Chromium-project; het opensourceproject dat Google heeft opgezet voor de ontwikkeling van zijn webbrowser. BoringSSL, waarvan de naam nog niet vaststaat, is een aangepaste versie van OpenSSL waarin Google verscheidene patches heeft doorgevoerd. Volgens Langley zijn deze aanpassingen nodig voor producten zoals Android en Chrome.

Aanvankelijk baseerde Google zijn ssl-implementaties op de software van OpenSSL met daarbovenop zijn eigen patches, maar dit zou niet langer praktisch zijn: Android en Chrome zouden steeds meer custom software vereisen, terwijl de door Google aangeleverde patches lang niet altijd werden verwerkt in de releases van OpenSSL. Door de toenemende complexiteit van deze manier van software ontwikkelen is gekozen om met een fork van OpenSSL verder te gaan, die met name bedoeld lijkt te zijn voor gebruik in Googles eigen producten.

OpenSSL kwam onlangs in het nieuws door de Heartbleed-bug, die ervoor zorgde dat een aanvaller delen van het geheugen van een server kon uitlezen. Daardoor konden privacygevoelige gegevens worden onderschept. Eerder deze maand werd nogmaals een bug ontdekt, die een man-in-the-middle-aanval mogelijk maakte. Veel grote sites en softwarediensten werden getroffen door de bugs, waaronder Android en Chrome van Google.

Reacties (79)

[Loller1]

Weet je, open source is fijn enzo, maar is het punt ervan niet juist dat je dingen deelt, iets constant blijven forken lijkt me zeer onwenselijk, tenzij het originele project natuurlijk is stil gevallen...

[Plofkotje]

Als je de staat van het OpenSSL project ziet, met bug reports in hun bugtracker die al jaren niet opgelost worden, een fout zoals Heartbleed in de code, de totaal onleesbare manier waarop ze de code in elkaar flansen, support voor systemen die al eeuwen niet meer gebruikt worden maar wel de code onleesbaar maakt en waarvoor hele routines herschreven moeten worden die je op elk normaal OS in de standaard library vindt, kun je er wel vanuit gaan dat het orginele project stil is gevallen..

Een hoop bugs die ze in LibreSSL pletten (de OpenBSD fork) worden in de OpenSSL bugtracker terug gevonden en dan zijn ze ergens begin 2010 gevonden. Persoonlijk moedig ik het alleen maar aan dat er meer ogen op de OpenSSL code vallen, want OpenSSL is echt in erbarmelijke staat qua code en onderhoud. Het enige waar ze actief aan lijken te werken is OpenSSL FIPS (OpenSSL Software Foundation doet meer aan FIPS consultancy dan aan het onderhouden van hun project) en ernstige bugs.

[Reactie gewijzigd door Plofkotje op 23 juli 2024 11:48]

[mr_greenguy]

Ja spijtig dat google niet gewoon gaat meewerken aan de libreSSL fork. Zou stukken productiever zijn.

[Plofkotje]

De reden dat Google niet verder gaat met LibreSSL is omdat LibreSSL compatible wilt blijven met de OpenSSL ABI en een drop in replacement wilt worden, en Google daar niet zoveel behoefte aan heeft en liever gewoon alles eruit sloopt wat ze niet meer nodig hebben, en past dan liever gewoon hun software die ervan gebruikt moet maken aan.

Het gaat LibreSSL om nog zo veel mogelijk compatible te blijven en het vervangen van OpenSSL zo makkelijk mogelijk te maken, Google gaat liever voor een efficiëntere oplossing.

[DoFken]

Dat staat toch net in het artikel? De patches die Google voorziet worden niet altijd in OpenSSL opgenomen, dus dan vind ik het begrijpelijk dat ze hun eigen versie gaan onderhouden.

Ik ben alleen benieuwd, als die nu vooral op de google producten gericht is, wat de opensource-wereld er zélf zal aan hebben en hoe deze versie door derden nuttig kan gebruikt worden.

[Umbrah]

Dat zou hier dan de reden ook van zijn, OpenSSL zal in google's opzicht waarschijnlijk te veel op desktop/server richten qua features/optimalisatie, terwijl google "hooks" wil voor sandboxes, en low-power optimalisaties... het is een kwestie van de optimalisatie & innovatie kunnen bepalen wat bij veel OSS producten ontbreekt. De UI van Libre-office, bijvoorbeeld is voor meer en meer mensen niet voldoende, OpenSSL is nu niet voldoende, X.org is door veel mensen al als "meh" benoemd, GMP als arithmetics module heeft zo z'n criticasters (mpir doet meer & sneller en optimaliseerd beter), en zo kan je doorgaan...

FOSS is juist bedoeld om forken mogelijk te maken als de koers je niet aanstaat; het Tanenbaum-torvalds debate zie je nu nog steeds de uitwerking van, Linux wordt door veel bedrijven als een te zware/logge architectuur gezien dus zie je de PS4 en AMD ineens gigantisch op BSD hameren, QNX is nooit echt klein geweest, en de mach-kernel hoef ik denk ik niet eens te noemen.

Zelfs linux zelf heeft nooit echt commercieel succes "in het zicht" gekregen totdat er een bedrijf langs kwam en zei: die GNU componenten die het geheel gnu/linux maken zijn nogal "meh", en vervolgens ripten ze die er uit en hadden we ineens een Linux distributie genaamd Android.

Over 5 jaar denk ik dat we uiteraard nog steeds wel gnu/linux distro's zullen zien, maar misschien ook wat meer gnu/bsd's; en mogelijk zelfs linux distro's zonder de gnu kanten... of "complete-renewed" gnu-linuces. Wayland/MIR, dat soort dingen...

Forken = innovatie.

[Verwijderd]

OpenSSL had te weinig onderhoud. En dit is nu sinds kort weer veranderd. Alles is dus beter als dat het eerst was. Hoezo negatief bericht dan? Daarnaast kunnen forks elkaar code ook toepassen en lenen. Je kan gewoon bij elkaar in kijken en bij elkaars bug trackers.

Een fork heeft inderdaad soms nadelen waarop jij doelt. Maar dat is niet altijd zo. Zoals jij zegt: Het originele project was inderdaad dood gevallen en dus een fork prima wenselijk of een goede funding. Beide zijn gedaan.

[Dreeass]

Waarom gaan ze niet samenwerken met de mensen van OpenBSD die nu aan het werken zijn aan LibreSSL, ook een fork van OpenSSL?

[MBV]

ArsTechnica gaat daar iets verder op in:

http://arstechnica.com/se...openssl-called-boringssl/

Kort gezegd gaat Google optimaliseren voor embedded toepassingen, waar LibreSSL een drop-in replacement wil zijn voor OpenSSL. Google doet aanpassingen aan de API's, LibreSSL alleen aan de kern. En Google zal wijzigingen van LibreSSL waarschjinlijk gewoon overnemen.

[Verwijderd]

Zoals ik het lees is het alleen bestemd voor Google intern, de API is immers niet stabiel en wordt volledig gecontroleerd door de behoeftes van de "Clients" van Google: Android en Chrome.

"There are no guarantees of API or ABI stability with this code: we are not aiming to replace OpenSSL as an open-source project,"

Daar kun je als 3rd party ontwikkelaar natuurlijk niet zoveel mee, een API die niet stabiel is. Beter gebruik je dan LibreSSL, dat op basis van een open API werkt en niet de closed google controlled API zoals bij BoringSSL. Het is dus juist niet een "drop-in replacement voor OpenSSL" zoals je hier boven schrijft en mijns inziens met +2 verkeerd beoordeeld wordt.

Waarom zet Google het dan op het net? Geen idee wellicht overrompeld door het LibreSSL initiatief?

[Reactie gewijzigd door Verwijderd op 23 juli 2024 11:48]

[Rafe]

Omdat ze dan weer een set patches ten opzichte van LibreSSL moeten onderhouden, nu kunnen ze hun eigen koers varen. Om compleet te citeren van Langley's blog:

There are no guarantees of API or ABI stability with this code: we are not aiming to replace OpenSSL as an open-source project. We will still be sending them bug fixes when we find them and we will be importing changes from upstream. Also, we will still be funding the Core Infrastructure Initiative and the OpenBSD Foundation.

But we’ll also be more able to import changes from LibreSSL and they are welcome to take changes from us. We have already relicensed some of our prior contributions to OpenSSL under an ISC license at their request and completely new code that we write will also be so licensed.

[Verwijderd]

Daar hoeven ze toch niet voor te open sourcen? Er is geen enkel nut om een library die bedoeld is voor Google intern (Chrome/Android, API verandert onder regie van Google) te open source voor anderen. Het enige nut is voor Google op basis van security: codereview door derden.

[Rafe]

Samenwerken met gerelateerde projecten idd, en het laten zien dat ze niets te verbergen hebben.

[m-m]

Waarom zet Google het dan op het net? Geen idee wellicht overrompeld door het LibreSSL initiatief?

Mja, ik denk dat het ook wel een rol speelt dat het weliswaar van de licentie striktgenomen niet hoeft maar dat het ze toch wel een boel goodwill in de opensource-wereld kost als ze het niet doen. Kan me bijvoorbeeld voorstellen dat ze graag een goede samenwerking met de OpenSSL/LibreSSL teams willen en dat het gesloten houden van hun eigen fork daar niet aan zou bijdragen.

En uiteraard het klassieke argument dat door derden naar hun code te laten kijken de veiligheid vergroot wordt.

[Verwijderd]

Misschien een hele rare vraag hoor, maar is niet verstandig om broncode van versleutelingssoftware binnenshuis te houden?

[Verwijderd]

Dat kan verstandig zijn als je onvoldoende vertrouwen hebt in het versleutelalgoritme enof de implementatie (Security by obscurity). Daarnaast zou het verstandig kunnen zijn indien je er een concurrentievoordeel uit denkt te kunnen halen.

Edit: het nadeel van het binnenshuis houden is dat het onafhankelijke externe audits bemoeilijkt.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 11:48]

[Rafe]

Aanvullend op 'security through obscurity', de principes van Kerckhoffs (in 1883 opgeschreven):

1. The system must be practically, if not mathematically, indecipherable;
2. It must not be required to be secret, and it must be able to fall into the hands of the enemy without inconvenience;
3. Its key must be communicable and retainable without the help of written notes, and changeable or modifiable at the will of the correspondents;
4. It must be applicable to telegraphic correspondence;
5. It must be portable, and its usage and function must not require the concourse of several people;
6. Finally, it is necessary, given the circumstances that command its application, that the system be easy to use, requiring neither mental strain nor the knowledge of a long series of rules to observe.

De broncode hoef je niet te publiceren, maar je kan er vanuit gaan dat de vijand er toch wel achterkomt hoe het werkt - bijvoorbeeld door decompilatie. Dan moet het dus nog steeds veilig zijn.

[koelpasta]

Punt 1 gaat linea recta in tegen punt 2.
Iets dat in de praktijk on-ontcijferbaar is is gewoon een vorm van geheim.

[zarex]

Je vergeet hierbij het verschil tussen de software waarmee je versleuteld en het versleutelde bericht zelf.

Als de sourcecode van de software in handen van anderen komt mag het niet zo zijn dat versleutelde berichten zonder de sleutel te ontsleutelen zijn.

[belal]

Juist niet, open source heeft meer mensen die naar de code kijken en fouten er uit halen.

Overigens zie ik het probleem niet van een fork door Google. In dit geval doen ze dat vooral om te zorgen dat hun eigen patches er standaard in zitten en ze dus niet iedere keer een nieuwe patch hoeven te maken als er een nieuwe versie is van openssl.

Verder houden ze de bugfixing van openssl vast in de gaten om die bugs er bij hun ook uit te halen...

[svenM]

In theorie zijn er meer mensen die er naar kijken. Maar dat lost niet altijd alles op. Kijk maar naar openssl

[Gomez12]

Juist niet, open source heeft meer mensen die naar de code kijken en fouten er uit halen.

Ik zou toch onderhand echt wel denken dat mensen in de gaten hebben dat dit enkel maar tegen OS werkt.

De white hatters die zijn het niet / zitten in tunnelvisie waardoor ze het missen.
De black hatters profiteren ervan.

Het is namelijk zo dat er theoretisch meer mensen naar de code kunnen kijken en fouten eruit halen, praktisch gebeurt dit op een zeer kleine schaal

[Triblade_8472]

Dat heet closed source en dan is er de vraag of dat mag van de OpenSSL licentie.

Daarnaast wil men er graag voor kiezen om geen security by obscurity te plegen. (al hoewel ik daar echt wel voordelen in zie (ja ook nadelen))

Het punt voor OpenSSL (forks) is of het uitmaakt dat het open source is. Als je een goed product hebt met een trapdoor encryptie dan geeft het niks dat men de code kan lezen.

[Room42]

Nee, want als het goed is, staan er in de broncode geen geheimen. Als dat wel zo is heet dat 'security by obscurity', dan wordt er dus kunstmatig iets 'veilig' gemaakt.

[Sfynx]

Misschien een hele rare vraag hoor, maar is niet verstandig om broncode van versleutelingssoftware binnenshuis te houden?

En dan erop vertrouwen dat de software alleen doet wat de afdeling marketing zegt dat het doet?

[hardwareaddict]

Nu daarover is geen onduidelijkheid.

Want SSL-met-gat-erin, nog een vertaling van boring-ssl, laat toch duidelijk aan de naam zien wat het is....

[svennd]

Ik heb liever dat een bedrijf een open initiatief helpt dan zelf een eigen fork bouwen ... dit zorgt ervoor dat er 2* zoveel code is, die toch hetzelfde doel heeft.

[Mar2zz]

Er staat in het artikel dat google dat deed; patches leveren aan openssl. Maar zij implementeerden niet alles. Het is dan logisch voor google om te forken dat geeft minder werk. Daarnaast blijft t open source dus kan openssl meeliften op eventuele patches van google. T initiatief om code te implementeren en daarmee workload komt dan bij openssl te liggen.

[elmuerte]

Google had ook OpenSSL kunnen sponsoren zodat het OpenSSL niet uit slechts een parttimers bestond.

[jurroen]

Je hebt een goed punt. Persoonlijk denk ik wel dat ze dan beter manuren kunnen doneren dan financiële middelen. Er zitten teveel bugs en onlogische code in OpenSSL op het moment. Ik denk dat als je geld sponsort en dezelfde devvers er dan full time aan gaan werken dat de kwaliteit van code niet per definitie verbeterd.

Vanuit dat oogpunt kan het denk ik geen kwaad om te forken. OpenSSL kan die patches meenemen, hoewel ze om mysterieuze redenen dat soms botweg weigeren.

Persoonlijk, als ik erom zou wedden, zou ik mijn geld inzetten op LibreSSL. Met de 'rampage' hebben ze al ontzettend veel werk verzet en blijven doorgaan. Het huidige plan is om de eerste versie mee te shippen met de nieuwe OpenBSD, die op 1 november uit zou moeten komen. Daarna willen ze het gaan porten naar andere OS', zoals bijvoorbeeld Linux.

In de tussentijd ben in aan het spelen met PolarSSL. Heeft een stuk minder vulnerabilities, of in ieder geval, een stuk minder 'out in the open' vulnerabilities. Er is een speciale fork van 'nginx' waar ik nu mee proefdraai. De tijd zal leren hoe het verder gaat!

[aval0ne]

Ze geven al alle patches aan openssl, wat wil je nog meer?

[Rvanlaak]

Sterker nog; het artikel geeft aan dat Google patches zal blijven leveren aan OpenSSL.

[alt-92]

En als dat open initiatief niet of niet tijdig wat met jouw code doet, wat dan? Blijf je zitten wachten of ga je een actiever ontwikkelbeleid hanteren op je fork?

Gentlemen, place your bets.

[halofreak1990]

Dan heb je het verkeerde initiatief. LibreSSL is al veel verder met het integreren van een aantal Chromium patches maar wordt door iedereen buiten OpenBSD klaarblijkelijk genegeerd.

[Adm.Spock]

Die gasten van LibreSSL richten zich vooralsnog alleen op de BSD distributies. En wat dat betreft zijn ze op het moment vooral nog bezig om de support voor antieke OS'en eruit te slopen.

[halofreak1990]

En wat dat betreft zijn ze op het moment vooral nog bezig om de support voor antieke OS'en eruit te slopen.

En terecht; we leven immers niet meer in de middeleeuwen. Niemand met gezond verstand gebruikt die ouderwetse systemen nog, en de backwards-compatibility implementatie van OpenSSL is een van de vele veroorzakers van de ellende.

[arjankoole]

Dat is veel te kortzichtig. Er zijn legio plekken waar unix varianten van tien jaar geleden draaien, naar volle tevredenheid en functioneren. Het gaat in dergelijke omgevingen om betrouwbaarheid en stabiliteit, niet om 'modern doen'

[Adm.Spock]

Jup, dus die Unix varianten mogen blijven, maar support voor VMS, Netware en OS/2 mag toch wel 's afgelopen zijn?

[belal]

Dat zou kunnen als alle patches die Google voorstelt ook in de openssl code zouden landen, doordat dat niet gebeurt moet google telkens weer een nieuwe patch maken en kost het ze dus veel tijd en geld.

[gjmi]

Het probleem is juist dat ze blijkbaar niet exact hetzelfde doel hebben. Volgens het artikel zijn er patches van Google die niet door openSSL worden overgenomen.

[Verwijderd]

Ik heb liever dat een bedrijf een open initiatief helpt dan zelf een eigen fork bouwen

Het staat het open initiatief natuurlijk vrij om de gemaakte wijzigingen in de fork terug te porten naar het origineel. Het is ook zeker niet ongewoon dat een fork uiteindelijk weer samengaat met het origineel.

De tijd zal het in dit geval leren.

[ieperlingetje]

Zou men met het uitbrengen van een eigen fork (en dus meer fragmentatie) er ook niet voor willen zorgen dat de ssl library veiliger wordt? Stel dat er een lek gevonden wordt in libressl wil dat niet meteen zeggen dat er ook een lek zit in in boringssl, waardoor de impact bij het vinden van een lek kleiner is (wat niet het geval was bij heartbleed).

[Verwijderd]

BoringSSL is bestemd voor intern gebruik door Google, er zitten Android/Chrome specifieke calls in de API en de API is niet stabiel en verandert onder de behoefte van Google alleen. Het is dus geen drop-in replacement voor OpenSSL functionaliteit; de API is geschreven naar Google Android en Google Chrome en de governance van de API ligt ook bij Google intern.

Patches van OpenSSL worden door Google zelf aangebracht in hun Boring SSL library, waarschijnlijk gaan ze nu ook het zelfde moeten doen voor patches van LibreSSL.

De reden dat Google het online zet heeft volgens mij meer met security te maken: code review door derden. En wellicht om het LibreSSL initiatief te frustreren want veel mensen denken dat BoringSSL net als LibreSSL een drop-in replacement voor OpenSSL is maar dat is dus niet zo.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 11:48]

[Mathijs]

En waarom "Boring"SSL? Zou wel fijn zijn als ook even te lezen was waarom ze zo'n naam bedenken.

[Avathar]

LOL profetisch: een medewerker van Google die Langley heet
https://en.wikipedia.org/wiki/Central_Intelligence_Agency
"The Central Intelligence Agency (CIA) is one of the principal intelligence-gathering agencies of the United States federal government. The CIA's headquarters is in Langley, Virginia"
Hehehe je weet gewoon dat als google iets maakt er een NSA backdoor in zit.

[RoestVrijStaal]

Ach, zolang voor de externe ontwikkelaar er amper duidelijke documentatie is om de library in zijn product te gaan gebruiken, maakt het geen sikkepit uit hoeveel forks er van OpenSSL zijn en gaan komen.

En aangezien Google deze fork meer speciaal voor haar producten heeft gemaakt dan dat het een project op zichzelf is, zal het een van de laatste keuzes aan SSL-libraries voor je eigen applicatie zijn

[aileron]

Lekker iedereen z'n eigen fork maken van OpenSSL, boringSSL, LibreSSL. Hoe lang is het straks wachten op incompatibilities?

[Amiga3000]

ClosedSSL was beter geweest.

[aileron]

Ik snap je sarcasme, maar om eerlijk te zijn is opensource ook niet altijd zalig makend. Dat staat los van het feit dat het nog steeds 10 keer beter is dan closed source.

[notsonewbie]

Bold! nog al een risico als je dan als bedrijf gehackt wordt en je chromium gebruikers an masse de l&l zijn inzake bijv. telebankieren en aankopen op het www.

In de USA heb je dan een class-act aan je kont en kan je failliet gaan.

[Reactie gewijzigd door notsonewbie op 23 juli 2024 11:48]

[belal]

En Microsoft met zijn eigen closed source openssl implementatie heeft dit issue niet dan.

Sorry, maar om dit bold te noemen is wat kortzichtig.

[arjankoole]

Microsoft gebruikt geen OpenSSL, Mozilla ook niet. (Mozilla gebruikt hun eigen SSL implementatie: NSS) afaik geld een soortgelijk verhaal voor safari.

[Whatson]

Nee. http://blogs.technet.com/...tbleed-vulnerability.aspx

[jaapzb]

Hoezo, ze gebruikten sowieso al OpenSSL, dus als ze zelf meer tijd gaan steken om hun eigen fork veiliger te maken, kan het alleen maar beter worden.

[!nFerNo]

Ze kunnen natuurlijk ook meer tijd gaan steken in OpenSSL. Ik snap het niet goed waarom er een fork komt.

Artikel eens wat wakkerder gelezen. Blijkbaar werden bijdrages van Google niet altijd aanvaard, de vraag is natuurlijk waarom dat gebeurde.

[Reactie gewijzigd door !nFerNo op 23 juli 2024 11:48]

[Pendaco]

Artikel eens wat wakkerder gelezen. Blijkbaar werden bijdrages van Google niet altijd aanvaard, de vraag is natuurlijk waarom dat gebeurde.

Dat staat in het originele artikel

We have used a number of patches on top of OpenSSL for many years. Some of them have been accepted into the main OpenSSL repository, but many of them don’t mesh with OpenSSL’s guarantee of API and ABI stability and many of them are a little too experimental.

[aval0ne]

Volgens mij weet je niet wat een class act betekent. Het slaat in deze context nergens op.

[notsonewbie]

Jawel, was echter met mijn hoofd bij een ander topic, overigens is een class act in de zin van bedrijven, omzet, personeel e.d. opgeheven.(Uiteraard...) wij in NL volgen wel...)
"The CLASS Act was repealed January 1, 2013"

Ik doel op een groep mensen die een law suite tegen google kunnen doen, een "class action suit".
Als door dat SSL, ondanks e.d., er meer dan 5 miljoen dollar gejat gaat worden of anderzins verdwijnt.

[Reactie gewijzigd door notsonewbie op 23 juli 2024 11:48]

[Zenomyscus]

In de USA heb je dan een class-act aan je kont en kan je failliet gaan.

Het scheelt dat Google genoeg geld heeft om flink te lobbyen en in dat geval gewoon een afgesproken bedrag gaat uitkeren. Al heb ik er wel redelijk vertrouwen in dat Google competent genoeg is om het gewoon zinnig te ontwikkelen.

[army]

Dat vertrouwen dat ze competent zijn heb ik helaas niet gezien het feit hoe oa Chromium bv ingetrokken certificaten behandeld. Als je populair bent dan kan het zijn dat je certificaat voor max 2,5 dag door Chromium cq Chrome als niet veilig wordt bestempeld en daar wordt het certificaat weer als "veilig" bestempeld helaas.

[Tonko Boekhoud]

Gut, welk woordenboek is dat?

In dat van mij wordt boring vertaald met saai. En dat zal wel zijn in de betekenis van saaie, begrijpelijke code die niet voor Heartbleeds zorgt.

[gjmi]

Het blijft open source, dus het zal wel meevallen met die class-act.

[notsonewbie]

Het blijft open source, dus het zal wel meevallen met die class-act.

Oh dat kan, ik weet het gewoon niet.
Vergelijk ik weer even met auto's, je mag zelf na je garantie velgen en banden uitzoeken.
Stel na 20 ongelukken blijkt dat de gebruiker dezelfde velgen of banden hadden.
Zou de fabrikant er dan ineens mee wegkomen, want aftermarket en niet origineel bedoeld voor die wagens?

Ineens vraag ik me af (serieus) is een , zeg ubuntu gebruikende-, klant die bij telebankieren bestolen wordt, die iets anders dan apple, windows, android of osx gebruikt, meteen een klant die minder van een bank vergoed krijgt, want open source OS...?