IP+port+tid ja .... men i min løsning skal ingen af delene gemmes. Kun ID.
Med hensyn til den manglende fornyelse. Informationen om at B og C begge har mødt A sendes ingen steder hen - der kræves fysisk adgang til enheden for at hante data ud. Den centrale server er kun til for at have en liste af ID'er der er potentielt smittede. Denne liste opdateres "manuel" ved at min mobiltelefon tappes for kontaktede ID'er når jeg testes positiv.
Vi er enige om årivatlivsbeskyttelsen i dine 2 designs er forskellige.
Ny er jeg på ingen måde privacy ekspert, men hele ideen om at lave et system til at opspore folk OG SAMTIDIG opnå 100% privatliv lader sig nok ikke gøre.
Well.....
IP-adresser på mobilnætværk deles for det mest så mange andre vil anvende samme IP.
ID'et kan som jeg siger bare være random - men det ikke destå mindre aldrig fornyet. Idéen er at det skal være stort nok til at undgå kollisioner.
Design med en central server har vel egentlig intet med privacy at gøre.
Så i min løsning er man helt privat - med undtagels af måske IP (man ved med sikkerhed at han ikke befindersig i tyskland hvis éns IP befinder sig i Danmark) og det faktum at man spore mit ID og dets kontakt til and ID'er. Og det er jo netop meningen!
Nu har jer ikke læst alle kommentarerne - og heller ikke næranalyseret selv indlægget, men jeg forestiller mig følgende simple løsning
En app på alle mobiltelefoner udsender via. bluetooth et unikt ID - lad os sige sha512(imeinr+bluetoothadresse) eller bare sha512(usec tid + 1024 random data). Den selvsamme app noterer de ID'er som andre instanser i nærheden udsender. De data gemmes lokalt og sendes ingen steder hen.
Hvis jeg konstateres smittet tappes min telefon for de ID'er jeg har været i nærheden af. De ID'er placeres på en central server på sikker vis (app'en må ikke selv kunne gøre dette). ID'erne markeres med smittestatus (nej,måske,ja)
Appen kontakter periodisk en central server og spørger om status på ens eget ID.
De to version er ikke samme software. Skype for business er blot Microsft Lync med et andet navn.
Hvad menes der med at kernen er krypteret. Er den kryptere på disk? Er hele disken krypteret? Er kernen krypteret i ram? Jeg forstår ikke hvad der menes.
2 mil pr. revisor (en virkelig dyr en). Det giver jo så 300000 stk. ansat i 10 år. :D
Jeg synes de taber ALLE småkagerne gang på gang.
:D ok - jamen det er jo glimrende. Prøv i øvrigt lige at regne ud hvor lang tid man kan lønne 50 softwarefolk for 900 mio. kr. Jeg får det til omkring 30 år.
Tværtimod.
De 50 folk ville komme til at sidde tæt ved de mennesker der skal bruge systemet. Tidlige udgaver vil kunne prøvekøres tidligt og rettes til efter brugernes ønsker. Har du mange uafklarede aspekter i et software projekt er det en fornuftig måde at gøre det på.
Derudover så ville softwarefolkene være ansat i SKAT - og derved er det ikke konsulent- og kontraktfriktion og løbende tilrettelser - selv efter systemet er leveret - vil ikke udgøre et problem.
Jeg tror ikke fejlen var at bygge det som ét stort system. Jeg tror fejlen ligger i at man ikke ansatte 50 softwarefolk og lavede systemet selv.
De fleste TT-skærme kører 60 Hz. Enkelte kører 100 Hz ....Så mere end 60 fps giver typisk ikke mening. 120 fps giver slet ikke mening - det går jo ikke op i 100.
Det er et godt spørgsmål, men takket være dig er vi nu alle HELT VÅGNE. Jeg var ellers ved at blunde igen efter Peters udemærkede indlæg :D
Mon ikke det er 5GHz?
Når det så er sagt, so er linux/*bsd distroerne atså kvikke til at patche deres pakke. Thumbs up!
Jo jo - jeg er bare stadig lidt ærgelig over de mange "Ja" stemmer. Jeg troede folk efterhånden var lkar over at når det drejer sig om EU så er det bedst bare at stemme "Nej". Vi kan altid komme med bussen senere - og når man først er kommet med kan man ikke stå af.
Jeg tror sq at det er alle de andre stemmer der er indrapporteret forkert. Med den tilslutning DF fik virker det utroligt at det blev et "Ja".
Mon ikke Java på et tidpunkt om ikke så mange måneder køler lidt af. Antallet af sikkerhedshuller der findes kan jo ikke bliver ved. Desuden så får Nets jo stadig opdateringerne til test inden i frigives.
Det har du naturligvis ret i. Jeg mente blot at det var relevant at nævne at selvom man havde anvendt alle 64 bit, så havde ikke hjulpet noget fordi det anvendte cipher kan bryde.
Så vidt jeg ved er problemet med GSM og for den sags skyld også blutooth ikke nøglelængden. Det er derimod det faktum at de begge anvender et cipher der er baseret på en særlig kombination af linære skifteregistre. Det kan brudes uanset om de sidste 10 bit i nøglen er 0 eller ej.
Her er det vel vigtigt at påpege at ChromeOS også er Linux. Dog er det naturligvis ikke Ubuntu eller lignenede, men alligevel.
Søren Holm