Microsoft får på hattepulden over dårlig ODF-understøttelse i Office 2007

ODF-alliancen beklager sig over, at Microsofts understøttelse af Open Document Format er inkompatibel med andre ODF-applikationer.

Alt imens Microsoft mener, at de med Service Pack 2 til Office 2007 har implementeret ISO-standarden Open Document Format, giver ODF-alliancen nu igen med grovfilen.

ODF-alliancen tæller medlemmer som f.eks. IBM og Sun Microsystems, og i et factsheet klager lobbyorganisationen over manglende understøttelse af ODF-formatet i Office-pakken. Også kompatibiliteten med andre ODF-understøttende applikationer er utilstrækkelig, mener ODF-alliancen.

Blandt andet bliver softwaregiganten kritiseret for, at Office 2007 som udgangspunkt afviser at åbne password-beskyttede filer i stedet for blot at bede om adgangskoden. Det skriver h-online.com

Ligeledes håndteres 'track changes' uhensigtsmæssigt, så revions-ændringer gemt i andre applikationer ikke dukker op, når dokumentet åbnes i Office 2007.

ODF fortolker disse pointer som tegn på, at Microsoft ikke har nogen reel interesse i sømløs integration af ODF-dokumenter, hvilket ifølge alliancen også understreges af, at Microsoft allerede med Office 2003-pakken lovede ODF-integration ? og fejlede.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (53)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Martin Kjeldsen

Det er ikke de værste problemer. Fx problemer med formler i regneark. Se http://www.odfalliance.org/resources/fact-sheet-Microsoft-ODF-support.pdf.

Et af problemerne for nogle er at tilsyneladende at understøttelsen af ODF i Office 2007 dårligere end MS' eget CleverAge Add-in til 2003 (http://www.robweir.com/blog/2009/05/update-on-odf-spreadsheet.html). At understøttelsen er blevet dårligere synes nogen er mistænkeligt...

  • 0
  • 0
Jasper Bojsen

[b]Om Track Changes[/b]
Det er korrekt at Microsoft ikke har implementeret ”track changes” (på dansk ”Registrér ændringer”). Det har Microsoft valgt ikke at gøre, fordi ODF specifikationen er så tvetydig og utilstrækkelig på dette område, at det ikke er muligt at imødekomme det funktionalitetsniveau, som brugere af denne funktionalitet forventer.

Track changes anvendes af mange mennesker hver dag til udarbejdelsen af f.eks. kontrakter og studieopgaver og i mange andre situationer, hvor flere personer arbejder sammen om et dokument. Det siger sig selv at forventningen om forudsigelighed og høj kvalitet er helt essentiel når to eller flere personer arbejder sammen om et dokument. Den forudsigelighed er ODF ikke i stand til at levere.

Sagen er i øvrigt den at pga. manglerne i ODF specifikaitonen, er der reelt ingen ODF implemenering som kan levere den nødvendige kvalitet, heller ikke f.eks. OpenOffice, Lotus Sympohony, som hurtigt kan bruges til at opføre sig uforudsigeligt når dokumenter gemmes i ODF.

Man læse mere om de tekniske detaljer omkring netop dette emne beskrevet her: http://blogs.msdn.com/dmahugh/archive/2009/05/13/tracked-changes.aspx

I dettte blog indlæg fremgår det bl.a. også hvorledes man ved selvsyn kan opleve manglerne i ODF specifikationen ved at gennemføre nogle simple test i OpenOffice eller Lotus Symphony. Ligeledes kan man læse hvorledes der findes i alt 4 sider i ODF specifikationen, der beskæftiger sig med Track Changes, mens der til sammenligning findes 121 sider i Open XML.

Open XML har i øvrigt intet problem med at håndtere Track Changes.

Såvidt jeg er bekendt så vil ODF 1.2 ikke indeholde nogen forbedringer til dette område.

[b]Om password beskyttelse af ODF dokumentet[/b]

Ved gennemlæsning af ODF 1.1 specifikationen vil man opdage, at det er den samme linie som går igen og igen når der tales om password-beskyttelse, nemlig: ”[i]To avoid saving the password directly into the XML file, only a hash value of the password is stored.[/i]”

Det siger sig selv at denne linie er ikke er tilstrækkelig. Der fremgår f.eks. intet omkring hvilken hash-algoritme som skal anvendes. Uden denne viden er det selvsagt ikke muligt at åbne dokumentet i et andet program.

Igen kommer ODF specifikationen til kort i forhold til Open XML og der findes reeelt ikke nogen måde med ODF 1.1 hvorved det er muligt at implementere password på en forudsigelig måde, som følger standarden.

[b]Om formler i regneark[/b]
ODF 1.1 specificerer ikke formler i regneark og derfor findes der ikke nogen ODF standard måde at beskrive formler i regneark på. Dette har gennem tiderne skabt mange problemer mellem programmer som f.eks. OpenOffice, Lotus Symphony og KOffice.

For flere detaljer herom foreslår jeg dette blog indlæg: http://blogs.msdn.com/dmahugh/archive/2009/05/09/1-2-1.aspx

[b]Generelt[/b]

Det er intet mindre end absurd at kritisere Microsoft for ikke at implementere, det som ODF ikke specificere selv (bekalger dobbelt negationen). Ligesåvel som det er absurd at kritisere Microsoft for at ODF på visse områder er for tvetydig og mangelfuld. Mere om det her: http://blogs.technet.com/gray_knowlton/archive/2009/05/11/clearing-up-a-...

Sagen er den af Microsofts implementering af ODF 1.1 specificationen sandsynligvis er den mest tro implementering af ODF 1.1 som overhoved findes i dag. Det er i hvert fald den mest gennemsigtige implementering, for det er nemlig muligt at læse alt om de beslutninger, som Microsoft har måtte tage i implementeringen ODF i de implementeringsnoter som Microsoft har offentliggjort her: http://www.documentinteropinitiative.org/

Jeg har skrevet lidt mere gerenelt om implementeringen af ODF i Microsoft Office her: http://blog.hvorom.dk/post/2009/04/15/ODF-support-i-Microsoft-Office-200...

Jasper H. Bojsen,
Microsoft Danmark
Info: http://blog.hvorom.dk

  • 0
  • 0
Peter Stricker

Open XML har i øvrigt intet problem med at håndtere Track Changes.

Fint for Open XML. Men vil du ikke lige definere hvad det er du kalder Open XML.
Er det det lukkede format der bruges af Microsoft Office 2007, og som aldrig nogensinde skal gøre sig forhåbninger om at blive anerkendt som ISO standard?
Eller er det det dokumentformat der er kendt som ISO-29500, og som der endnu ikke findes en implementering af?

For jeg går ikke ud fra at du mener Open XML ( http://www.philo.de/xml/ ).

  • 0
  • 0
Poul-Henning Kamp Blogger

”To avoid saving the password directly into the XML file, only a hash value of the password is stored.”

Det siger sig selv at denne linie er ikke er tilstrækkelig.

Det er fuldt ud tilstrækkeligt, hvilket alle med blot en lille bitte forstand på sikkerhed ved.

For det første er alle relevante password-hash algoritmer idag selv-identificerende.

For det andet: selvom de ikke var, kan du bare køre det password brugeren angiver igennem alle de algoritmer du har til rådighed i systemt og se om en af dem matcher.

Hvis du mener der er nogen relevant risiko ved at gøre dette, er det fordi dit system indeholder trivielt svage password-hash algoritmer der for længst burde have været fjernet.

Poul-Henning

  • 0
  • 0
Jesper Lund Stocholm Blogger

PHK,

Det er fuldt ud tilstrækkeligt, hvilket alle med blot en lille bitte forstand på sikkerhed ved.

For det første er alle relevante password-hash algoritmer idag selv-identificerende.

Det vidste jeg faktisk ikke. Vil du dermed sige, at du ud fra fx "KPJA3nE8Da+/V6ES9EOep/XQGBs" kan fortælle mig, hvilken hashfunktion, salt, spincount etc, der er brugt?

Men derudover er det nu ikke den såkaldte "document protection", der er det rigtige problem her - det er password-beskyttelse på pakkeniveau, dvs kryptering.

  • 0
  • 0
Jasper Bojsen

[b]Poul-Henning Kamp sagde:[/b]
Det er fuldt ud tilstrækkeligt, hvilket alle med blot en lille bitte forstand på sikkerhed ved.

Det har jeg nu svært ved at se logikken i, og desuden forholder du dig f.eks. heller ikke til det faktum at "Track Changes" er underspecificeret i ODF.

Måske du var lidt for hurtig med at kaste "vrøvl, dårlige undskyldninger FUD og spin" stenen?

Sagen er at ODF måske nok er en interessant specifikation - som i øvrigt er væsensforskelligt fra Open XML specifikationen -, men ODF kan dog ikke stå alene og ej heller opfylde alle de behov som brugerne i dag forventer, af et filformat som skal understøtte en moderne kontorpakke. Det er specielt manglerne ift. track changes et godt og illustrativt eksempel på.

Jasper H. Bojsen,
Microsoft Danmark
Info: http://blog.hvorom.dk

  • 0
  • 0
Poul-Henning Kamp Blogger

(Læs jeres lektier om kryptering og passwords før i udtaler jer om den slags.)

Når jeg kalder jeres udgydelser her for FUD og spin, er det fordi det er tydeligt for enhver, at i prøver at forsvare beslutninger der er taget i ond tro af Microsoft alene for at forhindre konkurrence med MS-Office pakken.

Grundloven i kompabilitet hedder: "Be liberal in what you accept, be conservative in what you produce".

Microsofts wanton ignorering af relevante informationer i ODF filer, har kun til formål at skade interoperabiliteten.

Hvis Microsoft ville interoperabilitet, ville de ikke ignorere relevante data med dårlige undskyldninger som "fordi de ikke er gode nok".

Endelig synes jeg det er meget underholdende at høre Microsoft belære andre om hvor vigtigt det er at følge standarder præcist.

Hvis det er så vigtigt, gider I så lige rette de fejl der er i Microsofts misbrug af Kerberos protokollen ?

Eller er disse specifikations-varianser ikke vigtige, fordi de er til Microsofts fordel ?

Etik, Microsoft har ikke hørt om det.

Poul-Henning

  • 0
  • 0
Jesper Lund Stocholm Blogger

Hej Poul-Henning,

(Læs jeres lektier om kryptering og passwords før i udtaler jer om den slags.)

Jeg spørger jo sådan set bare om noget, som jeg tilsyneladende ikke vidste så meget om, som jeg troede.

Er du ikke sød at uddybe, hvad du mener med, at en hash-funktion (værdi) er selv-identificerende? Det var min opfattelse, at anvendelsen af en hash-funktion resulterede i en tilfældig række bits - hvilket i mine øjne ville gøre det svært at detektere, om der var brugt en specifik funktion.

Hvis du har et link til noget information om det, så vil jeg sætte pris på det.

Når jeg kalder jeres udgydelser her for FUD og spin, er det fordi det er tydeligt for enhver, at i prøver at forsvare beslutninger der er taget i ond tro af Microsoft alene for at forhindre konkurrence med MS-Office pakken.

Jeg synes, at du bruger ordet "jer" lidt i flæng. Mit indlæg var - så vidt jeg selv vurderer - et opklarende spørgsmål samt en kommentar om, at kritikpunktet fra ODF Alliance gik på kryptering af en pakke - noget, der er fuldt specificeret i ODF 1.1.

:o)

  • 0
  • 0
Jasper Bojsen

[b]Poul-Henning Kamp skrev[/b]:

Hvis Microsoft ville interoperabilitet, ville de ikke ignorere relevante data med dårlige undskyldninger som "fordi de ikke er gode nok".

Microsoft vil og kan skam interoperabilitet, men sagen er nu en gang den at ODF specifikationen på visse punkter ikke er god nok, fordi den er underspecificeret og tvetydig eller begge dele.

Jeg ved godt at [i]det bedste forsvar er et angreb[/i], men i stedet for at skyde til højre og venstre synes jeg det kunne være interessant om vi startede med at forholde os helt konkret til "track changes", som jo også bliver omtalt i artiklen ovenfor.

Kan du f.eks. vise mig en ODF implementering af track changes som virker tilfredsstillingen og forudsigeligt? Jeg har ikke fundet nogen, men måske du har måske en ide til hvor jeg kan lede?

Jasper H. Bojsen,
Microsoft Danmark
Info: http://blog.hvorom.dk

  • 0
  • 0
Morten Abildgaard

Microsoft vil og kan skam interoperabilitet...

Hvis det er tilfældet havde det så ikke været mere rentabelt og givende for alle brugere af diverse Office-pakker, at bruge ODF som grundlag i MS Office 2007, og arbejde videre med det i stedet for at opfinde Open XML og indføre det som ISO-standard osv.

  • 0
  • 0
Poul-Henning Kamp Blogger

Hashede password strenge er selvindentificerende på to måder.

Intelligente folk giver deres hash-funktioner en prefix-string, som f.eks "$1$" så de er explicit selvidentificerende, det gør det lidt nemmere.

Men alle password hashes er per definition selvidentificerende på den måde, at du får den samme streng ud, hvis du kører det samme password igennem den samme algoritme med samme salt.

Derfor er det noget fis at man ikke kan checke et password uden at kende den præcise algoritme der er brugt: man kan bare prøve alle de algoritmer man har til rådighed.

Se også: http://phk.freebsd.dk/pubs/ieee.software.pdf

Poul-Henning

  • 0
  • 0
Martin Kofoed

"Stol Tilbage - Kaffe I Kop".

Denne debat har alle ingredienser til at blive en voldsomt underholdende sag. Det er dårligt nok nødvendigt at røre rundt i dén her cocktail:

  • Jasper tungt lastet med de seneste hårdtslående argumenter direkte fra Microsofts Intranet.

  • "Open XML er ikke en dokumentstandard"-triggeren. Denne gang endda med link til .. Tadaa, Open XML.

  • PHK beder folk om at læse op på det stof, de vælger at kritisere. Det er naturligvis håbløst umoderne, og det burde PHK vide.

  • Jesper som i stadigt stigende grad forsøger at lægge en smule afstand til det hele, og helst bare vil fremstå som den uvildige part.

  • Etik? Er det ikke sådan lidt udgået? Dømt for anløben moral flere gange? Come on.. Nu ser vi fremad!

Det kan KUN blive bedre .. :-)

  • 0
  • 0
Jesper Lund Stocholm Blogger

Hej Poul-Henning,

Hashede password strenge er selvindentificerende på to måder.

Intelligente folk giver deres hash-funktioner en prefix-string, som f.eks "$1$" så de er explicit selvidentificerende, det gør det lidt nemmere.

Ok - vi kan altså konkludere, at de, der lavede den hash-funktion jeg inkluderede, ikke er intelligente. Vi må også understrege, at et "prefix" på værdien ikke har noget med selve algoritmen at gøre men blot er en mulig konvention for persistering af hash-værdier. I den hash-værdi jeg nævnte findes dette prefix ikke, så den sociale konvention du nævner hjælper ikke meget her.

Men alle password hashes er per definition selvidentificerende på den måde, at du får den samme streng ud, hvis du kører det samme password igennem den samme algoritme med samme salt.

Undskyld - men det er jo noget pjat.

Du skrev jo

[b]Poul-Henning:[/b]
Det (at der i ODF-spec blot står, at man skal putte en hash-værdi i en attribut uden at kunne specificere algoritme, salt, spins etc, JLS) er fuldt ud tilstrækkeligt, hvilket alle med blot en lille bitte forstand på sikkerhed ved.

Og nu siger du, at den er selvidentificerende, hvis man kører brugerens password) igennem samme hash-værdi og salt, da man derved får samme værdi. Men PHK, problemet er jo, at vi ikke kender hash-værdien og et eventuelt salt eller spincount.

Jeg er helt sikker på, at du ved meget mere om sikkerhed end jeg, men jeg er også sikker på, at du tager fejl her. Jeg kender i øvrigt godt din glimrende artikel - jeg har læst den flere gange tidligere. Jeg synes blot ikke, at den hjælper os meget med vores konkrete problem.

Derfor er spørgsmålet jo stadig, hvordan du kan identificere den anvendte hash-værdi, salt, spins etc ud fra selve hash-værdien? Hvordan vil du ellers verificere, at brugerens indtastede password er korrekt?

  • 0
  • 0
Poul-Henning Kamp Blogger

@Jesper:

Mht. til passwords: Hvis program A kan finde ud af at verificere et password i en given fil, så kan program B også.

Den kontekst A bruger kan B også bruge.

Det du omtaler som "salt, spins" mv. er, hvis de ikke er den del af den hashede streng, en del af algoritmen.

Ellers ville program A heller ikke kunne verificere passwordet.

Microsoft vil ikke have ODF til at virke som interoperabelt format og derfor opfinder de alle mulige stråmændsargumenter for hvorfor de gør et elendigt stykke arbejde med disse filer.

Længere er historien ikke.

Microsoft prøvede samme trick med TCP/IP, webservere, filservere, brugerauthentificering osv. osv.

Det er bad faith, hele vejen ned.

Poul-Henning

  • 0
  • 0
Jasper Bojsen

Microsoft vil ikke have ODF til at virke som interoperabelt format og derfor opfinder de alle mulige stråmændsargumenter for hvorfor de gør et elendigt stykke arbejde med disse filer.

Det er ikke korrekt, men du har naturligvis lov til at spekulere og tro hvad du vil. Microsoft [b]vil[/b] gerne, men der er ting som ODF ikke kan og det er i sagens natur svært at komme udenom.

Microsoft har i øvrigt indrapporteret 15 forslag til forbedringer af ODF, som alle blev afvist til ODF 1.2, men vi kan da håbe at de kommer med senere. Se bunden af denne artikel: http://blogs.msdn.com/dmahugh/archive/2009/05/13/tracked-changes.aspx

Hvornår forholder du dig i øvrigt til Track Changes? Track Changes er "broken" i ODF, men hvorfor ikke bare komme til tovs med det og fokusere på hvorledes vi kan få det fikset i ODF 1.3, 2.0 eller hvad den nu kommer til at hedde om 2-3 år?

Jasper H. Bojsen,
Microsoft Danmark
Info: http://blog.hvorom.dk

  • 0
  • 0
Poul-Henning Kamp Blogger

Jeg har ikke tænkt mig overhovedet at beskæftige mig med "track changes". Jeg opponerede alene imod det spin der blev fud'ed ud omkring passwords

Jeg er sikker på at man kan få meget tid til at gå med at finde ud af om "Microsoft vil have interoperatbilitet" eller ej, men det er formålsløst og tidsspilde.

Lad os istedet se om Microsoft arbejder aktivt henimod interoperabilitet eller ej.

Når man fyrer sådan noget vås af, som ovenfor om passwords, så er det tydeligt at man enten er A) 100% inkompetent, eller B) bruger enhver undskyldning for at gøre interoperabilitet til et problem.

Jeg ved at Microsoft har folk der har forstand på passwordbeskyttelse, jeg har talt me dem.

Ergo: B

Poul-Henning

  • 0
  • 0
Jesper Lund Stocholm Blogger

Hej Poul-Henning,

Mht. til passwords: Hvis program A kan finde ud af at verificere et password i en given fil, så kan program B også.

Den kontekst A bruger kan B også bruge.

Jeps - og det er vi helt enige i. Men dermed er dit udsagn fra tidligere jo også noget ævl. Du sagde jo, at selve hashværdien var nok - men du erkender nu, at man naturligvis skal bruge noget mere end den - evt kildekoden eller "kontekst" fra den applikation, der har genereret hashværdien.

Derfor begynder dit udsagn om, at hashværdien er "fuldt ud tilstrækkeligt, hvilket alle med blot en lille bitte forstand på sikkerhed ved" sgu efterhånden at runge lidt hult ...

Jeg synes ærligt talt, at du skulle stoppe dette her og blot erkende, at du var liiiige hurtigt nok ude med at tale om, hvor meget andre ved om sikkerhed.

  • 0
  • 0
Poul-Henning Kamp Blogger

Jesper,

Igen: tag lige og læs lidt kryptgrafiske grundbøger, det du siger er enten uinformeret vrøvl eller et bevidst forsøg på Microsoftbeskyttende flueknepperi.

Lad os lige skære det ud i pap:

Hvis OpenOffice kan verificere passwordet, hvorfor kan Office så ikke ?

OpenOffice er open source, hvad er det præcist Microsoft mangler, som de ikke kan finde i kildeteksten ?

Og hvis vi skal tage krydsfiner i brug:

Hvorfor er det OK at OOXML har en "formatter tekst som Word97 ville gøre det", men ikke OK for Office at implementere "check password som OpenOffice gør det" kode ?

Dobbeltmoralen er som altid tyk hos Microsoft apologister og spinnere...

Beviset på viljen til interoperabilitet er at man forsøger på det, det er tydeligt at Microsoft istedet forsøger at kaste grus i maskineriet.

Poul-Henning

  • 0
  • 0
Jesper Lund Stocholm Blogger

Hej Poul-Henning,

Igen: tag lige og læs lidt kryptgrafiske grundbøger, det du siger er enten uinformeret vrøvl eller et bevidst forsøg på Microsoftbeskyttende flueknepperi.

pfffffft! Lad os ikke glemme, at det var dig, der kom med et argument, som du ikke kan retfærdiggøre med andre udsagn end det poetiske "slå det op".

Hvis OpenOffice kan verificere passwordet, hvorfor kan Office så ikke ?

OpenOffice er open source, hvad er det præcist Microsoft mangler, som de ikke kan finde i kildeteksten ?

Jeg tror ikke, at der er noget Microsoft mangler ifht at kunne læse og forstå hashværdien i et ODF-dokument. Jeg synes lige som dig, at Microsoft skulle have kigget på Postel's Robustness principle og have implementeret understøttelse af læsning af værdierne genereret af fx OOo. Hvis algoritmen ikke levede op til Microsofts krav, så kunne de for min skyld have gemt vha en anden hash-funktion - blot de specificerede hvordan.

Dobbeltmoralen er som altid tyk hos Microsoft apologister og spinnere...

Ja, og du bliver ved med at referere til "spinnere" - uagtet at jeg på intet tidspunkt her har taget Microsoft i forsvar eller argumenteret for, at deres beslutning er god.

Synes du virkeligt, at det gør dine argumenter (som du ikke kan argumentere for) bedre, at du bliver ved med at referere til "spinnere"?

Det kan kun siges på én måde, PHK: "Det er for tyndt", og det er jeg sikker på, at du er klar over. Ellers ville du jo bare forklare, hvordan en hash-værdi kan være selv-identificerende.

  • 0
  • 0
Poul-Henning Kamp Blogger

Når jeg henviser dig til at læse en bog om emnet, er det fordi jeg allerede har forklaret det med den nødvendige tydelighed til at folk der ved blot et minimum om password beskyttelse er med.

Det gør du tydeligvis ikke:

Når man laver en hash af et password med en envejsfunktion får man som output en bitsekvens der er en funktion af to input: Det indtastede password og den brugte envejsfunktion.

(De frustrations faktorer du nævner ovenfor, salt mv. er enten den del af envejsfunktionen, eller de bliver kodet ud i bitsekvensen så envejsfunktionen kan finde dem når password skal verificeres. I begge tilfælde har de samme tilgængelighed som resten af delene).

Hvis du har en sådan bitstreng og en liste af mulige envejsfunktioner, så vil det rigtigt indtastede password virke som orakel der fortæller dig hvilken af de mulige envejsfunktioner der blev brugt.

Ved samme lejlighed får du også den viden du i virkeligheden har brug for: at passwordet er indtastet korrekt.

Dermed er det hash'ed password selvidentificerende.

(Med fornuftigt designede envejsfunktioner er sandsynligheden for at du opnår et falsk match, med en anden algoritme og et forkert password, for alle praktiske formål nul.)

Hvis du ikke er i besiddelse af det korrekt indtastede password er det inderligt ligegyldigt for dig hvilken envejsfunktion der er brugt og manglen på den viden stiller dig ikke på nogen måde i nogen ringere stilling.

QED.

Poul-Henning

  • 0
  • 0
Henrik Jensen

OpenOffice er open source, hvad er det præcist Microsoft mangler, som de ikke kan finde i kildeteksten ?

Problemet med dette argument er jo at det kan bruges om alting, om det så er understøttede hash-funktioner, track changes, formler og hvad der ellers har mangler i specifikationen.

Efter min mening så bør man enten droppe ODF + OOXML helt som dokumentstandarder og så udelukkende forsøge at sikre interoperabilitet ved at kigge i hinandens kildekode, og ellers så skal man specificere alt det nødvendige i standarderne. Det med blot at specificere en vis portion i standarderne, for derefter at påpege at resten kan man læse i kildekoden til den applikation man mener der har den bedste implementation, det virker altså bare useriøst.

  • 0
  • 0
Jesper Lund Stocholm Blogger

Hej Poul-Henning,

(De frustrations faktorer du nævner ovenfor, salt mv. er enten den del af envejsfunktionen, eller de bliver kodet ud i bitsekvensen så envejsfunktionen kan finde dem når password skal verificeres. I begge tilfælde har de samme tilgængelighed som resten af delene).

Ja, se nu begynder det jo at ligne noget - for det er her jeg ikke forstår dig. Du siger jo herover, at selvom et SALT var blevet anvendt i udregningen af hash-værdien, så behøves den ikke eksplicit, når et password skal verificeres.

http://en.wikipedia.org/wiki/Salt_(cryptography)

Jeg er med på, at hvis du får en hashværdi på 0x123, så kan du - givet passwordet fra brugeren - tage din liste af hash-funktioner og løbe den igennem fra ende til anden. I det øjeblik du får værdien "0x123" ved du, at brugeren har fat i det rigtige password, ex "PHK" (og så taler vi ikke om kollisioner her, da det - som du selv nævner - er en kende urealistisk at det skulle ske).

Men hvis SHA512-værdien for "PHK" var 0xab4296cd343fe", så ville værdien af PHK hashet med et salt jo være anderledes. Når du så udregner hashværdien og skal sammenligne dem, så vil du jo få "0xab4296cd343fe", da du jo netop ikke kender det salt, der blev anvendt.

Men her siger du altså, at man slet ikke behøver det salt til at verificere det angivne password og tilhørende hashværdi?

Når jeg er så interesseret i dette skyldes det, at OOXML i store træk var lige så uspecificeret som ODF, da OOXML blev sendt til ISO. Her kunne man dog angive, om algoritmen var fx SHA1, MD5 eller lignende. Men i forbindelse med ISO-processen blev det lavet om, så man nu kan specificere følgende værdier:

  • algorithmName
  • spinCount
  • saltValue
  • hashValue

Men det du siger er altså, at man ikke kan komme i den situation, at man skal bruge "Spin Count" eller "Salt Value", da man altid vil kunne finde disse informationer fra selve værdien? Eller er antagelsen, at alle implementeringer altid skal bruge samme spin count og salt - uanset hvilke krav man som organisation måtte have?

  • 0
  • 0
Poul-Henning Kamp Blogger

For mange år siden brugte folkene bag internettet en hel konference på at sikre at tingene virkede sammen.

Den hed INTEROP. Firmaer mødte op med deres computer og netværkskode og så blev dere ellers delt strafpoint ud, når der var ting der ikke virkede.

Det medførte rettelser i netværkskode men også rettelser til standarder, når man opdagede at de var uklare eller inkonsistente.

Det virkede rent ud sagt fantastisk og var en af de primære grunde til at Internettet faktisk virker.

Forudsætningen for en sådan tilgangsmåde er at alle deltagere ønsker at ting skal virke sammen.

Der er intet der tyder på at Microsoft ønsker dette og derfor vil ingen metode kunne få et godt resultat frem:

Man kan trække hesten til vandtruget, men ikke tvinge den til at drikke.

Poul-Henning

  • 0
  • 0
Poul-Henning Kamp Blogger

[quote[...] se nu begynder det jo at ligne noget - for det er her jeg ikke forstår dig. [...][/quote]

Nej, det er her du ikke forstår nok om kryptografi, du har tilsyneladende ikke ordforrådet til at forstå min forklaring...

Her er to ting at tænke over:

Hvis et salt er per instance, det vil sige at der vælges et nyt salt hver gang der vælges et nyt password, så er du pine død nødt til at kode det i den bitstreng der kommer ud.

Hvis saltet ikke er per instance, er det ikke et salt, men en konstant der indgår i envejsfuntionen.

En envejsfunktion kan godt være sammensat af flere trin, men det er stadig en envejsfunktion i denne sammenhæng.

Hvor mange gange man vælger at bruge f.eks SHA256 i sin envejsfunktion er blot en del af funktionens definition,
eller, hvis hvis man vælger hvor mange gange per instance, en del af salt (se ovenfor).

Hvad ISO har valgt at gøre med OOXML er blot at flytte en del af algoritmespecifikationen ind i dokumentet og dermed, reelt set til et per instance salt.

Hvis de variable ISO dermed har gjort til en del af salt er konstante i OpenOffice password validering, er der ingen grund til at kode dem i dokumentet: vi inkluderer jo heller ikke hvordan man udfører en SHA256 i dokumentet.

Jeg skal med toget nu, tænk selv videre, det er ikke rocket science.

Poul-Henning

  • 0
  • 0
Jasper Bojsen

Nu fristes man jo til at sige, at den nu efterhånden ret så lange debat frem og tilbage mellem Jesper og Poul-Henning med al tydelighed viser, at hvis ODF nu bare havde været specificeret tilstrækkeligt fra begyndelsen af, så kunne man jo bare fulgt specifikaitonen, i stedet for bygge underlige argumentoriske konstruktioner op, så som at "henvise til at læse grundbogen" eller i flæg med "hvad enhver burde og ikke burde vide om sikkerhed", hvilket jo hverken kvalificere sig som informativ tekst og da slet ikke normativ tekst for en standard. At henvise til kildekoden har heller naturligvis ikke meget med standardisering at gøre. Men alt det siger jeg naturligvis ikke ;-)

I stedet spørger jeg endnu en gang om ikke vi kan blive enige om at Track Changes er underspecificeret i ODF, samt enig om det faktum at hverken OpenOffice eller Lotus Symphony har været i stand til at implementere en forudsigelig Track Changes funktionalitet med ODF?

Og nu til et andet spørgsmål, som jeg reelt mener er out-of-context her: Kunne Microsoft have lavet interop mellem Microsoft Offfice og OpenOffice ved at læse i openOffice kildekoden? Naturligvis, men fokus her er jo ikke at etablere interop mellem to konkrete produkter, med med en gruppe af produkter og derfor går denne tilgang natirligvis ikke. For hvad med KOffice, iWorks, Corel WordPerfect, Google Apps etc. etc.?

Ideen med filformat standarder er at skabe en fælles referenceramme, ikke et krydsfelt af spagettikode mellem udvalgte programmer.

Jeg er sådan set enig med Poul-Henning om at strandarder (åbne eller ej) ikke kan løse alle problemer og ikke i sig selv tilvejebringer interoperabilitet. Det er bl.a. derfor Microsoft har publiceret implementeringsnoterne til ODF og Open XML. Men derfor kan der godt være forskel mellem standarder og en given standard kan godt være i stand til at løse en given opgave bedre end en anden. Ligeledes kan en standard godt fejle så greelt i et område at det kan give mening ikke at understøtte det pågældende område før standarden bliver bedre.

Jasper

  • 0
  • 0
Eskild Nielsen

SÅ vidt jeg husker, så er Microsoft gået med i ODF TC.

Da Microsoft jo tydeligvis er i besiddelse af en (lang?) liste over punkter i standarden, som ikke er tilstrækkeligt klart skrevet, eller som på anden måde ikke er tilstrækkelig, kan vi så forvente at de giver ODF TC relevant input om de problemer de har fundet?

På den måde kan ODF TC så finde frem til de nødvendige forbedringe af teksten.

OG I MELLEMTIDEN - BRUG KRÆFTERNE PÅ EN ANVENDELIG OG INTEROPERABEL ODF IMPLEMENTATION!

  • 0
  • 0
Jesper Lund Stocholm Blogger

Hej Poul-Henning,

Jeg synes ikke, at der er så stor grund til at blive ved med at være nedladende - jeg forstår godt dine [u]ord[/u] - det er dine [u]argumenter[/u] jeg ikke er enig i.

Det virker på mig som om, at du synes, at det er en ganske glimrende måde man har valgt at håndtere det på i ODF - altså kun at gemme hash-værdien i dokumentet. Jeg synes, at det er kluntet ikke at gemme navnet på funktionen, for det kræver, at man aktivt løber en række funktioner igennem for at verificere et password. Jeg kan ikke forstå, at man ikke har valgt at tilføje en ekstra attribut til dette. Det ville have været en no-brainer at gøre det.

Hvis man kigger i ODF 1.2 CD02 (seneste draft) har man da også valgt at tilføje netop denne attribut. Værdien for den kan være én af de "godkendte" hash-funktioner fra http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/ (XMLDIGSIG). Man lægger sig altså ret tæt op ad den tilsvarende konstruktion i OOXML med en række foruddefinerede værdier for hash-funktionerne.

Anyway - når jeg kigger forskellige implementeringer igennem for at se, hvordan hash-værdier og salt normalt håndteres, så virker det som om, at der er en konvention om, at man tilføjer det anvendte salt til enden af hash-værdien - dvs har man anvendt RIPEMD-160, så er de første 160 bits hashværdien og "resten" er det anvendte salt. Derfor kan man sagtens argumentere for, at man ikke behøver at have den som en seperat attributværdi. Jeg skal ikke kunne sige, om det er "normen" at gøre det på den måde - det ved du sikkert bedre end jeg. Jeg kunne dog også finde eksempler på implementeringer af fx SHA1, der blot "prepender" salt til den angivne tekststreng og herefter ikke nævner det mere.

Men der er jo stadig spin count tilbage. Hvis man læser Microsofts argumentation for at udskille spin count seperat i OOXML, så går den på, at man gerne vil kunne angive denne dynamisk for at gøre det (lidt) sværere at lave dictionary attacks samtidig med, at man kan udvide den i fremtiden uden at miste kompatibilitet med allerede dannede hashes, når hardware godtgør, at man ikke "kun" skal anvende et spin count på 100000 men i stedet kan anvende den rekursivt 1000000000 gange.

Du nævnte selv, at Microsoft har folk ansat, der ved ganske meget om password-beskyttelse - kunne man ikke tænke sig, at det var nogle af dem, der havde været inde over her?

:o)

  • 0
  • 0
Poul-Henning Kamp Blogger

Det virker på mig som om, at du synes, at det er en ganske glimrende måde man har valgt at håndtere det på i ODF - altså kun at gemme hash-værdien i dokumentet.

Ja, det er faktisk alt rigeligt.

Men bevares, det gør da ikke nogen skade at lave et felt med algoritmens navn.

Det jeg opponerer imod er at Microsoft lægger armene over kors og siger "det her kan vi slet ikke arbejde med" og bruger det som en undskyldning for at saboterer interoperabilitet.

Anyway - når jeg kigger forskellige implementeringer igennem for at se, hvordan hash-værdier og salt normalt håndteres, så virker det som om, at der er en konvention om, at man tilføjer det anvendte salt til enden af hash-værdien

Jesper, det er derfor vi stopper nu:

Dit udsagn svarer til at sig at "så vidt jeg kan se er der en konvention om at biler har et hjul i hvert hjørne".

Som jeg skrev ovenfor, så er det ikke et valg man har: hvis det er et salt er man pinedød nødt til at gemme det sammen med hashværdien.

Det er ikke blot en "konvention" nogen har besluttet fordi de syntes at det så pænt ud.

Hvis man ikke gør det, kan man ikke bruge signaturen til noget som helst.

Hvis du ikke ved mere om kryptografi end som så, så bør du ikke blande dig i diskussioner om det emne.

Poul-Henning

  • 0
  • 0
Jesper Lund Stocholm Blogger

Hej Poul-Henning,

Det jeg opponerer imod er at Microsoft lægger armene over kors og siger "det her kan vi slet ikke arbejde med" og bruger det som en undskyldning for at saboterer interoperabilitet.

Ja - og jeg er ikke uenig med dig i dette. Jeg tror Microsoft har valgt at lave en meget tekstnær implementering af ODF for bla. at vise hvilke uhensigtsmæssigheder, der er i ODF. Jeg tror også, at man i Microsoft har valgt "the high road" og ikke villet gå på kompromis med at miste funktionalitet fra Microsoft Office, når et dokument skal persisteres i ODF. Det virker på mig som en "alt eller intet"-tankegang, som måske nok kan forsvares - men brugerne taber under alle omstændigheder (uanset om det skyldes manglende information i ODF eller ej).

Som jeg skrev ovenfor, så er det ikke et valg man har: hvis det er et salt er man pinedød nødt til at gemme det sammen med hashværdien.

Ja, hvis man har anvendt et salt skal dette bruges til at verificere den angivne klartekst. Jeg har aldrig sagt andet. Man kan herefter vælge at smække salt'et i enden af hashen eller levere det med ved siden af.

Uanset hvor meget du kalder mig en idiot, så kan jeg ingen steder se, at man kun har ét valg - nemlig at appende salt til hashværdien. Man har også muligheden for at levere salt ved siden af hash-værdien. Og udover det mangler vi stadig det anvendte spin count. Det er muligt, at du synes man er idiot, hvis man ønsker dynamisk at kunne ændre spin count, men hvis man trods alt skulle ønske dette, så er hashværdien ikke nok i sig selv til at kunne identificere dette spin count - hvilket du oprindeligt påstod.

... men det virker da som om, at vi har en masse at tale om i morgen til bloggermødet ... kommer du?

:o)

  • 0
  • 0
Poul-Henning Kamp Blogger

spin count er ikke nogen gud given egenskab ved en envejsfunktion og derfor er det tåbeligt at gøre den til en globalt defineret parameter for alle envejsfunktioner.

Det anvendte spin-count er enten konstant og i så fald en del af envejsfunktionens algoritmiske definition, eller det er variablet og dermed en del af salt.

At hive det ud som separat felt er kryptografisk inkompetance.

Poul-Henning

  • 0
  • 0
Jesper Lund Stocholm Blogger

Hej Poul-Henning,

At hive det ud som separat felt er kryptografisk inkompetance.

Ok - de ved tilsyneladende ikke så meget om passwordbeskyttelse i Microsoft som du tidligere nævnte - eller også har de snakket med de forkerte.

Det er muligt, at du synes, at det er en idiotisk konstruktion, men udskilning af spin count dækker for mig at se en use-case som ikke var dækket, hvis du kun har hashværdien at lege med. Jeg kan ikke se, hvordan du kan udskille spin count fra et salt (som du siger det er en del af, hvis det er "per instance"), men jeg må nok erkende, at jeg ikke kan få dig til at fortælle mig det - jeg ved jo ikke "blot et minimum om password beskyttelse", så det vil jo være urimeligt for mig at bede dig konkretisere dit udsagn om spin counts.

:o)

Ses vi i morgen?

  • 0
  • 0
Christian E. Lysel

Jasper,

Nu fristes man jo til at sige, at den nu efterhånden ret så lange debat frem og tilbage mellem Jesper og Poul-Henning med al tydelighed viser, at hvis ODF nu bare havde været specificeret tilstrækkeligt fra begyndelsen af, så kunne man jo bare fulgt specifikaitonen, i stedet for bygge underlige argumentoriske konstruktioner op, så som at "henvise til at læse grundbogen"

Aha ... hvis to mennesker har en lang debat, om elementær viden, skal dette dokumenteres bedre i en standard.

Jeg vil hermed gerne debattere at 4+4 ikke er lig 8!

  • 0
  • 0
Jesper Lund Stocholm Blogger

Hej Christian,

Nej, det er jo en _en_vejs hash!

Jeg bad ikke om at få det oprindelige password men værdier som hash[u]funktion[/u], salt og spin count.

Hvad er inddata til hash algoritmen vi skal gætte?[/quote]
Det var jo ikke en konkret opgave, så jeg sendte ikke input med.

Jeg kan ikke huske, hvilken værdi jeg dannede hashen med, så her er et nyt par:

hash: iitxRePWnN4YD+d8CXAdxfsMiT8
pswd: fXmpER2%G

:o)

  • 0
  • 0
Jesper Lund Stocholm Blogger

Hej Christian,

Det giver ikke mening uden ind- og uddata.

Nej - det er korrekt. Men Poul-Hennings initielle udsagn indikerede, at man fra selve hash-værdien kunne sige noget intelligent om hash-funktionen. Derfor sendte jeg ikke input-data med.

Jeg vil i aften forsøge at finde hash funktionen, hvis den er iblandt de funktioner jeg har adgang til.

Det synes jeg kunne være super fedt, hvis du ville.

:o)

  • 0
  • 0
Henrik Jensen

Hvilken password beskyttelse er det præcist at vi snakker om?

Som jeg ser det er der følgende tre muligheder i forhold til ODF / OpenOffice.org

  • Det password som benyttes til beskyttelse af hele dokumentet og som gemmes i manifest.xml filen. Det er som jeg ser det fint specificeret i ODF og uanset debat om hvorvidt at hash-værdien er nok o.s.v. så er der både angivelse af algoritme, salt, iteration count m.v. så det burde Microsoft godt kunne understøtte

  • Så er der password til beskyttelse af udvalgt indhold, f.eks. celler i en tabel. Det er her at specifikationen ser ud til at være ganske begrænset som Jasper beskriver, men der gør sig også følgende gældende så vidt jeg kan se:

1) OpenOffice.org understøtter ikke password i denne situation på trods af at det er indeholdt i ODF standarden, i hvert fald ikke i den version 3.0.0 jeg sidder med, der sættes blot et flag. Beskyttelsen er altså blot mod at man får ændret noget ved en fejl da man kan slå beskyttelsen fra uden brug af password

2) I ODF 1.2 kan jeg se at man også har tænkt sig at udvide med blandt andet angivelse af den algoritme der er benyttet til

Mit bud er derfor at eftersom OpenOffice.org (og formentlig alle andre ODF implementationer?) aldrig har implementeret password på dette niveau som beskrevet i ODF standarden, så har man aldrig bemærket at standarden ikke er særlig god på dette punkt. Det er man så nu begyndt at rette op på i ODF 1.2.

  • Så kan der sættes et password i OpenOffice.org for at beskytte 'Track Changes'. Man beskytter imod at 'Track Changes' kan slås fra. Dette password gemmes i konfigurationsparameteren 'RedlineProtectionKey' (Meget sigende navn), som ikke er specificeret som en del af ODF standarden, der er altså kun én måde at finde ud af hvordan den præcist benyttes på og det er ind at kigge i kildekoden til OpenOffice.org. Det har jeg ikke gjort men ved en hurtig søgning kunne jeg se at i hvert fald én person der tidligere har beskrevet at der blot benyttes SHA1 uden salt + iterations, hvilket jo så gør at hashværdien er tilstrækkelig information, men tilgengæld en hel del lettere at lave dictionary-attacks imod. Måske var det samme oprindelig tænkt omkring førnævnte passwords til beskyttelse af indhold, men i såfald ville det jo stadig være passende at beskrive det i standarden, så man ikke skal kigge i kildekode/søge på nettet for at finde informationen.
  • 0
  • 0
Jesper Lund Stocholm Blogger

Hej Christian,

Bruger jeg denne definition sammen med http://www.sinfocol.org/herramienta... kommer jeg frem til du ikke har brugt en af hash funktionerne i afsnittet Hash().

Hmmm ... hvad gør vi så?

(og tak for linket, i øvrigt - den side skal nok blive nyttig på et senere tidspunkt)

Men tilbage til hash-funktionen. Jeg har ingen anelse om, hvilken funktion jeg har brugt - men jeg har "beskyt regneark"-funktionen i OOo Calc 3.01 på ubuntu 9.04 (den laver sjovt nok den samme værdi, hvis jeg bruger OOo Calc 3.1 på Windows.

Jeg har i går prøvet at finde ud af, hvilken algoritme OOo bruger (og hvor den ligger i deres kode repository), men uden held. På baggrund af den side du har sendt med de mange hash-funktioner, kan jeg nok konkludere, at man i OpenOffice.org ikke bruger en "standardiseret" hash-funktion uden ekstra spincount eller salt.

Som sagt prøvede jeg at finde kildekoden til algoritmen i går, men jeg fandt ikke noget relevant. Ved du (eller nogle af jer andre) hvor algoritmen er enten beskrevet eller implementeret i OOo?

  • 0
  • 0
Christian E. Lysel
  • Så er der password til beskyttelse af udvalgt indhold, f.eks. celler i en tabel. Det er her at specifikationen ser ud til at være ganske begrænset som Jasper beskriver, men der gør sig også følgende gældende så vidt jeg kan se:

1) OpenOffice.org understøtter ikke password i denne situation på trods af at det er indeholdt i ODF standarden, i hvert fald ikke i den version 3.0.0 jeg sidder med, der sættes blot et flag. Beskyttelsen er altså blot mod at man får ændret noget ved en fejl da man kan slå beskyttelsen fra uden brug af password

OASIS 1.1 definere table:protection-key, som bruges af OpenOffice 3.0.1 (Build:9379) Ubuntu 9.04.

  • 0
  • 0
Christian E. Lysel

Hejsa Jesper.

Hmmm ... hvad gør vi så?

Jeg kan sagtens Base64 decode min hash værdi fra <office:spreadsheet><table:table .... table:protection-key="hash" ....>

Men jeg kan ikke Base64 decode din hash værdi.

Er det blot følgende?
iitxRePWnN4YD+d8CXAdxfsMiT8=

På baggrund af den side du har sendt med de mange hash-funktioner, kan jeg nok konkludere, at man i OpenOffice.org ikke bruger en "standardiseret" hash-funktion uden ekstra spincount eller salt.

Er du ikke meget hurtig til at konkludere?

PS: En spincount kan godt være indbygget i funktionen. Fx er SHA1/1K, SHA1 med spincount 1000.

  • 0
  • 0
Jesper Lund Stocholm Blogger

Hej Christian,

eg kan sagtens Base64 decode min hash værdi fra <office:spreadsheet><table:table .... table:protection-key="hash" ....>

Men jeg kan ikke Base64 decode din hash værdi.

Er det blot følgende?
iitxRePWnN4YD+d8CXAdxfsMiT8=

Jeps - en lidt større del af "kagen" er her:

[code=xml]<table:protected="true" table:protection-key="iitxRePWnN4YD+d8CXAdxfsMiT8=" (...(/>](code]

Er du ikke meget hurtig til at konkludere?

Måske ... men jeg håber da meget, at vi finder ud af algoritmens navn. Set ud fra interoperabilitetshensyn synes jeg heller ikke, at det umiddelbart virker optimalt, hvis OOo brugte en hash-funktion med "n[i]K[/i]-notation, da det åbne spørgsmål jo så bliver - hvor mange forskellige multipla af K skal jeg teste igennem for at finde den anvendte hash-funktion?

  • 0
  • 0
Christian E. Lysel

Først ... hvad er sikkerheden i at beskytte et felt alle kan læse med et password ... hvor forhindre dig i at rette dokumentet så beskyttelsen ikke er slået til i begge standarder?

Jesper,

Måske ...

Måske? Du hælder et 8-bit tegnsæt ind i SHA1 og undre dig over hash funktionen kommer frem til noget andet end det angivet i dokumentet.

[qoute]
men jeg håber da meget, at vi finder ud af algoritmens navn.
[/quote]

SHA1

chel@asus:~/Desktop/q$ echo -n 'fXmpER2%G' | iconv -f latin1 -t UTF-16LE | openssl sha1 -binary | base64  
iitxRePWnN4YD+d8CXAdxfsMiT8=

Set ud fra interoperabilitetshensyn synes jeg heller ikke, at det umiddelbart virker optimalt, hvis OOo brugte en hash-funktion med "nK-notation, da det åbne spørgsmål jo så bliver - hvor mange forskellige multipla af K skal jeg teste igennem for at finde den anvendte hash-funktion?

Det er igen ligegyldigt.

Kik på bitstørrelsen, dette bruges til at udlukke hash funktioner, i dette tilfælde SHA-0, SHA-1 og nogle 160 bit udgaver af andre ... derefter løber man funktionerne igennem med fx spincount 1000 ... for hver gennemløb skal man teste om de 20 byte, matcher det som står i dokumentet.

Hermed har du testet spincount 0-1000.

  • 0
  • 0
Henrik Jensen

OASIS 1.1 definere table:protection-key, som bruges af OpenOffice 3.0.1 (Build:9379) Ubuntu 9.04.

Det var underligt, jeg tænkte først at det bare var fordi at det var ændret mellem 3.0.0 og 3.0.1 så jeg tog og opgraderede til 3.1.0 (Build:9399) på windows

Men stadig hvis jeg åbner et Writer dokument, indsætter en tabel, højre-klikker på en celle, vælger Cell->Protect og så sætter den bare et flag, intet password. Jeg kan gå ind og unprotecte igen uden password.

Kan der være forskel på windows og linux versionen?

  • 0
  • 0
Christian E. Lysel

Men stadig hvis jeg åbner et Writer dokument, indsætter en tabel, højre-klikker på en celle, vælger Cell->Protect og så sætter den bare et flag, intet password. Jeg kan gå ind og unprotecte igen uden password.

Skal du ikke starte med slå beskyttelse på i "sheet"'et?

PS: Hvad skal man bruge beskyttelsen (protection) til?

Den er reelt intet værd.

  • 0
  • 0
Henrik Jensen

Skal du ikke starte med slå beskyttelse på i "sheet"'et?

Jo i Spreadsheet, men nu var det Writer, altså et tekstdokument jeg "legede" med. Og der tror jeg ikke at man skal slå noget til på side/dokument-niveau først. Den brokker sig i hvert fald ikke når man slår protection til og den er også beskyttet indtil man har valgt unprotecte igen.

Og nu kan jeg faktisk at se at på sektioner i tekstdokumenter der virker det, altså der kan man angive password. Så det er åbenbart bare ikke helt konsistent.

PS: Hvad skal man bruge beskyttelsen (protection) til?

Den er reelt intet værd.

Så på et tidspunkt en beskrivelse fra OpenOffice.org hvor de skrev at det var for at beskytte mod sig selv, altså at man får ændret noget ved en fejl.

Men giver dig ret det er ikke lige en af de funktioner jeg oftest benytter. :-)

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