Analyse af udfordringer ved iframe integrationsformen

Analyse af udfordringer ved iframe integrationsformen Version 0.8 9. april 2008 Portalintegrationsprojektet Se mere på www.modernisering.dk/integrationsmodel 1

INDHOLDSFORTEGNELSE INDLEDNING...4 1.1 BAGGRUND... 4 1.2 REFERENCER... 4 1.3 KONTAKTER... 4 FORUDSÆTNINGER OG ANTAGELSER...5 ARKITEKTUROVERBLIK...6 INDLEJRING AF LOGINBILLEDER...7 1.4 LØSNINGSFORSLAG 1: PORTAL SØRGER FOR AT SELV AT VÆRE FØRST MED LOGIN... 7 1.5 LØSNINGSFORSLAG 2: JUST-IN-TIME LOGIN... 8 1.6 ANBEFALING... 8 TIMEOUT HOS LOGINLØSNING...9 1.7 LØSNINGSFORSLAG 1: PORTALEN HOLDER LOGINLØSNINGENS SESSION I LIVE... 9 1.8 LØSNINGSFORSLAG 2: LØS PROBLEMET VIA GENEREL TIMEOUT POLITIK... 9 1.9 ANBEFALING... 10 AKTIVERING AF SINGLE LOGOUT...11 1.10 LØSNINGSFORSLAG... 11 BLOKERING AF COOKIES...12 1.11 LØSNINGSFORSLAG 1: ANVEND URL REWRITING... 12 1.12 LØSNINGSFORSLAG 2: OMKONFIGURÉR BROWSEREN... 12 1.13 LØSNINGSFORSLAG 3: ANVEND DNS ALIAS... 13 1.14 LØSNINGSFORSLAG 4: BRUG EN REVERSE PROXY... 13 1.15 LØSNINGSFORSLAG 5: ANVEND P3P POLITIKKER... 13 1.16 ANBEFALING... 15 SAMLEDE ANBEFALINGER TIL INTEGRATIONSMODELLEN...16 MERE OM P3P...17 2

ÆNDRINGSHISTORIK Version Dato Initialer Beskrivelse 0.8 09-04-2008 TG Første udkast klart til review efter præsentation på ERFA møde. 3

Indledning 1.1 Baggrund Gennem arbejdet med det fællesoffentlige portalintegrationsprojekt er der identificeret en række udfordringer ved iframe integrationsformen i relation til den fællesoffentlige brugerstyringsløsning. Udfordringerne kan, hvis de ikke adresseres, lede til uhensigtsmæssige brugeroplevelser på portalerne som eksempelvis flere loginbilleder på én gang, krav om login selvom brugeren er aktiv, eller at applikationer ikke kan holde sessioner med brugeren. Dette dokument beskriver disse udfordringer nærmere og fremdrager en række løsningsmuligheder med tilhørende fordele og ulemper. Analysen udmunder i en række konkrete anbefalinger til, hvorledes den fællesoffentlige integrationsmodel [OIM] kan opdateres, således at disse uhensigtsmæssigheder kan undgås. 1.2 Referencer [OIM] "Den fællesoffentlige integrationsmodel for Borgerportalen og Virksomhedsportalen", Version 1.01, Februar 2008, Den Digitale Taskforce. [DKSAML20] OIO Web SSO Profile 2.0, IT- og Telestyrelsen (2008), http://www.itst.dk/arkitektur-ogstandarder/standardisering/standarder-for-serviceorienteretinfrastruktur/standarder-for-brugerstyring/standarder-forbrugerstyring [P3P] "The Platform for Privacy Preferences 1.0 Deployment Guide, W3C. http://www.w3.org/tr/p3pdeployment 1.3 Kontakter For yderligere information vedrørende integrationsmodellen henvises til: Den Digitale Taskforce, særligt vedrørende integrationsmodellen (oim@modernisering.dk). Center for Borger.dk, IT- og Telestyrelsen, særligt vedrørende Borgerportalen (cbo@itst.dk). Center for Virk.dk, Erhvervs- og Selskabsstyrelsen, særligt vedrørende Virksomhedsportalen (virk-integration@eogs.dk). Center for Serviceorienteret Infrastruktur, IT- og Telestyrelsen, særligt vedrørende single sign on (csi@itst.dk). 4

Forudsætninger og antagelser I dette afsnit beskrives de forudsætning og antagelser, der ligger bag analysen. For det første antages, at portalerne anvender den fællesoffentlige brugerstyringsløsning (FOBS) som en selvstændig komponent, der er helt afkoblet fra portalerne. Den fællesoffentlige brugerstyringsløsning afvikles fra sit eget domæne (sikker-adgang.dk) og betjener såvel portaler, applikationer på portaler samt selvstændige web applikationer, der ikke indgår i portaler. FOBS opfatter portalerne som enhver anden web applikation og giver ikke nogen særbehandling til disse. På grund af timingen mellem de forskellige projekter anvender virksomhedsportalen til at begynde med ikke den fællesoffentlige brugerstyringsløsning men derimod sin egen brugerrettighedsløsning (BRS). Der kan således være problemstillinger i denne analyse, der ikke er relevante for Virk før en migrering til FOBS. Den fællesoffentlige brugerstyringsløsning har i forbindelse med login brug for at kunne vise en brugergrænseflade i brugerens browser. Denne ønskes kun vist på FOBSløsningens egen hovedside, der kan brandes som et velkendt, sikkert og trygt sted for brugerne at logge på. Specielt er det uhensigtsmæssigt, hvis brugergrænsefladen for FOBS optræder som en indlejret del af andre sider (f.eks. via framing), da brugeren så kan være i tvivl om, om han virkelig logger ind på den rigtige side. Endelig vil der i vurderingen af forskellige løsningsmetoder blive lagt vægt på, at anvendelse af iframe integrationsformen skal kunne ske med så minimale ændringer til eksisterende applikationer som muligt. 5

Arkitekturoverblik Nedenstående figur illustrerer et grundlæggende scenarie, hvor en portalside indlejrer indhold fra to applikationer via iframes. Scenariet er udgangspunktet for de udfordringer, der er identificeret i samspillet mellem den fællesoffentlige brugerstyringsløsning og iframe integrationsformen: Figur 1: Portalside med indlejrede applikationer Som det fremgår af figuren henter browseren indhold fra både portal og de to applikationer og samler dette til en samlet visning på klienten. Al kommunikation mellem portaler / applikationer og den fællesoffentlige brugerstyringsløsning i forbindelse med login og single sign-on (SSO) sker via brugerens browser, der re-dirigeres frem og tilbage med SAML 2.0 beskeder indlejret som parametre. Hver applikation / portal sender browseren over til loginløsningen, når brugeren første gang har brug for at tilgå en beskyttet ressource og modtager herefter et svar med en SAML 2.0 assertion, der indeholder attributter om brugeren. Alle applikationer og portaler har efter login via FOBS løsningen ansvaret for at holde deres egen session med brugeren samt logge brugeren ud ved anmodninger om single logout. For detaljer henvises til [DKSAML20]. 6

Indlejring af loginbilleder Den første udfordring kan opstå, når en applikation, som er indlejret via frames på en portal, har brug for login og derfor sender browseren over til FOBS løsningen. Hvis FOBS løsningen ikke i forvejen har en session med brugeren, vil denne svare med en html side, der rummer et login skærmbillede. Dette har som konsekvens, at FOBS løsningens brugergrænseflade indlejres på portalen, hvilket er uhensigtsmæssigt jævnfør antagelserne for analysen. Ydermere kan man risikere, at portalsiden indlejrer loginbilledet flere gange (én per applikation / frame), hvilket vil resultere i en stærkt forvirrende brugeroplevelse. 1.4 Løsningsforslag 1: Portal sørger for at selv at være først med login Det første løsningsforlag går ud på, at portalen skal sørge for, at dens eget hovedvindue altid starter en session hos loginløsningen, før en applikation indlejret med iframes har brug for login. Dermed vil login for de indlejrede applikationer bestå i en SSO operation, som ikke præsenterer nogen brugergrænseflade, men blot sender brugeren direkte tilbage til applikationen med en SAML assertion. Hvordan portalen holder styr på, at den altid selv er først med login, overlades til den tekniske implementering af portalerne. Eksempelvis kan applikationerne ved registrering på portalen angive (som en del af meta data), om de kræver login eller ej. Fordele: Interaktionen med loginløsningen vil altid ske i portalens hovedvindue og aldrig i frames. Løsningen indebærer umiddelbart ingen ændringer for applikationerne. Portalerne pålægges en ekstra byrde med at holde styr på, hvornår brugeren skal logges på. Fremgangsmåden kan have implikationer for portalens indretning, herunder organisering af offentlige og private sider. Nogle applikationer vil måske kun kræve login i visse situationer, afhængigt af brugerens valg, mens andre måske ikke kræver login før et bestemt trin nås. I sådanne tilfælde kan portalen være tvunget til gennemtvinge overflødige eller præmature logins. Dette vurderes dog som en et meget lille problem i praksis. Som en ekstra foranstaltning mod at loginløsningen viser en brugergrænseflade, kan man kræve, at de framede applikationer i deres kald til FOBS sætter IsPassive attributten på SAML <AuthnRequest> beskeden. Dette indikerer, at loginløsningen ikke må tage visuel kontrol over brugergrænsefladen (dvs. returnere html). Dette krav forudsætter dog, at applikationerne er bekendt med, at de er indlejret i en frame. 7

1.5 Løsningsforslag 2: Just-in-time login En mere avanceret løsning kunne være, at framede applikationer kommunikerede til portalen, når de havde behov for login, hvorefter denne så sørgede for login fra hovedvinduet. Fordele: Login sker kun, når der er behov for det og aldrig i en frame. Løsningen kræver avancerede ændringer til såvel applikationer som portal f.eks. skal der etableres en mekanisme til kommunikation mellem disse. Dette vurderes at gøre løsningen uholdbar. Hvis hovedsiden på portalen skifter til loginbilledet, mistes indhold og tilstand i de indlejrede frames umiddelbart, hvilket kan være stærkt generende for brugeren. 1.6 Anbefaling Det første løsningsforslag anbefales gennemført ved at indføre de omtalte krav til portaler i integrationsmodellen. 8

Timeout hos loginløsning Den næste udfordring er en variant af den første, der kan opstå, når brugeren har været aktiv på portalen et stykke tid. Her kan loginløsningens session med brugeren være udløbet på grund af inaktivitet, mens portalens eller de indlejrede applikationers egen session med brugeren er holdt aktiv på grund af lokal aktivitet. Hvis brugeren nu åbner en ny applikation i en frame på portalen, der har behov for login, og portalen pga. sin gyldige session ikke først sender hovedvinduet via loginløsningen, kan loginløsningens brugergrænseflade dels blive indlejret i en frame og dels vil brugeren blive bedt om at logge på, skønt han har været aktiv. 1.7 Løsningsforslag 1: Portalen holder loginløsningens session i live Det første løsningsforslag går ud på at kræve, at portalen periodisk fornyr sin session via et kald 1 til loginløsningen, uanset at brugeren måtte være aktiv på portalen og dermed holder den lokale session i live. Perioden skal indrettes, så browseren kommer forbi loginløsningen inden dennes session udløber, og dermed fornys IdP-sessionen uden at brugeren præsenteres for et loginbillede. Fordele: Løsningen medfører ingen ændringer i applikationerne. Brugeren oplever ikke, at han pludselig skal logge på igen, blot fordi han skifter til en ny applikation i portalen. Portalen skal kende og indrette sig efter loginløsningens timeoutpolitik. Brugeren kan opleve uventede loginbilleder, hvis han alene er aktiv i en enkelt frame og tilgår portalens hovedvindue efter portalens- samt loginløsningens session er timet ud. Her vil portalen henvise til loginløsningen, der vil prompte for login, skønt brugeren løbende har været aktiv. Når hovedsiden skifter, fordi browseren skal forbi loginløsningen, kan indhold og tilstand i indlejrede frames gå tabt. 1.8 Løsningsforslag 2: Løs problemet via generel timeout politik Det andet løsningsforslag er en udvidelse af det første med et krav om, at alle serviceudbydere i føderationen (portaler såvel som applikationer) periodisk skal forny deres session hos loginløsningen, uanset at brugeren måtte være aktiv i den lokale løsning. På den måde vil loginløsningens session blive holdt i live, så længe brugeren er aktiv hos en vilkårlig serviceudbyder i føderationen, der er tilknyttet loginløsningen. Fordele: 1 Et SAML <AuthnRequest>. 9

Denne løsning giver den mest optimale brugeroplevelse og færrest muligt (uventede) loginskærmbilleder. Loginløsningens session udløber aldrig, så længe brugeren er aktiv. Løsningen forudsætter, at alle serviceudbydere i føderationen kender og indretter sig på loginløsningens timeout politik. Der kræves mere af applikationernes sessionhåndtering, f.eks. skal de kunne holde brugerens seneste http request i luften inkl. parametre etc. mens browseren sendes forbi loginløsningen, og bagefter skal de kunne genoptage behandlingen af requestet, når browseren kommer retur. 1.9 Anbefaling Løsningsforslag 2 foreslås gennemført som en anbefaling til føderationens medlemmer og et obligatorisk krav til portalerne. Der kan således være enkelte applikationer, hvis sessionshåndtering ikke vil kunne håndtere de omtalte mekanismer, og da er det tilladt ikke at følge anbefalingen. Selvom dette kan medføre uhensigtsmæssige brugeroplevelser i form af uventet login, vurderes det dog at ville forekomme meget sjældent i praksis. 10

Aktivering af single logout Normalt skal hver applikation i føderationen i sin brugergrænseflade have en mekanisme (f.eks. en knap eller et link) til aktivering af single logout. Dette krav er dog uhensigtsmæssigt for applikationer, der er indlejret på portaler via frames, da den samlede brugergrænseflade så kan rumme flere instanser af disse knapper / links. Her er den ønskede brugeroplevelse i stedet, at portalens hovedvindue alene rummer muligheden for at aktivere single logout. Ved brug af SAML 2.0 s single logout protokol vil det normalt være den serviceudbyder, der initierer single logout, som kan vise brugeren en kvitteringsside. Hvis brugeren derfor kunne aktivere single logout i en frame, ville det være framen, som kom til at vise kvitteringssiden for logout, hvilket retteligt hører til i portalens hovedvindue. 1.10 Løsningsforslag Det foreslås, at problemet løses ved at applikationer gøres bevidste om, at de er framede, og i givet fald undlader at vise knapper og links til aktivering af single logout. Eksempelvis kunne portalen medsende en parameter til framede applikationer, eller man kan konfigurere forskellige URL er i portalens registreringsværktøj. Den præcise, tekniske mekanisme overlades til portalerne at specificere. Fordele: Løsningen giver den ønskede brugeroplevelse både med hensyn til at undgå multiple SLO knapper / links og kvitteringer for logout i frames. Applikationerne skal opføre sig forskelligt afhængigt af, om de er indlejret i en frame eller ej. Det vurderes dog som værende simpelt at aktivere / deaktivere en single logout knap / link baseret på en parameter. Det skal bemærkes, at der principielt ikke er noget til hinder for, at en framet applikation kan rumme en knap til lokal logout - dvs. hvor der kun logges ud af den lokale session med applikationen. Dette kan afhængigt af udformningen risikere at forvirre brugerne i en portalkontekst, og det overlades til portalerne at specificere, om dette er tilladt eller ej. 11

Blokering af cookies Af hensyn til brugernes privatliv blokerer nogle browsere og anti-spyware løsninger for cookies til framede applikationer, som afvikles fra et andet domæne end portalen (såkaldte third party cookies ). Dette er et stort problem, fordi mange applikationer anvender cookies til at holde sessioner med brugeren. Endvidere kræver FOBS løsningen, at serviceudbydere anvender en common domain cookie til at opdage brugerens Identity Provider, så problemet er essentielt at løse. 1.11 Løsningsforslag 1: Anvend URL rewriting Dette løsningsforslag går ud på at anvende andre metoder end cookies til at holde sessioner med brugeren. Dette kan eksempelvis være URL rewriting, hvor sessionen med brugeren holdes ved dynamisk at indlejre et sessionsid i alle URL er, der sendes til brugerens browser. Ved at inspicere dette ID efterfølgende i requests kan serveren således afgøre hvilken bruger, der er tale om. Fordele: URL rewriting er en velkendt og velafprøvet teknik til sessionshåndtering. Forslaget løser ikke problemet med common domain cookie eller andre cookies, applikationer måtte anvende til f.eks. at gemme brugerpræferencer etc. Ikke alle applikationsservere understøtter URL rewriting, og her kan det kræve et stort arbejde at tilføje dette i applikationerne selv. 1.12 Løsningsforslag 2: Omkonfigurér browseren En anden mulighed består i at detektere dynamisk, om browseren blokerer cookies, og i givet fald instruere brugeren i at ændre browserens indstillinger, således at dette ikke er tilfældet. Fordele: Løsningen kræver ingen ændringer af portaler eller applikationer. Dette vil udgøre et væsentligt problem for brugervenligheden, da de relevante menuer formentlig vil blive opfattet som svært tilgængelige for den almindelige bruger. Det er et særdeles dårligt signal at sende, at brugerne skal sænke sikkerhedsniveau et i deres browser, for at en fællesoffentlig sikkerhedsløsning kan fungere. 12

1.13 Løsningsforslag 3: Anvend DNS alias Et tredje forslag går på domænedeling via DNS, så tredjeparts-cookies reelt laves om til førsteparts cookies. Dermed vil browseren ikke opfatte cookies som problematiske og derfor lade dem passere uantastet. Specifikt vil man fra portalens domæne kunne oprette et alias i DNS, som peger på det domæne, hvor den framede applikation afvikles fra. Fordele: Løsningen kræver ingen ændringer af portaler eller applikationer. Det kan blive tungt at administrere og vedligeholde alle disse alias er. Der kan være udfordringer med DNS caching, således at ændringer ikke slår igennem med det samme. Mingeleringen med domænenavne kan give uheldige implikationer for certifikathåndtering (SSL servercertifikater er udstedt til et specifikt domæne). Serviceudbyderne kan formentlig ikke længere bestille de certifikater, deres løsning skal bruge, fordi domænet er ejet af en anden organisation. Hvis portalen skal til at bestille og håndtere certifikater for alle indholdsleverandører, der anvender iframes, bliver administrationen meget tung. 1.14 Løsningsforslag 4: Brug en reverse proxy En fjerde løsning er at bruge en såkaldt reverse proxy i portalens domæne, der dynamisk henter indhold hos serviceudbyderne, der skal indgå i iframes. På den måde ser det for browseren ud som om, at alt indhold kommer fra portalens domæne. Fordele: Ingen ændringer af applikationer, hvis proxy laver URL rewriting, så links tilpasses. Kræver ny proxy infrastruktur hos portaler. Al trafik går gennem proxy en, der bliver single point of failure. SSL servercertifikater vil give problemer, da serverens domænenavn ændres. Sensitive data transporteres til og eksponeres hos portalerne. 1.15 Løsningsforslag 5: Anvend P3P politikker Det sidste løsningsforslag går ud på at tilfredsstille browserens privacy krav, således at cookies ikke blokeres. Dette kan opnås ved at definere en privacy politik og gøre den tilgængelig for browseren i elektronisk form. Den tekniske standard på området hedder Platform for Privacy Preferences (P3P) og rummer: Et rammeværk og vokabular for beskrivelse af et web sites privacy politik. Et sæt af dataelementer som kan anvendes i P3P politikker. En protokol for transmission af politikker til en browser. 13

For detaljer henvises til http://www.w3.org/p3p. 14

Fordele: P3P er designet til at kunne anvendes på eksisterende web servere uden software ændringer eller opgraderinger. Der anvendes således standard-mekanismer, der allerede findes i alle web servere. Applikationer skal ikke ændres med mindre cookies i dag anvendes til formål, browserne ikke vil acceptere ved standardindstillinger. Teknikken løser problemet for common domain cookie. Det er en pænere opførsel, at serviceudbyderne opfører sig privacy-aware, hvor man bl.a. har formuleret og efterlever en eksplicit politik. Serviceudbydere skal designe en privacy policy samt sikre, at den efterleves (inkl. organisatoriske implikationer). Der vil være et ekstra arbejde forbundet med at konfigurere web servere til at sende de rette P3P http headere (formentlig minimalt). Se i øvrigt appendiks bagest i dokumentet for en vurdering af de tekniske, økonomiske og brugeroplevelsesmæssige aspekter af P3P. 1.16 Anbefaling Det anbefales at anvende det sidste løsningsforslag. Integrationsmodellen bør således udvides med et krav om, at serviceudbydere, der anvender iframe integrationsformen, skal formulere og implementere en P3P politik. Det er frivilligt men anbefalelsesværdigt for serviceudbyderne at anvende P3P på andre områder end cookie-håndtering. 15

Samlede anbefalinger til integrationsmodellen Nedenstående opsummerer kort de anbefalinger, der foreslås indarbejdet i integrationsmodellen [OIM]: 1. Portaler skal sørge for, at deres hovedvindue altid kræver login via FOBS løsningen, før en framet applikation brug for login. 2. Applikationer skal have at vide af portalerne, om deres indhold er indlejret i en frame. 3. I givet fald bør de sætte IsPassive attributten på SAML authentication requests. 4. En framet applikation bør undlade at vise knapper / links til initiering af single logout. I stedet skal portalerne have en fælles komponent til initiering af single logout (og vise kvittering bagefter). 5. Det er obligatorisk for portaler og kraftigt anbefalet for andre applikationer periodisk at forny sessionen ved at sende et SAML <AuthnRequest> til FOBS-løsningen, selvom brugeren er aktiv lokalt (i henhold til føderationens timeout politik). 6. Serviceudbydere, der anvender iframe integrationsformen, skal formulere og implementere en P3P privacy politik for cookie-håndtering. Det er frivilligt men anbefalelsesværdigt for serviceudbydere at anvende P3P på andre områder end cookie-håndtering. 16

Mere om P3P Nedenfor beskrives kort en række egenskaber ved P3P, der vurderet forud for anbefalingen om inddragelse i integrationsmodellen. For detaljer henvises til http://www.w3.org/p3p Tekniske risici De potentielle tekniske risici ved at anvende P3P kunne være: En web server hos en serviceudbyder kan ikke understøtte P3P og dermed ikke anvende iframe integrationsformen mod portaler. Nogle browsere kan ikke forstå P3P og vil derfor ikke kunne tilgå et P3P-enablet web site. Det vurderes, at ovenstående risici er minimale. Dels er P3P er designet til at kunne anvendes på eksisterende web servere uden softwareændringer eller -opgraderinger. Der anvendes f.eks. standard-mekanismer i http protokollen, der allerede findes i web servere og browsere. Endvidere vil browsere, der ikke kender de specielle P3P http headere, blot ignorere dem, og vise siden normalt. Ydermere kan det nævnes, at P3P har været i anvendelse nogen tid, og der er ikke fundet rapporter om, at det skulle give problemer i forhold til ældre browsere. Økonomiske implikationer Der er for en serviceudbyder ikke forbundet nogen direkte omkostninger ved anvendelse af P3P i relation til indkøb af software, hardware, licenser etc. De elektroniske politikker (XML format) kan skabes i hånden eller via simple værktøjer, som der findes en række gratis udgaver af (bl.a. fra IBM). De økonomiske omkostninger er således begrænsede til arbejdet, der er forbundet med indførelsen, herunder: Udarbejdelse af en privacy politik. Denne skal bl.a. beskrive hvilke informationer, der indsamles, og hvordan de anvendes (f.eks. om de videregives til tredjeparter). Gennemgang af procedurer og applikationer for at sikre, at politikken overholdes. Dette kan i visse tilfælde medføre et behov for tilretninger. Oversættelse af politikken til elektronisk format. Konfiguration af web servere, så politikken i elektronisk form er tilgængelig for browsere. Der er således et vist organisatorisk og et minimalt teknisk arbejde forbundet med at anvende P3P men få egentlige økonomiske risici. Arbejdets omfang vil afhænge af, hvilke data der indsamles, behandles og evt. videresendes i de konkrete applikationer. I øvrigt vil ovenstående arbejde i et vist omfang alligevel skulle foretages af organisationer, der skal efterleve DS-484 standarden og lov om behandling af personoplysninger, og under alle omstændigheder må det betegnes som god praksis aktivt at definere og efterleve en privacy politik. 17

Brugeroplevelsen Et andet væsentligt aspekt er, hvilke indvirkninger P3P vil have på brugeroplevelsen. For browsere, der ikke har støtte for P3P, vil brugeroplevelsen som tidligere nævnt være uændret. Browsere, der understøtter P3P, vil derimod visuelt kunne informere brugeren om, hvilken politik det aktuelle web site anvender til beskyttelse af hans oplysninger, og dels vil browseren kunne foretage en sammenligning med brugerens præferencer repræsenteret ved browserens sikkerhedsindstillinger. Samlet set giver P3P altså mulighed for en mere tillidsvækkende og informeret brugeroplevelse. 18