Anders Jensen

VisitDenmark sendte 270.500 breve via e-Boks - nu undersøger Datatilsynet sagen

Eboks skal naturligvis ikke anvendes til markedsføring, og loven er da også 100% klar. Markedsføringslovens $10:

"En erhvervsdrivende må ikke rette henvendelse til nogen ved brug af elektronisk post, et automatisk opkaldssystem eller telefax med henblik på direkte markedsføring, medmindre den pågældende har givet sit forudgående samtykke hertil. "

Det er en klokkeklar overtrædelse af markedsføringsloven som VisitDenmark har lavet.

Derudover er det mærkeligt, at de har kunnet sende til folks e-boks. Mig bekendt er CPR-nummeret den eneste nøgle der knytter e-boks og BBR sammen. Hvorfor er VisitDenmark i besiddelse af disse personoplysninger? Det ligner en klar GDPR overtrædelse.

9. maj 2019 kl. 08:39
It-primadonnaen – skideirriterende og uvurderlig

Indlægget blander en række positive og negative egenskaber sammen, selvom disse egenskaber udemærket kan forekomme adskilte.

Passionerede, kompentente og erfarne IT-folk der stræber efter den højest mulige professionelle standard er ikke nødvendigvis "primadonnaer". Stereotypen findes bestemt, og den er måske også ganske udbredt fordi medarbejdere med centrale kompetencer kan slippe afsted med at opføre sig som primadonnaer, men der er også masser af eksempler på sindssygt dygtige og centrale IT-folk som ikke opfører sig som primadonnaer.

Men det er klart, at dygtige IT-folk stiller store krav til den virksomhed de arbejder i, både i forhold til ledelsen, kollegerne, kulturen og arbejdets indhold. Det gør de fordi de kan, i modsætning til den almindelige lønmodtager som er mere eller mindre tvunget til at finde sig ledelsens luner. Det er uvant for mange virksomheder at lønmodtagere uden ledelsesansvar i så høj grad skal forkæles og lyttes til for at man kan fastholde dem. Man er vant til, at det er ledelsen der kan slippe afsted med primadonna-opførsel.

Men selvcentrerede, bryske primadonnaer skaber jo netop ikke et fedt arbejdsmiljø omkring sig. De skræmmer andre dygtige folk væk.

Og den vigtiste opgave for de dygtigste og mest centrale IT-folk er jo tværtimod, at gøre sig selv undværlige ved at løfte deres kolleger og i det hele taget bidrage til en virksomhedskultur, der er attraktiv for dygtige medarbejdere.

30. januar 2019 kl. 12:18
Nu er 'dødsdatoen' for Microsofts mobilplatform klar: Skift til iOS eller Android

Hvis man har en telefon som er mindre end 2 år gammel og som har et alvorligt sikkerhedshul, så vil jeg da anbefale at man reklamerer.

Jeg ved ikke om der har været sager på det, men jeg vil mene at købeloven er fuldstændig klar. Sikkerhedshuller er fabrikationsfejl, og de skal udbedres indenfor en" rimelig tid". Jeg har svært ved at forestille mig, at "rimelig tid" til at rette et alvorligt sikkerhedshul kan være længere end et par uger. Ellers har du ret til at få pengene tilbage.

23. januar 2019 kl. 07:27
Blockchain til karakterbog og Alexa overvåger børnene: Her er kommunernes digitale vision

Idéen om at karakterer skal gemmes i en "blockchain" er da tåbelig. Et ganske almindeligt, centralt system til at gemme og digitalt signere karakterbeviser ville være langt simplere og billigere.

Faktisk ville det være fuldt tilstrækkeligt hvis uddannelsesinstitutionen sendte en digitalt signeret kopi af karakterbeviset til borgerens E-boks. Så følger beviset borgeren, der kan ikke snydes med det da det er digitalt signeret af uddannelsesinstitutionen, og der kræves ingen yderligere trediepartsverificering udover helt almindelig KPI-infrastruktur til at checke signaturens gyldighed, hvilket er infrastruktur der allerede er til rådighed i form af NemID.

Der er absolut ingen fordele ved at karakterer gemmes i en "blockchain" - kun kompleksitet, omkostninger og privacy-issues.

14. september 2018 kl. 10:08
Fandt meget stor sårbarhed, men blev afvist: »Trist, at du prøver at tjene penge på dette«

Jeg er helt uenig med NSM i, at folk der finder sikkerhedshuller i IT-systemer ikke skal have findeløn.

Tværtimod burde det være et lovkrav for overhovedet at få lov til at opbevare personfølsomme oplysninger om borgere, at man betaler et rimeligt honorar til folk der finder sikkerhedshuller i disse systemer.

6. september 2018 kl. 10:31
Juleopgave del 1: Find din adresse

Hej Sanne,

Det er ikke muligt at hente mere end 10.000 adresser fra WFS tjenesten.

Du kan hente alle adresser i andre formater, bl.a. GeoJSON, som er understøttet af det meste GIS-software.

Læs mere her: http://download.aws.dk/

19. december 2017 kl. 07:58
Udvalg anbefaler kopiafgifter på smartphones, eksterne harddiske og andre enheder

Blankmedieafgiften blev indført for at kompensere branchen for den lovlige kopiering til privat brug.

Argumentet var allerede svagt i 1992, men i det giver ingen mening i 2017. I dag foregår det lovlige forbrug primært via streaming og betalte downloads, som er beskyttet via DRM. Derfor er det slet ikke muligt at foretage nogen som helst former for lovlig kopiering til privat brug, udover den som ophavsretshaverne eksplicit giver tilladelse til. Derfor giver det ikke mening at de skal have yderligere kompensation, udover den pris de tager for deres tjenester. De fastsætter jo selv præcis hvor meget der skal betales, og de fastsætter selv præcist hvor meget der må kopieres.

4. september 2017 kl. 23:54
Dataforsyningsstyrelsen dropper kodeord i klartekst efter kritisk fokus

Årsagen til at kodeord gemmes i klartekst kunne også være, at kodeordet anvendes til mange forskellige typer services, eksempelvis WFS/WMS, FTP og custom REST services.

27. juni 2017 kl. 08:55
Betaler for 40 sårbarheder årligt i eget system: Det ville være katastrofalt, hvis nogen får hacket sig ind

For at få tilladelse til at behandle personfølsomme oplysninger for danskere burde det simpelthen være et krav, at man stiller et testsystem til rådighed hvor uafhængige kan udføre penetrationstests, og der burde være statsligt fastsatte minimumstakster for bounties, så de uafhængige testere kan få en rimelig betaling hvis de finder noget.

Kravet burde gælde både offentlige og private systemer som behandler personfølsomme oplysninger.

20. juni 2017 kl. 11:01
Denne gang får Javascript asynkrone funktioner med ECMAScript 2017

Har du dårlige erfaringer med eksempelvis Babel og regenerator til at understøtte async/await? "Mareridtsagtigt" lyder jo ikke specielt tiltalende ;-)

19. april 2017 kl. 18:31
Denne gang får Javascript asynkrone funktioner med ECMAScript 2017

Jeg kan ikke se hvorfor man nødvendigvis skal benytte TypeScript for at anvende ny javascript-funktionalitet. Babel har nogenlunde lige så god support for at oversætte moderne JavaScript til ES5, og har da også understøttet async/await i over et år.

19. april 2017 kl. 18:28
NemID bliver til MitID - alternative navne

Det burde hedde StatsID. Systemets formål er jo at staten kan identificere borgeren.

22. marts 2017 kl. 19:13
Ny løsning fra MobilePay går i kødet på Nets' guldæg: Betalingsservice

Virksomheder kan opkræve alle de gebyrer de vil, men de må ikke kalde det et mobilepay-gebyr med mindre betalingen faktisk er til mobilepay:

http://www.forbrug.dk/Artikler/Test-og-raad/Penge-og-oekonomi/Privatoekonomi/Kender-du-prisen-paa-Betalingsservice

I øvrigt er min erfaring, at virksomheder i DK meget sjældent opkræver urimelige betalingsgebyrer, som i væsentlig grad overstiger de reelle betalingsomkostninger. Har du nogen eksempler på dette fænomen?

3. marts 2017 kl. 09:25
Et succesfuldt offentligt it-projekt: Udvikler-engagement har været afgørende

Vi har haft overvejelser om det ville give mening for DAWA at flytte visse typer af søgninger (især autocomplete og tekstsøgninger) over i en ElasticSearch eller lignende, mest fordi jeg formoder ElasticSearch vil performe bedre.

Jeg kender ikke ElasticSearch godt nok til at kunne vurdere, om vores søgninger kan implementeres lige så godt (eller endnu bedre) i Elastic, og hvor stor performancegevinsten vil være på den type søgninger, som vi udfører.

Derudover er problemet, at vores søgninger kan kombineres med andre query-filtre, herunder også eksempelvis geografiske begrænsninger.

Indtil videre har vi altså valgt at holde os 100% på Postgres. Det er dels fordi vi er ret godt tilfredse med de resultater vi kan levere med Postgres, og selvom vi formentlig kunne få bedre performance med Elastic, så performer vores API godt nok til, at brugerne ikke ville opleve den store forskel i praksis. Et skift til Elastic eller lignende vil også være en dyr omgang at implementere - I hvert fald ikke under 200 timer, sikkert mere, og dertil kommer den øgede driftskompleksitet. Opgaven er svær at estimere præcist. Men det kunne være sjovt at afprøve, hvor effektivt Elastic klarer de søgninger vi laver, sammenlignet med Postgres.

9. februar 2017 kl. 11:55
Et succesfuldt offentligt it-projekt: Udvikler-engagement har været afgørende

Lyder som en relevant feature for et projekt som jeres. Bruger I disse features aktivt?

Ja, vi anvender PostGIS til følgende:

  • Konvertering mellem ERS89 og WGS84 koordinatsystemer
  • Reverse geocoding og andre GIS queries (polygon-søgning, circkelsøgning), nabovejstykker
  • Beregning af adressers DAGI-tilknytning og Zonestatus og bebyggelser ud fra deres geometrier
  • Som backend til WFS- og WMS services baseret på GeoServer

Vi har været særdeles godt tilfredse med PostGIS. Vi havde lidt udfordringer med håndtering af store polygoner (en region er et multipolygon som består af ~300.000 punkter), men det kunne løses ved at dele regionen op i mindre bidder før indeksering.

Har I haft mange udfordringer med tegnsæt? Jeg antager naivt, at I har været nødt til at få jeres system til at spille sammen med en masse gamle legacy-systemer...

Vi indlæser data fra en del forskellige kildesystemer, men det er heldigvis ikke mere legacy end at det primært er HTTP, XML og JSON.

Vi tilgår et par WFS-services for at hente DAGI-temaer og zonekort, og et HTTP-JSON-baseret API som DAR 0.9 udstiller til os, hvor vi modtager adresseændringer. Derudover tilgår vi også et HTTP-JSON API der udstiller danmarks højdemodel, for at få fat i adressens Z-koordinat.

Så er der en del data vi modtager i filer, det er bl.a. Bebyggelser (JSON), Vejmidter (JSON), og Adresseudtræk (CSV),. Derudover indlæser vi CPRs vejregister, som er et lidt mere legacy format med recordtyper og faste feltbredder. Matrikelkortet modtager vi i XML-format.

Ejerlavsfortegnelsen og postnumre vedligeholder vi selv manuelt i i et par CSV-filer.

Vi kører UTF-8 og da_DK collation i databasen på alle tabeller og kolonner. I det omfang vi har haft behov for at konvertere kildedata fra andre tegnsæt har vi anvendt iconv-lite. Da vi har samme tegnsæt og collation på alle kolonner har vi ikke haft nogen problemer i forhold til databasen, og læsning af kildedata har blot været et spørgsmål om at køre dem igennem iconv-lite med det rigtige tegnsæt.

PostgreSQL har så vidt jeg ved support for at man kan joine to kolonner med forskellig collation, samt at lave indices med andre collations en kolonnens, så det kan gøres effektivt. Men det er stadig lidt besværligt at håndtere forskellige collations, man skal holde tungen lige i munden og vist også angive hvilken collation der skal anvendes når man JOINer, hvis man joiner på kolonner med forskellig collation.

8. februar 2017 kl. 22:03
Et succesfuldt offentligt it-projekt: Udvikler-engagement har været afgørende

Kan du evt. fortælle lidt mere om jeres brug, styring af og samarbejde med leverandører af udviklingsydelser?</p>
<p>Sidder der folk med udviklerkompetence i styrelsen eller er de rene Product Owners?

Jeg er udvikler og sidder på leverandørsiden, så jeg må hellere overlade det til Finn at svare på dit spørgsmål.

Jeg kan dog afsløre, at Finn selv kodede den første, fuldt funktionsdygtige prototype af DAWA, så der er bestemt udviklerkompetencer til stede i SDFE :-)

8. februar 2017 kl. 21:24
Et succesfuldt offentligt it-projekt: Udvikler-engagement har været afgørende

Det er klart at IPv6 andelen er ekstra lav når klienter med IPv6 ikke får det tilbudt alligevel.

Ja det er da alligevel lidt specielt. Gad vide hvordan Amazon afgør hvem der skal tilgå CloudFront via IPv6, og hvordan de styrer det.

8. februar 2017 kl. 20:38
Et succesfuldt offentligt it-projekt: Udvikler-engagement har været afgørende

IPv6 andelen for det seneste døgn har været 0,35%.

Vi anvender som nævnt CloudFront, så det CloudFront der styrer hvilke DNS-svar du får. Det er ikke nødvendigvis alle klienter med en IPv6-adresse, som benytter IPv6. Selv skriver de om dette:

To maintain high customer availability, CloudFront will respond to viewer requests by using IPv4 if our data suggests that IPv4 will provide a better user experience.

Det er lidt uklart hvordan dette helt præcist fungerer.

AAAA-records ser ud som følger:

ahj$ dig dawa.aws.dk AAAA

; <<>> DiG 9.8.3-P1 <<>> dawa.aws.dk AAAA ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59823 ;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION: ;dawa.aws.dk. IN AAAA

;; ANSWER SECTION: dawa.aws.dk. 30 IN CNAME d1ab8pula12u5s.cloudfront.net. d1ab8pula12u5s.cloudfront.net. 60 IN AAAA 2600:9000:2002:b000:1a:21b7:8c00:93a1 d1ab8pula12u5s.cloudfront.net. 60 IN AAAA 2600:9000:2002:6200:1a:21b7:8c00:93a1 d1ab8pula12u5s.cloudfront.net. 60 IN AAAA 2600:9000:2002:6400:1a:21b7:8c00:93a1 d1ab8pula12u5s.cloudfront.net. 60 IN AAAA 2600:9000:2002:e00:1a:21b7:8c00:93a1 d1ab8pula12u5s.cloudfront.net. 60 IN AAAA 2600:9000:2002:7c00:1a:21b7:8c00:93a1 d1ab8pula12u5s.cloudfront.net. 60 IN AAAA 2600:9000:2002:c200:1a:21b7:8c00:93a1 d1ab8pula12u5s.cloudfront.net. 60 IN AAAA 2600:9000:2002:9800:1a:21b7:8c00:93a1 d1ab8pula12u5s.cloudfront.net. 60 IN AAAA 2600:9000:2002:3200:1a:21b7:8c00:93a1

8. februar 2017 kl. 19:56
Et succesfuldt offentligt it-projekt: Udvikler-engagement har været afgørende

Vi anvender single-master, multiple slaves. Masteren er dermed et single point of failure, men kun for skrivninger til databasen.

PostgreSQL blev valgt af følgende årsager:

  • Gennemprøvet teknologi
  • Explicit skema
  • Transaktioner
  • GIS-support
  • Tekstsøgningssupport
  • Vi kendte den relativt godt da vi begyndte på projektet
  • Ikke behov for at skalere skrivninger

DAWA har få skrivninger i løbet af dagen (typisk mindre end 1 i minuttet). Det meste dataindlæsning foregår som daglige kørsler om natten.

Driftssetuppet er overordnet som følgende:

  • Amazon CloudFront som cache. CloudFront agerer også firewall, der beskytter mod alt andet end valide HTTP-requests. Da DAWA er et fleksibelt søge-API, er det en relativt lille procentdel af requests, som kan caches (~30%). De fleste requests ryger altså igennem til databasen.
  • Brocade Virtual Traffic Manager som Load-balancer og firewall. Det er et nyt tiltag, hidtil anvendte vi Amazons ELB. Der er 2 stks af disse - den ene er i hot standby. De er placeret i hver deres Amazon availability zone.
  • En autoskaleret gruppe af amazon-instanser som kører NodeJS og Postgres Replicas. Disse instanser er også fordelt på to availability zones.
  • En PostgreSQL master.

DAWA håndterer typisk omkring 3 mio. requests i døgnet. I dagtimerne omkring 40 requests i sekundet. Trafikken varier meget - det er helt normalt med spikes på over 100/sekund. En sjælden gang oplevede vi også, at et anvendersystem havde rigtigt mange besøgende og derfor forårsagede over 300 requests/sekund.

I dagtimerne ser vi normalt ca. 2 nye, unikke IP'er pr. sekund.

Skyd endelig løs hvis I har flere spørgsmål.

8. februar 2017 kl. 19:04
Et succesfuldt offentligt it-projekt: Udvikler-engagement har været afgørende

Ja, DAWA kører på NodeJS platformen og anvender PostgreSQL som database.

8. februar 2017 kl. 17:03