Allmänt
En stor del av vårt arbete just nu ägnas åt ”SDK”, dvs Ineras projekt Säker digital kommunikation för offentlig sektor. ”SDK” i texten hänvisar till det, och dessa är troligen bara relevanta för dig som representerar en offentlig organisation.
Större saker
Integration med e-post/fax
Sedan tidigare kan TDialog ta emot krypterade e-postmeddelanden och använda för att skicka TDialog säkra meddelanden. Detta kan användas för integration mot e-post, och mer specifikt integration med virtuell fax från leverantören Generic. Inkommande fax kan alltså bli TDialog säkra meddelanden utan inblandning av fysiska faxar.
Nytt i 3.11 är att denna integration även fungerar åt andra hållet, dvs man kan skicka faxmeddelanden från TDialog via leverantören Generic.
Dokumentation om denna integration kommer i Konfigurationsdokumentationen under nästa vecka.
Accessibility/WCAG
En lösning som värnar användarens personliga integritet måste även vara användbar för så många användargrupper som möjligt, så inte exempelvis en funktionsnedsättning gör att ens information hanteras på ett mer osäkert sätt. Det som kallas tillgänglighet/accessibility (ej att förväxla med tillgänglighet/availability inom IT-säkerhet) är därför oerhört viktigt. Accessibility är ett kontinuerligt arbete som TDialog utfört med ganska varierande framgång. Nu har vi gjort en ordentlig genomsökning och har en rutin för att verifiera framöver. Detta är ett område där vi lär oss, och vi uppskattar gärna feedback på specifika problemområden vad gäller Accessibility, på samma sätt som vi uppskattar feedback i övrigt.
Sessionshantering
Från och med 3.11 varnar TDialog när användaren är på väg att loggas ut, och genom att trycka “OK” i varningen fortsätter man vara inloggad. Om användaren inte klickar OK före sessionstidens slut sker en redirect till inloggningssidan.
Om användaren skriver i rubrikfältet och i textfältet kommer sessionen numera hållas uppdaterad, dvs användaren kommer fortsätta vara inloggad även om den bara skriver i textfältet. Det är fortfarande en webbapplikation, ska man skriva något långt kan det vara bra att skriva det lokalt och sedan klistra in det i applikationen eftersom den bland annat är beroende av Internet, men det blir i alla fall en bättre upplevelse gällande sessionen.
Mindre saker
Extra behörighet på gästanvändare
Som avancerade TDialog-användare känner till så går det att sätta vilken behörighet en gästanvändare (oftast en medborgare) ska ha i TDialogs gränssnitt. Hos vissa av er kan medborgaren skicka till vem den vill och kanske även självregistrera, hos andra är medborgaren begränsad till att bara svara på kommunikation från interna användare. Nu finns ett till verktyg i denna verktygslåda. I en miljö som annars bara tillåter gästanvändare att svara på tilltal kan man nu ge vissa gästanvändare behörighet att kommunicera med vem de vill. Detta sätts med hjälp av användarens e-postadress, och i likhet med liknande funktioner i TDialog finns flexibilitet i att ha en lista av e-postadresser och/eller domäner, dvs anger man lisa@gmail.com;@grevlinge.se så kommer just Lisa och samtliga användare i domänen grevlinge.se kunna skicka till vilka interna användare de vill. Observera att en gästanvändare i TDialog aldrig kan skicka till en annan extern användare och detta ändras inte i och med detta, det blir bara lite mer flexibilitet mellan att bara kunna svara eller att kunna skicka till andra interna användare.
SDK: Extrakontroll av avsändare
Som beskrivs i “övrigt från TDialog” nedan finns en sårbarhet i kontrollen av avsändare i SDK-ramverket som TDialog har behövt hantera. Enkelt uttryckt är sårbarheten som att skicka ett brev i ett kuvert från Grevlinge kommun och att sedan i brevet låtsas vara från Polisen (till exempel). Det syns på kuvertet att avsändaren är Grevlinge kommun, men eftersom användaren av meddelandeklienten bara tittar på själva meddelandet och inte på kuvertet kan man framgångsrikt lura användaren att man är från Polisen. Observera att sårbarheten endast gäller att avsändaren inte kontrolleras, det finns ingen läckagerisk rent tekniskt med denna sårbarhet.
Sårbarheten är en del av ramverket, dvs den fanns i både TDialog och i SDK:s testklient, och det räckte att ha ett certifikat från SITHS/EFOS, man behövde inte ens vara med i SDK-federationen för att kunna skicka på det sättet. Kunder som varit i verksamhetspilot har självklart varit informerade i hela processen. Både TDialog och SDK:s tesklient har nu infört kompensatoriska kontroller för denna sårbarhet i sina respektive meddelandetjänster. Nu i 3.11 krävs att avsändaren angiven i själva brevet matchar avsändaren av kuvertet, för att använda den tidigare analogin.
SDK: Snabel-a
I SDK:s adressbok tilläts inte snabel-a, vilket är ett problem för TDialog som använder en e-postanalogi vad gäller sin adressering. Från TDialogs sida tycker vi också att det borde vara upp till organisationerna själva hur de namnger sina brevlådor. För tillfället har vi löst problemet genom att om man skriver till en adress med ::: (trippelkolon) så tolkas det om till snabel-a, dvs om det finns en adress i adressboken “arbetsmarknad_norr:::grevlinge.se” och någon i SDK skriver till den funktionen så kommer adressen i TDialog översättas till arbetsmarknad_norr@grevlinge.se, vilket dels gör att man känner igen sina TDialog-adresser och dels gör att e-postnotifieringen fungerar. Det är inte klart hur regelverket kommer se ut för SDK framöver, men vi är starka proponenter för att inte ramverket ska förbjuda tecken i adresserna (annat än möjligen av rena IT-säkerhetsskäl).
Nästa release
Under våren, sommaren och tidiga hösten har TDialog arbetat intensivt tillsammans med Certezza med att installera och konfigurera dem av våra kunder som är piloter i SDK:s testbädd, samt verksamhetspiloter. Vi har idag 3 verksamhetspiloter (samtliga i SDK:s prodmiljö för någon dag sedan, eventuellt har Arbetsförmedlingen anslutit sedan dess) och ett 20-tal piloter i testbädden. Det är oerhört glädjande att vi kommit så långt, dels att vi nu kan se att TDialog har en fungerande och välanvänd plattform för SDK både i test och produktion och dels att vi nu har riktiga användare som kör lösningen och kommer med feedback. Större delen av 3.12 planerar vi att ägna åt gränssnittsförbättringar, primärt för SDK men det kan även komma andra till del. Preliminärt releasedatum för 3.12 är någon gång vid årsskiftet, men erfarenhetsmässigt vet vi att det är svårt att uppskatta.
Övrigt från TDialog
SDK
TDialog gjorde alltså en Responsible Disclosure av en sårbarhet i SDK-ramverket. Det visade sig att projektet kände till sårbarheten, men diskussionen gjorde att man prioriterade upp att hantera det, vilket TDialog tycker är bra. TDialog skulle önska att man går ännu längre, idag signeras inte meddelanden som skickas i SDK men TDialog skulle önska att så vore fallet. Den fix TDialog gjort nu till 3.11, och som rekommenderas från projektet, löser såvitt vi kan se just detta problem, men möjligheten att lita på avsändaren vore betydligt större om hela avsändarmeddelandet vore signerat. Denna sårbarhet visar också tydligt att ingen lösning, TDialog eller någon annan, kan försäkra sig mot sårbarheter i underliggande ramverk. Vi gör vårt bästa för att upptäcka sådant, vilket tydligt visas av denna incident, men varje leverantör (inklusive SDK-projektet) måste ta ansvar för sina delar. TDialog anser det viktigt att SDK-ramverket och dess infrastruktur utsätts för en noggrann sårbarhetsanalys före ett breddinförande, men där har vi ingen beslutanderätt utan kan bara säga vad vi tycker.
Fysiska försändelser
Vi som arbetar med IT tenderar att tycka att ju mer automatisering och ju mer digitalisering, desto bättre. Det finns dock fall där det inte är möjligt att digitalisera. Det kan exempelvis handla om när en användare är oförmögen eller ovillig att samarbeta för att kommunicera. Ibland behöver organisationen helt enkelt se till att en invånare juridiskt har fått ta del av informationen även om invånaren vägrar eller inte kan registrera sig eller öppna ett digitalt meddelande. I dessa fall kan man behöva skicka fysiska försändelser, och nu byggs en integration mellan TDialog och leverantören Ekopost för att kunna skicka TDialog-meddelanden som fysiska försändelser.
Integrationen använder sig helt och hållet av TDialogs befintliga integrationsgränssnitt, så det är egentligen inte ny funktionalitet i TDialog. Däremot vill vi informera om att denna lösning är på väg att komma på plats och skulle kunna användas av fler kunder.
Eletroniska möten
Ingen har kunnat undgå explosionen av elektroniska möten de senaste månaderna, och det har även förekommit diskussion om säkerheten i mötena. Certezza arbetar framgångsrikt med möten via programvaran Jitsi (webbaserat, open source on prem-lösning, krypterat mellan användare och server). TDialog tycker valet av möteslösning är bra, och planerar framöver att kunna bidra med att dels kunna skicka inbjudningar på motsvarande sätt som till ett Teams-möte och dels att få stark autentisering vid inloggning till mötet och motsvarande spårbarhet, dvs mötesinbjudaren bestämmer vilka som får logga in (vilka användar-ID:n, personnummer, HDA-ID:n etc) och kan sedan se vilka som är med på mötet av dem som bjudits in. Därmed tänker vi oss att få samma spårbarhet och konfidentialitet på videomöte som vi redan har på meddelanden. Vi tänker oss att påbörja detta arbete strax före årsskiftet.
Kundtjänst
Vi ser intresse för att använda TDialog för mer kundtjänstliknande scenarion. Ett exempel är Arbetsförmedlingen, och nu finns även en privat aktör som använder TDialog som meddelandefunktion till “Mina sidor”. Man använder TDialogs webservicegränssnitt för kundupplevelsen, men för kundtjänstpersonalen har man intressant nog gjort en embedding av TDialogs gränssnitt i kundtjänstapplikationen. TDialog har gjort en del anpassningar för en sådan mer kundtjänstorienterad vy (som inte påverkar övriga TDialog) och vi informerar om detta här ifall att det är intressant för andra kunder.
Tack, om inte annat hörs vi till 3.12!
