Viser innlegg med etiketten Datafaglig. Vis alle innlegg
Viser innlegg med etiketten Datafaglig. Vis alle innlegg

15. februar 2013

Scrivener - et fantastisk skriveverktøy


Scrivener er et fantastisk skriveverktøy for å rette fokuset på innholdet, og fjerne fokuset fra formatteringen. Trenger du å skrive godt innhold som henger sammen, sikre at det er en eller flere røde tråder i det du skriver, eller har behov for å omorganisere teksten din en del mens du skriver? Da er Scrivener verdt å se nærmere på.

Lærere som lager lærestoff, forskere som skriver vitenskapelige avhandlinger, studenter som skriver oppgaver og forfattere som skriver bøker - verden over - bruker Scrivener. Konseptet er å tilby funksjonalitet som lar deg lage innhold, organisere og omorganisere til du får det riktig, og til slutt eksportere resultatet til for eksempel et word-dokument. Først da - når teksten er ferdig innholdsmessig - bør du nemlig bruke tid på formatteringen (i følge folkene bak Scrivener). Jeg var skeptisk til denne påstanden, men gav verktøyet en sjanse og ble ikke skuffet. Tvert i mot. Jeg ble så imponert og fascinert at jeg bare måtte blogge om erfaringene!





Figur 1: Med Scrivener får innholdet og selve skriveprosessen fokus, og du har ulike måter å se innholdet på. Klikk på bildet for å åpne i større versjon


Det begynte med at jeg fikk Scrivener "gratis" som del av pakken "Macheist" som jeg kjøpte høsten 2012. Mange skrøt på Twitter av Scrivener, og jeg fikk lyst til å sjekke ut hva dette var for noe. Jeg gikk gjennom en tutorial som tok to timer, og lærte meg dets grunnleggende funksjonalitet. Ja - det er en høy læringsterskel, men det sier meg at når det først er lært er det desto mer nyttig. Etter de to timene så jeg potensialet med verktøyet, men det gjenstod fortsatt å prøve det i praksis.


Jeg bestemte meg for å forbedre et eksisterende øvingsopplegg ved å endre på øvingsteksten i de 5 gamle øvingene i faget Sosiale medier (5 studiepoeng, IINI2004). Utfordringen var å lage en bedre rød tråd og samtidig ta vare på gode elementer fra det gamle opplegget.


I gamle dager ville jeg lagd 5 nye dokumenter i Word. Jeg ville åpnet 5 gamle og limt inn tekst derfra i de 5 nye. Det krever ikke at 10 dokumenter er åpne samtidig i Word, men det krever at 10 dokumenter er "åpne i hodet mitt" samtidig. Jeg må nemlig ha oversikt over gammelt innhold og nytt innhold, og holde styr på hvilke seksjoner som kan klippes herfra og derfra. Det hadde gått helt fint, men ville krevd maksimalt fokus, og om jeg ble avbrutt ville jeg vel nesten måtte starte på nytt neste gang. 

Jeg kunne brukt et tankekart, og da ville jeg fått oversikt over innholdet i gammel struktur og lett kunne reorganisere til ny struktur. Men linken mellom gammel tekst, ny tekst og tankekartet vil ikke være særlig god. 

Jeg bestemte meg derfor for å teste ut hvorvidt Scrivener kunne brukes som verktøy, siden det gir fokus på skriveprosessen og innholdet. Formatteringen er irrelevant på et så tidlig stadium i utviklingsprosessen. Det er mer enn nok å holde styr på den røde tråden. I Word og andre verktøy får formatteringen fort fokus enten man vil eller ei, og det er vanskelig å få oversikt over 10 dokumenter som er åpne samtidig. I Scrivener er det (mye) lettere. Den korte historien er at Scrivener overrasket meg veldig positivt. Jeg var ferdig med hele omstruktureringsjobben på et par timer og hadde da i tillegg fått skrevet teksten til en av øvingene, lagt en plan (med rød tråd) for de andre øvingene, og i tillegg skrevet et veldig vanskelig notat om PLN. Jeg er ganske sikker på at jeg ville brukt mye mer tid på dette enn to timer, og med dårligere resultat om jeg hadde kjørt den gamle metoden med Word-dokumenter. 




Figur 2: Det å kunne stille opp dokumenter side om side er ikke noe nytt, men det er ikke det som gjør dette oppsettet effektivt. Det du ser er nemlig ikke to dokumentvinduer, men to vinduer med dokumenter inni. Et dokument kan når som helst byttes ut med et annet, og det gjør Scrivener veldig egnet til å jobbe effektivt med lange, kompliserte tekster eller en rekke dokumenter samtidig. Ser du forskjellen? Jeg måtte prøve det i praksis for å forstå hvor vanvittig kraftig dette er... Klikk på bildet for å åpne i større versjon

Ble du nysgjerrig nå på metoden? Jeg gjorde slik:
  • Jeg importerte de gamle øvingene (sos-oving1 til sos-oving5, se figur 2) inn i Scrivener. Dette var word-filer og derfor ble formatteringen med, men det er greit. Hensikten for min del var bare å få oversikt over hva de gamle øvingene inneholdt. 
  • Jeg skrev et sammendrag i synopsis-feltet ved å trykke på Inspector til hvert dokument, og skrive der (figur 2) 
  • Jeg lagde fem-seks nye dokumenter som var tomme, disse representerte ny øving 1, 2, 3, 4 og 5 samt et ekstra notat til øving 2 (figur 1 og figur 2)
  • Jeg gikk til corkboard view og kunne nå se hva gammel øving 1, 2, 3, 4 og 5 handlet om, siden teksten fra synopsis vises tydelig. Dermed var det lett å se hva nye øvingene burde handle om og skrive direkte inn i corkboard view (figur 1). Da ser jeg også hva som skal/kan gjenbrukes fra gamle øvinger, og ser helt tydelig den røde tråden gjennom opplegget. 
Så kommer utfordringen: Gjøre om stikkordene skrevet inn i corkboard-view (synopsis-feltet) til ny øvingstekst. Altså gjøre ferdig øvingen. Og det er her Scrivener fremstår som genial slik jeg ser det. Som figur 2 viser, så kan en kjøre todeling av skjermen, og ved å klikke i den ene ruten og så velge noe fra venstrestolpen, vises det dokumentet der. Ved å klikke i den andre ruten og velge noe annet fra venstrestolpen, vises det dokumentet der. Ergo ser jeg to dokumenter i hver sin rute, og kan lynraskt bytte mellom dokumentene som skal vises i hver rute. Det fins faktisk en enda enklere metode enn å måtte klikke i margen - jeg kan nemlig bruke Cmd+Alt+pil opp eller ned for å bla til forrige/neste dokument i henhold til listen i venstrestolpen. Altså navigasjon mellom ulike dokumenter. Ruten står fast, og slik kan jeg lynraskt titte på for eksempel gammel øving 3 eller 4 i venstre-vinduet for å se om de har noen momenter som skal inn i ny øving 2 som vises i høyre-vinduet. Tilsvarende: hvis jeg ser at noe passer i for eksempel ny øving 5, så trykker jeg Cmd+Alt+pil ned tre ganger, og da viser høyre-vinduet ny øving 5-dokumentet.

Noen observasjoner:
  • Jeg kan når som helst gå til corkboard-view (eventuelt lynraskt ved å trykke på Cmd+2). 
  • Hvorfor er det så viktig at jeg kan navigere raskt? Fordi da mister jeg ikke fokus på den tanken jeg har i hodet. Omstrukturering av innhold er veldig mentalt krevende. Ved bruk av Word må 10 åpne dokumenter samtidig holdes styr på. Det er da fort gjort at idéer glemmes bort fordi en bruker tid på å hente fram riktig dokument, og en får også mye dårligere oversikt. Det er komplisert nok å ha alt i hodet som skal hit og dit når jeg omorganiserer. 
  • Scrivener tilbyr mye mer funksjonalitet og snarveier enn bare to-dokumentsvisning. Alt gjør at jeg kan fokusere 100 % på innholdet. Det å lære seg å navigere raskt i teksten med tastaturet er vel anvendt tid, og sitter snart i fingrene på samme måte som det å klippe ut og lime inn tekst med tastaturet. 
  • Det fins også en rekke mer avanserte funksjoner som er ment å støtte deg i skriveprosessen. Tagger, metadata, mulighet for å sette status på hvor ferdig et dokument er, søke opp innhold på ymse vis, og så videre.
Det er mulig å formattere teksten helt enkelt med overskrifter, punktlister og liknende, men poenget med Scrivener er å få fokus på innholdet, ikke formatteringen. Som vist i figur 3 kan du få ekstra fokus på innholdet ved å gå i fullskjermmodus - da får du svarte felter på sidene og kun innholdet synlig. Tekststørrelse og bredde på de sorte feltene kan selvsagt justeres etter ønske. En fin egenskap ved fullskjermmodus er at du alltid skriver midt på skjermen. Det gjør at du kan se midt på skjermen, noe som er lite anstrengende. Hver gang en ny linje påbegynnes, flyttes arket heller enn markøren, akkurat som på en gammel skrivemaskin. Dersom du ikke liker dette kan du slå av funksjonen i innstillingene. Liker jeg det? Ja, veldig godt. Jeg har aldri skrevet slik før, men nå vil jeg ikke ha det anderledes!



Figur 3: Fullskjermmodus i Scrivener fjerner ikke bare alt som kan forstyrre deg, men du har også full kontroll på bredden og størrelsen, bakgrunn, skrifttype etc (uten at skrifttypen i dokumentet endres selv om du skriver med det du trives best med å se på skjermen). I tillegg kan du skrive i skrivemaskinmodus, noe som alltid gjør at du kan se midt på skjermen. Det er lite slitsomt for øynene og verdt å prøve. Klikk på bildet for å åpne i større versjon

Jeg fikk så fin flyt i skriveprosessen skissert ovenfor at jeg kommer til å bruke Scrivener til mye skriving fremover:
  • Tipsserie om effektivitet på itfag-bloggen: Består i praksis av 15-20 blogginnlegg som må henge sammen og bygge på hverandre. De jeg har skrevet til nå kan jeg importere inn i Scrivener, mens de andre kan jeg skrive fra bunnen av i Scrivener i stedet for å føre rett inn i Wordpress. Scrivener eksporterer forresten til HTML som ren (les: clean) HTML og ikke noe dill-dall-tagger slik andre programmer gjør. Dermed kan jeg veldig lett lime resultatet inn i Wordpress når et innlegg er ferdig skrevet. Det at Scrivener fokuserer på innhold, betyr ikke bare at du må forholde deg til tekst. Du kan importere bilder og andre medieressurser uten problemer. Det er bare formatteringen du ikke skal bry deg med! 
  • Papers: Vitenskapelige papers er gjerne 5-10 A4-sider lange, og på engelsk. Det er veldig krevende å strukturere teksten på en god måte og få teksten kort nok. Hvilke argumenter skal først og sist? Ofte starter en å skrive, og må så omstrukturere. Til slik skriving kan en med fordel bruke Scrivener. Da får en fokus bare på innholdet. I tillegg er omorganisering veldig lett ved å enten dra på ulike "dokumenter" i venstre-stolpen, eller ved å dra rundt på dokumentene i corkboard-visning. Paperet ditt er nemlig ikke ett dokument slik Scrivener ser det, men en samling av mange små dokumenter (eller seksjoner). Og det er der forskjellen fra for eksempel Word blir tydelig - i Word lager du ett dokument og skriver på det. I Scrivener tar du utgangspunkt i idéer du har og lager ett dokument for hver idé, tanke eller tema. Du kan velge å vise et og et dokument i hovedruten, eller markere flere i venstrestolpen og slik se en lang strøm av disse dokumentene i hovedruten. I siste fall blir det på samme måte som i Word, men i Word kan du (så vidt jeg vet) ikke fokusere på kun en del. Du kan skrive synopsis (sammendrag) for hvert dokument og slik få oversikt over hva alt handler om og identifisere røde tråder (corkboard-view ala figur 1). I tillegg gjør Synopsis og notis-feltet det mulig å skille tanker og idéer fra innholdet du skriver, noe som er veldig smart. Det er mer vrient å få til i Word. 
  • Leksjoner: Du kan skrive enkeltleksjoner eller hele fag i Scrivener. Jeg holder på å omorganisere faget IKT i læring (IFUD1044, 10 studiepoeng) og bruker Scrivener til det. Det gir meg en helt annen oversikt og gjør det lett å flytte rundt på tekst hit og dit slik at det henger bedre sammen enn før. 
Digresjon: Dette blogginnlegget skrev jeg i Evernote, ikke i Scrivener. Hvorfor det? lurer du kanskje på. Hvorfor det? lurer jeg også på. Gammel vane er trolig svaret. Det burde vært skrevet i Scrivener!

Oppsummert: Scrivener er et verktøy som har høy læringsterskel. De har laget en "tutorial" som tar ca 2 timer å lese gjennom, i form av et Scrivener-prosjekt en skal lese og redigere i. Da lærer man ikke bare grunnleggende funksjonalitet, men ser også mer tydelig hvilke muligheter dette fantastiske verktøyet åpner for. Scrivener fins både for Windows og Mac og anbefales på det varmeste. Legg gjerne igjen en kommentar om du har spørsmål, noe var vanskelig forklart, eller har egne erfaringer som er verdt å dele om Scrivener. 

27. august 2010

Tips: En god blogg å lese

Har du interesse for IKT, data og teknologi? Læring? Undervisningstips? FoU-arbeid? Da har jeg en blogg å anbefale: http://blogg.itfag.hist.no. Den skrives av alle mine kollegaer, og jeg er redaktør.

Vi har mange interesser og erfaringer, og tenker at bloggen er en fin arena for å dele og få erfaringer. Vi skriver om faglige temaer som sikkerhet, Web, programmering, økonomi og IT, Linux, drift, databaser, ITIL, Windows server og så videre. Vi skriver også om undervisningserfaringer og tips fra daglig arbeid, FoU-prosjekter og liknende. Vi har som ambisjon å komme med ca 2 innlegg hver uke fremover, og til nå er det skrevet en bred variasjon av innlegg.

Hvorfor en slik blogg?

  • AITeL har meget stor kompetanse totalt sett, og ønsker å bidra i samlingen av gode fagblogger i Norge. Vi vil synliggjøre vår faglige kompetanse, undervisningserfaringer og forskningsprosjekter.
  • Gjennom en blogg når vi ut til mange med tanker, ideer, erfaringer og interesser.
  • Det er lærerikt for hver enkelt å skrive blogginnlegg, men også for hele fagmiljøet internt (vi er 40 ansatte). Ofte oppstår det nye ideer gjennom skrivingen.
  • Bloggen er en fin arena for dialog og kommunikasjon. Engasjerte lesere vil ofte gi innspill i form av kommentarer som gir dybdeinnsikt, utvidet forståelse og merverdi til det opprinnelige innholdet.

Så legg til http://blogg.itfag.hist.no i leselisten din, her kommer det mange godbiter framover!

19. mars 2010

Jørund Leknes på Skype, årsmøtet til AITeL/TISIP

Avdeling for Informatikk og e-Læring ved HiST og TISIP har sitt årsmøte på Oppdal, og inviterte Jørund Leknes for å snakke om utfordringer for framtida. Han satt hjemme i Trondheim og snakket over Skype. Det fungerte smertefritt. Her er det viktigste han sa:

Om klima og IKT

  • IKT står for 2 % av utslippene. Store tjenerparker sluker strøm. Vi må tenke miljøvennlige innkjøp, kanskje mer over mot cloud computing etc.
  • IKT kan brukes til å redusere reising.
  • Smarte hus er utstyrt med teknologi for å regulere strømforbruket smartere, for eksempel.

Om kollektive bidrag

Crowd sourcing handler om å benytte seg av samfunnets kollektive kunnskap i større grad til å skape nye ting, jobbe smartere, løse problemer. Wikipedia er et godt eksempel hvor alle kan bidra og mobilisere seg. Anbefaler bok: Wikinomics.

Om frie data

Hvor mange bruker yr.no? Alle. Det morsomme er at også i Sør-Afrika vil de fleste svare det samme. yr.no tilbyr en god tjeneste fordi dataene er åpne. Det er viktig å tilby sentrale data til alle, men det forutsetter at data bør være frie. For oss blir det viktig å spørre oss: Hvilke data skal være frie? Sitter vi på noen data som bør frigjøres og spres mer aktivt? Lærestoff, forelesninger og så videre?

Om formater

Teknologipolitikk handler om regulering. Offentlig sektor er pålagt å bruke noen standarder (for eksempel ODF, PDF, HTML). Informasjon må selvsagt være tilgjengelig. Godt eksempel: Jørund ringer til en offentlig institusjon. Han stiller et spørsmål, men får ikke svar. Institusjonen sier nemlig at han har feil telefon. Det er kun de som har Sony Ericsson som kan få svar fra institusjonen, og det har ikke Jørund. Det er selvsagt uholdbart.

Om Universell utforming

Universell utforming handler ikke bare om tilgang til bygg for funksjonshemmede. Det handler vel så mye om IKT-systemer og digitalt innhold. Her kommer det til å bli stort fokus fremover. Det er nye regler som trer i kraft 1.juli 2011 for alle nye løsninger, mens eksisterende løsninger har litt lengre tid på å tilpasse seg.

Om fri programvare:

400+ kommuner i Norge. Dersom en bruker fri programvare, så er det lettere å samarbeide om å bygge på løsningene, og det er mye å spare. Mange virksomheter ser på deltakelse i fri programvareprosjekter som svært positivt. Kanskje AITeL derfor bør oppfordre i større grad til at studentene jobber med friprog-prosjekter som hovedprosjektoppgave?

Om nettjenester

Når vi får bedre IT-løsninger og brukervennlige tjenester, så oppnår vi mange fordeler. Kostnadene går ned, behandlingstiden går ned. Nye tjenester oppstår og det gir nye muligheter.

Om personvern

Når stadig mer skjer digitalt, blir vi mer sårbare. Ser en skummel trend med personvern. Nevner Tele2 som eksempel hvor mange Hvorfor krypterer vi ikke e-poster i større grad? Kan fremtidens studenter bidra til å øke fokus på dette? Vi trenger forståelse for hvordan en kan utvikle sikre, tekniske løsninger.

Om Datalagringsdirektivet

Vi bør tenke grundig gjennom Datalagringsdirektivet. Hva skjer når vi bygger opp registre over hva folk foretar seg? Hvilken retning driver dette oss i? Hvordan kan vi bruke teknologien for å hindre overvåking i stedet for å fremme overvåking?

28. februar 2010

Om Twitter og sikkerhet

I dette innlegget vil jeg rette fokus mot Twitter-sikkerhet generelt og tilgang for 3.parts applikasjoner spesielt. Mange kan allerede dette, men jeg prøver å reflektere over sikkerhet med utgangspunkt i hvordan weben er programmert, hvordan tjenester kommuniserer seg i mellom, og hva dette kan innebære med tanke på strategier for sikker bruk.

Bakgrunn: Phishing er høyaktuelt

I etterkant av jordskjelvet i Chile februar 2010 var det flodbølgevarsel mange steder i Stillehavet/Asia, blant annet på Hawaii. Den 27.februar var det veldig mange som sendte Twitter-meldinger med informasjon, observasjoner fra folk på Hawaii, lenke til direktesendinger, bilder og analyser. Spammerne hev seg raskt på og sendte tilsynelatende flodbølge-relaterte meldinger med lenker til sitt innhold (for eksempel porno, spyware eller phishingforsøk). De utnyttet med andre ord en katastrofesituasjon til å prøve å lure andre. Det er fort å gå i fellen for brukere som er opprørte og desperate etter å få informasjon, eller bare ønsker å følge med "live". Forkortede lenker (bit.ly og tiny.url) er smarte for å spare tegnplass, men en flott metode for å lure folk.

I forrige blogginnlegg tok jeg utgangspunkt i et konkret phishing-forsøk på Twitter og så på hvorfor brukere lett kan gå fem på og hvordan hackeren tenker for å realisere phishingen i praksis. Phishing er en varig trussel, og det kommer stadig nye og troverdige phishing-forsøk og metoder. Målet med slike angrep er som regel å samle inn flest mulig brukernavn/passord. Mange brukere har samme passord på ulike tjenester, så verdien av en stor passordsamling er gull verdt for hackeren, men det kan også være andre motiver for å fiske til seg brukerdata.

Om du først blir utsatt for angrep eller har mistanke om at noe er galt, så er det mest åpenbare tiltaket å endre passordet så raskt som mulig. Da vil ikke lenger en eventuell hacker kunne misbruke kontoen din. Tilsynelatende.

But behold. There is more.

Connections-innstillingen i Twitter

Etter å ha dypdykket litt i Twitter+phishing og blant annet fått tips av @AtelierKari, er det ett tiltak som er minst like viktig som å regelmessig endre passord, og som alle bør gjøre fra tid til annen. Under Settings på twitter.com er det en arkfane som heter Connections. Her vises alle 3.parts applikasjoner som har tilgang til å gjøre bruk av Twitter-kontoen din. Du har selv godkjent (autorisert) slike, men du har trolig ikke lagt dem til via Twitter-innstillingene.

Bildet over (klikk for stor versjon) viser en applikasjon som jeg brukte for en tid tilbake. Jeg ønsket å generere et bilde av mine følgere på Twitter til bruk i en presentasjon om sosiale medier (på en konferanse). Jeg fant tjenesten Twilk, som kan lage et flott collage-bilde bestående av profilbildet til alle mine følgere (til høyre, klikk for stor versjon).

Twilk trenger derimot aksess til min brukerkonto for å kunne gjøre dette (fordi Twitter sitt API krever autentisering fra applikasjoner som for eksempel vil lese meldingshistorikken til en bruker). Jeg måtte derfor gi Twilk tilgang til Twitter før Twilk kunne sette i gang med jobben. Ser du et potensielt faremoment her?

OAuth, 3.partsapplikasjoner og API

La oss først se kort på hva et API er. Jeg har selv programmert et lite system som poster Twitter-meldinger automatisk i kraft av en annen bruker. Det brukte jeg til å spre 150 mac-tips automatisk utover sommeren 2009. For å få til det, måtte jeg gjøre bruk av Twitter-API-et. Det har Twitter-utviklerne programmert slik at andre utviklere (meg for eksempel) kan gjøre nytte av sentral funksjonalitet i Twitter, det være seg å poste meldinger, lese meldinger, telle opp antall følgere, hente ut brukernavnet til følgere og så videre. API-et gir tilgang til verdier Twitter har, slik at andre utviklere kan lage egne systemer som bruker disse verdiene.

Twilk (nevnt over) bruker noe som heter OAuth, en åpen protokoll for å autorisere tilgang til en tjeneste fra en annen via et API. Med OAuth kan utviklere lage programvare/tjenester som gir tilgang i kraft av en bruker på en annen tjeneste. Siden Twilk bruker OAuth mot Twitter vil Twilk ikke få brukernavnet og passordet mitt, men har likevel tilgang til å operere mot min konto. OAuth brukes som metode for å gi Twilk privilegier for min Twitter-bruker. Det er bra, for det er nettopp det som må til for å utføre jobben. Jeg vil at Twilk skal kunne hente alle profilbildene til mine følgere, og sette disse sammen til ett stort bilde sortert etter frekvens på hvor ofte vi har kommunisert på Twitter. Jeg vil derimot IKKE at Twilk skal få passordet mitt, for jeg vet ikke hvem som har laget Twilk og stoler ikke på at de har ærlige hensikter. Altså kun tilgang, intet passord. OAuth sikrer dette.

Når bildet jeg "bestilte" var ferdig laget av Twilk, så ønsket jeg ikke å lage flere. Dette var altså en engangsbruk for meg. Men - det jeg nå har oppdaget (en måned i etterkant) er at Twilk fortsatt ligger inne med aksess som autorisert 3.partsapplikasjon under Connections-innstillingen i Twitter! Dette er utrolig skummelt. Jeg kan bytte passord og føle meg trygg, men Twilk har likevel tilgang. Tenk over hvilke følger dette egentlig har. Det er jeg som først gav tilgang og den er vedvarende. Twilk har ikke passordet mitt, men kan likevel operere mot kontoen min slik de vil. De kan faktisk sende spam-meldinger i mitt sted, selv om de har lovet meg på websidene deres at de kun skal samle inn alle profilbilder til mine følgere. Jeg stoler på at de ikke gjør det, men kan jeg være sikker?

Tiltak for beskyttelse

Svaret er nei. Jeg kan ikke stole på Twilk, og jeg kan ikke stole på noen andre aktører. La oss ta noen tankeeksperimenter (med Twilk som tilfeldig hypotetisk eksempel :-) Twilk kan starte med ærlige hensikter, men bli kjøpt opp av uærlige mennesker. Twilk kan være designet til å være tilsynelatende nyttig mens hensikten egentlig er å lure folk til å gi tilgang til deres aller helligste på Twitter. Twilk eller en hvilken som helst annen Twitter-tjeneste kan lure meg. Jeg vet ikke, og derfor må jeg ta forhåndsregler.

Dersom du gir tilgang til en 3.parts tjeneste i Twitter-sammenheng, så foretrekk de som benytter Oauth. Vær skeptisk hvis tjenesten ikke bruker OAuth, men eksplisitt ber om ditt brukernavn og passord. Vil du virkelig leke med ilden, så kan det være lurt å endre Twitter-passordet først (for eksempel til "1234"). Logg så inn (lek med ilden), bruk tjenesten, gjør deg ferdig og endre deretter tilbake til ditt opprinnelige passord igjen. Da har en potensiell uærlig aktør fått et ubrukelig passord.

Slett 3.partstjenester fra Connections-innstillingen med en gang du er "ferdig" med å bruke dem.

Twitter anbefaler selv på sine websider å sjekke Connections-innstillingen jevnlig (takk til @AtelierKari for lenke. Dette gjelder selv om du ikke mener du har gitt tilgang til noen 3.partsapplikasjoner! Du kan nemlig være "hacket" uten at du vet om det, og hackeren kan ha gitt tilgang til applikasjoner i ditt sted. Hvis det skjer, så har hackeren kontroll selv om du bytter passord, fordi slike applikasjoner er autoriserte en gang for alle uavhengig av hvor ofte du bytter passord. Fjern de tjenester du får listet opp som du ikke har et aktivt forhold til. Da bør du være rimelig trygg. Dette kan virke paranoid, men du vet aldri hvordan mennesker bak slike tjenester har tenkt og programmert løsningen sin. Tjenester som kan synes profesjonelle og nyttige, kan i virkeligheten være et skalkeskjul for noe helt annet.

I tillegg til alle tiltakene nevnt i dette innlegget (med evt. kommentarer) bør du også se på forrige blogginnlegg med kommentarer, som lister en del viktige tiltak for å beskytte seg mot phishing. En viktig strategi er for eksempel å anse varsler som kommer per e-post kun som en varsling om at noe er nytt, ikke som en snarvei til dette nye (sier sikkerhetsguru Bruce Schneier). Altså må du logge eksplisitt inn på tjenesten i stedet for å klikke på lenken. Det tar litt mer tid, men er sikrere og er noe jeg som regel gjør selv, uansett hvor troverdig lenken ser ut.

Oppsummering og konklusjon

Det kan være flere kilder til misbruk av din Twitter-konto. Hvis en hacker får deg på fiskekroken og får vite passordet ditt, så kan hackeren poste meldinger i ditt sted (for eksempel gjennom et automatisert script eller ved manuell innlogging). Et umiddelbart tiltak er tilsynelatende å bytte passord. Dette kan løse problemet, men som vi har sett er det også mulig for hackeren å legge inn 3.partsapplikasjoner som for alltid vil være autoriserte, uavhengig av dine passordskifter. Det er derfor viktig å både endre passord jevnlig/ved mistanke og å sjekke Connections-innstillingene i Twitter hvor autoriserte 3.partsapplikasjoner kan administreres. Bruk gjerne 3.partsapplikasjoner, men vær alltid varsom og grunnleggende skeptisk. Da går det bra. Disse forhåndsreglene gjelder for øvrig ikke bare Twitter, men også Facebook og andre Web 2.0-tjenester.

Dersom du tror dette innlegget kan ha nytte for andre som kan ha nytte av å kjenne til problematikken, så spre gjerne. Hvis jeg får spam på Twitter så sender jeg en beskjed til spam-offeret som viser til dette og forrige blogginnlegg om problematikken, føl fri til å gjøre det samme om du vil:

Hei, du er trolig hacket og har sendt ut spam. Noen vet passordet ditt. Se analyse/tiltak på: http://bit.ly/bhCr4m og http://bit.ly/dwFauK

Har du andre sikkerhetshensyn som folk bør være klar over når det gjelder Twitter, eller synspunkter på dette innlegget?

25. februar 2010

Twitter og phishing

I dag ble jeg forsøkt "hacket" på Twitter. Jeg gikk ikke fem på, men jeg ser for meg at mange gjør det. Angrepet er utspekulert. Jeg fikk nemlig en direktemelding fra en nordmann på Twitter (varsling via e-post). Da er det fort gjort å bli lurt. I dette innlegget skriver jeg om mine erfaringer og refleksjoner, og prøver å forklare hva phishing er slik at du kan lære mer om sikkerhet på nett generelt og phishing spesielt. Jeg vil også foreslå noen strategier for å unngå å gi fra deg din innloggingsinformasjon.

Analyse av et phishing-forsøk

Start med å se nøye på denne meldingen:

Her har en nordmann, la oss kalle ham "Lasse", tilsynelatende sendt en direkte melding til meg. Som vi skal se senere er det ikke Lasse, men en automatisert rutine, som har sendt meldingen. Det er fordi Lasse har blitt lurt i første omgang, og med en gang han blir lurt, brukes han som virkemiddel for å lure andre. Hvis jeg blir lurt, så brukes jeg også.

Meldingen er skrevet på engelsk. Jeg ante derfor raskt at det var "moser i luften". Neste bilde viser hva som møter brukere som klikker på lenken:

Klikk på bildet for å åpne i større versjon

URL-en i adressefeltet avslører at dette ikke er en Twitter-side. Det hackeren her har gjort, er å gå til Twitter, vise kildekoden, kopiere den, lage en ny fil, lime inn HTML-koden og så legge ut filen på sitt eget nettsted. Det er den falske websiden vi ser i bildet over, men det ser helt likt ut med hvordan Twitter presenterer innlogging når du klikker på noe som krever innlogging uten å være logget inn.

Hackeren har for øvrig endret en viktig detalj i HTML-koden. Når du skriver inn brukernavn og passord og trykker "Sign in"-knappen, så lagres informasjonen i en database. Jeg har ikke prøvd, men dersom hackeren er lur så vises enten ressursen du forventet å få se (et bilde i dette tilfellet), eller så vises en feilmelding, eller kanskje redirigeres du til den ekte Twitter-innloggingssiden. En smart hacker vil prøve å skjule overfor alle ofre at de nettopp har blitt lurt til å oppgi brukernavn/passord. Derfor må en være føre var i stedet for etterpåklok i slike situasjoner. Det er verdt å understreke at hackeren ikke sitter klar og reagerer i det folk trykker. Hackeren har laget et automatisert script/programrutine som utføres i det øyeblikk "logg inn"-knappen trykkes. Alt er klargjort på forhånd. Derfor kan tusenvis gå i fellen samtidig.

Hackerens motivasjon

Du lurer kanskje på: Hva skal egentlig hackeren med innloggingsinformasjonen din? Hackeren har laget et script som automatisk logger inn i kraft av offeret og sender tilsvarende direktemeldinger til dem som offeret følger. Meldingen sprer seg da i takt med at stadig nye mennesker går på. For hver ny person som blir lurt øker databasen over gyldige brukernavn og passord. Målet er å få flest mulig brukernavn/passord. Hvorfor er dette skummelt? Hva skal hackeren med dette?

Twitter-kontoen din brukes ved første øyekast til å lure andre. En kan fort tro at målet blir å lure flest mulig, men det er ikke tilfelle. Det er mer korrekt å si at metoden er å bruke eksisterende nettverk og tilliten som ligger i direkte meldinger, til å lure flest mulig. Målet er ikke å lure folk, men å stjele fra folk. Hva da? Hva er verdien av at hackeren vet brukernavnet og passordet ditt og mange andre sitt? La oss tenke over hva hackeren egentlig har. Han har ikke bare en liste over brukernavn/passord, men han kontrollerer faktisk utrolig mange ekte, etablerte Twitter-kontoer. Dette er verdifullt. Veldig verdifullt. Han kan for eksempel spre reklame for et produkt med jevne mellomrom, og nå hundretusenvis av følgere som ellers ikke ville fått informasjonen. Tenk deg at jeg plutselig sender ut reklame på Twitter for en duppedings, uten at jeg selv vet om det. Hvordan vil mine følgere tolke det? Jo, de vil ta det som en anbefaling siden jeg ellers skriver faglig interessante meldinger. Dersom et firma sender en slik, så overses det i større grad. Det å misbruke hackede kontoer blir derfor et kraftig instrument med tanke på reklame. En kan tenke seg mange varianter av dette. Det er derimot noe enda mer alvorlig vi bør se på.

Hackeren vet at mange mennesker benytter samme brukernavn og passord for ulike web-tjenester. Når hackeren har en riktig kombinasjon av passord/brukernavn, kan hackeren prøve denne på gmail, paypal, facebook, ... og så videre. Det er ikke sikkert det går, men det kan være. Det kommer an på hvilken passordstrategi offeret har benyttet. La oss si at hackeren gjennom et slikt angrep klarer å samle inn 10.000 brukernavn/passord. Det er da sannsynlig at en god del av disse har samme id-er på en rekke nettsteder (de som er på Twitter er trolig på mange nettsteder, så her er det bare å prøve i vei). Om hackeren bare får treff med brukernavn/passord på 100 PayPal-kontoer av 10.000 ofre, så er det likevel god butikk. Det er også mulig å lage automatiserte rutiner som tester om innlogging lykkes eller ikke, og bygger opp nye lister over hvilke brukernavn/passord som fungerer på hvilke nettsteder. En manuell analyse utført av hackeren vil også kunne avsløre mønstre i passordene. Selv om en bruker varierer passordet fra tjeneste til tjeneste, vil hackeren kanskje kunne klare å gjette seg til hva variasjonen består av, og slik knekke de virkelige inntekstbringende tjenestene (PayPal for eksempel).

En annen motivasjon kan være å samle en stor base av brukernavn/passord og så selge til høystbydende slik at de kan gjøre butikk av det.

Hvorfor lykkes slike angrep?

Dette er en variant av såkalt "social engineering". Hackeren har forstått Twitter og vet at direktemeldinger varsles per e-post og vises med full tekst i e-posten. Brukeren som får en slik e-post (potensielt offer) trenger altså ikke logge seg inn på Twitter for å se meldingen. Den står i klartekst i e-posten. Men - her er det en lenke og teksten gjør folk nysgjerrig på hva som er bak lenken. Mange vil klikke og møter en beskjed om å logge seg inn på Twitter. Noen aner lunten og avbryter, men siden en kom fra e-postprogrammet og ikke fra Twitter direkte, vil mange trolig tenke at "aha, nå vil Twitter at jeg logger inn for å se ressursen så da får jeg logge inn". At en får direktemelding gjør det hele mer troverdig. Prøv gjerne å oppsummere overfor deg selv hva som nå er nøkkelen til hackerens suksess.

Min korte oppsummering er at hackeren lykkes ved å

  • gjøre angrepet troverdig og å skape tillit
  • lede offeret til en falsk versjon av en webside, med det formål å stjele informasjon fra offeret
  • bruke offeret som virkemiddel for å skalere opp angrepet

Hvordan unngå phishingangrep?

Phishing er utbredt. Det er fordi vi i det siste har sett en sterk vekst i nettbaserte tjenester. Stadig mer av daglige gjøremål skjer på nett, og massen av brukere øker kraftig. Det betyr at potensielle ofre øker tilsvarende. Det er viktig å være oppmerksom på lenker en klikker på. Hvis jeg får en lenke med varsling om at jeg har fått melding på Facebook, Twitter eller andre tjenester, så åpner jeg alltid et nytt blankt vindu og logger inn på den aktuelle tjenesten. Deretter klikker jeg på lenken i e-posten. Det tar noen sekunder ekstra, men hindrer at jeg blir lurt dersom lenken er en phishing-lenke. Selv om varslingens meldingstekst ser autentisk ut kan det være phishing. Bedre føre var...

Dine passord er gull verdt. De gir deg tilgang til noe bare du skal ha tilgang til. Dersom ditt passord på en tjeneste blir kompromittert, enten ved hjelp av phishing eller andre teknikker, så ønsker du trolig å redusere skaden så mye som mulig. Da kommer vi inn på passordstrategi. Vi mennesker har ikke evne til å huske mange ulike passord, og faller for fristelsen til å bruke samme passord overalt. Det gjør derimot eksponeringsfaren større i tilfelle du blir lurt overfor en tjeneste. Jeg har skrevet en praktisk veileder om hvordan en kan tenke om gode brukernavn og passord som er høyaktuell i så måte.

Dersom du har mistanke om at du har blitt utsatt for et slikt angrep, så endre Twitter-passordet ditt umiddelbart. Da vil hackeren ha et ugyldig passord og kan ikke lenger utnytte brukerkontoen din. Vurder nøye om du virkelig vil bruke samme passord flere steder. Twitter er en avansert tjeneste med tanke på økosystemet rundt Twitter, og kan være ekstra sårbart for angrep. Selv har jeg nå endret slik at Twitter-passordet mitt er unikt kun for Twitter.

Hva tenker du?

I dette innlegget har jeg prøvd å reflektere litt om hvordan slike angrep typisk utføres, motivasjonen til hackeren og hva du kan gjøre. Har du forslag til flere argumenter eller andre mulige synspunkter? Legg gjerne igjen en kommentar.

31. august 2009

Gode presentasjoner og Powerpoint 2010

Jeg har lagd ganske mange presentasjoner i mitt liv, og merker at jeg stadig utvikler meg, men fortsatt har veldig mye igjen å lære. Det er derfor spennende å se en demo av hva Powerpoint 2010 kan by på (video under). Det konkurrerende programmet Keynote (fra Apple) har i et par år hatt mange av de samme mulighetene, og neste Keynote-versjon kommer sikkert med mye nytt for å "matche" Powerpoint. Likevel - det viktigste spørsmålet er ikke knyttet til om en velger Apple eller Microsoft. Det som trengs er å gå bort fra den tradisjonelle måten å tenke presentasjoner på, og etter min mening er dette delvis et ansvar som programvaren må ta på seg.

Det mest interessante med Powerpoint 2010 er å se hvordan brukergrensesnittet for å lage gode presentasjoner er lagt opp. 95% av verdens presentasjoner består av (alt for mange) kulepunkter. Det er her utfordringen ligger - å få folk til å tenke anderledes når de skal bygge opp sine presentasjoner. Det er derimot ikke slik at fancy overganger og speileffekter er mest riktig å bruke, og at det er viktig at programvaren har mest mulig slik funksjonalitet. Det å lage gode presentasjoner er en kunst, både med tanke på utseende, hva en vil presentere og hvordan en strukturerer innholdet. I tillegg er det viktig å forstå samspillet mellom det deltakerne ser, og det du sier som foredragsholder. Edward Tufte har kritisert måten Powerpoint brukes på, særlig bruken av kulepunkter som ofte resulterer i "cognitive overload". Det å gå bort fra kulepunktene, eller kanskje heller, gå bort fra den tradisjonelle måten å bygge opp/holde en presentasjon på, krever en ny tenkemåte. Kulepunkter kan ha mye for seg, men bare om de brukes gjennomtenkt og riktig. En bok som har god teoridiskusjon og med mange fine eksempler på hvordan en kan tenke nytt om sine presentasjoner og gå over i mer visuelle tankebaner, er Slideology av Nancy Duarte. Anbefales!

Jeg har lært mye om gode presentasjoner bare ved å bruke programmet Keynote. Apple har tatt et veldig riktig steg ved å oppfordre brukere av Keynote til å benytte såkalte "smart builds" og "magic moves" som setter det visuelle (bilder) i fokus. Dette (og mer til) har gitt meg som foredragsholder ny lyst til å lage anderledes, mer visuelle presentasjoner. Tilbakemeldingene vitner om at publikum også liker noe som ikke er så preget av kulepunkter. Jeg brukte først Powerpoint for Windows, så Powerpoint for Mac, men byttet for 2 år siden til Keynote etter å ha oppdaget hvordan Keynote implisitt hjelper meg til å tenke mer visuelt. Kreative mennesker klarer alltids å lage flotte presentasjoner uansett hvilken programvare de bruker, men ikke folk flest. Det er derfor etter min mening viktigst av alt at programvaren oppfordrer oss til å lage gode presentasjoner.

Jeg håper derfor at PowerPoint 2010 kan oppfordre sine millioner av brukere til å tenke nytt slik at vi slipper å se de samme rekkene med kulepunkter på konferanser og foredrag heretter. Vi bør snart være modne til å ta steget mot bedre presentasjoner, etter snart 15 års kulepunkt-trening med PowerPoint/Keynote og tilsvarende verktøy. Det er da også spennende å se hvordan Web 2.0-verktøy som for eksempel Prezi oppfordrer oss til å tenke helt nytt og tilbyr noe radikalt anderledes enn Powerpoint/Keynote.

21. mars 2009

Observasjoner fra en forfatter

Før og etter jul har jeg brukt mye tid på å lage ny 3. utgave av "Webprogrammering i PHP" (http://phpbok.no). Det var en lang, men lærerik prosess sammen med Gyldendal. Det er slitsomt å komme i gang, for det er et aldri så lite fjell å bestige. Hva innebærer prosessen med å skrive bok, og vedlikeholde den i ettertid? Hvordan kommunisere korrekturfeil på en effektiv måte? Fins det tips og triks for å skrive bedre norsk?

Disclaimer: Dette blogginnlegget kan inneholde grammatiske feil. I en eventuell 2. utgave av dette blogginnlegget vil trolig korrekturleseren ha oppdaget de fleste, og språket være ytterligere perfeksjonert.

STEG 0. Snart tomt for bøker:

Gyldendal følger med i timen og varsler fra når det nærmer seg tomme lagerhyller. Det er da, så vidt jeg har skjønt det, tre valg:

  • Trykk opp på nytt, men nytt opplag (jeg må endre teksten på kolofonsidene først i boka om trykkeri, ISBN-nr etc)
  • Trykk opp på nytt, men som ny utgave (jeg må gjøre litt større endringer som gjør at sidetall forskyves og tekst byttes ut)
  • Levetiden er over, salget er for dårlig og boka fjernes fra sortementet

For min del var det alternativ to som slo til. Ny utgave, masse jobb og bare å bygge seg mentalt opp. Det er lurt å få en endelig sluttdato, og det er lurt å starte i god tid før denne sluttdatoen (men lett er det ikke).

STEG 1. Installasjon av programvare:

Før du får gjort noe som helst med skriveprosessen, må skriveprogramvaren installeres og fungere som det skal. Adobe FrameMaker brukes av forfattere hos Gyldendal/TISIP. Det er et enormt stabilt program som støtter 100 % godt opp om skriveprosessen, men et problem for mange er at bruksterskelen er noe høyere enn Word. Manglende fonter (skrifttyper) kan også være et problem, men jeg har alt i en mappe: Programvare, fonter, kildefilene til boka og også hjelpeinstruksjoner jeg selv lagde tilbake i 2004 da boka ble skrevet første gang. Det var noen år siden sist jeg lærte meg FrameMaker. Jeg ble overrumplet av mine egne fingre som automagisk gjorde noen hurtigtast-kommando-kombinasjoner, og vips, var stilen "2 punkts dummy" satt inn over en ny figur - akkurat slik den skulle i henhold til den profesjonelle Gyldendal-malen. Boka består av 14 kapitler, og hvert kapittel er lagret som én fil. Alle bilder og figurer er for øvrig lenket inn i hver kapittelfil. Figurer med piler, bokser og liknende er laget i Microsoft Powerpoint, og som følge av lenkingen er det bare å dobbeltklikke på en figur, så spretter Powerpoint opp og jeg kan endre figuren som ønsket, lagre, og alt er oppdatert i boka. Heldigvis slapp jeg unna feil i selve FrameMaker-oppsettet.

STEG 2. Planlegge endringer:

Jeg har samlet kommentarer både fra tilbakemeldinger (skjema på websidene mine), fra lærere rundt om i landet som bruker boka i undervisning, og som jeg har pønsket ut selv. Jeg lagde meg en gjøremålsliste som et eget dokument. Denne ble to A4-sider lang. Jeg har aldri helt skjønt vitsen med funksjonen "gjennomstreking" i vanlige tekstbehandlere, men nå fikk den mening: strek gjennom ting etterhvert som de gjøres, for da ser jeg hva som er gjort. Det er også motivasjon i dette. Endringene mine var i grove trekk:

  • Oppdatere installasjonsrutinene for hvordan PHP, MySQL og Apache installeres.
  • Endre all HTML-kode til XHTML-form. Det skulle vært gjort fra starten av, men er i hvertfall på plass nå.
  • Fjerne stoffet om register_globals.
  • Ta med litt mer om MySQLi.
  • Rette feil.

Todo-listen er vist i figuren under og gir et visst inntrykk av hva en slik ny utgave kan innebære av arbeidsoppgaver.

STEG 3. Ta inn over seg ikke-planlagte endringer:

Deretter viste det seg at det var behov for en ny korrekturrunde, da "et par kommaleifer" i de forutgående versjonene var oppdaget på tross av en grundig vask i 2004. Begrepet "et par" kan bety "2" (dette visste jeg) men også "1500" (det vet jeg nå). Med mellom 3-5 kommafeil per side i snitt, og 400 sider totalt i boka, er det ikke overdrevent å si at det var minst 1500 kommafeil som måtte rettes ...

STEG 4: Just do it:

1500 kommafeil og ymse skrivefeil... For en jobb! Den beste metodikken når du er kommet så langt, er "just do it". Sett i gang, og det går gradvis fremover.

STEG 5: Lær deg å lese korrekturspråket:

Jeg vil påstå at jeg behersker følgende språk: Norsk, nynorsk, engelsk, tysk, fransk og korrektur. Korrekturspråket er trolig ukjent for de fleste. Det har en spennende syntaks og er et språk som kan læres relativt lett. Jeg lærte det av meg selv, mens jeg leste, ved å tenke meg til hva som var riktig og hva som var galt. Tegnene er snedige, men de er faktisk ganske smarte. La oss gå gjennom anmerkningene i figuren under for å forklare hvordan profesjonelle korrekturlesere formidler sine funn til forfatterne:

I rekkefølge ser vi følgende kommunikasjon fra korrekturleseren uti margen til høyre:

  • fjern kommaet
  • komma etter "r"
  • komma etter "8"
  • slå sammen e og s og sett bindestrek mellom
  • fjern kommaet
  • komma etter "n"
  • punktum etter "g"
  • fjern komma etter "dagen"
  • komma etter "h"

Legg merke til hvordan korrekturleseren på en kompakt, presis og unison måte klarer å formidle hva som er feil og hvordan det kan rettes opp. Det er altså tegn for å slå sammen bokstaver, koder for å legge til og for å slette. En uerfaren skribent kan tro at det er forskjell på andre og tredje kommafeil (ref listen over og i figuren), men det at vinkeltegnet foran "r," og "8," går ulik vei, har faktisk bare å gjøre med at korrekturleseren har behov for å skille de to fra hverandre. Det er her snakk om samme type feil, men likevel to instrukser. Det blir viktig å knytte instruksene til riktig feil i tilfelle det er forskjellig type feil i nær avstand. Videre har jeg funnet ut at det krøllete tegnet visstnok står for "delur", eller var det "delatur", som uansett betyr å slette (nesten som delete på datamaskinen).

STEG 6: Skjerp deg til neste gang:

Det er gunstig for egenmotivasjonen å betrakte korrekturleserens tilbakemeldinger som noe positivt, for eksempel "mulighet for læring". Jeg har unektelig lært en hel del av korrekturen og håper nå å aldri se en kommafeil og andre flaue formularer igjen i mine kommende produksjoner. I god delingsånd avsløres noen av mine tips og triks som kan være til nytte for alle som skriver bøker eller andre mer seriøse tekster:

  • Kommaet skal med stor sannsynlighet være stikk motsatt av det du selv tror. (Hvis du bytter om, så er det antakeligvis stikk motsatt da også, så det er kanskje like greit å gi opp først som sist :-)
  • Husk at det ikke skal være komma foran ordet "og". Bare av og til. Plasser derfor et komma foran "og" med jevne mellomrom, men ikke overdriv.
  • Jeg bruker trolig orddeling med binde-strek altfor mye i mine skriblerier. Et ord som "sekund-delen" skal ikke deles, har jeg erfart, men for å forsvare meg selv tror jeg at jeg tenderer mot å dele ord som jeg selv legger inn pause i når jeg uttaler det muntlig. Mulig det er fordi jeg er nordlending at det blir pause når jeg sier "sekund-delen" muntlig? Altså at palataliseringseffekten slår ut i slutten av "sekund" og dermed ødelegger noe? For å gjøre det hele mer komplisert, skal ord som hash-funksjon vitterlig deles med bindestrek. Det er mulig at dette skyldes at de uttaler slike ord nokså "tregt" nedpå Østlandet ;-)
  • Ordet "automagisk" passerte heldigvis språkvasken også i denne korrekturrunden! Jeg antar det er fordi Gyldendal har innlemmet ordet i sitt vokabular etter at det med viten og vilje ble snik-innført i min 1.utgave (eller skal det være "snikinnført"?)
  • "Webprogrammering i PHP" er ei bok om programmering, mer nøyaktig om å lage dynamiske og interaktive, solide websider/systemer. Boka har mange eksempler på programkode som forklares og drøftes i teksten. Språkvaskeren (som for øvrig var meget dyktig) - gikk grundig til verks og rettet språkleifer i selve programkoden! Det er ikke bare imponerende, men viser også at webprogrammering er i ferd med å ta av og når ut til stadig nye målgrupper (nå også korrekturlesere). Fra spøk til alvor: Problemet er bare at disse leifene også reflekteres i skjermbildene mine. Hvis en kodesnutt har kode for å oppsummere valgt flyreise etter en flybestilling, og jeg i output-teksten har skriveleifer - så hjelper det lite å rette feilene i programkoden fordi da må jeg også ta nytt bilde av skjermen/websiden. Det må være samsvar mellom figurene og programkoden. Grammatiske feil i koden er altså ikke-trivielle å rette. Skjermbilder må nemlig lagres som TIFF og behandles i Photoshop slik at de får riktig fargerom - noe jeg husket lite av fra 2004. Resultat: Programkoden i boka er visse steder preget av programmeringslærer-norsk, mens teksten i boka bærer form av norsklærer-norsk.
  • Det å "gjentegne" er ikke noe ord. Når jeg nå ser at det står alene, og ikke i kontekst, er jeg faktisk ganske enig. Hva skulle vel "gjentegne" bety? Hmmmm.
  • Vær konsekvent. Når korrekturleseren (eller du) oppdager et ord som er feil, så søk gjerne opp alle forekomster av dette ordet og erstatt først som sist. Ikke fall for fristelsen å kjøre så effektivt som mulig ved å velge "erstatt alle". Det kan få uforutsette konsekvenser hvor du mister tekst eller får nye rare ord som resultat. Jeg prøvde denne snarveien uten å tenke på endelser som ville bli feil, og resultatet ble at jeg fikk 3 timers ekstra ryddejobb. Småkjedelig, men en fin erfaring.
  • Jeg lukter forresten at hele denne punktlisten trolig vil måtte omskrives med tanke på orddeling, kommaets plassering og tungt språk hvis en korrekturleser får snus i den :-)

STEG 7: Lag ordliste over dine terminologiske uvaner underveis:

Dine feil er deg allerede tilgitt, men du har samtidig en gyllen mulighet til å unngå å falle tilbake til gamle synder. Vil du skrive godt i alle sammenhenger, bør du vende gamle vaner først som sist. Her er mine vanligste feil som jeg heretter skal prøve å få riktig i all skriftlig kommunikasjon:

Punktlisten tar formen: Det heter ikke ... men ...

  • anderledes ... annerledes
  • etterhvert ... etter hvert
  • adskilt ... atskilt
  • syv ... sju
  • inni ... inne i
En korrekturleser har allerede fått snusen i dette blogginnlegget før det er publisert, og skriveprosessen avbrytes derfor av en il-melding fra Gyldendal med følgende opplysning: Syv/sju og inne i /inni representerer valgfrie former. Har man først valgt den ene formen, bør den gjennomføres konsekvent. Ok, da forstår jeg og er faktisk litt lettet. La oss fortsette listen:
  • forklaring til ... forklaring på
  • mulighet til ... mulighet for
  • tilslutt ... til slutt (ok, den kjøper jeg)
  • i det ... idet (noe skjer)
  • forståelse for ... forståelse av
  • ettersom ... etter som
  • tungvindt ... tungvinn
Hepp, hepp, hepp... Ikke så fort nå! Ny oppklaring fra Gyldendal: Forståelse for / forståelse av er begge gangbare uttrykk, men de betyr forskjellige ting. Forståelse for uttrykker gjerne en slags empati, mens forståelse av gjerne brukes i betydningen ”oppfatte/skjønne” Det samme gjelder ettersom (= da/siden) og etter som (= etter hvert som). Tungvinn brukes når det står til et hankjønnsord; tungvint når det står til intetkjønn. Observasjon til deg som leser fra meg: La du merke til den elegante bruken av semikolon fra Gyldendal her?!! La oss fullføre listen:
  • potensiale ... potensial
  • tvert i mot ... tvert imot
  • priviligert ... privilegert (den er vrien og jeg tipper at de fleste skriver dette ordet feil. Tenk på "et privilegium")

Siden jeg har skrevet bok om webprogrammering, tenker jeg umiddelbart at jeg ikke bør skrive en slik ordliste på papir og heller ikke i et digitalt dokument. Jeg bør rett og slett lage en database og et tilhørende web-grensesnitt hvor brukeren kan legge inn ord som staves feil i ett tekstfelt, og ordets riktige form i neste tekstfelt. Dette var en god idé! Søk etter ord er en viktig funksjonalitet å lage. Systemet kan utvides med flere brukere, og da bør innlogging på plass og validering av inngangsdata for å unngå hacking er et must. Fordelen med å tillate flere brukere i et slikt system, er at da kan en dele ord med andre, se på andres ordlister, stjernemerke favorittord, bli venner med andre som har samme ord på sin liste, og så videre. Hmmmm, dette skal jeg gjøre - det blir jo en slags Facebook for språkinteresserte, og det er meget lett å realisere når en kan PHP!
Nei, forresten, dette blir vel for nerdete! Nå tar jeg helt av og bør heller prioritere det som må gjøres av forsømte oppgaver fremover. Men kanskje du som leser boka vil lage et slikt system? I så fall vil jeg gjerne registrere meg som bruker!

STEG 8: Puh, endelig ferdig ...

... eller bare nesten. Du er riktignok ferdig med bokskrivingen, men får skriveabstinenser og har et par timer senere skrevet et lengre blogginnlegg om prosessen.

STEG 9: Blogginnlegg publiseres:

Av gammel vane sendte du blogginnlegget til Gyldendal for korrekturlesing. Det kommer i retur med et par anmerkninger, og først nå kan du publisere det.

STEG 10: Etterarbeid:

Det meste begynner på 0 i programmering (indeksverdier i arrays/tabeller/matriser for eksempel). Den oppmerksomme leser ser at også denne listen starter på 0, så dette er faktisk det ellevte steget. Selv om en tilsynelatende er ferdig, vil forfatteren gå inn i en langtekkelig fase der neste utgave av boka planlegges mentalt, gradvis. Tanker modnes og en følger jevnlig med på utviklingen av fagfeltet på jakt etter nye ting som må oppdateres. Ambisjonen om å skrive noe bonusmateriell og lage noen filmklipp som legges ut på bokas ressursside (http://phpbok.no/) skal realiseres, men bare ikke akkurat nå. Kanskje i morgen.

Slik var altså min bokprosess. Jeg kan dessverre ikke garantere mot verken kommafeil eller orddelingsregelbrudd i dette innlegget, men håper det var litt nyttig å få vite hva som kreves av vedlikehold i forbindelse med en bokutgivelse. Vil du skrive bok, så er oppfordringen min: Gjør det! Du lærer enormt mye både faglig, av skriveprosessen og av kommunikasjonen med forlaget. Det tar tid, men du kan søke om stipend (jeg fikk ikke) eller kanskje få aksept av en oppegående arbeidsgiver om at det er nødvendig med sammenhengende tid til å skrive (det fikk jeg). Du vil aldri angre, så ikke nøl, og lykke til!

5. mars 2009

Gode passord

Spotify er blitt hacket. Dette er meget alvorlig fordi mange bruker samme brukernavn/passord flere steder på web. Det er lurt å bytte passord hos Spotify (gjelder de som laget konto før 19.des 2008). Jobben blir tidkrevende fordi du også bør bytte alle andre steder hvor du har brukt samme passord. Hendelsen understreker også hvor sårbare vi blir når vi legger våre data på web, og stoler blindt på systemene. Dette blogginnlegget vil ta opp litt mer i dybden om passord. Jeg har tidligere skrevet en veileder om passord men den tror jeg ikke så mange har oppdaget, så derfor har jeg tatt en del av teksten derfra i dette blogginnlegget.

Mange passord er ikke sikre nok

Bruce Schneier er en guru på sikkerhet og det månedlige nyhetsbrevet hans Crypto-Gram anbefales på det sterkeste. Han skriver ofte om folks forhold til sikkerhet. Mange tror for eksempel at det er lurt å erstatte teksten -en på slutten av et passord med et 1-tall, men det er ikke godt nok. Passord-knekke-programvare prøver slike substitutter. Schneier skriver blant annet (et stykke ned i artikkelen) at bare ved å ta 1000 vanlige ord som "password", "1234" og liknende, og så kombinere med 100 vanlige endelser som "1", "@", "4u", årstall og så videre, vil en finne 24 % av alle passord (i følge hans studier). Et program kan gjøre dette lynraskt.

Hvordan lage gode passord?

Hvordan skal en så tenke angående sine passord? Jeg har ikke nødvendigvis noen fasit, men her er noen tips til hva du kan tenke på i valget av passord, og noen eksempler på slike. Egenskaper ved et godt passord:

  • Lett å huske. Du bør ikke skrive opp passordet noen steder.
  • Lett/raskt å skrive. Det reduserer sannsynligheten for at noen ser over skulderen din hva passordet er.
  • Ha minst ett siffer i seg. Unngå bare sifre, eller å repetere enkelte tegn for mange ganger. Da blir oppgaven å knekke passordet lettere.
  • Bestå av minst 8 tegn, gjerne flere, og helst en miks mellom store, små, sifre og spesialtegn.
  • Byttes regelmessig. Hva som er regelmessig er relativt. Byttes det for ofte, medfører det at passordene går i surr, og folk starter å skrive ned passordene - noe som er dødssynd nummer én.
  • Ikke inneholde vanlige ord som fins i ordlister.
  • Unngå enhver form for informasjon som kan knyttes til deg, for det er gjerne det første som en angriper forsøker seg på. Deler av navnet ditt + familie, fødselsdatoer, adresser, telefonnumre, brukernavn og liknende må unngås. Det hjelper ikke om du staver baklengs, med store/små bokstaver, dobbelt opp og andre basisteknikker.

Det kan synes vanskelig å oppfylle kriteriene fra forrige punktliste. Hvordan skal du gå fram for å lage et godt nok passord? Her er noen tips:

Tips 1: For å få mer enn 8 tegn, så tenk i form av setninger. Slike husker du mye lettere enn tilfeldige tegn og de kan gi tilnærmet like gode passord. Du kan stokke om på setninger, kombinere strofer fra to sanger, ta en bestemt bokstav fra hvert ord i setningen, eller liknende. En ofte brukt teknikk er å velge første bokstav fra en kjent sang, et dikt eller en setning du selv lager. "Det snør, det snør - tiddelibom sa Ole Brumm" kan da gi passordet Ds,ds-tsOB. Legg merke til at komma brukes i passordet. Det er ikke bare lov, men gjør det til et bedre passord. Passordet er dessuten lett å huske og består tilsynelatende av tilfeldig valgte tegn.

Tips 2: En annen teknikk er å slå sammen to eller flere ord, og så knytte disse sammen med et eller flere spesialtegn. Hvis du ser på passordet tull-geit:house finner du en blanding av engelske og norske ord. Det er også lett å huske, lett å skrive, har 15 tegn, men bare små bokstaver, og ingen sifre. Likevel et sterkt passord

Tips 3: Passordet Berg1 er en fin by 03 har 21 tegn, og det er mer enn nok. Det er lett å huske og lett å skrive, og har spesialtegn (mellomrom), store og små bokstaver og sifre. En kan også sette opp slik at dette passordet gjelder for mars måned (nr 03 tilsvarer mars). Når april kommer, og du logger inn, vil du fort oppdage at du skriver inn 03. Slik får du automagisk en påminnelse om at det er på tide å bytte passord. Det enkleste er å bytte til "Berg1 er en fin by 04", men det skader ikke å være mer kreativ. Det er sunt å bytte hele passordet. Hvis du heller vil bytte hvert år, så bruk 09 for 2009, 00 for 2010, 11 for 2011 og så videre.

Tips 4:La oss se på en litt mer avansert konstruksjon: Berg1 by@Vestland1.no. Her kombinererer du ting som naturlig hører sammen (evt. som du later som at hører sammen). Bergen ligger på Vestlandet i Norge (no). Det er likevel nesten umulig å gjette et slikt passord, skjønt veldig lett å huske for deg. Oppbygningen som en e-postadresse fører til at du får brukt flere spesialtegn, og gjør det lett å huske, siden @ kan leses som engelske "at". Dermed betyr altså ola@adresse.no det at ola hører til hos (at) adresse.no. Denne tankemåten kan du bruke til å lettere bygge opp gode passord.

Tips 5: Det kan bli en utfordring dersom du har mange ulike passord. En god regel er å ikke bruke samme passord på mange steder, fordi dersom passordet ditt blir kompromittert (dvs at andre får tak i det) på ett sted, kan det brukes til å logge inn på andre steder. Det kan være lurt å benytte kategorier med middels, sikkert og meget sikkert nivå på passordene dine. Da trenger du tre passord å holde styr på, og hvis ett passord avsløres (som nå var tilfelle med Spotify) trenger du ikke endre mer enn de tjenestene som er på samme sikkerhetsnivå.

Alternativt kan du ha ett passord for hvert eneste sted du skal logge inn på:

  • arbeidRliv1@work.yes - brukes på jobben. Arbeid er livet for mange. En slik setning gir store og små bokstaver til dette passordet. R kan leses "er" og 1 kan leses "et". Med andre ord: Lett å huske og teknisk sett et sterkt passord.
  • famili1Rliv1@home.jippi - brukes på hjemmemaskinen. Familien er viktig. Lett å huske.

Et passord er mer enn bare passordstyrken

Passordets styrke er bare en liten del av sikkerheten knyttet til et passord. Tenk over viktigheten av følgende:

  • Del aldri ut passordet til andre, og må du det, så bytt det etterpå (selv familiemedlemmer).
  • Tenk over hvor og hvordan du bruker passordene dine. Ser noen over skulderen din? Går det an å lese på leppene dine hva du skriver? (hvor mange sier vel ikke pinkoden inni seg ved betaling med VISA i butikken... :-)
  • Memorer passordet, ikke skriv det opp. Skriv eventuelt opp tilstrekkelig informasjon til at du, og bare du, klarer å resonnere deg fram til riktig passord.
  • Kategoriser de passord du har. Det beste er å ha unike passord for hvert system. Dersom du har mange, kan du dele inn i kategorier for grad av sikkerhet, for eksempel "viktig", "middels" og "usikkert". Du kan for eksempel klassifisere slik at passord relatert til jobben, brukes også i nettbank (siden begge er viktige systemer som bare du skal ha tilgang til). For å logge inn på din brukerkonto hos diverse Internettjenester som Facebook, Twitter, bloggen din, gmail/hotmail, etc. bruker du passord fra en annen kategori.
  • Ringer noen til deg og spør om passordet ditt, med begrunnelse i at de er IT-personell som må sjekke opp diverse ting? Sannsynligheten for at du blir utsatt for "Social Engineering" er stor. Dvs noen som prøver å lure deg til å oppgi passordet ditt.
  • Passord skal byttes regelmessig. Et problem er å komme på passord, noe helt annet er å vite hvordan en faktisk kan få utført skiftet. Enhver virksomhet/bedrift/institusjon bør ha en sikkerhetspolicy og/eller veiledere som forklarer hva som må til for å bytte passord på for eksempel e-post, ansatt-PC, felles dataområder, nøkkelkort og liknende. I tillegg har du mange egendefinerte steder hvor du bruker passord. Det kan være lurt å notere seg disse stedene, og fremgangsmåte for å bytte (hvis det er vanskelig å huske). Prøv å skrive slike ting på en slik måte at ikke uvedkommende forstår informasjonen.
  • Hvor skriver du inn passordet ditt (i hvilke systemer)? Har du klikket på en lenke i en e-post eller på en hjemmeside du ikke kan si 100% at du vil stole på? Du kan bli utsatt for phishing, en form for "Social Engineering" hvor noen prøver å lure deg til et falskt nettsted. Den som har laget det falske nettstedet ønsker å "fiske til seg" passord og opplysninger som han/hun egentlig ikke skal ha. Dersom du prøver å logge inn på det falske nettstedet (i god tro), vil personen som lagde det falske nettstedet ha mottatt denne informasjonen og vil kunne bruke den på det ekte nettstedet, og slik klare å logge inn, identifisert som deg. Fiskes ditt e-postpassord opp, kan den andre lese e-posten din. Fiskes ditt nettbank-passord opp, kan du tape penger. Phishing er ekstra skummelt dersom du bruker det samme passordet ditt flere steder. I så fall kan "en uskyldig surfetur (du klikker på lenke i phishing-angreps-e-post) ende i en stor fisketur hvor angriperen får notet fullt av mange fisker".

Mer om passord

Jeg har laget en liten passordgenerator i programmeringsspråket PHP hvor du kan få generert forslag til et passord ved å skrive inn navnet ditt. Ikke verdens beste løsning, men småmorsomt. Det er for øvrig ikke noe hemmelig som skjer bak kulissene, ingen loggføring og ingen lagring av det som skrives inn, så det er bare å leke seg!

Hvis du lurer på hvor sterkt et passord er, så kan du teste det hos svenske Post og Telestyrelsen (PTS). Merk: SSL brukes i det du skal skrive inn selve passordet ditt. Du kan dermed være trygg på at ingen avlytter linjen og snapper opp de passord du vil analysere. Vær kritisk ved bruk av slike webbaserte verktøy, fordi det kan jo være "slemme" personer som har laget tjenesten og bare ønsker å snappe opp alle passord som skrives inn. PTS i Sverige er nok en rimelig seriøs og trygg aktør.

Hvilken strategi bruker du for å lage passord?

24. februar 2009

En IEpoke er over

Mange store nettsteder, store deler av Twitter, bloggosfæren, digg og en rekke andre fora kjører i disse dager en viktig kampanje der målet er å fjerne Internet Explorer 6 (forkortet: IE 6) for godt. De meget dyktige og oppegående webutviklerne hos FINN.no skal ha honnør for å ha satt i gang med et godt tiltak som selv Microsoft støtter!! Jeg støtter denne kampanjen fullt ut, og vil benytte anledningen til å reflektere litt rundt hva som gikk galt, hvorfor det ble slik, hvorvidt strategi har vært involvert og hvilke konsekvenser IE 6 har medført for Internett som sådan.

MERK: Dette innlegget ble publisert tirsdag kveld (24.feb) men oppgradert og finpusset i løpet av onsdag før lunsj, med blant annet illustrasjoner, lenker og mer utfyllende tekst.

IE 6 har ødelagt mye

Internet Explorer til og med versjon 6 er på mange måter noe av det verste som har skjedd for Internett sitt vedkommende. IE 6 var dårlig både teknisk, funksjonelt og sikkerhetsmessig og ble i tillegg raskt utdatert sammenliknet med konkurrentene - derom levnes ingen tvil. Mange har gjennom bruk av Internet Explorer fått ødelagt eller infisert maskinene sine av trojanere, ormer og andre ulumskheter.

En del skyldes brukernes egen uvitenhet, men en del skyldes et dårlig og usikkert produkt. Selv ikke etter de siste oppgraderingene, regnes IE 6 å være sikker. Microsoft vet selvsagt dette, og har de siste årene oppfordret brukere til å oppgradere til IE 7. Problemet er at det har gått for tregt.

Det er én ting at brukere av Internet Explorer generelt og IE 6 spesielt ikke har fått den mest effektive og sikreste opplevelsen av Internett. Det er mye mer alvorlig at IE faktisk har "ødelagt" en hel del av weben. IE har rett og slett skapt en ukultur på web, og er indirekte skyld i større kostnader for kunder som har kjøpt webløsninger enn hva har vært nødvendig. IE har også hindret innovasjon. Dette er alvorlige påstander som må utforskes nærmere, men la oss først se på hva en nettleser er og hvor viktig en rolle den spiller.

En smart strategi

Mange med interesse for data har lurt på hvorfor en så tung, seriøs aktør som Microsoft ikke klarte å lage en bedre nettleser enn IE 6 i årene mellom høsten 2001 og høsten 2006. Klarte de det ikke rent teknisk, prioriterte de det ikke eller var det ren strategi?

Det er vanlig at brukere setter likhetstegn mellom "Internet Explorer" og "Internett" - de skiller altså ikke på nettleseren som programvare og nettet som forum for innhold og aktiviteter. Skillet er selvsagt viktig. En nettleser er et program som brukes for å navigere på Internett, typisk for å vise og navigere mellom websider. Ulike nettlesere kan ha mer eller mindre avanserte funksjoner. De som ikke skremmes av ny teknologi og setter pris på effektivitet, stabilitet og sikkerhet, har trolig prøvd nettlesere som for eksempel FireFox, Opera, Safari eller Google Chrome, men har som regel alltid hatt den "alternative" nettleseren Internet Explorer i bakhånd i fall det ville være nødvendig.

Netscape var kongen på haugen først på 90-tallet, men ble etterhvert utkonkurrert av Microsoft. Internet Explorer ble nemlig spredd til Hvermannsen gjennom at den var forhåndsinstallert på nesten alle PC-er som ble solgt. Det å "bundle" Internet Explorer som nettleser i operativsystemet Windows var et taktisk lurt trekk av Microsoft, for når "alle" brukte Windows ville også de fleste bruke Internet Explorer. Faktisk brukte over 95 % Internet Explorer i glansdagene (2002/2003), inkludert undertegnede.

Andel brukere av Internet Explorer (hentet fra Wikipedia).

Med mange hundre millioner brukere av Internett er denne prosenten ikke uten betydning. Det er forståelig at Microsoft lagde IE. Det var en selvsagt ting å skulle spre den med Windows. Bare ved å for eksempel sette MSN som startside i Internet Explorer på alle nye PC-er hadde Microsoft et enormt potensial for å trekke kunder (og annonseinntekter) til denne og andre tjenester. Mange brukere vet for øvrig ikke at det er mulig å endre startsiden. Det var faktisk også strategisk smart å ikke legge flid i å lage den bedre med tanke på standarder! Kan dette ha en strategisk forklaring?

Microsoft innså tidlig at nettleseren deres var inngangsporten, eller nøkkelen om du vil, som gjorde at millioner av brukere kunne benytte nettet. Dermed var de med på å spre nytteverdien av Internett. Kontroll av nettleseren kunne til en viss grad styre utviklingen på nettet. Et eksempel på viktigheten av dette, er CSS, JavaScript og ikke minst Ajax - pragmatiske teknologier som bidro til å gi ny dynamikk, gradvis, til gamle websider med "relativt" små grep. Med Ajax er det mulig å hente data i bakgrunnen fra tjeneren, uten at websiden må oppdateres/refreshes. Ajax har gitt oss veldig responsive websider som er brukervennlige og funksjonsrike. Et eksempel er Google Docs som er på full høyde med vanlige skrivebordsapplikasjoner og muliggjør samskriving på web. Faktisk har Google (og også Yahoo, Apple med flere) en hel rekke tjenester som avhenger av Ajax. Til og med i næringslivet har for eksempel norske 24sevenoffice brutt med den tradisjonelle skrivebordsapplikasjonen, og bygget sitt produkt rundt Ajax. Ajax muliggjør nemlig kjøring i nettleseren, og det betyr at brukerne ikke trenger å installere noe ekstra siden Ajax bygger på standarder som nettlesere "skal" støtte. Det eneste som trengs er tilgang til Internett, og fordelen er at en har tilgang til sine data uavhengig av hvilken maskin en jobber fra (hjemme, arbeid, hytta, Internettkafé, ...). Flere stiller spørsmål om de egentlig trenger kostbare Word når de har gratistjenester som Google Docs.

Ajax er en samling av standarder og teknologier som JavaScript, CSS, DOM og det såkalte XMLHttpRequest-objektet. Microsoft har dårlig JavaScript-ytelse i sine nettlesere, men Ajax er likevel ikke noe fremmedord i Microsofts verden: Det var de som først lagde konseptet bak XMLHttpRequest, og Ajax brukes også aktivt i ASP.NET-drevne løsninger. Internet Explorer (særlig versjon 6) er derimot ikke god på Ajax/JavaScript. I stedet for å være pådriver for åpne standarder gjennom utvikling av Ajax-drevne systemer, slik for eksempel Apple gjør (til manges forundring :-), pusher Microsoft heller Silverlight (Flash-aktig teknologi). Det er mange i bransjen som mener dette er et uheldig valg (for Internett sitt ve og vel). Det er lett å lære seg Ajax, og det betyr at stadig flere kan lage slike tjenester og løsninger. Ajax er godt nok til å gjøre det en vil (noe 24sevenoffice og Google er levende beviser på), så hvorfor kan ikke alle bruke det? En annen tanke er at vi nettopp som følge av Ajax-utbredelsen, ser tjenester ala Google Docs spire, og disse er utvilsomt seriøse konkurrenter med Office, og kanskje også i siste instans med Windows. Slike applikasjoner og tjenester på web reduserer nemlig behovet for et operativsystem! Det eneste brukere trenger for å jobbe og løse oppgaver, er i prinsippet nettleseren.

Problemet med nettleseren IE 6 ligger i at altfor mange bruker den! Det var gunstig for Microsoft å ha en nettleser, men når alle brukte den var det ikke noe poeng å lage den veldig god. Ved å helt bevisst avvike litt - men bare litt - fra standardene til W3C, satte Microsoft kjepper i hjulene til konkurrentene og holdt på kundemassen! La oss se enda nærmere på dette.

All makt til nettleseren!

Tenk over det: Alt på web må lages av noen, typisk webutviklere. En webside består av innhold og kode. Det er opp til nettleseren å tolke og vise informasjonen på en forståelig måte. Det er en utfordring å lage en nettleser som fungerer på alt fra enkle til mer komplekse sider. Enighet om hvordan en skal lage websider blir derfor viktig. Tim Berners-Lee står bak markeringsspråket HTML, som er veldig utbredt for å lage websider. HTML (XHTML) er et veldefinert språk som har gjort det mulig for alle å lage websider. (X)HTML tolkes av nettleseren (nettleseren er laget for å forstå (X)HTML og en rekke andre standarder/teknologier). Når noe tekst på en webside er kodet med taggen <h1> vil typisk nettleseren velge å vise akkurat denne teksten som en svart overskrift. Hvem som helst kan i teorien lage sin egen nettleser (men lett er det ikke :-), og det er mulig å lage en nettleser der overskrifter ala <h1> vises i rød skrift med en fancy skrifttype, eller at teksten vises opp ned i vertikal retning oppå all annen tekst! Alle nettlesere viser heldigvis <h1> mer eller mindre likt, og det er fordi de følger retningslinjene til W3C (World Wide Web Consortium). Det er enighet om at en <h1> skal være en overskrift og ha luft før og etter, og være i svart standardskrift.

Når du besøker et nettsted, vil den aktuelle websiden vises for deg utelukkende fordi nettleseren er snill og viser innholdet slik som forfatteren av websiden opprinnelig har tenkt det. Forfatteren av websiden kan anta at ting vises slik som han/hun vil, men det beste er å teste at dette faktisk blir tilfelle. Det er tidkrevende for utviklere å lage gode websider og det er utrolig slitsomt og kjedelig når det oppstår feil (under utvikling). Nettsteder med avansert funksjonalitet må testes, og jobben med å få nettstedet til å fungere likt hos alle brukere uavhengig av nettleser, har tradisjonelt sett vært både tidkrevende, kostbar og teknisk veldig vanskelig.

I dagens Internettverden ser vi flotte nettsteder rent utseendemessig, med stadig mer dynamikk og interaksjon. For å tilby kompleksitet på en god måte, er det laget en rekke veldefinerte standarder som (X)HTML, CSS, JavaScript og så videre. Det er også kritisk at alle nettlesere implementerer standardene mer eller mindre likt, for da kan utviklere lage websidene i henhold til standardene, og være sikker på at alle får samme resultat presentert. Tenk over viktigheten av dette. Et konkret eksempel på hva som kan være vanskelig, er menyer på websiden som utvider seg når du holder musepekeren over og avslører undermenyer for videre navigasjon. Slik funksjonalitet er både nyttig og utbredt, men bygger gjerne på en kombinasjon av CSS og JavaScript. Dette er to teknologier hvor IE 6 avviker en del sammenliknet med andre nettlesere. Jo mer komplekse teknikker som brukes for å lage websider, jo strengere krav stilles til nettleserne for at de skal klare å vise sidene riktig. Hva er "riktig"? Det er selvsagt det som forfatteren av siden har ønsket. Det blir åpenbart irriterende dersom en meny viser en undermeny langt til høyre på siden i én nettleser, men ikke i en annen.

IE 6 er en stygg ulv som det ikke er lett å drepe

Spørsmålet blir dermed: "Er nettleserne så snille at de følger standardene?" IE 6 har bare delvis oppfylt standardene. I rettferdighetens navn må nevnes at andre nettlesere heller ikke har fulgt standardene fulgt ut. Det er likevel spesielt alvorlig når ikke Internet Explorer 6 har gjort det, gitt IE 6 sin dominerende posisjon gjennom en årrekke. Det kan virke som om at Microsoft helt bevisst har gjort sine egne, små endringer som viker fra standardene - med viten og vilje. Enten det, eller så er dataingeniørene i selskapet ikke særlig dyktige (noe som ikke er tilfelle). De har faktisk brukt enorme ressurser på å utvikle nettleseren i følge Wikipedia. En kan ikke ved en feiltakelse utvikle et produkt som så gjennomført bryter med etablerte standarder. Det er altså bevisst strategi. Det blir som at en har det norske språket - med alle dets grammatikalske regler - vel forankret i den norske skole, men så velger en lærer å lage sin egen variant (som også undervises til elevene) med unntaksregler her og der, o-endelser bak verb som normalt har -a eller -en, og så videre. De som blir opplært i dette språket, har det greit, men de andre får trøbbel. Problemet er altså at Microsoft i kraft av IE 6 har opptrådt som en slik lærer. Problemet er at denne læreren er blitt verdens viktigste og mest innflytelsesrike lærer.

Penger er en viktig faktor i de fleste sammenhenger. Webutviklere testet løsningene sine helt til de fungerte perfekt i IE 6, og sa seg så fornøyde. Det oppstod etterhvert en ukultur der stadig flere webløsninger ble laget til å fungere med Internet Explorer. Nå, når nyere utgaver av Internet Explorer har færre feil og følger standardene bedre, og folk i større grad har byttet/oppgradert nettleser, får de gamle websidene et alvorlig problem. Det som først var laget til å fungere med IE 6, fungerer ikke mer.

I tillegg er det viktig å understreke at IE 6 har vært med på å hindre innovasjon. Utviklere har budsjetter å forholde seg til, og i stedet for å bruke penger på å lage god funksjonalitet, måtte en viss sum avsettes til grundig testing og unødvendig frustrerende koding for å få websidene til å fungere uavhengig av nettleser. Kan en påstå at IE 6 implisitt har bidratt til å gjøre webutviklingen vanskelig og unødvendig dyr, med mindre innovasjon som resultat?

Det er også viktig å merke seg at utviklere verden over har nytt godt av nettopp dette! Oppegående virksomheter som lagde store webløsninger innså rundt 2004/2005 at det var et problem å kode løsninger som passet spilte på IE 6 sine premisser. Det beste på lang sikt, ville vært å ikke ta hensyn til IE 6, og prøve å få Microsoft til å lage en bedre nettleser. Dette ville derimot på kort sikt ha frustrert brukerne av IE 6 (95 %). Et ryddig alternativ ville vært å unngå funksjonalitet som en visste ville skape problemer. Men vent - ville det ikke være strategisk smart å kode nettopp basert på IE 6 sine premisser? Du får X antall kroner for å lage en webløsning. Du lager en slik, den fungerer perfekt med IE 6, og kunden er fornøyd. Noen få år senere går verden videre. Kundene bytter nettlesere (oppgraderer til IE 7 for eksempel) og hva skjer? Jo, løsningen fungerer ikke fordi IE 7 følger standardene i større grad enn IE 6! Dette er interessant, for hvem kan nå fikse løsningen? Det er uaktuelt å leie inn et nytt firma, så kunden må bevilge mer penger og leie inn samme firma på nytt til å løse et problem som ikke burde oppstått i utgangspunktet! Dobbel inntjening til det smarte firmaet! Hvorvidt noen har tenkt slik i praksis, vites ikke, men det er ikke vanskelig å tenke seg at dette ville vært gunstig. Det er etisk uholdbart overfor en kunde å bevisst gjøre slik (uten å informere kunden godt om problematikken), men det kan faktisk være en konsekvens av IE 6 sin dominans og dårlige standardstøtte!

Et eksempel hvor sluttbrukerne har slitt med oppgraderingen til IE 7, er systemene ePhorte og ESS. Disse brukes for eksempel på HiST og i en rekke offentlige virksomheter. At for eksempel ESS må være tidenes dårligste webløsning som en har betalt flesk for, skal ikke tas opp her, og har i utgangspunktet ikke noe med IE 6 å gjøre (men det måtte bare nevnes i ren frustrasjon :-). Faktum er at en rekke større systemer som brukes i arbeidslivet har blitt utviklet til å fungere med IE 6. Dersom brukerne krever av sin IT-avdeling å få IE 7, FireFox eller andre nettlesere installert i hele virksomheten, kan det rett og slett gjøre at arbeidstakerne selv ikke får til å bruke de programsystemene virksomheten har betalt dyrt for i sin tid. Dette har vært et problem for ESS og ePhorte sin del, men jeg er ikke oppdatert på hvorvidt problemene er fikset per i dag. Slike systemer har garantert bidratt til å redusere spredningen av Windows Vista, som kommer med IE 7, i både det offentlige og næringslivet verden over. Slik kan en faktisk hevde at brukere verden over holdes til gamle, svake, usikre operativsystemer (Windows XP) når nye og bedre operativsystemer er tilgjengelige (Vista og snart Windows 7, ser bort fra Mac og Linux i denne sammenhengen).

Til slutt er det verdt å nevne at brukere ikke liker endringer. De som har lært seg IE 6, og byttet til IE 7, har ofte lurt på hvor menyene ble av. Hvor er favorittene? Hvorfor ser ting anderledes ut? Hvordan kan jeg skrive ut kvitteringen på bestilt flyreise? Basert på erfaringene til slekt og venner observerer jeg at overgangen fra IE 6 til IE 7 ble opplevd som vanskeligere enn overgangen fra IE 6 til FireFox!

Om kampanjen

Det er i utgangspunktet gunstig at IE 6 forsvinner så fort som mulig. Spørsmålet er hvordan en kan få folk til å oppgradere? Mannen i gata ser ikke behovet, og har kanskje ikke kompetansen til å oppgradere. Microsoft selv har helt fra IE 7 kom prøvd å få folk til å oppgradere gjennom både ny service-pack og introduksjonen av Windows Vista. Miljøet rundt åpen kildekode fikk et løft for noen år siden som følge av det negative fokuset om dårlig sikkerhet i Internet Explorer. Dette gav folk initiativ og lyst til å bytte til FireFox, Opera og faktisk også til Mac. På tross av at andelen som bruker Internet Explorer har falt enormt de siste årene om en teller antall brukere, så går det fortsatt for tregt med å bli kvitt versjon 6. Tallene er klare: Mange nettsteder viser til at 20 % av deres besøkende har IE 6 (statistikk kan enkelt hentes ut basert på loggføringen som alle webtjenere gjør av sine besøkende). Det viser seg at flere besøkende på dagtid har IE 6. Dette kan tyde på at PC-er på arbeidsplassen er verstingene mens hjemme-maskinene er oppdaterte!

Gjennom en snedig kodesnutt og en moderne metodikk, har norske Finn.no brukt Twitter og andre Web 2.0-metoder for å akselerere kampanjen med å fjerne IE 6. Det er til og med laget en wiki som støtter opp under kampanjen, hvor hvem som helst kan legge inn status etterhvert som målet mot en IE 6-fri verden nærmer seg. Grunnen til at Finn.no har fått stor oppmerksomhet, er at de oppfordrer alle større nettsteder til å legge inn en liten kodebit på sitt nettsted. Denne vil kun vises til brukere av IE 6, som får opp en melding om at de har en gammel og utdatert nettleser og lenke til oppdateringssiden. Det er altså nettstedene som varsler brukerne det gjelder, og da er sjansen større for at det faktisk skjer noe. Ved å få med store aktører som VG og Dabladet, har Finn.no lykkes i å nå ut til veldig mange nordmenn. Alle som leser disse avisene på nettet - og har IE 6 - får meldingen. Har du en liten webside, trenger du sikkert ikke ta deg bryet med å legge ut beskjeden, men det skader heller ikke at folk varsles om og om igjen. Tanken er at irritasjonen over denne store boksen skal sparke folk bak slik at de oppdaterer eller bytter nettleser. Jo flere som maser, jo raskere går bytteprosessen (er tanken). Hyppig besøkte nettsteder bør derfor seriøst vurdere å følge Finn.no sin oppfordring.

Det er ikke noe nytt at nettsteder varsler brukeren (for eksempel gjennom popup-bokser) med oppfordring om å oppgradere nettleseren for å få maksimalt utbytte av nettstedet. Apple lanserte i 2008 den avanserte webtjenesten mobile.me, som ikke fungerer optimalt med Internet Explorer. Apple sparker hardt til Microsoft og sier rett ut: "Internet Explorer 7 has known compatibility issues with modern web standards that affect Web 2.0 applications such as MobileMe.". En kan nok for øvrig sparke en del tilbake mot Apple i andre sammenhenger, men det er ikke tema i dette innlegget.

Det er også kommet innvendinger fra et brukerhetsperspektiv overfor Finn.no sin metodikk. Bloggen IAllenkelhet foreslår at ansvaret ikke bør skyves over på brukerne fordi det ikke er brukervennlig, og mener at utviklere fortsatt bør lage kode tilpasset IE 6. Holdningen er noe passiv, for da vil problemet strekkes ut i tid, men de tenker nok egentlig på sitt eget nettsted og jeg tolker det ikke dithen at anbefalingen går ut til alle andre store aktører om å innta samme holdning. Dette er fair nok av Iallenkelhet, men det får atter en gang tankene til å gå til for eksempel Apple. De har ofte gjort seg upopulære ved å si at "nå tenker vi nytt", vel vitende om at dette går ut over de som har gamle systemer. De satser på at folk oppgraderer og betaler for nye systemer. Microsoft har ofte tenkt motsatt, og strebet etter bakoverkompatibilitet. Nytenkning gjør at dårlig teknologi kan kastes vekk, mens bakoverkompatibilitet ikke bare tar med seg dårlig kode videre, men også lærer brukere opp til dårlige vaner og åpner for aksept av gamle metoder. Av og til er det tungt å bryte bånd bakover. Dette er nok også en av grunnene til at IE 7 ble som den ble. IE 7 utgjør nemlig et steg i riktig retning, men løser på langt nær alle problemer. Microsoft tar en gradvis tilnærming til problemet og viser slik vilje til bot og bedring, samtidig som problemet strekkes ut i tid. Dette kan være bevisst valg, men det kan også ha tekniske årsaker. Det tar tid å lage en god nettleser. Uansett - IE 6 må ut først, dernest IE 7, og det er effektivt å irritere brukerne til å oppgradere! Det kan også være effektivt å stevne Microsoft for EU-kommisjonen slik Opera (og nå også Google) har gjort.

Oppsummering

Microsoft har med en finurlig strategi klart å erobre verden og spre IE 6. De har trolig tjent godt på dette over mange år, men samtidig skutt seg selv litt i foten. Ryktet som en seriøs aktør i dataverdenen er delvis svekket. IE 6 har medført mange smertefulle hyl fra webutviklere, og har på flere måter bidratt til å skape en ukultur i bransjen. Det er mange grunner til å ønske IE 6 en brå og brutal død. Det er derimot noe positivt også: IE 6 bidrar også til å sette enda større fokus på åpne standarder! Det er fort å glemme at norske Opera generelt og Håkon Wium Lie spesielt skal ha mye av æren for profileringen av åpne standarder på web. I tillegg har vi fått etablert det norske Friprog-senteret, og diskusjonen rundt åpne standarder generelt det siste året, har vært sunn. Jeg vil derfor runde av denne "korte" refleksjonen med å understreke at lille Norge er langt fremme og en viktig stemme på Internett, noe også kampanjen til Finn.no vitner om.

Bruk av Internett blir stadig viktigere. Det kommer stadig nye medier for å aksessere webbasert innhold, som både telefoner, TV-apparater og så videre. Det blir i så måte ekstra viktig at standarder følges av de som lager webbasert innhold. Målet må være en åpen og fullstendig interoperabel web. Acid3 er en avansert "syre-test" med 100 kriterier som alle kan utsette sin nettleser for (prøv gjerne selv :-). Foreløpig scorer Internet Explorer 7 og 8 svakt (under 20 av 100 mulige poeng), mens Apple sin Safari i versjon 4 og Opera i versjon 10 visstnok skal klare 100 poeng. Slike tiltak og måleredskap er med på å sette et seriøst fokus på standarder og innovasjon. Det er viktig å understreke at Acid3 ikke er den eneste testen av betydning, og at det er andre kriterier som kan brukes for å avgjøre hvor god en nettleser er. Det blir feil å si at IE 8 er dårligere enn Opera/Safari/FireFox basert på Acid3-resultater alene. Acid3 er likevel viktig for å vri fokuset over på hva nettlesere, og dermed utviklere, kan gjøre. Dette er et riktig steg på veien bort fra å programmere med tanke på å håndtere ulikheter mellom nettleserne. De som lager nettlesere har faktisk et enormt ansvar i og med at Internett er blitt et så viktig medium som det er! Det er gunstig om leverandørene av nettlesere fremover vil vise seg sitt ansvar verdig, for da følger utviklere av websider etter.

Offentlige og private virksomheter som har kjøpt/utviklet systemer som nå ikke er kompatible med nye nettlesere, sliter i disse dager. Leverandørene av disse gammelmodige websystemene har etter min mening et alvorlig forklaringsproblem. Sluttbrukerne kan ikke ta konsekvensene på evig tid, men har krav på å få en sikker, god, funksjonell og fremtidsrettet nettleser. Internett er blitt et førstehånds verktøy, og en dårlig nettleser som IE 6 er ingen forunt å bruke, ikke minst fra et sikkerhetsmessig perspektiv.

Hva tror du om alt dette?

14. februar 2009

1234567890

"Akkurat nå" er et historisk sekund. Nå er nemlig klokka nøyaktig 1234567890!

I dataverden er det viktig å telle sekunder, men det ville blitt litt vel mange om en skulle begynt å telle ved Kristi fødsel. 2000 år med sekunder, blir et uhensiktsmessig stort tall. En bestemte seg derfor rett og slett for å lage en helt ny tidsregning til bruk i dataverdenen. Denne heter Unix time, Posix time, eller Unix epoch om du vil, og i dataverdenen snakker en ofte om et (Unix) tidsstempel.

Det er mulig du leser dette for sent til å overvære hendelsen, men med "akkurat nå" menes i det sekundet dette innlegget ble publisert. Dette er en sannhet med modifikasjoner, fordi innlegget ble publisert den 14.februar 2009 kl 00:31, uvisst nøyaktig på hvilket av de 60 sekundene i minutt 31. På dette tidspunktet sov jeg forresten, men jeg fikk til å publisere sånn omtrentlig på Unix-tidspunktet 1234567890 rett og slett takket være Unix time! [1]

Unix time fungerer på følgende måte:

  • "Klokka" startet på tallet 0 den 1.januar 1970 (UTC-tid)
  • Hvert sekund øker tallet med 1, så den 2.januar 1970 var Unix time blitt 60 sekunder x 60 minutter x 24 timer = 86.400. Unix time øker altså med 86.400 hvert døgn.
  • Det tas ikke hensyn til såkalte Leap Seconds [2]. Leap seconds er juksesekunder som legges til våre vanlige klokker (dvs atomklokkene) for å justere tiden slik at den er helt i synk med jordrotasjonen. Unix time har altså ikke slike juksesekunder, og sakker dermed etterut sammenliknet med vår tid...

Akkurat nå (når dette innlegget ble publisert) er altså klokka 1234567890, eller 1.234.567.890 for å tydeliggjøre hvor stort dette tallet er. Altså litt over 1 millliarder. Eller 14.februar 2009 kl 00:31:30 sagt på forståelig norsk!

Hvis Unix time øker hvert sekund, når passerte da Unix time 1.000.000.000? Det skjedde den 9.september 2001 og ble feiret av datafolk verden over, blant annet en kollega. Hendelsen medførte også problemer. Noen datasystemer taklet nemlig ikke at tiden passerte 999.999.999. Vi støter nok på et nytt problem i januar 2038, for da er grensen nådd for hvor stor Unix-tallet kan bli for de systemer som har avsatt "bare" 32 bits til klokkeinformasjonen. Et 32-bits tall representert binært, kan bare bli en viss størrelse stort, og denne størrelsen er antall sekunder som forekommer på ca 136 år. Fra 1970 til 2038 er det 136 år? Nei, det er det ikke, men hvis du går like langt bakover i tid (noe mange datasystemer gjør) så blir det totalt 136 år. Fra 1970 til 2038 er det nemlig 136/2 = 68 år, og fra 1970 til 1901 er det også ca 68 år. Spennet går nøyaktig fra 13.desember 1901 til 19.januar 2038, og er på ca 136 år. Hva som typisk vil skje når den binære representasjonen av 2038 nås, er vist i figuren under (hentet fra Wikipedia)

Det er lett å regne med sekunder. I programmeringsspråk fins det en rekke funksjoner for å omgjøre fra et Unix tidsstempel til det tilsvarende tidspunktet i vanlig datoformat, og omvendt. Selv liker jeg best PHP som språk, og da kan du for eksempel finne ut hvilken dato det er nøyaktig 8 uker fra nå av. I PHP brukes da funksjonene time() og date(), slik:

  $datoenOm8Uker = time() + (7 * 8 * 24 * 60 * 60);
  echo 'Nå er det den:       '. date('d-m-Y') ."\n";
  echo 'Om 8 uker er det den: '. date('d-m-Y', $datoenOm8Uker) ."\n";

Poenget er at funksjonen time() returnerer tidsstempelet som er akkurat nå (hos tjeneren der PHP-programmet utføres). Dette er altså et tall som er antall sekunder siden 1.januar 1970. For å få datoen 8 uker fram i tid, er det bare å plusse på det antall sekunder som 8 uker er, med andre ord 60 sekunder i 60 minutter i 24 timer i 7 dager i 8 uker. Enkelt og greit! Variabelen $datoenOm8Uker har nå et tall som er over 1 milliard stort og som representerer 8 uker fram i tid. Dette tallet (som nå er i sekunder) kan gjøres om til en menneskelig lesbar dato på ønsket form ved å sende det inn som andre argument til funksjonen date(). Dette er gjort i siste setning.

Et tankeeksperiment: Per og Kari har kanskje 39 års bryllupsdag den 11.mai 2009. Dette er interessant nok, men det er mer interessant for den hengivende Per å fortelle sin Kari når de har 1234567890 sekunders-bryllupstid! Siden de giftet seg den 11.mai 1970, så betyr det at de på 14+31=45 dager etter sin opprinnelige bryllupsdag, kan feire 1234567890 sekunder sammen! 1234567890 Unix time tok utgangspunkt i 1.januar (1970) og det er 45 dager mellom 1.januar og 14.februar (uavhengig av årstall). Derfor må bryllupstiden "1234567890" til Per og Kari være 45 dager etter deres egentlige bryllupsdag, altså 45 dager etter 11.mai 2009. Dette betyr videre at dersom du er født en gang etter 14.februar 1970, så kan du bare regne ut og begynne nedtellingen til når du blir 1234567890 sekunder gammel!

Vil du lage deg en PHP-snutt som viser når Per og Kari skal feire begivenheten? Den blir for eksempel slik:

  $datoSomSekunder = mktime(0,0,0,5,11,2009);
  //har nå fått 11.mai 2009 som antall sekunder etter 1.1.1970
  $dagerFramITid = 60 * 60 * 24 * 45;
  $begivenhetenIUnixTid = $datoSomSekunder + $dagerFramITid;
  echo "45 dager etter den 11.mai 2009 er det den: ";
  echo date("d.m.Y", $begivenhetenIUnixTid);

Altså har Per og Kari vært gift i 1234567890 sekunder den 25.juni 2009 gitt at de giftet seg den 11.mai 1970. Her brukes mktime() for å regne om fra en dato til den tilsvarende Unix-tiden. Det fins sikkert enda mer elegante måter å regne om dette på med færre kodelinjer.

Oppdatering noen timer senere: Nedtellingen skjedde for øvrig en rekke steder i verden, også på Twitter (bildet leses nedenfra og opp)

Unix time er ikke nerdete, men gøy, eller hva?

[1]: Datasystemer, for eksempel bloggen min hos Google, kan nemlig publisere ting automatisk frem i tid. Dette er basert på når den tilsvarende Unix-tiden for publisering (publiseringstidspunktet jeg har satt) "blir tatt igjen" av den virkelige Unix-tiden som tikker og går. Snedig. Det er muligens bare en teller som øker og øker for hvert sekund og to tall som hele tiden sammenliknes, men det er trolig implementert på en litt mer effektiv måte i operativsystemet på tjeneren hos Google. Unix time er i bunn og grunn en teller, og de fleste datasystemer gjør bruk av slike tellere på en eller annen måte.
[2]: Siste gang et leap second ble lagt til, var på nyttårsaften 2008. Unix time legger altså ikke plutselig til et ekstra sekund, og det er rett og slett fordi at om en la til et ekstra sekund når resten av verden gjør det, så vil det nærliggende sekundet "forsvinne". Dette betyr i praksis at noen tall ikke eksisterer, og det passer dårlig i dataverdenen å hoppe over noe ved telling eller å si at et tall ikke eksiterer. Det kan for eksempel medføre at en if-test aldri blir utført, noe som er uholdbart fra et programmeringsteknisk synspunkt.