Datatilsynet afviser anmeldelse af manglende HTTPS på læge-hjemmeside - er det et problem?

Illustration: REDPIXEL.PL, BigStock
Ifølge Datatilsynet er det ikke et problem, at der ingen synlig hængelås er på en side, hvor der eksempelvis skal indtastes et cpr-nummer.

Skal der være en HTTPS-forbindelse på hjemmesider, hvor der skal indtastes følsomme data, eller er det nok, at selve formularen, hvor data bliver indtastet i, sender via en krypteret forbindelse?

Ifølge et svar fra Datatilsynet, så er det tilstrækkeligt med beskyttelse, hvis formularen blot sender data krypteret. Der behøver altså ikke være en grøn hængelås eller stå HTTPS i det synlige adressefelt i browseren.

Version2-læser Dan Storm er stødte tidligere på året på en hjemmeside for en læge, hvor der blandt andet skal indtastes CPR-nummer.

Selve siden er ikke beskyttet med HTTPS, og det fik Dan Storm, der arbejder som Senior Backend Developer, til at rette henvendelse til Datatilsynet.

»Jeg mener dog, at siden ikke overholder Datatilsynets udtrykkelige krav om kryptering ved overførsel af personnumre via hjemmesider,« skrev Dan Storm blandt andet i sin henvendelse til Datatilsynet.

Ikke nok beskyttelse

Dan Storm påpeger desuden i henvendelsen, at oplysningerne, der bliver indtastet i den indlejrede formular på den pågældende side godt nok bliver sendt via HTTPS. Men det er ikke godt nok, mener han.

»Dette er dog ikke nok til at beskytte mod man-in-the-middle angreb, siden med formularen ikke er leveret via en krypteret forbindelse,« skriver Dan Storm i sin henvendelse til Datatilsynet og fortsætter:

»Ved at siden med formularen mangler kryptering kan man, via et man-in-the-middle angreb, modificere sidens indhold uden den besøgendes umiddelbare viden og derefter opsnappe både CPR nummer, kommentaren til lægen og og e-mailadressen - en ret triviel opgave i virkeligheden.«

Ingen anledning til bemærkninger

Datatilsynet har set på Dan Storms henvendelse, og essensen i det relativt kortfattede svar fra tilsynet lyder:

»Datatilsynet kan oplyse, at tilsynet i forbindelse med en tidligere sag har undersøgt sikkerheden på den pågældende hjemmeside. Undersøgelsen gav ikke tilsynet anledning til bemærkninger, da transmission af oplysninger på hjemmesiden ifølge en IT-sikkerhedskonsulent i tilsynet sker via HTTPS.«

Dan Storm har sidenhen sendt korrespondancen til Version2. I et efterfølgende interview uddyber backend-udvikleren, hvorfor han mener, det er et problem med den manglende HTTPS-beskyttelse - ofte vist via en hængelås - på den pågældende hjemmeside.

»Når certifikatet er valideret, og man dermed får den 'grønne hængelås', så sikrer HTTPS-laget, at indholdet fra serveren er uændret, når det når klienten. Det er grundstenen i HTTPS,« siger Dan Storm og fortsætter:

»Når hængelåsen ikke er der, så har brugeren ikke nogen garanti for, at indholdet ikke er ændret mellem serveren og brugeren, der sidder og kigger på siden. Og det er her, problematikken omkring man-in-the-middle kan opstå.«

Det vil eksempelvis sige, at hvis en bruger lokkes til at koble på et ondsindet wifi-hotspot, som en angriber kontrollerer, så kan angriberen manipulere indholdet på siden fra lægen, og opsnappe de oplysninger, brugeren indtaster.

»Jeg synes, det er rimeligt banalt, men nu arbejder jeg selvfølgeligt også med det. Men som borger havde jeg nok en eller anden forventning om, at de ville kunne forstå inde ved Datatilsynet, at det her er et problem.«

Forskelligartet opfattelse

Dan Storm peger på, at problemstillingen nok også udspringer af en forskelligartet opfattelse hos ham selv, og så Datatilsynet i forhold til, hvad det vil sige, at oplysninger bliver sendt krypterede.

Og han mener i den forbindelse ikke, det giver mening at tale om, at oplysninger på en ikke HTTPS-beskyttet side bliver sendt krypterede, uanset om der så måtte være en indlejret HTTPS-formular på sitet.

Problemet er blandt andet, påpeger Dan Storm, at oplysningerne, som bliver indtastet i formularen, kan blive opsamlet via et Javascript, skudt ind på den ubeskyttede side.

»Vi kan ikke forvente, at alle forstår forskellen (på hængelås og ingen hængelås). Man kan sige, at hvis der var krav om, at siden, hvor oplysningerne bliver indtastet, er krypteret, så har man jo gjort hvad man kunne for at beskytte data fra fra Datatilsynets side - og selvfølgeligt også fra udbyderen af sitets side. Sådan er det ikke nu,« siger han.

Version2 har bedt Datatilsynet forholde sig til Dan Storms kritikpunkter.

Datatilsynet: Hængelås er ikke nogen garanti

Kontorchef i tilsynet Lena Andersen oplyser via mail, at »vi ikke ønsker at sagsbehandle med medierne som mellemmand - hvis den pågældende borger har yderligere han vil vende med os, må han rette direkte henvendelse hertil – ikke via medierne.«

I forhold til den generelle pointe om, at Datatilsynet ikke mener, det er nødvendigt med en HTTPS-forbindelse/hængelås på et site, hvor der indtastes eksempelvis et cpr-nummer, oplyser Lena Andersen, at tilsynet ikke stiller krav om hængelås, »da en synlig hængelås eller farven på hængelåsen ikke er nogen garanti.«

Datatilsynets ikke udelte begejstring for synlige HTTPS-forbindelser/hængelåse er ikke ny.

Version2 omtalte i oktober sidste år en såkaldt sikkerhedstekst fra Datatilsynet. Det skete i en artikel med overskriften 'Datatilsynet advarer mod at stole på hængelåsen i browseren'.

I sikkerhedsteksten fra Datatilsynet lyder det blandt andet:

»Visning af hængelås eller HTTPS i browserens adressefelt garanterer ikke imod, at uvedkommende kan kikke med eller endda ændre i dataudvekslingen.«

I teksten bemærker tilsynet desuden, at en hængelås eller HTTPS i browserens adressefelt indikerer, at »der er anvendt kryptering, men ikke hvilken slags, eller i hvilken grad krypteringen beskytter imod, at uvedkommende omdanner de kryptere data til læsbart format.«

Hvad tænker Version2's læsere? Har Datatilsynet en pointe i, at det ikke i sig selv giver mening at kræve en umiddelbart synlig HTTPS-forbindelse på en hjemmeside, hvor der indtastes eksempelvis et cpr-nummer - altså forudsat at data ellers sendes krypteret fra siden?

Eller er det Dan Storm der har ret i, at der bør være HTTPS på den slags sider for at forhindre manipulation af indhold og diverse man-in-the-middle-angreb?

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (49)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Søren Mors

Det er muligt at datatilsynet har ret i at data er tilstrækkeligt beskyttet, i for hold til lovens krav, hvis de sendes retur over https. Men Dan Storm har da også indlysende ret i at det ikke beskytter imod et man-in-the-middle angreb.

Og helt ærligt, hvordan kan man have tillid til udviklerne af systemet hvis de ikke engang formår at sætte https på hele siden. Det er enten dovenskab eller inkompetence. Svært er det altså ikke mere.

  • 12
  • 0
Anne-Marie Krogsbøll

Jeg har netop konstateret, at en hjemmeside, som har tusindvis af medlemmer (røber ikke hvilken), godt nok har hængelås, men samtidig fra samme side (forsiden) benytter en ikke-krypteret login-formular (konstateret via "Egenskaber"), hvor man beder om cpr og password.

Det er vel om muligt endnu værre - for folk ser hængelåsen, og går ud fra, at formularen så er sikker. Eller er det mig, der tager fejl? Behøver selve formularen ikke være angivet som krypteret/sikker, hvis den ligger på en sikker side?

Jeg har meldt det til den pågældende institution - men undrer mig over, at der aldrig bliver ende på den slags - hvor har de ansvarlige IT-folk i foretagendet haft deres hjerne de sidste mange år? (med mindre det er mig, der tager fejl, og formularen faktisk er sikker, selv om den ikke ser sådan ud. Men i så fald er det noget rod).

  • 6
  • 0
Søren Mors

Hvad mener du helt præcist med at du har konstateret at login formularen ikke er krypteret? Hvis den bor i sin egen iFrame som hentes over en usikker forbindelse er der et problem. Hvis den adresse den sender svar tilbage til er på en usikker forbindelse er der et problem. Men hvis den bare er en del af siden, og siden hentes over en sikker forbindelse, så er alt godt.

  • 3
  • 0
Anne-Marie Krogsbøll

Søren Mors:

Tak for svar. Jeg skal prøve at forklare: På forsiden (som har hængelås og angives som "sikker forbindelse" i "Egenskaber") er et menu-punkt, som hedder "Log på". Når man klikker på dette, fremkommer en login-boks, hvor man kan vælge imellem at bruge cpr og password (det er det tydelige førstevalg). Der er links til NemID, hvis man hellere vil det.

Ved højreklik på selve denne login-boks får man så som vanligt adgang til "Egenskaber". Af denne fremgår så klart og tydeligt, at forbindelsen er "ukrypteret" - men i en "sikker zone" (sidstnævnte er vel min egen indstilling i browseren?). Jeg tolker dette som at loginboksens oplysninger sendes via ikke-krypteret forbindelse, for det er vel det, der står?

Selve certifikatet ser for mit utrænede øje ud til at tilhøre rette ejer.

Men som krølle på historien kan jeg så oplyse, at da jeg tjekkede for 5 minutter siden (en time efter, at jeg adviserede stedet om, at jeg havde anmeldt til Datatilsynet), var "Egenskaber" pludseligt ændrede, så det nu fremgår, at loginboksen sendes via "TLS 1.2, AES med 256 bit kryptering (høj); ECDH_P256 med 256 bit udveksling".

Mon ikke det er en halv indrømmelse? :-) Men det vigtigste er, at sagen nu er i orden.

Jeg anmeldte, fordi en sådan sag jo kunne betyde, at stedet heller ikke har styr på sin øvrige behandling af meget følsomme personoplysninger (herunder mine), som de ikke kan undgå at ligge inde med. Det håber jeg, at Datatilsynet vil tjekke op på.

  • 5
  • 0
Axel Nielsen

Alle steder hvor der kan udveksles følsom information skal selvfølgelig være certificeret/krypteret fra start til slut.

Kun derved kan man være sikker på at udbyderen af servicen har gjort sit yderste for at beskytte informationen.

Hvis ikke man har en eller anden form for verificérbar dokumentation for at dén service man besøger, vitterlig stammer fra dén udbyder den påstår, så kan man principielt ikke stole på siden overhovedet, heller ikke indlejrede scripts, links mm.

Næste lag er om man stoler på valideringen af certifikatet, men det er en anden snak...

  • 6
  • 0
Claus Bobjerg Juul

Datatilsynet har helt sikkert juridisk ret i at siden overholder loven.

Men hvilken grad af sikkerhed vil man helst have 20% sikkerhed for at forbindelsen ikke er kompromitteret (min anslåelse af den beskrevet løsning) eller 70% sikkerheds for at forbindelsen ikke er kompromitteret (min anslåelse af en HTTPS løsning)

  • 1
  • 0
Claus Mattsson

Det er bestemt også ønskeligt. Læger og speciallæger er dog små private virksomheder og de vil ikke betale for den tilslutning til NETS ligesom rigtig mange andre brancher heller ikke vil.

Klinikker der anvender Cure4You, kan man via Cure4You som borger, oprette et såkaldt premium medlemskab, der bl.a. låser op for brugen af NemID. Hagen ved dette er at udgiften flyttes over på borgeren, der selv skal betale. Jeg mener pt. beløbet ligger på 200,-/år.

  • 1
  • 0
Jens Beltofte

Oplevede fornyligt i forbindelse med selvbetjening på et website fra et kommunalt ejet selvskab, at formularer hvor brugeren blev bedt om at udfylde CPR-nummer m.m. hverken benyttede HTTPS på selve siden hvor formulareren var placeret, eller for den sags skyld submittede formularen via HTTPS.

Kontaktede ejer af websitet via deres Facebook siden nogle dage før påske, de læste beskeden (tak for det Facebook), men har aldrig svaret. Efter påske valgte jeg at kontakte deres webmaster direkte på email. Autoreply med info at webmaster var på ferie i nogle uger....

Endte med at kontakte myndigheden der ejer det pågældende selvskab direkte, da jeg har en kontakt i deres IT-afdeling. Min kontakt har så sørget for at viderebringe problemet og de har nu fået styr på det.

Har siden fundet ud af, at det pågældende website er relanceret inden for det sidste halve år, og det gør mig endnu mere skuffet og irriteret, når man i 2016/2017 ikke tager sikkerheden seriøst.

  • 4
  • 0
Henrik Biering Blogger

NemID bør anvendes


Det er helt irrelevant for den her omtalte sag om det indlagte "sikrede" login er NemID eller almindelig brugernavn og password. For uanset hvilken løsning, det er, har hverken patienten eller lægen nogen sikring mod man in the middle angreb, hvis ikke forbindelsen til alle dele af siden sendes krypteret.

At lave en negering af "hængelås i browseren er ikke nok til at sikre brugeren" til "manglende hængelås i browseren er nok til at sikre brugeren" bringer Datatilsynet i liga med Erasmus Montanus's "En sten kan ikke flyve. Morlille kan ikke flyve. Ergo er morlille en sten!"

På den anden side, når virksomheder som NETS ikke forstår sig på basal browser-sikkerhed, hvordan kan man så forvente at en institution som Datatilsynet skal gøre det?

  • 3
  • 0
Anne-Marie Krogsbøll

Jeg kan fortælle, at jeg netop er blevet kontaktet af AAK (som der var tale om - da sagen nu er ordnet, er det vel OK at fortælle). Her spiller man uforstående overfor, at der skulle være et problem. Og da problemet jo altså blev løst i morges mellem 7 og 9, er det jo svært at fremvise nu.

Grr.... det gør mig endnu mere betænkelig, at man tilsyneladende forsøger at lade som ingenting - eller kan det lade sig gøre, at det er et midlertidigt problem, som kan være forsvundet af sig selv?

  • 3
  • 0
Henrik Biering Blogger

Uden at skulle være på tværs, så er CPR nummeret udelukkende til identifikation og ikke til autentifikation. I teorien, er det lige så ligegyldig information, som et kontonummer i en bank.


Principielt korrekt, men så alligevel ikke.

For enhver kan nu lave en tjeneste, der beder om CPR-nummer som brugernavn suppleret af en adgangskode, som gerne må være en 4 cifret pinkode. Og nu er chancen stor for at en del brugere af mnemo-tekniske årsager vil anvende samme adgangs/pin kode som til NemID. Og med CPR-nummeret har du bl.a. brugerens adresse, så du (relativt) let kan skaffe dig kodekortet eller hardwarenøglen.

For at kunne klassificere en autentifikationsløsning som reel 2-faktor, må der ikke være sådanne koblinger mellem faktorerne, som CPR-nummeret altså udgør.

Derudover er CPR-nummeret det ideelle "correlation handle" for virksomheder, der går sammen om at profilere en bruger, der jf. persondatalovgivningen har afleveret forskellige subsæt af sine oplysninger til forskellige parter. Derfor anvender alle moderne systemer såkaldt "directed" eller "pairwise" identifikatorer, som kun kan sammenkobles ved brugerens egen mellemkomst eller evt. via en central autoritet.

  • 2
  • 0
Claus Bobjerg Juul

I teorien, er det lige så ligegyldig information, som et kontonummer i en bank

Dit CPR nummer følger dig hele livet (Det er meget svært at får et nyt CPR nummer) et kontonummer i en bank, kræver blot at du skifter bank, du kan måske endda bede din nuværende bank om at oprette en nyt konto til dig og derved få et nyt kontonummer.

  • 2
  • 0
Claus Mattsson

For at kunne klassificere en autentifikationsløsning som reel 2-faktor, må der ikke være sådanne koblinger mellem faktorerne, som CPR-nummeret altså udgør.

Svagheden ligger i NemID, det relatere sig ikke til identifikatoren. Jeg ved ikke hvor svært eller nemt det er at anskaffe sig den anden faktor. Men den anden faktor er nem at spærre. En politianmeldelse burde dække evt. misbrug.

  • 0
  • 0
Claus Mattsson

Jeg forstår det ikke rigtigt - vil du ikke have noget imod, at nogen ved fremvisning af dit cpr-nummer tager lån i dit navn?

Eller hvis nogen ringer til din hospitalsafdeling, og får følsomme prøvesvar ved at opgive dit cpr-nummer?

Det ville jeg være slemt ærgerlig over. Men så anvendes CPR nummeret også til andet end identifikation.

Ideelt set, så udgives samtlige kongerigets CPR numre i en stor publikation til offentligheden. Så holder anvendelsen af CPR nummeret som autentifikation hurtigt op.

  • 4
  • 0
Anne-Marie Krogsbøll

Det ville jeg være slemt ærgerlig over. Men så anvendes CPR nummeret også til andet end identifikation.


Tak for svar, Claus.
Jamen, du kan da have ret i, at hvis ingen misbrugte cpr, så var der intet problem - men problemet er jo, at det forekommer, og derfor må man jo være meget på vagt overfor steder, som sløser med ens følsomme oplysninger - og så længe cpr kan misbruges på den måde - og bliver misbrugt på den måde - så bliver man vel nødt til at regne det for stærkt følsomt? Så kan man altid på længere sigt arbejde mod at begrænse skaderne på den måde, du foreslår.

  • 1
  • 1
Henrik Biering Blogger

Svagheden ligger i NemID, det relatere sig ikke til identifikatoren


Jo, det relaterer sig også til identifikatoren. Der vil uanset diverse opfordringer til brugere om ikke at genbruge adgangskoder på tværs af logins være en kraftig statistisk kobling mellem brugerid og adgangskode ("noget kun brugeren ved"). Og den sammenhæng kan udnyttes ved såvel phishing som via hackede sider.

Denne (bruger-forskyldte) svaghed er en af årsagerne til at man til kritiske anvendelser ofte må kræve 2-faktor autentifikation for at opnå en passende sikkerhed. Og her er den viden man i praksis særdeles let kan tilrane sig via CPR-nummer en væsentlig hjælp til at skaffe sig adgang til f.eks. "noget kun brugeren har". (Udover den svaghed NemID har ved at engangs-kodekortet ikke sikrer mod realtime phishing).

  • 1
  • 0
Thue Kristensen

NemID bør anvendes, jeg ville aldrig oplyse f. eks. mit CPR nummer på denne måde, det er en overflødig handling.

Men der er jo ingen meningsfuld garanti for at en NemID-loginboks er reel, så du ville ikke være sikrere ved at indtaste dit CPR-nummer via NemID.

  • 1
  • 0
Kenn Nielsen

Grr.... det gør mig endnu mere betænkelig, at man tilsyneladende forsøger at lade som ingenting - eller kan det lade sig gøre, at det er et midlertidigt problem, som kan være forsvundet af sig selv?

Og dérfor er det - generelt - vigtigt at dokumentere fejlen så godt som muligt, inden man fejlmelder.

Så kan man sende dokumentationen - igen - når fejlen genopstår.

Eller man kan selv kigge på den , hvis man bliver i tvivl om hvad man oplevede, når man som fejlmelder bliver udråbt som "amaot"..

K

  • 1
  • 0
Anne-Marie Krogsbøll

Ja, jeg ved det, Kenn Nielsen. Føler mig også dum og naiv, at jeg ikke regnede med den reaktion fra AAK. Men kan du lige, til brug næste gang, oplyse mig om, hvor det er "Print screen"-funktionen ligger i nutidige windows-udgaver? For PrtSc-tasten virker ikke - ellers havde jeg brugt den for en sikkerheds skyld ( men i så fald ville jeg nok have følt mig urimeligt mistænksom samtidigt....).

Og derudover: Jeg håber jo, at Datatilsynet vil tjekke sagen - i så fald går jeg ud fra, at der må findes en log, hvor man kan se, hvad der er foregået? For det er vel for sent at genskabe fejlen fra en eller anden temp-fil fra min egen computer?

  • 0
  • 0
Gert Madsen

Det er dog direkte i strid med loven om persondata


Jo. Det er vist også her det står at CPR numre er hemmelige.
Hvorom alting er, så er det både tidskrævende og dyrt at få rodet sig ud af nogens misbrug af CPR-numret.

"man kan efterfølgende gøre krav gyldig."
Du mener vel "gøre krav ugyldige" ?

At få ret, betaler hverken brevpapir, frimærker eller fridage.
Så uanset CPR-nummerets indbyggede svagheder, så er det en god ide, at holde det så skjult som muligt.

  • 1
  • 0
Henrik Biering Blogger

Svagheden ligger i NemID, det relatere sig ikke til identifikatoren.

NemID løsningen indeholder muligheden for at spærre for brugen af CPR-nummer som id. Det er skal slåes til for alle brugere og herefter er det ikke et issue længere.

Det er lidt svært at argumentere i mod dig, når det er svært at vurdere hvad du selv mener, jf. ovenstående 2 successive svar.

Men så er vi vel enige om at det ville være bedst at undgå issuet ved at BrugerID ikke defaulter til CPR-nummer, men er et frit tilvalg for borgere, der ikke mener at de har noget at skjule eller har noget imod at få lidt mere spænding i tilværelsen.

  • 2
  • 0
Claus Mattsson

Det er lidt svært at argumentere

Ja. Kommunikation er ikke altid nemt. :)

Men så er vi vel enige om at det ville være bedst at undgå issuet ved at BrugerID ikke defaulter til CPR-nummer

Helt enig.

men er et frit tilvalg for borgere, der ikke mener at de har noget at skjule eller har noget imod at få lidt mere spænding i tilværelsen.

Jeg synes godt man kan argumenterer, at det ikke skal være en mulighed at tilvælge dårlig sikkerhed. Jeg kan heller ikke fravælge kryptering på en sikret service f.eks. loginside. Men ellers er jeg enig :)

  • 1
  • 0
Anne-Marie Krogsbøll

Tak, Kenn, for at minde mig om klippeværktøjet. Havde glemt det, fordi jeg i et par år har været rigtigt glad for Linux Mint - men Mint er desværre uvenner med min nyindkøbte computer (arbejder på sagen :-( ).

Så fremover skal der ikke forekomme udokumenterede fejlmeldinger fra mig....

  • 0
  • 0
Anne-Marie Krogsbøll

Tak for tip, Peter Stricker. Jeg forsøgte mig med den metode, men kunne ikke rigtigt få det til at virke - men klippeværktøjet virker. Havde bare glemt det.

I øvrigt opfølgning på AAK - jeg har fået denne mail:
"Kære Anne-Marie Krogsbøll
Tak for din besked.
Jeg påstår ikke, at du ikke har haft den oplevelse med vores side, som du beskriver, hvorfor jeg naturligvis fortsat vil undersøge, hvad årsagen kan have været.
Når det er sagt, så har vi ikke rettet på måden hvorpå man logger på vores selvbetjeningsside, siden vi lancerede den torsdag den 3. november 2016.
Ved tilføjelse af funktioner eller ændringer i forbindelse med fejl i øvrigt så har vi et hold testere, der gennemløber en lang række testscenarier i de top-8 mest anvendte browsere fordelt på PC, Mac, Android- og Apple-devices.
Der er ingen, der er inde og fifle med vores systemer. Det kan vi nemlig se ud fra nær-realtidsanalyse af de fleste af vores logfiler, heriblandt også loggen fra vores webservere.
Jeg takker dog for din årvågenhed og at du har gjort os opmærksom på din oplevelse."

Underskrevet digitaliseringschefen, som sådan set jo har svaret venligt, så ingen grund til at sætte hans navn her.

  • 0
  • 0
Kenn Nielsen

Og derudover: Jeg håber jo, at Datatilsynet vil tjekke sagen

Jeg er bange for det er derfor du får beskeden:
"Vi aner ikke hvad du taler om" - efter fejlen er væk.

Dette giver muligheden for at afvise Datatilsynet 'i døren' med en bemærkning om at "anmelder tog fejl"..

K
Edit:
Var lige 'borte' en times tid og trykkede >gem< inden jeg opfattede at livet også her går videre uden mig :-)

Høfligt svar, og ikke noget med at skyde budbringeren, - så jeg tog nok (glædeligt) fejl.

  • 1
  • 0
Anne-Marie Krogsbøll

Tak for nedslående svar, Kenn.

Kan Datatilsynet ikke kræve logfilerne udleveret? Eller kan der fifles med disse?

Men datatilsynet vil måske selv være glade for at få en undskyldning for ikke at undersøge sagen - det kræver jo arbejde, som de måske ikke har ressourcer til.

  • 0
  • 0
Anne-Marie Krogsbøll

Kenn Nielsen:
Ja - svaret er imødekommende, og lyder for mig også umiddelbart som om, man faktisk gør en del for at sikre systemerne. Jeg kan så undre mig over, om det virkeligt kan lade sig gøre, at en sådan fejl - pludselig spontan overgang til http i stedet for https, og spontant tilbage igen, uden menneskelig indgriben, kan opstå? Det har jeg ikke teknisk indsigt til at vurdere - det lyder bare lidt mærkeligt, synes jeg. Hvis det ikke kan lade sig gøre, så er der jo et eller andet galt i deres sikkerhedsprocedurer, som ikke fanger alle typer fiflen/fejl.

Og har det overhovedet noget med browsertype at gøre, om forbindelsen er http eller https?

Nå, jeg håber, at de faktisk undersøger sagen nærmere, sikkerhedsprocedurer eller ej.

  • 0
  • 0
Anne-Marie Krogsbøll

Jeg må for en god ordens skyld fortælle, at den videre (stadigt igangværende) kommunikation med AAK viser, at de nu tager sagen alvorligt, og gør et seriøst stykke arbejde med at finde fejlen - selv om den ikke mere er aktuel. Det skal de roses for.

  • 0
  • 0
Anne-Marie Krogsbøll

Nej, Morten. Hvordan gør jeg det?

Men jeg tænker også, at da der er tale om en lille "dialogboks", som fremkommer ovenpå selve forsiden, så er det vel ikke en, som gemmes i gamle versioner af hjemmesiden?

Bortset fra det, så har jeg på nuværende tidspunkt fået tiltro til, at AAK bedre kan finde fejlen end mig - og de benægter heller ikke, at den har været der, så behovet for at dokumentere er lige nu ikke så stort.

  • 0
  • 0
Log ind eller Opret konto for at kommentere