2) MitID må ikke længere iframes, men kræver full page redirect
Det bliver da rart at se en grundlæggende sårbarhed blive fikset.
Men jeg kan helt ærligt ikke forstå hvorfor vi ikke bare kan forbedre NemID uden at det skal have nyt navn og alle skal igennem et setup step.
(Personligt ville jeg også gerne bruge min yubikey)
Rart at se bitwarden på toppen af den liste :)
Jeg har personligt været super glad for birwarden... Efter jeg flyttede fra lastpass.
Støt kulturlivet med skattekroner hvis det er du vil...
Men det her bare dumt og uærligt!
Jeg kommer ikke til at kunne bruge crypto med key escrow til en troværdig spiller. Ikke til min hjemme backup.
Og jeg kan ikke bevise hvornår den backup er taget, før eller efter lovgivningen trådte i kraft.
Og jeg kan ikke bevise at tilfældige data på min harddisk fra et tidligere wipe ikke er krypteret indhold..
Ja, helt ærligt har jeg krypterede blobs som jeg ikke kan huske password :)
Jeg kan godt se det er attraktivt at få de store virksomheder til at have key escrow. Men personligt tror jeg det bliver noget rod, lidt lige som cookie regulering..
Hvornår er det blevet kriminelt at søge oplysninger om retsplejen?
Har de ikke andre beviser?
Hmm, ja, det virker lidt urimeligt at fremlægge sådanne søgninger som beviser.
Skyldig eller ej, er det jo forståeligt at man undersøger sin egen situation.
Nogen jurister der kan forklare hvorfor man fremlægger dette?
However, due to a bug in the firmware, retrieving slot 451
during early boot fails. Therefore, p is in fact a zero buffer.
Consequently, the resulting key is constant for all devices
Wow, det er jo trivielle fejl, man kan næsten spørge om de overhovedet har testet det.
Der er nok noget om at en monokultur for C++ ikke er ideelt. Men på den anden side kunne vi måske godt klarer os uden en lukket compiler der er begrænset til Windows.
Note. der er selvfølgelig ingen risiko for at MSVC forsvinder. Der er sikkert alt for meget software som specifikt kræver den compiler.
Men at forskellige open source projekter begynder at have et brugbart alternativ på Windows er ikke skidt.
Ind til videre har man jo fravalgt mingw på Windows fordi der var performance problemer.
Flyttet vil vel ikke gøre testsituationen lettere, though?
Nej, tests vil nok altid være et problem.. men i det mindste skal der ikke installeres en compiler længere :)
Disclaimer: Indtil for en måned siden arbejdede jeg for Mozilla på taskcluster, der automatisere infrastruktur for test of release pipelines.
Mozilla bygger Firefox for Windows på Windows, hvorimod både Linux og OS X builds kører på Linux i en docker container.
Windows og OS X er nogle af de værste platform at skulle automatisere. Fordi vi ikke rigtig har en god historie for containerization. I Mozillas nuværende CI/release setup, findes der Dockerfiles i mozilla-central der specificere hvordan build og tests environments skal opbygges. Det vil sige at man kan tilpasse build/test environments ved at ændrer i kildekode og prøve tilpasningerne af med et push til try (test branch med mange hoveder).
Alt hvad man kan gøre for at flytte konfiguration ind under source control ved siden af Firefox kildekoden er en god ting. Windows og OS X testing er en blocker, da man mangler gode container løsninger. (docker for windows giver dig ikke lige frem et windows skrivebords miljø, men der er derimod nemt at kører xorg under docker på Linux).
Note: man kunne selvfølgelig bruge fulde VMs, istedet for containers, men overhead a meget højere - og det er lidt begrænset med skyer som har nested virtualization (hvilket også er langsomt). Så skal man på packet.net eller scaleway, da de tilbyder bare-metal. Det sker nok også en dag :)
Det medfører dog også andre problemer, da man så kommer til at mangle object storage som S3. Hos Mozilla replikeres artifacts mellem forskellige regions hos AWS, når der bliver hentet i en anden EC2 region. Dette holder cross-region transfer cost under kontrol. Og i en sky object storage kan man selvfølgelig bruge en caching-proxy, men det er igen flere ting der skal bygges, vedligholdes, skaleres og opdateres.
Anyways, min pointe var at frihed til at bygge under Linux giver rigtig mange muligheder i automation. Bare installationen af MSVC kan nemt blive noget rod, da man sikkert ikke må distribuere den.
For mig virker artikel 13 som et stort indgreb, og det bestemt ikke tydeligt om webhosts, etc. også vil blive pålagt filtering. For mig der heller ingen tvivl om at det ikke vil virke godt. Jeg kan godt se at intentionen er god, men jeg mener ikke at omkostningerne skal på lægges tjeneste udbydere.
Derudover, så er det vigtigt at huske at tjeneste udbydere vil implementere dette med hensyn på at minimere ansvar/risiko. Det ser vi med GDPR og cookie-loven, der ofte ses implementeret uden andet mål end at minimere risikoren for bøder. Det samme vil ses her. Udbyderne vil implementere dette på en dum måde.
Note. man kunne også kræve at alle uploads skulle underskrives med NemID eller lignende, så man aldrig kan uploaded noget uden at blive holdt ansvarlig. Dermed kan brugere som systematisk uploader rettighedskrækende materiale holdes ansvarlig. Men jeg tvivler på at det ville være mere populært hos befolkningen :)
Og kan kun opfordre til at vi får telefonerne til at kime:https://changecopyright.org/en-US/call-now
Artikel 11 og 13 udgør en trussel mod vores åbne internet.
Update: Den sekratær jeg snakkede med sagde at hendes MEP nok skulle stemme imod. Jeg har dog ikke hørt fra nogle af de danske MEPs jeg har skrevet til :)
Jeg gætter på det primært retter sig mod folk der scanner websites.
On topic, så kan det også være en god idé med en bug bounty, om ikke andet kan man sende en flaske :)
At omstille til https kan være dyrt og meget tidskrævende
At HTTPS er et krav, har været varslet i mange år. Det kan ikke kommer som en overraskelse. Og hvis du har skills til at lave et CSS hack, så har du også evner til skifte til HTTPS.
Alt skal på HTTPS, og det har været meget tydeligt de sidste 5 år. Vi har brug for HTTPS alle steder fordi vi skal vide at den information vi læser kommer fra det rigtige sted. Fordi alle sikkerheds lag har huller, så vores bedste forsvar er flere lag.
Året er 2017, der er ingen undskyldning for ikke at være på HTTPS.
Se: https://github.com/digabi/digabi-os
I kommentarer på https://news.ycombinator.com/item?id=15513698 blev det fremhævet at de i Finland beder eleverne boot en Linux distro fra usb-disk.
Det er jo relativt nemt at sætte en distro op, således at diverse programmer er installeret; at der ikke er root adgang... Man kunne måske ligefrem koble det med en keylogger og screen recorder.
Mon ikke U2F ville være en bedre løsning.
hyperFIDO koster 10 USD, Yubikey U2F koster 20 USD, Yubikey m. U2F og NFC koster 40 USD, ved bestilling af 5-10 millioner kunne man nok få lidt rabat :)
Og ja, indtil NFC+U2F er bedre understøttet, så bliver mobil support måske noget med at man skal godkende mobilen ved at logge ind på en computer (ved første login).
I sidste ende vil spørgsmålet om kryptografi blive afgjort politisk
Måske, vores bank og betalings systemer er jo stadig meget primitive når det kommer til sikkerhed. Hvordan forestiller vi os at et "ansvarligt" krypterings system skal kunne fungere, når vi knap nok kan administrer sikker betaling online.
Bemærk at vi i denne uge igen snakker om et kæmpe hul i en sikkerhedskrititisk protocol, denne gang WPA. Og der er idag ingen der tror det bliver det sidste store hul vi finder. Så den eneste medicin jeg kan påskrive er flere uafhængige lag af sikkerhed. Hvordan skal det kunne lade sig gøre med "ansvarlige" bagdøre?
Jeg mindes et (formentligt bevist) provokerende debat indlæg af PHK... Hvor der blev argumenteret imod HTTPS.
Mit argument for HTTPS var at flere sikkerhedslag er nødvendigt; fordi de fleste af vores sikkerhedslag har masser af huller. Og det her er nok hverken den første eller sidste mandag vi vågner op til et gigantisk hul et sted i stakken.
Note. til API'er bruger jeg gerne HTTPS + en "authorization" header med en per-request HMAC, netop fordi der nok kommer endnu en bug i HTTPS.
- Public buckets er fint til offentlig data
- Der er ingen grund til kryptere offentlig data
Jeg kan godt lide at lukke for object-listing for at tvinge folk gennem mit API.. Men jeg kan godt forstå at man fra vælger den slags, da det giver 403 istedet for 404 når et objekt ikke kan findes.
Personlig giver jeg ikke meget for Amazons server-side kryptering, det er måske en smule bedre end ingenting.. Men end-to-end er det eneste der for rigtigt gør en forskel.
Bøder fikser ikke dårlig software...
Tag f.eks. problemet med ukrypterede emails, hvis vi nu krypterede alle emails så var det ikke et problem mere. Istedet forsøger man at lærer folk hvad de må og ikke må sende per mail...
(email er bare et eksempel på software systemer der skal tænkes lidt om)
Jeg synes lige vi skal huske at der her handler om IT sikkerhed.
definerer Poul Henning-Kamp som hvid, hankøn, højtlønnet og barnløs
Det samme kunne man sige om håndvåben...
Giftige paralleler til højreorienterede Trumpere i Amerikansk politik er ikke passende her, håndvåben er ikke det samme som hemmelige samtaler... Der er mange andre farlige/dumme/skadelige former for ytringer som vi glædeligt lader aviserne printe.
IT sikkerhed er og bliver en af de helt store udfordringer, ikke mindst på grund af manglende økonomiske incitamenter. Og for at lave et sikkert IT system skal man have flere uafhængige lag af sikkerhed.
- HTTPS er et lag,
- Netværks sikkerhed er et andet lag,
Selv hvis hverken min ISP eller regering er et problem. Så er der idag millioner af mennesker med kompromitterede wifi routers. Utallige krompromitterede devices på dit LAN netværk, etc... Og rigtigt mange mennesker har en computer inficeret med diverse malware, og selv om lokal malware kan installere et rodcertifikat, så gør det stadig et angreb mere besværligt.
Mht. til at have en nedgraderet TLS spec der ikke er krypteret, men kun verificere kilden, så tror jeg nok det skib er sejlet. Desuden vil der unægteligt være tusindvis af dumme sikkerheds huller hvor kryptering vil begrænse skaden.
Note: børshandler, nyhedsmedier, etc, har alle login detaljer og cookies, for slet ikke at tale om meta-data fra børshandler/besøg som kan bruges til automatiske mod handler (at vise interesse får prisen til at stige).
Der er mange grunde til at ville have HTTPS alle steder, det er ikke kun it-liberalister. Flere uafhængige lag af sikkerhed er nødvendigt, i dag har alt for mange kritiske systemer kun et lag.
Jonas Finnemann Jensen