• Bör
• www.anvandbart.se/ab/webblasarens-kontroller

Det är inte alltid man som webbutvecklare är särskilt glad över webbläsarens navigation. Den tar ifrån en kontrollen över hur användaren rör sig genom webbplatsen.

Speciellt i webbapplikationer kan detta ställa till med problem, om användaren plötsligt backar tillbaka till sidor hon redan passerat, stänger ett fönster och därmed avbryter utan att uttryckligen avsluta, eller öppnar ett nytt fönster mitt under inmatningen och därmed ur systemets synvinkel samtidigt är både en och två användare.

Javascript ger möjlighet att ta bort kontrollerna från webbläsaren. Det kan vara frestande, men det är en frestelse man inte bör falla för. Att avlägsna kontrollerna upplevs ofta av användaren som ett oartigt ingrepp i hennes sfär. Det kan också leda till rent praktiska problem, till exempel att det kontrollösa fönster du skapat styr utseendet på nästa fönster användaren öppnar, vilket kan tvinga henne att starta om webbläsaren för att återfå kontrollerna.

• Skall
• www.anvandbart.se/ab/forvarna-fonster

Om en länk öppnar nya fönster, förvarna om att det kommer att ske, till exempel genom att skriva ”(nytt fönster)” intill länken eller genom att berätta det i title-texten.

Se till att det finns en tydlig väg tillbaka, till exempel en knapp som stänger det nya fönstret och för användaren tillbaka till det ursprungliga (observera att det bör vara en knapp, inte en länk – se Låt inte knappar fungera som länkar eller länkar som knappar, sid 120).

Se även WCAG 10.1 (prioritet 2), sid 363, och 13.1 (prioritet 2), sid 368.

• Bör - undantag, se boken
• www.anvandbart.se/ab/undvik-fonster

Länkar som öppnar nya fönster förvirrar ofta användaren. Det nya fönstret kan lägga sig framför det gamla och helt eller delvis dölja det.

Ytterligare en källa till förvirring är att nya fönster förstör funktionen hos bakåtknappen (eftersom sidorna man försöker gå tillbaka till visades i det gamla fönstret). Det är därför kontraproduktivt att försöka hålla kvar användaren på den egna webbplatsen genom att öppna nya fönster när man länkar till andra webbplatser. En användare som följer sin vana att använda bakåtknappen för att återvända kan då inte göra det.

Erfarna användare vet naturligtvis om att de istället måste stänga det nya fönstret. Men för många av dem är det en källa till irritation att inte själva kunna välja när ett nytt fönster skall öppnas genom att skift- eller högerklicka (eller om de använder Macintosh: kringelklick).

Trots dessa invändningar kan det vara motiverat att öppna ett nytt fönster till exempel för att visa en hjälptext eller be användaren om kompletterande uppgifter. Ett sådant fönster bör vara litet, för att signalera att det inte är något nytt utan har en kompletterande funktion. Det bör, i synnerhet om det innehåller hjälptexter, ha kvar webbläsarens meny så att det går att skriva ut (se även Ta inte bort webbläsarens kontroller, sid 332).

Överväg möjligheten att istället för att öppna nya fönster för hjälptexter, ladda om den ursprungliga sidan men med hjälptexterna på plats. På det sättet hamnar hjälpen nära den uppgift som skall utföras.

Nytt fönster eller ej

Mer generellt kan en tumregel formuleras så här:

• Ett nytt fönster kan öppnas om användaren mentalt är kvar på sidan och bara skall läsa eller göra något kompletterande.

• Ett nytt fönster öppnas inte om användaren går till en ny sida.

Framtidsosäkert

Det är stor risk att utvecklingen går mot nya fönster överhuvudtaget inte pålitligt kan öppnas. Se Öppna aldrig ett nytt fönster från en annan domän, sid 331.

Se även WCAG 10.1 (prioritet 2), sid 363.

• Skall
• www.anvandbart.se/ab/404

Det vanligaste felmeddelande på webben är ”404 – File not found”, som man får om man försöker gå till en icke-existerande webbsida. Eftersom detta fel är så ofta förekommande bör webbplatsen ha en speciell 404-sida. Denna kan innehålla:

• Text som förklarar att sidan inte kan hittas.

• Länk till ingångssidan och eventuellt även länkar till populära avdelningar.

• Länk tillbaka till sidan man kom ifrån (görs vanligen med javascript).

• Sökruta, och om webbplatsen har innehållsförteckning och index, länkar till dessa.

• Felkoden 404.

• Skall
• www.anvandbart.se/ab/artiga-felmeddelanden

Den viktigaste regeln för ett felmeddelande är: få inte användaren att känna sig dum.

Andra saker som är bra att tänka på:

• Felmeddelandet skall vara väl synligt och uttryckligen informera användare om att något gått fel.

• Det bör vara begripligt formulerat och inte bygga på teknisk jargong, förkortningar eller sifferkoder (sådant kan finnas med eftersom de kan hjälpa felsökningen, men skall vara diskreta).

• Det bör ge en precis beskrivning av vad som hänt och vad problemet är.

• Det skall vara artigt, och får inte beskylla användaren för att gjort fel.

• Det bör ge konkreta råd om hur problemet kan lösas eller undvikas. Skriv detta i positiv form, undvik ord som ”ej” och ”inte”.

Om felet beror på att något är ur funktion eller ur drift på serversidan, berätta att ni jobbar på att lösa det (om det är sant) och ge gärna en uppskattning av när ni tror det kan vara klart (beräkna tiden med marginal – att ge löften och sedan bryta dem är skadligt för relationen med användare).

Bild 117. Har jag gjort fel – eller har webbplatsen tekniska problem? Ett slött felmeddelande som helt lastar över jobbet till användaren. Hon skall inte bara hitta felet (utan att få någon ledning om i vilket fält det kan vara) utan måste också lista ut om det överhuvudtaget finns något fel att hitta. (www.adrassandring.se)

• Tips
• www.anvandbart.se/ab/kaklosa

Sträva efter att inte utestänga användare som av någon anledning inte kan eller vill ta emot kakor. Gör så mycket av webbplatsen som möjligt tillgänglig även för dem.

Upplys på ett artigt sätt användaren om att det finns tjänster hon inte kan använda. Hon har förmodligen ett genomtänkt eller tvingande skäl till att inte ha kakor, så undvik att bara säga åt henne att slå på kakfunktionen.

Egentligen räcker det att användaren ser denna upplysning en gång under ett besök på webbplatsen. Men just eftersom hon saknar kakor är det svårt att veta om hon fått varningen tidigare eller ej. Därför bör den inte göras med en javascriptdialogruta (som blockerar allt arbete med webbplatsen tills man klickat ”OK”) utan hellre som en varningstext på sidan.

• Skall
• www.anvandbart.se/ab/captcha

Ett populärt sätt att säkra att det är en människa som t.ex. försöker registrera sig är att visa upp ett förvrängt ord och be användaren skriva det.

Problemet med metoden är att den är fullständigt otillgänglig för blinda användare. Se WCAG 1.1 (prioritet 1), sid 349 .

Mer acceptabla är tester som kräver att man förstår en instruktion, typ ”Skriv första bokstaven i denna webbplats namn”.

• Tips
• www.anvandbart.se/ab/inaktiva-anvandarkonton

Ett användarkonto som inte längre används tar upp diskutrymme till ingen nytta. I sig kanske inte något stort problem, hårddiskar är billiga. Värre kan vara att populära användarnamn är upptagna utan att komma till bruk.

Därför kan det vara en god idé att bestämma hur länge ett konto får vara inaktivt innan det rensas bort.

Om du har användarens e-postadress, kan det vara uppskattat att sända en varning en månad före och ge användaren en chans att rädda sitt användarnamn. Om användaren inte gör något sänd en sista varning 24 timmar innan kontot utplånas.

Att koppla användarkontot till en verklig människa

För att en användare skall bli identifierad krävs att det finns en koppling mellan användarkontot och den verkliga människan.

Gör kopplingen lagom säker

Kopplingen mellan användarkonto och verklig människa kan göras på en mängd olika sätt, och även på detta område gäller det att hitta en balans mellan bekvämlighet och säkerhet. Ju säkrare man vill vara, desto krångligare och dyrare blir det vanligen att ordna.

Osäkra kopplingar

Ofta räcker det för webbplatsen med en begränsad visshet i kopplingen mellan användaridentitet och verklig identitet. Här är några sådana metoder.

• Användarens egen uppgift

Att användaren säger att hon är en viss person är naturligtvis så långt ner på säkerhetsskalan man kan komma, men i sammanhang där användaren har något att tjäna på att uppge sitt korrekta namn kan det fungera. Räkna dock med att hitta en och annan ”Kalle Anka” bland användarna.

• E-postadress

Ett av de absolut vanligaste sätten är att kräva att användaren uppger en e-postadress och att sedan skicka ett e-brev till denna adress som användaren antingen skall svara på eller klicka på en länk i.

Eftersom det är lätt för vem som helst att skaffa en Hotmail-adress ligger naturligtvis även denna metod långt ner på säkerhetsskalan.

• Personnummer

Att be användaren uppge sitt personnummer är ytterligare en metod. Det är förvånansvärt svårt att gissa sig fram till ett fungerande personnummer (bara vart tionde försök lyckas), men för den som vill lura systemet är det naturligtvis inget hinder.

Att be om personnummer kan vara integritetskänsligt, och utestänger alla människor i hela världen utom de få som har ett svenskt personnummer.

• Vanlig adress

Ett betydande steg i säkerhet – och i krångel – tar man genom att skicka användarnamnet och lösenordet i ett vanligt brev till det namn och den adress användaren uppger.

Även detta går naturligtvis att lura, men bara med visst besvär.

Säkra kopplingar

Var gränsen går för att man skall känna sig trygg i hopkopplingen mellan människa och användarkonto är en bedömningsfråga. Ingen metod kan ge fullständiga garantier mot bedrägerier.

Den nivå man tycks ha valt åtminstone hos svenska myndigheter är att den elektroniska identifieringen måste vara minst lika säker som när någon i den verkliga världen legitimerar sig med sitt id-kort.

Generellt kan man säga att de metoder som godtas är sådana som just kräver att användaren i något skede personligen och med id-kort bevisat sin identitet.

• Konventionell legitimering

Detta görs vanligen genom att skicka inloggningsuppgifterna i ett rekommenderat brev som användaren måste gå till sitt postutlämningsställe och legitimera sig för att få ut.

• Överförd säkerhet

En av de mest spridda autentiseringsmetoderna bland dem som betraktas som säkra är BankID . För att få ett sådant måste användaren ha ett konto i en internetbank (och för att ha det måste hon någon gång ha legitimerat sig på konventionellt sätt).

• Elektroniskt id-kort

Det finns numera elektroniska id-kort. De ser ut som vanliga konventionella, men har dessutom en datorkrets. För att använda det måste användaren ha tillgång till en dator med en kortläsare, samt kunna id-kortets lösenord.

• Visa upp sig

I vissa sammanhang är det lättare att fastställa identitet. Till exempel för intra­nät­en, där kontrollen är informellare men lika sträng. Där får användaren sitt konto i samband med anställningen.

• Bör
• www.anvandbart.se/ab/registrering-tillbaka

Om användaren skapar ett användarkonto beror det ofta på att det är något hon vill göra som hon har framför sig och som kräver att man registrerat sig. Det är därför lämpligt att användaren tas tillbaka till sidan hon var på innan hon började registreringen, när den är klar.

Om hon skapade användarkontot från en inloggningssida, bör hon loggas in i samband med att kontot skapas (se nästa råd) och därefter komma till nästa steg i processen.

• Bör - situationsberoende, se boken
• www.anvandbart.se/ab/lita-ej

En inloggning varar i allmänhet så länge som sessionen varar. Har man en generös tidsgräns för denna (vilket man bör ha) kan detta vara ett säkerhetsproblem om användaren till exempel använder en lånad dator eller lämnar sin egen dator obevakad. (Det bör noteras att en användare som loggar in från till exempel ett internetcafé även utsätter sig för risken att inloggningen avlyssnas direkt på datorn.)

Utloggning kan ha en viss psykologisk effekt – det känns bättre för användaren att uttryckligen kunna avbryta sessionen. Men som säkerhetsmekanism är den inte mycket att lita på. Användare glömmer alltför ofta att logga ut.

Även tidsgränser som skydd är problematiska. Sätts de snålt så blir de snabbt irriterande genom att användaren tvingas logga in igen så snart hon gjort en paus. Sätts de generöst finns risken att någon annan tar över sessionen efter att användaren lämnat datorn.

Vägar att stärka säkerheten kan vara certifikat för att säkra att användaren bara loggar in från sin egen dator och engångslösenord för att hindra lösenordsstöld. Tillsammans med om-autentisering vid säkerhetskritiska ögonblick kan den senare lösningen ge god säkerhet även för cafésurfaren.

Ett mer cyniskt, men möjligen rättvist sätt att se problemet är att faktiskt se det som användarens ansvar att skydda sin användaridentitet, till exempel genom att alltid låsa sin dator när hon lämnar den och inte utsätta sig för de risker som lånade datorer innebär.

• Tips
• www.anvandbart.se/ab/sakra-pengarna

Ett alternativ för kommersiella webbplatser är att inte lägga någon större energi på att säkerställa användarens identitet utan istället koncentrera sig på pengarna. Kontokorten erbjuder tillräcklig säkerhet i att binda en beställning till en betalning. Visserligen är säkerheten låg – vem som helst som lyckats komma över kontokortsnumret och de andra uppgifterna på kortet kan utan problem lura systemet. Men fallen av bedrägeri är inte fler än att kostnaderna för dem täcks av systemet.

• Tips
• www.anvandbart.se/ab/skyddande-skal

Det kan det vare en god idé att begränsa möjligheterna att lura systemet genom att reglera varifrån man överhuvudtaget kan autentisera sig. Det är till exempel vanligt att intranät bara får användas från det interna nätverket. Även för publika webbplatser kan behörigheten att utföra säkerhetskänsliga saker, till exempel publicera nya sidor, begränsas till interna användare.

Ibland kontrolleras också datorns IP-nummer som en del av autentiseringen – detta ersätts dock alltmer av certifikat.

• Tips. 24-timmarswebben: se boken
• www.anvandbart.se/ab/sparad-autentisering

Ett sätta att göra tillvaron mycket enklare för användaren – till priset av kraftigt sänkt säkerhet – är att automatiskt autentisera henne när hon kommer till webbplatsen nästa gång. Det enda som krävs är att hon använder samma dator. (Eller för att vara exakt, är samma användare på datorn och använder samma webbläsare.)

På ett tekniskt plan görs detta genom att en permanent kaka sparas. Se vidare Kakor , sid 325 .

Säkerheten för den här sortens autentisering är naturligtvis låg, eftersom den är knuten till användarens dator istället för till henne själv. Samtidigt är bekvämligheten hög, när användaren väl loggat in första gången behöver hon sedan aldrig tänka på det igen. För många webbplatser som inte hanterar känslig information, är detta rätt avvägning.

24-timmarswebben rekommenderar dock att man om möjligt inte använder automatisk autentisering.