Jeg kan ikke helt gennemskue om PHK - efter at have refereret det Slagelsegensiske hjemmeværns triumfer - synes det er en god eller dårlig ide at oprette et cyber-hjemmeværn.
Min holdning er at krig er for alvorlig en sag at overlade til amatører (politikere inklusive, i øvrigt).
Det "gamle" hjemmeværn havde til opgave at hjælpe med at forsvare dansk territorium og operere efter den regulære hær var besejret - det var en måde at opsuge alle de bevæbnede modstandsfolk, der havde rendt rundt og gjort livet surt for tyskerne under 2. verdenskrig. Staten fik registreret hvem de var og fik (nogenlunde) kontrol over hvilke våben de havde, og så var det officielle Danmarks voldsmonopol sikret.
Hvad er det lige et cyber-hjemmeværn skal tage sig af - hvilke systemer skal det forsvare? Hvornår skal det træde i aktion? Hvad er det OK at angribe og hvem er fjenden? Hvordan forestiller man sig at cyber-våben skal kunne reguleres? Der er jo ikke lige et bundstykke på NotPetya koden som staten kan låse inde, indtil de mener det skal bruges.
Jeg fatter ikke hvordan det kan være en gevinst for samfundet. Der er af og til en mentalt ustabil hjemmeværnsmand der går amok og skyder uskyldige. Cyber-hjemmeværnsmanden kan også gå amok, og så har vi potentielt problemer i en helt anden kaliber.
Der er trods alt en hel del forskel på at skulle scanne 2^9 adresser vs minimum 2^96 adresser (hvis ellers jeg forstod RIPEs dokument omkring IPv6 allokation korrekt).
I teorien korrekt, men praksis viser at der er nogle klare tendenser omkring hvordan administratorer tildeler adresser i IPv6. Der er sågar RFC 7707 som beskriver problemet: https://tools.ietf.org/html/rfc7707
Langt de fleste offentligt tilgængelige services på et IPv6 netværk ligger i et meget mindre adresserum and 2^96.
Det er min erfaring at testsystemer er et mega stort problem når det handler om persondata.
Det er muligt at anonymisere data, når man flytter produktionsdata over til et testmiljø, men det er besværligt. Og så springer man tit over hvor gærdet er for lavt og tager en rå kopi. Men så skal man pinedød have eksakt samme adgangsstyring, firewalls, logning og alle mulige andre sikkerhedsforanstaltninger på sit testsystem. Og det har man ofte ikke, fordi det er besværligt.
Udviklere og testere vil ikke have besvær. Men hvis et system indeholder produktionsdata så skal det håndteres som et produktionssystem. Og det er tydeligvis ikke sket her.
GDPR rammer alle personhenførbare oplysninger. Alle oplysninger, der kan pege på en bestemt person, er underlagt GDPR. Og det er uanset hvilken kontekst, oplysningerne indgår i.
Så et personnavn er klart under GDPR. Brugerens ID i DK-Hostmaster's database (NIC handle) er også under GDPR, uanset at det kun er DK-Hostmaster der har tabellen som mapper NIC handle til en person. Telefonnummer kan være under GDPR, hvis det er personens egen telefon og ikke et fælles firma-nummer - med den krølle at hvis det er et en-mands firma så bliver alle firma-identiteter automatisk også person-identiteter.
Hvis du som privatperson registrerer et domæne skal din identitet bekræftes ved at du logger ind med NemID, og herefter bliver NIC handle, navn og adresse offentliggjort i DK Whois. Alle disse er personoplysninger og omfattet af GDPR.
Smukt er det ikke. Men det er vel OK at man venter med at kaste kroner ud til design af logoer, indtil kontrakten er halet hjem.
Håber bare deres systemdesign bliver pænere end det grafiske design - desværre ser man tit det modsatte.
Jeg skal nemlig sende kopi af både pas og sundhedskort, når min bank skal sikre sig at jeg ikke er en slem, russisk penge-hvidvasker.
(ironi kan forekomme i ovenstående)
Nej lad os dog slippe af med alle de plasticdimser jeg skal slæbe rundt med i pungen. Og jeg er helt enig i at det blå og det gule kort skal slås sammen. Men gør det nu for pokker muligt at have det digitalt, så jeg ikke skal risikere at miste noget der tæller som identitetspapirer blot ved at en tilfældig langfingret østeuropæer kommer for tæt på i Metroen.
Som udgangspunkt bliver al offentlig telekommunikation i Danmark aflyttet.
Hørt!
:-)
Man kan betale sit kontingent med Mobilepay. Så mon ikke bidrag kan indbetales samme sted?
På http://datamuseum.dk/kontakt-ddhf/bliv-medlem/kontingenter-mv/ står der:
bankkonto i Danske Bank: Reg.nr. 4130 Kontonr. 4130466303 alternativt via MobilePay til 3091 6285.
IBAN: DK11 3000 4130 4663 03 SWIFT-BIC: DABADKKK
Man kan selvfølgelig også bare melde sig ind - det gør jeg nu :-)
Teleselskaberne har en samfundskritisk funktion.
CfCS får bemyndigelse til at overvåge datatrafik hos virksomheder med sådan en funktion.
Ergo kan staten nu overvåge alle danskeres kommunikation.
I den gode sags tjeneste, naturligvis.
Er også en del af prisen, men det ser ikke ud til at være med i regnskabet.
Et af mine første møder med Jacob var på NBI tilbage i slut-90'erne, hvor han rodede med en DEC Alpha-baseret arbejdsstation. Alle vi andre i SSLUG rodede med Linux på Intel-baserede PC'ere og servere, men Jacob nørdede med Alpha'en.
Og den skulle selvfølgelig kunne programmeres i Ada.
Sådan var Jacob bare - det han ikke kendte til blev undersøgt, og man kunne altid høre om noget nyt han nu havde gravet sig ned i.
Et spændende menneske, som jeg vil savne.
hvad er det præcist i GDPR, som gør at dette bliver slettet?
Jeg gætter på at det er artikel 16 - retten til at få fejlagtige data rettet - som er i spil her. Såden om det er beskrevet i artiklen så er det en Jobcenter sagsbehandler, der har noteret at Bente er psykisk ustabil, og det er han/hun ikke fagligt kompetent til at vurdere. Derfor er informationen ikke korrekt, og så har man krav på at få den korrigeret eller slettet.
så tænker jeg, at din idé om APIer allerede er i spil.
Der findes allerede et API til Rejseplanen:
Fantastisk - miraklernes tid er åbenbart ikke helt forbi endnu! Så hvorfor bruger de ikke bare dem?
DSB kunne måske integrere det hele i deres app - de har jo bestilt en app til 187 millioner, så der burde vel være luft til at integrere et par systemer mere ...
Nu forventer jeg ikke at politikere har hørt om webservices, API'er og løst koblede systemer - men de burde nok kende til fordelene ved konkurrence. Især når man kommer fra Liberal Alliance.
Hvorfor ikke i stedet kræve at både Rejsekortet og Rejseplanen stiller et API / webservice til rådighed, så man kan integrere billetkøb og rejseplans-opslag i en vilkårlig app? Så kan de jo integrere hinandens funktioner - og endnu bedre, så kunne der komme en konkurrerende 3. parts applikation som (sikkert) kunne gøre det bedre.
Man kan tvinge bankerne (med PSD direktivet) til at kunne snakke sammen, og private firmaer til at kunne udveksle data (GDPR's dataportabilitet). Men offentlige tjenester? Glem det ...
Ahem - det er jo ikke helt rigtigt. Et TLS certifikat identificerer hvem der står bag websitet.
F.eks. har https://ida.dk et fint certifikat, men en rådden kryptering. Chrome siger det kort og godt: "The connection to this site uses TLS 1.0 (an obsolete protocol), RSA (an obsolete key exchange), and AES_128_CBC with HMAC-SHA1 (an obsolete cipher)."
Men jo, det er flotte tal for udrulningen af TLS som LetsEncrypt kan præstere.
Er det at to personer er blevet gift, i kirke eller ej, en følsom oplysning ?
Absolut! Der kan være mange grunde til at man ikke vil have sit giftermål blæst ud i offentligheden:
- Hvis familien ikke bryder sig om giftermålet
- Hvis det er kendisser som ikke vil have nyheden blæst ud i Se&Hør
- Hvis der er eks-kærester med stalking-tendenser
Plus at for nogle er det simpelt hen en personlig sag, ikke noget der rager andre end dem de selv vil fortælle om det.
Der er intet fix til Lasspass eller alle de andre software password managers. Så længe et password giver adgang til alle (eller mange) passwords og det sker på en computer der er connected til internettet, så er der et problem.
Du taler i absolutter. Sikkerhed er et kontinuum, og Lastpass, 1Pass, Bitwarden osv er stadig langt bedre end simpel menneskelig hukommelse fordi de gør det enkelt at bruge forskellige koder til forskellige websites, og fordi de gør det enkelt at bruge komplekse og/eller lange koder.
Kan det blive bedre hvis man bruger 2FA eller biometri? Ja, men det gør almindelige brugere bare ikke fordi der stadig er mange forskellige implementationer af det og mange websites ikke understøtter det overhovedet.
Den vej jeg bor på starter i det ene hjørne af en lille plads. Så på venstre side af gadeskiltet er det nr 13 på pladsens gadenavn, og på højre side af gadeskiltet (og lidt ned ad vejen) ligger så nr 13 på min vej.
Dengang der var fodpost til fik vi jævnligt post til hinanden.
Der er da et par andre muligheder for lignende forvekslinger, som jeg lige kan komme på:
- Lejre kommune (lejre.dk) kan vel let blive "lejr.dk", "lejer.dk" eller "ejer.dk"
- Sorø kommune (soroe.dk) kan vel let blive "oroe.dk"
- Vejen kommune (vejen.dk) og "vejn.dk" ?
- Stevns kommune (stevns.dk) og "stevn.dk" - det ligner helt samme problematik, da stevn.dk vist er privat ejet.
Morsø kommune har vist gjort det rigtige, de ejer både "morsoe.dk" og "mors.dk". Ditto med Faxe kommune (faxe.dk og fakse.dk).
Der er vel egentlig to helt forskellige problemer her.
Mailen sendes ukrypteret over et offentligt netværk (Internet). Det er hvad overskriften peger på, og det har været forbudt i mange år. I praksis kan man så diskutere hvor stort et problem det egentlig er, eftersom stort set alle mailservere på nettet i dag understøtter kryptering (90% iflg. Google, 95% iflg Facebook).
Mailen sendes til en forkert modtager-adresse. Her hjælper kun at kryptere indholdet, men det har mig bekendt aldrig været et krav fra Datatilsynet.
Men kunne den kommunale mail-admin dog ikke tilføje disse adresser hos @randers.dk til de stakkels medarbejderes adressebog, så de ikke selv skal taste den fulde mailadresse ind? Det burde vel fange de fleste fumlefingre-mails.
Henrik Størner