Det officielle lydspor til dette indlæg er to sange, den ene er titelsangen fra filmen Wag the Dog
https://www.youtube.com/watch?v=mR-3rMBLxyQ og den anden er på listen over sange fra filmen og noget vi allesammen mangler https://en.wikipedia.org/wiki/Wag_the_Dog
https://www.youtube.com/watch?v=umAurdHLNzU eller på Spotify
https://open.spotify.com/track/3ChXTNUIdmlFStxCtM3Q6a?si=qLxKlJVYTF2hlBy...
I want to go where the people dance
I want some action, I want to live!
Action, I got so much to give
I want to give it
I want to get some too
Hvem savner ikke at danse svedende sammen med andre, jeg gør!
Nå, det var den positive del.
Dette indlæg handler om problemet Corona Apps, og mindre om selve de apps der er foreslået. Lad venligst være med at linke mig til PEPP-PT
https://www.pepp-pt.org/ eller C3P0 appen, DP3T hedder den rigtigt. Jeg kender dem tak, og faktisk ikke så imponeret. Jeg er heller ikke tilhænger af jer, mine venner som konstant linker til disse - når både I og jeg ved at den danske app overhovedet aldrig nogensinde bliver en open source privacy bevarende app, medmindre det sker ved et ekstremt heldigt uheld. Send mig gerne kravspeccen som den udvikles under og jeg vil glædes og overbevises.
Jeg skal dog også samtidig sige at jeg ikke har læst alt omkring Corona apps, ej heller er kontaktsporingsekspert eller lægeligt uddannet. Hvad jeg dog er, en elefant til at huske meget af det jeg har læst. Vidende om en del detaljer og teknologier på et relativt dybt niveau indenfor specielt netværk og Internet, herunder protokoller, kryptering, apps og projekter på internet. Jeg kender også the Mythical Man-Month, selvom jeg mangler et par kapitler og den ligger her på kontoret.
https://en.wikipedia.org/wiki/The_Mythical_Man-Month
Det er omtrent et fuldtidsarbejde at følge alle trådende om Corona apps, og hvis jeg skal have overblik finder jeg journalisten Henrik Moltke frem https://twitter.com/DRMoltke og https://twitter.com/moltke for relevante links, tak Henrik!
Emnet for idag er ansporet af Corona apps, men det er ikke begrænsningen. Anvendelsesområdet for Corona apps burde være EKSTREMT snævert, men det vil blive bredt ud. Eksempelvis lader det til at første version endda kommer uden kontaktsporing, så det er allerede sket.
Formålet med indlægget idag er,
Jeg vil gerne have dig til at læne dig lidt tilbage, gerne så du ikke kan nå tastaturet, og overveje:
Kan man lave et stort komplekst IT-sikkerhedsmæssigt projekt som skal forbinde store organisationer, potentielt store lande, som skal pushes ud på en skala svarende til befolkninger og ramme mindst 70% under opretholdelse af privatlivets fred og resistent overfor trusler fra staten, andre stater, kriminelle og kommercielle interesser.
Det er vist en tanke værd, og måske skulle vi allesammen være startet med om kontaktsporing ved apps ER en god ide, men det må andre kloge sig om.
Jeg lavede for nyligt en hurtig tråd omkring Corona apps.
https://twitter.com/kramse/status/1251189805704269825
Den startede:
Mht fucking #Corona apps, er det værd at tænke på Schneier's Law: "any person can invent a security system so clever that she or he can't think of how to break it."
- det er PRÆCIS sådan Corona apps bliver udviklet nu. Det ER et shit show, og bliver værre!
https://schneier.com/blog/archives/2011/04/schneiers_law.html
og jeg vil nu prøve at sætte lidt flere ord på end twitterformatet tillader.
Bruce Schneier er en kendt og anerkendt IT-sikkerhedsekspert og kryptograf. Blandt andet forfatter til biblen Applied Cryptography, John Wiley & Sons, 1994. ISBN 0-471-59756-2 og en lang række andre bøger. Han har om nogen været en kilde til viden og konklusioner indenfor IT-sikkerhed og IT-sikkerhed i samfundet. Det kan anbefales at læse https://www.schneier.com/ og jeg kan ofte genfinde citater og resultater som er +10-15 år gamle men stadig korrekt og relevante.
The term Schneier's law was coined by Cory Doctorow in a 2004 speech.[19] The law is phrased as:
Any person can invent a security system so clever that he or she can't imagine a way of breaking it.
Kilde: https://en.wikipedia.org/wiki/Bruce_Schneier
Det er oprindeligt indenfor kryptografi, men for Schneier er det lidt bredere:
To Schneier, peer review and expert analysis are important for the security of cryptographic systems.[17] Mathematical cryptography is usually not the weakest link in a security chain; effective security requires that cryptography be combined with other things.[18]
Kilde: https://en.wikipedia.org/wiki/Bruce_Schneier
Husk dette når du hører buzz-words om algorithmer, nøglelængder osv. Den kryptografiske algoritme som vælges til et system kan være den bedste og mest sikre, men den kan anvendes forkert og den kan fra designet af være et dårligt valg til funktionen som skal opfyldes!
Lad os som eksempel bruge AES:
https://en.wikipedia.org/wiki/Advanced_Encryption_Standard
Det er en fantastisk algoritme Rijndael som er udvalgt gennem et 5 årigt standadiseringsforløb blandt 15 andre forslag. Den opererer med nøglelængder på 128, 192 eller 256 bits. Skal man bygge et system med AES er der altså valgmuligheder.
Det næste vi skal vælge er Mode of operation https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation
Hvilken en skal vælges? CBC, CFB, OFB, CTR
Der er også et begreb vi støder på Initialization vector (IV):
An initialization vector has different security requirements than a key, so the IV usually does not need to be secret. However, in most cases, it is important that an initialization vector is never reused under the same key. For CBC and CFB, reusing an IV leaks some information about the first block of plaintext, and about any common prefix shared by the two messages. For OFB and CTR, reusing an IV completely destroys security.
Hvis man husker WEP så var der problemer med svage IVer og de blev genbrugt fordi der kun var 24-bit til IV.
OK, så vi skal have styr på nøgler og IVer - som skal være tilfældige. Tilfældighed er et helt emne for sig, og det skal være på enheder af meget forskellig type. Det er godt at få styr på, for vi skal sikkert bruge andre ID felter osv.
Sidespor, en analyse af IV kan potentielt inkludere de IDer som apps tænkes at sende ud, og der er snak om Media Access Control (MAC) adresser på wifi og bluetooth niveau. Hvor lange skal de være, hvor ofte skal de skifte, hvor mange brugere, hvor ofte kommer der kollisioner, hvordan håndteres kollisioner osv. osv. Der ligger vist et par PhD afhandlinger allerede der.
AES og block cipher mode of operation omtaler også padding, som skal håndteres.
Det er altså ikke trivielt at sige, vi bruger AES!
Hov, nu vi lige omtalte AES er der et par andre vigtige konklusioner:
* Ting tager tid
* Der blev arbejdet med 15 forslag fra forskellige grupper
* Der blev udvalgt på nogle relativt håndgribelige, læs tekniske parametre, som hastighed på små og store computere, implementation i hardware og software. Det er hvad jeg husker AES stod relativt stærkt på.
AES was announced by the NIST as U.S. FIPS PUB 197 (FIPS 197) on November 26, 2001.[4] This announcement followed a 5-year standardization process in which 15 competing designs were presented and evaluated
Kilde: https://en.wikipedia.org/wiki/Advanced_Encryption_Standard
AES er forøvrigt kun den algoritme som holder tingene hemmelige. Til internetbrug har vi Transport Layer Security (TLS)
https://en.wikipedia.org/wiki/Transport_Layer_Security TLS er vores standard internetteknologi til at sende data med, og bruges til HTTPS.
Den bør man selvfølgelig bruge alle steder man kan. Den virker nemt fra IP-adresse til IP-adresse og tilbyder en hemmelig tunnel man sende og modtage data over. Det virker fra en klient, mailprogram eller browser til en server på internet.
Dog er det værd at bemærke at TLS har været lang tid undervejs,
HTTPS som vi alle bruger er pt. ca i sin 5. generation. SSLv2, SSLv3 OG TLS 1.0 anbefales IKKE. De blev udviklet over mange år, og SSL 1.0 blev slet ikke releaset grundet sikkerhedsfejlNæsten ALLE SSL/TLS implementationer har haft fejl Random link, https://www.acunetix.com/blog/articles/history-of-tls-ssl-part-2/ TLS Security 2: A Brief History of SSL/TLS | Acunetix Second part in the series on TLS/SSL gives a brief history of TLS/SSL from its inception back in 1993 by netscape to-date
Kilde: egne tweets
TLS vil naturligt indgå i Corona apps, men TLS dækker ikke brugssituationen, og der er nogle omkostninger ved at bruge TLS. Det koster en del processortid, herunder Diffie-Hellman https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange . TLS vil derfor nok ikke være muligt at gøre for hvert eneste broadcast. Det vil også være en mulighed for at overbelaste services, eller hvis apps modtager mange data som er krypterede.
Til Wi-Fi Protected Access (WPA) som vi allesammen bruger til kryptering af trådløse forbindelser lavede man en udvidet integritetsbeskyttelse TKIP og MIC, se https://en.wikipedia.org/wiki/Wi-Fi_Protected_Access . Det skulle forhindre falske pakker i at blive sendt. Desværre kom man vist til at vælge en timeout på 2 sekunder hvis der kom falske pakker, hvilket gjorde ude-af-drift angreb trivielle - send falske pakker, done.
WPA var efterfølger til WEP og løste alle kendte problemer, men skabte et par nye. Pudsigt nok er man igang med WPA3 som blev annonceret i 2018, og som nu analyseres for sikkerhedsfejl og publiceres papers omkring, se eksempelvis DRAGONBLOOD
Analysing WPA3's Dragonfly Handshake
By Mathy Vanhoef (NYUAD) and Eyal Ronen (Tel Aviv University & KU Leuven) https://wpa3.mathyvanhoef.com/
Konklusionen her er:
TL;DR: Det tager lang tid at lave IT-sikkerhedsprotokoller som skalerer og virker på internet.
Nu er TLS jo tiltænkt sessioner på applikationslaget, og lidt tung at arbejde med - omkostninger i setup, Diffie-Hellman osv.
Hvis vi istedet ser på pakker har vi også lidt erfaring fra Internet med IPsec, https://en.wikipedia.org/wiki/IPsec
Det er protokoller som kan autentificere, integritetsbeskytte, og kryptere, fortrolighedsbeskytte, pakker. De er publiceret omkring slut 1990erne se RFC-2401: Security Architecture for the Internet Protocol og efterfølgere.
Disse protokoller indeholder Internet Keying Exchange (IKE) (version 1)
IPsec & IKE i 1998 blev ligeledes defineret gennem årevis med dygtige hjerner, specificeret som standarder. Her blev de nødt til at lave bake-off hvor udviklerne mødtes fysisk og lavede debugging fælles, grundet forskellige implementationer af "standarderne". Nu +20y på IKEv2
Henrik Kramselund Jereminsen
Heartbleed som mange kender, blev introduceret i 2012, publicly disclosed 2014 - der gik flere ÅR efter hvor der stadig kom rettelser til software og hardware pga denne ene fejl.
og i 2016 ca. 250k systemer PÅ INTERNET med HB
https://en.wikipedia.org/wiki/Heartbleed
https://shodan.io/report/89bnfUyJ
Nu vi taler om kryptering har jeg holdt mig til tekniske udfordringer, men der er også en politisk side. Det inkluderer Crypto Wars, regeringer som forsøger at holde kryptering svagt nok til at de kan bryde det, og de problemer det giver. Apple iPhone kryptering er jo udskældt eksempelvis i San Bernadino shooter sagen og fra 1990erne huske vi export-restrictions, Wassenar. Sådan i nyere tid ser vi australske politikere komme med helt vilde udtalelser.
Seneste skud på stammen er vist USA der igen igen prøver, nu med en think-of-the-children EARN IT act, random link THE EARN IT ACT: HOW TO BAN END-TO-END ENCRYPTION WITHOUT ACTUALLY BANNING IT
https://cyberlaw.stanford.edu/blog/2020/01/earn-it-act-how-ban-end-end-e...
Så vi kommer måske til at se at kryptering med vilje neddrosles i applikationer generelt, og corona apps med.
Ekstra læsestof omkring Weak Diffie-Hellman (DH) parametre https://weakdh.org/ - svagheder grundet netop den type indblanding.
De danske politikere og digitaliseringsstyrelsen udtaler sig om Apple og Bluetooth som om de med vilje har lagt forhindringer i vejen for NETOP DEN DANSKE CORONA-APP. Det lyder præcsit lige så ignorant som da Søren Pind tidligere snakkede om Apple-sagen. Det lyser med spotlight på deres mangle de teknologiforståelse.
Jeg skrev i min tweet tråd:
Godt vi kan håndtere certifikater og nøgler gennem mange år. Omtales som PKI, https://en.wikipedia.org/wiki/Public_key_infrastructure
Læs evt denne fine liste med fails indenfor CAer som har det som core forretningsområde https://sslmate.com/certspotter/failures
og fortæl mig hvordan SST kan gøre det bedre
Alle der har arbejdet med certifikater og nøgler ved at det hurtigt bliver komplekst. Det jeg prøver at sige med tweetet er at, selv firmaer som har det som kerne forretningsområde og tjener penge på samme - de kan ikke altid håndtere det korrekt.
Så hvordan får vi på kort tid et system om, parallelt med NemID, med vel nogenlunde samme sværhedsgrad op at stå. Alternativet er jo at bruge NemID - det er jo sikkert. Stop, jeg henter en kop kaffe og græder lidt. Forslaget om at bruge NemID har nok været oppe at vende, selvom det burde resultere i at vedkommende der foreslog blev smidt ud af vinduet (kun hvis mødet blev afholdt på 1.sal).
Der bliver snakket stolpe op og ned omkring IDer, tilfældighed, temporære ID osv. osv.
Nå, ovenstående var for at sætte tingene i perspektiv, hvad er vores erfaringer med eksisterende systemer.
Opsummeret er det vist:
De fleste af vores IT-sikkerhedsteknologier har taget årevis og enorme ressourcer at "forfine" til nuværende niveau, som er lidt crappy for at være ærlige.
De nye systemer skal i drift, og der er basalt set to dele som går forud, og som kan resultere i sikkerhedssårbarheder.
Design vs Implementation Vulnerabilities
Her er min mening at det er utopi at tro vi kan få designet noget som bare indenfor skiven af
det snævre scope som en Corona app sigter imod - kontaktsporing. Bare at få DEN del til at virke overhovedet under de begrænsninger der er virker svært. Læg dertil at den skal virke udenfor lab, i et yderst fjendtligt miljø - der hvor der kæmpes med Advanced persistent threats,
statssponsorerede aktører, organiseret kriminalitet.
Er det med i designet?
I den lavere ende, hvordan undgår man pranks, falske data, osv.
Jeg ville forsigtigt estimere dette arbejde til tusindvis af timer. Vel og mærke timer hvor dygtige arkitekter med tung viden indenfor kryptering, protokoller, validering af samme kunne arbejde sammen, struktureret og målrettet. Det er ikke nok at de sidder adskilt, med forhåndenværende viden fra youtube-University og digter lidt. The devil is in the detail!
Der er virkeligt mange detaljer som kan gå galt. Bemærk OGSÅ en vigtig pointe, selv det bedste design kan ødelægges fuldstændigt ved sidste tilføjelser og rettelser.
Når vi kommer til implementering af systemer og efterfølgende idriftsættelse. Så har vi faktisk viden om mange gode sikkerhedstiltag som man kan benytte, nogle kendt siden 1950erne. Desværre er det ikke altid sådan IT-sikkerhed er implementeret i DK, sorry. Der er begrænsninger i ressourcerforbrug, tid - det skal gå hurtigt, det burde adskilles fysisk og logisk med compartmentalization osv.
Jeg tror ikke vi kan forvente at man på ultra-kort tid, få uger kan både udvikle, modne, teste og sætte et stort komplekst system i drift.
Jeg forventer derfor, desværre, at vi kommer til at se forhastede løsninger, som kastes ind med en skovl.
Det skulle ikke undre mig om man pludselig kan finde en database backup på en åben web server, eller tilsvarende.
Husk også det miljø som samme app/system skal bruges i - trusselsbilledet
Kan man afsløre sort arbejde med sporingsaps, ja med et dårligt design vil man kunne identificere socialbedragere. Vil der være nogen som potentielt ændrer scope EFTER alle har installeret den og Corona er på vej væk, jeps,
Kan kriminelle misbruge apps? De vil ihvertfald forsøge, ligesom vi har set dem udnytte situationen på mange måder allerede, både fysisk og virtuelt. Der er altså tale om at vi skal have et system som er resistent og robust i den sammenhæng.
Det eneste gode der vil være at vi endeligt får lækket hele CPR, gør det nu bare :-P
I sidste afsnit kom der en bibemærkning om drift. Dette område har vi en del erfaringer fra i Danmark. Nogle af dem er desværre lidt triste. Hvor borgeres data ikke er beskyttet godt nok, eller decideret misbruges af offentlige myndigheder. Jeg vil lade det være op til læseren selv at genfinde eksemplerne på version2, men det er ikke kønt.
Jeg checkede selv en offentlig portal for nyligt og det var ikke helt kønt, jeg kan eksempelvis fortælle at tidligere CSC, nu DXC, har rekursive DNS servere stående,
hlk@cornerstone03:~$ host www.dr.dk dns1.csc.dk Using domain server: Name: dns1.csc.dk Address: 147.29.62.8#53 Aliases: www.dr.dk is an alias for www.dr.dk-v1.edgekey.net. www.dr.dk-v1.edgekey.net is an alias for e16198.b.akamaiedge.net. e16198.b.akamaiedge.net has address 2.17.0.91 hlk@cornerstone03:~$ host www.dr.dk dns2.csc.dk Using domain server: Name: dns2.csc.dk Address: 147.29.139.54#53 Aliases: www.dr.dk is an alias for www.dr.dk-v1.edgekey.net. www.dr.dk-v1.edgekey.net is an alias for e16198.b.akamaiedge.net. e16198.b.akamaiedge.net has address 2.17.0.91
altså det må man jo godt. Det er bare ikke anbefalingen når samme er authoritative servere for domæner:
bendix.dk csccg.dk danskvarefaktanaevn.dk dde-drift.dk elektrus.dk fh.dk gbsf.dk gentagneaborter.dk laegehaandbog.dk laegehaandbogen.dk livmoderhalskraeftforum.dk patienthaandbogen.dk ringstedforsyning.dk solbib.dk sundhed.dk vvs-net.dk vvsnet.dk xn--lgehndbogen-08aj.dk
Hov, sjovt nok dukker sundhed.dk op der. Det er et domæne som ikke har DMARC p=reject, ingen DNSSEC, og DXC har ikke RPKI osv.
Vi har også mange andre eksempler fra dansk digitalisering, hvor skeletterne vælter ud.
Selv politiet og rigspolitiet har jo nogle yderst pinlige sager og skandaler. Kommunerne har vist sig datahungrende og misbrugsklare, hej Gladsaxe. Landets justitsminister, over flere omgange fra flere partier, har ignoreret en evaluering/revision af logningsloven - for 9. gang - til trods for at de HAR indrømmet det er ulovligt.
Mit spørgsmål ovenfor var:
Kan man lave et stort komplekst IT-sikkerhedsmæssigt projekt som skal forbinde store organisationer, potentielt store lande, som skal pushes ud på en skala svarende til befolninger og ramme mindst 70% under opretholdelse af privatlivets fred og resistent overfor trusler fra staten, andre stater, kriminelle og kommercielle interesser.
Konklusionen her er:
Nej, det er tvivlsomt - og det vil ihvertfald kræve mange årsværker til design, udvikling, test osv.
Så når vi nu ser annonceringen og champagnepropperne springer over den nye app, så vær opmærksom på hvem der udtaler sig skråsikkert omkring sikkerhed, kan vi stole på dem.
Hvis de siger, denne app er sikker og vi stoler 100% på Netcompany, SST, Søren Brostrøm, hmm https://www.youtube.com/watch?v=XF2ayWcJfxo .
Konkret vil jeg mene vi har beviser på at vi ikke kan stole på det, og derfor bør udtalelser være langt mere forsigtige. På den anden side vil man have hr og fru remouladedanskere til at installere en app - så derfor ER DEN SIKKER!
Min holdning er derfor fra en IT-sikkerhedsvinkel at apps er en dårlig ide. Er det en dårlig ide når vi skal åbne samfundet, yadda yadda, ja - stadig en dårlig ide, for den vil ramme de svageste, som den slags altid gør.
Hvis der var mere plads kunne vi tage en snak om frivillighed, app bliver frivillig - men det er jo også frivilligt om du vil tage toget. Hvis offentlig transport pludselig kræver app fremvisning, hvad så. Det er for mig en nærliggende mulighed, men håber ikke det kommer til det.
Kilder:
BTW Nogle af de bøger jeg lige hev ned fra hylden til tråden:
Network Security: Private Communication in a Public World, Charlie Kaufman, Radia Perlman, Michael Speciner
The Art of Software Security Testing: Identifying Software Security Flaws
Af Chris Wysopal, m.fl.
24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them
Michael Howard, David LeBlanc, John Viega
Den sidste ville jeg ønske at alle udviklere læser.
Hej Henrik, Dette er vist et klassisk og mere kendt eksempel på "forkert" brug af algoritme ;-) Debian udvikleren, der ville fjerne en dangling pointer reference i openssl https://security-tracker.debian.org/tracker/CVE-2008-0166
Problemet for alle krypteringsalgoritmer har alle dage været hvor høj grad af tilfældighed, der indgår i proces fra plain til cipher! Et udmærket eksempel fra fredagens film Imitation Game *), hvordan Enigma blev knækket - udsendelse af vejrmeldinger på samme tidspunkt hver dag, Alle underskrevet Heil Hitler etc.
Ja det er forbløffende svært at få deterministiske computere til at lave tilfældige eller pseudotilfældige tal.
Et andet problem er valg af felterne, længderne osv. IV er eksempel på dette, men i andre tilfælde er det muligt at de anonymisere data, som 2014 eksemplet i NYC. https://www.theguardian.com/technology/2014/jun/27/new-york-taxi-details...
Panduragan realised that the medallion and licence numbers both have a very specific format. Medallions only take one of three formats either 5X55, XX555 or XXX555 while licences are all six-digit or seven-digit numbers starting with a five. That means that there are only 2m possible license numbers, and 22m possible medallion numbers.
blandet med noget MD5. Så hvis der ikke tænkes den slags ind, bliver det måske trivielt at gå fra noget krypteret til eksempelvis CPR eller anden nøgle.
Så er det klart at du har helt ret.. De vil ikke vælge at samarbejde med nogen, eller anvende udbredt Open Source (som så kunne have en chance for at være bare sådan rimeligt i orden) - og da denne app, som du siger nemt kunne gå hen at blive ligeså frivillig som offentlig transport (eller værre - i københavn cykler jeg faktisk altid til alt), så er det virkeligt seriøst, hvis de får lavet "deres sædvanlige kvalitetsløsninger" og får "tvunget" den på os alle, ligesom NemID - hvor man jo også bare valgte at tvinge folk over på NemID - istedet for at arbejde med brugervenligheden.. De offentlige har en historik med at foretrække pisk, frem for gulerod..
Jeg vil så inderligt, håbe at når nu de alligevel VIL lave en app - at de så følger "bare lidt med" - og anvender noget Open Source, der anvendes af andre lande også - og begynder at lære hvordan man samarbejder verden over, om software.. Der er enkelte kommunale projekter, der udvikler i Open Source regi, svjv..
suk.. en utopi med meget høj sandsynlighed :(
For mig er det væsentligste problem ikke om man kommer til at vælge en krypteringsmetode, der ikke er top-notch. Det er i virkeligheden ikke beskyttelse mod krimelle, som jeg er bange for.
For mig er det DAMD-sagen, der er det væsentlige: Hvordan sikrer vi mod, at data samles ind, og at man ændrer loven med tilbagevirkende kraft, så disse data nu kan bruges på en anden måde ("formålsforskydning")?
Og her mener jeg, at det allervæsentligste er, om arkitekturen er central eller decentral. Alt andet er sekundært.
.. om ikke også løsningen fra en af The Usual Suspects er blevet forsinket:
"Men appen, der er udviklet af Netcompany for Digitaliseringsstyrelsen, er løbet ind i en række problemer, der betyder, at appens lancering er udsat. "
https://www.dr.dk/nyheder/penge/dansk-corona-app-er-forsinket-partier-vi...
Gad lide at vide hvor mange penge samfundet allerede har spildt på den sag, det er jo nok noget som er godt skjult af mørkelygten.
