Ny Javascript-NemID kræver en engels tålmodighed på billig smartphone

Internetaktivisten Christian Panton forsøger i en video at logge ind fra en billig smartphone med den kommende NemID i Javascript, der netop er udviklet for at kunne få NemID til mobiltelefoner. Se, om det lykkes.

I disse dage er det blandt andet via borger.dk muligt at prøvekøre den kommende NemID-løsning, som - modsat den nuværende - også skulle fungere på mobiltelefoner og tablets. Datalogen og internetaktivisten Christian Panton har testet løsningen, der forsøgsvis kører på den offentlige login-portal NemLog-in, og dokumenteret resultatet i en video.

Og det er ikke et godt førstehåndsindtryk, NemID i Javascript efterlader, for det kræver en stor portion tålmodighed at få lov at logge ind på den billige smartphone, der bliver brugt i testen. Faktisk tager det omkring halvandet minut, før Javascript-appletten er loadet på Christian Pantons telefon, en ZTE Open med Firefox OS til omkring 500 kroner.

Han har tidligere i Version2's spalter givet sin analyse af en testudgave af den kommende NemID Javascript, der fyldte næsten en megabyte, blandt andet fordi Nets har valgt at obfuskere koden kraftigt - altså gøre koden meget mere kompliceret, så den umiddelbart er svær at læse og forstå for andre.

Læs også: NemID-pilfinger kritiserer test af NemID uden Java: 1 megabyte obfuskeret kode

Og nu har Christian Panton altså haft fingrene i en live-udgave af NemID JavaScript, der ifølge tidligere udmeldinger fra Digitaliseringsstyrelsen bliver officielt lanceret på tirsdag, 1. juli.

»Der er helt sikkert nogle performance-issues, hvis det kan tage så lang tid. Jeg har godt nok ikke den nyeste mobiltelefon, men er det virkelig niveauet, vi skal forvente af nyudviklede systemer? Vi skal jo huske, at NemID i JavaScript bliver lanceret som NemID til mobiltelefoner, så man må jo forvente, at det ikke er de kraftigste enheder, folk sidder med,« skriver han i en mail og fortsætter:

»Jeg håber, at der er en fra Nets eller Digitaliseringsstyrelsen, som vil forklare mig, hvordan de har tænkt sig at løse problematikken.«

Læs svaret fra Nets og Digitaliseringsstyrelsen: Nets og Digitaliseringsstyrelsen: Ja, den nye NemID til mobilen kører for langsomt

Det er ikke første gang, Christian Panton kaster sig over offentlige it-systemer. Som datalogistuderende demonstrerede han i 2010, hvor enkelt det er at ændre de basale oplysninger på rejsekortet.

Læs også: Studerende: Jeg kan snyde rejsekort uden at hacke kortets hjerte

Og siden da har han ad flere omgange kastet sig over NemID. Blandt andet da han tidligere på året lavede sin egen alternative NemID med Javascript, hvilket fik en noget kølig modtagelse hos NemID-leverandøren, Nets.

Læs også: Hjemmeudviklet NemID-klient får syngende nej: Trues med ‘nødvendige juridiske tiltag’

Se Christian Panton forsøge at opnå adgang via NemLog-in til tonerne af Edvard Griegs 'Morgenstemning' herunder. Telefonen, en ZTE Open med Firefox OS, hører til i den skrabede ende af smartphone-markedet og er udstyret med en 1 gigahertz enkeltkerne-CPU og 256 megabyte RAM.

Til sammenligning har Version2 målt load-tider på omkring 13 sekunder på en af de hurtige telefoner på markedet, en Nexus 5 med fire Krait 400-kerner på 2,26 gigahertz og 2 gigabyte RAM. Cirka samme load-tid præsterer en iPad 4 i standardbrowseren Safari.

Test gerne selv Javascript-NemID-login på Borger.dk og meld ind i debatten, hvilken load-tid I oplever - især med telefoner og tablets, som ikke hører til de hurtigste og dyreste i dag.

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

Det er ufatteligt at det er så sløv. Men ellers, så kan man undre sig over at UI'et ikke er lavet til at fungere optimalt på et mobilt device i stedet for at ligne den gamle applet. Jeg har samme problem som vi ser i videoen, altså at dele af appletten bliver skjult når keyboardet dukker op fordi header og footer skal være der - suk!

  • 15
  • 1
Allan Ebdrup

Suk. Nu kommer Hr. og Fru Danmark til at tro at JavaScript er langsomt, fordi de kommer til at forbinde ordet JavaScript med den nye NemID.

Jeg hører allerede mig selv forklare et par tusind gange, at JavaScript skam er en hurtig teknologi, men at NemID bare er lavet forkert... noget med en pind og en lort...

  • 21
  • 2
Baldur Norddahl

Sandheden er at NemID kan laves med en simpel webformular på en https-URL. Det kræver hverken Java eller Javascript. Problemet med den løsning er at så kan man ikke tage mange millioner for løsningen.

I stedet har man opfundet en række problemer og påstået at Java/Javascript kan løse disse. Men det er løgn. Alle problemer der måtte være med en webformular findes også i en Javascript løsning. Det kan selv den tungeste obfuskation ikke ændre på.

Vi har tusinder af netbanker på nettet, der alle beviser at en sikker loginløsning ikke behøver være så svært. Vi har tilmed flere standarter man kunne vælge at benytte.

  • 21
  • 1
Baldur Norddahl

Vi har allerede set at svagheden i NemID er papkortet og man-in-the-middle angreb. Hvis de absolut skal bruge penge på at lave noget avanceret, kunne de så ikke arbejde på at løse de reelle problemer? Papkortet kunne f.eks. erstattes af en kryptoterminal og samtidig kunne man passende sørge for at os virkshomhedsejere ikke skal rende rundt med et dusin NemID kort. En terminal per person tak.

  • 7
  • 4
Christian Nobel

Det ville vaere fint hvis NETS ville bruge Christian Pantons implementation som maal for hvilken performance der er brugbar.

Problemet er nok bare at Nets og den såkaldte digitaliseringsstyrelse
har et andet mål.

Og i det spil kan man da sandelig ikke tage smålige hensyn til brugernes behov - herregud, de er jo alligevel til for os, så de kan bare vente (hvis de overhovedet kommer så langt).

Vi byder velkommen til 2014 - og hvad kan man forlange for 47 millioner.

Suk.

  • 15
  • 0
Kristian Elmholt Bak

Så, det der bliver bevist i denne video er at langsomme telefoner er langsomme?

Måske - men vil du ikke sige, at et offentlig system ikke skal målrette sig selv efter at befolkningen skal ud og anskaffe sig nye smartphones og sørge for de ikke er på 3G, men 4G?

4G jo vel og mærke også kun er tilgængelig på visse smartphones...

Omkring 15 sekunder på en Lumia 920. Det er ca. 14 sekunder for lang tid.

Samme her - det var dog også på 4G med 2-3 "streger".

  • 6
  • 0
Simon Mikkelsen

Hvem i alverden har accepteret at vores skattekroner skal bruges på sådan en omgang svindel om humbug?

Lille Danmark kan da umuligt være de første i verden der har brug for at logge sikkert ind, men vi er de første der laver sådan en Rejsekort-løsning.

Historien viser, at man kan smide nok så meget krypto og obfuskering på klienten, men hvis angriberen har kontrol over klienten er det ikke andet end røg, spejle og fatamogana.

NemID i Javascript er ikke kun spild af vores tid, det er også spild af vores penge.

  • 11
  • 2
Alex R. Tomkiewicz

Hvem i alverden har accepteret at vores skattekroner skal bruges på sådan en omgang svindel om humbug?

Nemlig. Men i det postmoderne statscentrerede selvopfyldende statsfordelingssamfund (aka statsvelfærd - altså velfærd for selve staten - der har antaget egen eksistens) er der ikke noget der hedder skattekroner. Det er statens retmæssige rådighedsbeløb - også kendt som borgereksistensafgift. At vi er nogle utilpassede individer som synes pengene kunne bruges bedre til bedre værdiskabelse er uden betydning. Vi er blot utilpassede til statsrealitetens struktur. Fordelingsmekanismen af de retmæssige midler har ikke noget med borgerbaseret fornuft at gøre. Bureaukratiets skinnende klare interne logik mestres kun af kancelliets kardinaler og kan ikke forklares for proletariatet. Kancellikardinalerne tilgodeser blot de eksterne kancelli-præster i den privatnødvendige sektor som sikrer at den selvbærende statsgeometriske konstruktion opretholdes og fortsat tilgodeses.

Men derfor er løsningen stadig hul i hovedet.

  • 9
  • 1
Henrik Madsen

Må jeg foreslå at eksperterne som næste opgave slår sig på at få deobfuskeret Net's kode og få lavet en ren udgave uden al obfuskeringen og så få testet hvor hurtigt den loader.

Altså at få fundet ud af hvor mange sekunder ekstra det tager at loade, på Panton's billige mobil alene pga. obfuskeringen.

Mit gæt er at en stor del af tiden går med at få telefonen til at deobfuskere.

  • 7
  • 1
Jesper Louis Andersen

Jeg hører allerede mig selv forklare et par tusind gange, at JavaScript skam er en hurtig teknologi, men at NemID bare er lavet forkert... noget med en pind og en lort...

Javascript er egentlig en temmeligt langsom teknologi. Selv med nogen af de bedre JIT-oversættere. Men moderne maskiner er så hurtige at det ikke betyder det store.

I dette tilfælde handler det dog om at forklare hvorledes dårlig programmering ikke hjælper.

  • 3
  • 4
Henrik Pedersen

Det er ingen nyhed at Nets er en flok idioter. Sådan. De folk de har ansat til at udvikle det må have en forfærdelig smag i munden, hvis de selv ved hvor elendigt det de laver er (jeg håber næsten for deres skyld, at de er typen af udviklere der bare laller gennem det hele uden at tænke over korrekt design osv.)

Den GODE nyhed er at Javascript er nemmere at de-obfuskere og helt sikkert nemmere at erstatte. Man må da kunne lave nogle browser plugins der erstatter den der elendige JS fil? ;)

Hvornår ser vi btw. JS versionen på computerne? Kan man mon fake sig til den med falske headers?

  • 1
  • 2
Frithiof Andreas Jensen

Vi har tusinder af netbanker på nettet, der alle beviser at en sikker loginløsning ikke behøver være så svært.


Mjaeh - Nu render bankerne nok ikke ligefrem ivrigt rundt og offentliggør statistiker over hvor meget de bliver hacket, så vi ved faktisk ikke hvor sikker bankernes login-løsninger er i prakasis.

Deres hidtil bedste bud er faktisk NemID - som altid har indholdt "hooks" til spyware.

Hvis man vil af med NemID så skal det hackes, men, prisen på "hacktivisme" er gået op på det seneste.

  • 3
  • 2
Sune Marcher

på en LG G2.. er vel lidt ligesom det heller ikke virker til xp, vi kan ikke blive ved med at supportere gammelt skidt som en eller anden firefox tlf vel 4 mennesker i dk har ?


Der er lidt nogle andre krav, når vi snakker national infrastruktur, som vi tilmed får stoppet ned i halsen, hvad enten vi vil det eller ej.

Derudover er det unødvendigt ringe performance, det er jo ikke blot et spørgsmål om sloppy programmering, men om decideret performance-pessimisering, fordi nogle idioter tror på security through obscurity.

  • 5
  • 1
Allan Ebdrup

Javascript er egentlig en temmeligt langsom teknologi. Selv med nogen af de bedre JIT-oversættere. Men moderne maskiner er så hurtige at det ikke betyder det store.

Det kommer nok an på hvordan du ser på tingene og hvornår du kalder noget for en "langsom teknologi".

Jeg vil stadig fastholde at det vill være forkert at kalde JavaScript for en langsom teknologi (ifht Hr. og Fru Danmark). Udfra den betragtning, at der ikke er et sammenhæng mellem om dit website opleves langsomt og det at dit website bruger JavaScript.

Tvært i mod kan en intelligent brug af JavaScript, få dit website til at opføre sig endog meget hurtigere, end et website uden JavaScript. Udfra den synsvinkel så er JavaScript det direkte modsatte af en "langsom teknologi".

Almindelige web-brugere får en bedre og hurtigere oplevelse på nettet hver eneste dag pga. JavaScript. Det kræver et særligt "talent" at opnå den modsatte effekt, og så er vi tilbage ved pinden og lorten...

  • 7
  • 1
Sune Marcher

Tvært i mod kan en intelligent brug af JavaScript, få dit website til at opføre sig endog meget hurtigere, end et website uden JavaScript. Udfra den synsvinkel så er JavaScript det direkte modsatte af en "langsom teknologi".

Almindelige web-brugere får en bedre og hurtigere oplevelse på nettet hver eneste dag pga. JavaScript. Det kræver et særligt "talent" at opnå den modsatte effekt, og så er vi tilbage ved pinden og lorten...


Jeg er delvist enig med dig, så længe vi snakker relativt simple sites, med simpel og fornuftig brug af JavaScript til lidt AJAX og eventuelt client-side caching.

Men når man når op i lidt højere kompleksitet? Så kræver det talent ikke at fucke tingene op. Facebook, for nu at tage et eksempel de fleste kender, er f.eks. pænt sløvt på telefoner og tablets.

Sløvhed har sandsynligvis mere at gøre med resource leaks, ineffektiv event-handling og retarderet DOM-manipulation, end hastigheden af core javascript (som vel kan betegnes som "adequate"). Men jeg synes godt nok ofte at JS-tunge sites performer af helvede til, når jeg ikke lige sidder ved min quadcore/16gig-ram workstation... om det så er fra en tablet eller en laptop der er et par år gammel.

  • 1
  • 0
Sune Marcher

...ellers lægger du jo mærke til, når staten bootstrapper NSA exploits og tager den sidste rest af privacy fra dig.
Der er ingen grund til at tro, at NemId-klienterne IKKE anvendes som QUANTUM vector.


Hvorfor skulle de gøre så forbandet en obvious ting, når de har har overvågningsudstyr på alle de krydsfelter, de er interesseret i?

Om noget er (var) NemID et sødt lille røgslør, der fik folk til at fokusere deres paranoia det forkerte sted, så der ikke blev snakket så meget om de reelle aflytningsmuligheder :)

  • 0
  • 0
Morten Hansen

Jeg er jævnt tilfreds med muligheden for at jeg kan logge på via mobilenheder. At det tager de 10-15 sekunder for mig betyder ikke noget, det kan de få lov til at arbejde på, men det er ikke essentielt for mig. Af hensyn til usability ville jeg dog gerne se at de fik "Im working on it"-ikonet til at rotere som er meningen, det ville være fint.
Alt i alt er det fedt med muligheden! tak!

  • 2
  • 4
Michael Weber

Af hensyn til usability ville jeg dog gerne se at de fik "Im working on it"-ikonet til at rotere som er meningen, det ville være fint.
Alt i alt er det fedt med muligheden! tak!

Den med Ikonet studsede jeg også over.
Så vidt jeg ved, er det et animeret ikon og når man kan se det på skærmen, er selve ikonet færdigt-downloaded. Det får mig til at tro, at selve telefonen knokler på højtryk for at behandle koden og ikke har tid til at opdatere (renderer) ikonet.

  • 2
  • 0
Gert Agerholm

Først var det galt at det krævede Java. Nu er det galt at det er for langsom i JavaScript.

Det tager 8 sek. på min iPad Air, 14 sek. på min iPhone 5 for at få NemID login billedet. Det er tider jeg kan leve med. Lad os være glade over at der sker en udvikling og ikke altid surmule fordi det ikke er lige sådan som jeg vil have det, det er bedre at der sker en udvikling.

Det er SELVFØLGELIG ikke en blanko check til at lade ting som de er. De skal selvfølgelig udvikle og forbedre tingene. Og ja, login tiden må meget gerne forbedres, men det er for mig at se bedre at de kan bruge JavaScript i stedet for ikke at kunne, så kan de efterfølgende forbedre/optimere tingene.

Men ingen kan forvente at få high performande på en ældre low end enhed, det er utopi.

  • 2
  • 3
Sune Marcher

Men ingen kan forvente at få high performande på en ældre low end enhed, det er utopi.


Nej, det er det ikke - NemID javscript koden er bevidst pessimiseret, det er ikke et spørgsmål om at den ikke er optimeret nok.

Du kan jo prøve at spørge Christian Panton hvor lang tid hans løsning tog at loade... hvis du er for doven til at finde den kommentar hvor han svarer på det.

  • 1
  • 0
Peter Stricker

Men ingen kan forvente at få high performande på en ældre low end enhed, det er utopi.


Selv hvis det tog dobbelt så lang tid som Christian Pantons løsning, tror jeg ikke at folk ville klage.

Men hvis der var nogen, der havde spået at den officielle løsning ville være et par størrelsesordner langsommere, så var de nok blevet anklaget for at tegne et for dystopisk billede.

  • 1
  • 0
Gert Agerholm

Nej, det er det ikke - NemID javscript koden er bevidst pessimiseret, det er ikke et spørgsmål om at den ikke er optimeret nok.


Jeg er ikke ekspert eller har inside viden om hvordan løsningene teknisk set er implementeret, men det har du måske. Men det er facts at ældre udstyr VIL være langsommere. Hvis man køber low end VIL det være langsommere, et eller andet sted skal man jo spare for at lave en billig mobil enhed. Udviklingen går så hurtig at for hver gang der kommer en ny iPhone (min verden) fordobles CPU power. Det sker 1 gang pr. år. Går du 3 år tilbage taler vi om 8 gange. Lowend vil nok være højst halv så hurtig som high end, så det må være min. en faktor 16 i performance. Du kan ikke bilde mig ind at en faktor 16 i performance ikke vil have indflydelse på hvor hurtig ting afvikles.

  • 0
  • 2
Sune Marcher

Jeg er ikke ekspert eller har inside viden om hvordan løsningene teknisk set er implementeret, men det har du måske.


Læs de forskellige artikler om NemID-JS løsningen her på v2 - "løsningen" har en kæmpe mængde totalt overflødig obfuskering, og det er med stor sandsynlighed dette, der medfører den ekstremt dårlige performance. (Det kan selvfølgeligt ikke udelukkes at koden, før obfuskering, også er elendig, men lad os give NETS the benefit of doubt for nu).

  • 1
  • 0
Niels Hornekær

Nu er CPU hastigheden ikke den eneste hastigheds begrænsning. For mobile netværk er pakke størrelsen mere betydningsfuld. At sende MBs over et mobilt netværk er helt klart en dårlig løsning og ikke særlig scalerbart. Desuden betaler man nogle steder for antallet af MBs transmitteret. Derudover stiller det krav til lagringsplads på klienten.

  • 1
  • 0
Gert Agerholm

Læs de forskellige artikler om NemID-JS løsningen her på v2 - "løsningen" har en kæmpe mængde totalt overflødig obfuskering, og det er med stor sandsynlighed dette, der medfører den ekstremt dårlige performance


Jeg vil slet ikke udelukke at det ikke er en optimal løsning. Det jeg bare anker lidt er at "vi" diskuterer tingene set fra "vores" synspunkt og løsnings forslag. For at komme med en klar konklusion burde man have Nets begrundelse for hvorfor det er implementeret som det er. Først da kan man sige "De tager helt fejl..." eller "nå, det er derfor de har gjort det".

Det er altid meget nemt at kritisere en løsning efter at den er implementeret. Giv dem en chance. Hvis det så fortsætter med reelt (ikke hvad vi tror) at være skrammel, så er det berettiget med klar kritik. Jeg tror at konstruktiv feedback i første omgang er meget mere gavnlig som udelukkende negativ kritik. Det gør "modtageren" mere villig til at lytte. I modsat tilfælde går de i forsvarsposition, og så kommer der ikke noget godt ud af det.

Dette er ikke specielt henvendt til dig men mere en generel kommentar til sagen.

  • 0
  • 1
Tim Lauridsen

Det tog 20s på en Samsung Galaxy SIII med Android 4.4.4

Det er nok med vilje at det er langsomt, så kan men bruge 40 millioner på at optimere det senere ved at fjerne det indbyggede delay, den gamle java version er også langsom.
Det største problem er det super dårlige ui som ikke passer til mobile skærme, selve logon boksen er for lille og skærmen der fyldt op med en kæmpe header og footer bar. folk med dårligt syn vil havde svært ved at læse det som står i logon boksen.

  • 0
  • 0
Michael Thomsen

For at komme med en klar konklusion burde man have Nets begrundelse for hvorfor det er implementeret som det er. Først da kan man sige "De tager helt fejl..." eller "nå, det er derfor de har gjort det".

Hvis du havde gidet læse lidt om sagen inden du begyndte at skrive dine gætterier, så ville du vide, at grunden til, at NemID har valgt at gøre som de har gjort er, at deres sikkerhedsekspert/konsulent har den opfattelse at security by obscurity er godt.

Det er det ikke.

Hvorfor?

Fordi det højst forsinker angriberne et par timer, dage eller i heldigste fald et par uger.

Tilgengæld sidder vi nu tilbage med en løsning, som HVER gang du skal logge på nemid skal hente 1 MB obfuskeret applet og en browser, som efterfølgende skal dekryptere appletten.

Resultatet er, at på gængse telefoner på man en "du har været for længe om at indtaste din kode" fordi browseren har været lang tid om at processere skrammeldyngen.

Det er iøvrigt forunderligt, at man i disse miljøtider ikke klandrer NETS for at splide energi aka CO2!!! på at sende 1 MB data hver gang + energi på at deobfuskere koden før afvikling.

Det er altid meget nemt at kritisere en løsning efter at den er implementeret. Giv dem en chance. Hvis det så fortsætter med reelt (ikke hvad vi tror) at være skrammel, så er det berettiget med klar kritik. Jeg tror at konstruktiv feedback i første omgang er meget mere gavnlig som udelukkende negativ kritik. Det gør "modtageren" mere villig til at lytte. I modsat tilfælde går de i forsvarsposition, og så kommer der ikke noget godt ud af det.


Nu er det ikke første produkt, som PBS/Nets/NemID har leveret. Medmindre de har skiftet holdning siden sidst, så tror jeg ikke du skal krydse fingre for hverken en forklaring ("af sikkerhedshensyn") eller noget bedre.

  • 4
  • 0
Mark Rosenstand

35 sekunder i Safari på iPhone 4S.

Det er nærmest ubegribeligt hvor tåbelige beslutninger der bliver taget i Danmark. Først vælger man et Java-plugin, der allerede ved lanceringen var så godt som dødt på web-plan. De seneste versioner af Chrome på Linux understøtter ikke Netscape plugins (herunder Java), fordi det anses som nærmest ubrugt på verdensplan. Windows- og Mac-versionerne dropper også supporten snart, så find jer en browser I kan holde ud at bruge til offentlige erindrer.

Jeg åndede lettet op da jeg hørte om skiftet til JavaScript - indtil jeg så implementeringen. Første gang jeg loggede på Danske Netbank med NemID-JS var jeg overbevist om at det stadig var et Java-plugin, fordi det gik så langsomt. Maskinen var en (lånt) laptop med noget i7 processor. Kun teksten om skiftet (samt at det var muligt at højreklikke i dialog-boksen) afslørede ved første indtryk at der var tale om JS.

Den "øgede sikkerhed" taler vist for sig selv når man kan skrive et program til at de-obfuskere(?) den. Håbløst.

  • 3
  • 0
Morten Sjøgren

Jeg var til nemid javascript seminar i sidste uge og Nets kom med den dårligste undskyldning for dårlig performance, jeg nogensinde har hørt.

Løst citeret:

Performance er en brugeroplevelse, og så vi har ikke kunne blive enige om hvad god performance er, derfor kan vi ikke sige om en enhed performer ordenligt med nemid javascript.

Vi fik demonstreret login løsningen på en moderne laptop med Chrome og selv her var det sløvt, ca. ligeså langsomt som Java løsningen.

Javascript løsningen har to modes, standard mode - som ligner Java-appletten i størrelse og limited mode - der er beregnet til mindre skærme.
Vi fik "tippet", at hvis man loader iframen med en URL, der begrænser til standard mode, så vil load-tiden blive ca. 20% kortere.
Set udefra, er de to modes er ikke forskellige nok, til det retfærdiggøre den store forskel i kodemængden.

  • 1
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize