Öppna Skolplattformen polisanmäls av Stockholms stad

Det här togs upp av en annan. Användaren väljer själv vilken webbläsare de vill köra, så jag anser inte att Skolplattformen har något ansvar för det. Om man däremot använder webbläsarens APIer på ett osäkert sätt, då har man ett ansvar för det

Klart att Ö(SP) har ansvar även i appen. Om ex. Kivra appen har kända säkerhetshål som läcker mina e-brev / personuppgifter är det klart att dem är ansvariga. Bara för att det är en app frånsäger det inte ansvaret.

Frågan är väl snarare om de som gör webbläsaren har något ansvar? Självklart ansvarar de för säkerheten i webbläsaren, att den inte samlar in känslig information exempelvis, men inte för att en tjänst inte skickar för mycket information. Exakt samma gäller appen.

Jo precis, från API-anropet till och med appen.

Jo precis, från API-anropet till och med appen.

Rättsutredningen för den intresserade (9 korta sidor). Jag hittade där ingen direkt motivering till varför ett API skulle vara sekretessbelagt. Mest relevanta jag kunde hitta:

Sekretess och integritetsskäl i offentlighets- och sekretesslagen (2009:400) förkortat OSL, dataskyddsförordningen, registerförfattningar eller av immaterialrättsliga skäl kan dock inskränka vidareutnyttjandet.

En myndighet som meddelar ett beslut i ett ärende ska så snart som möjligt underrätta den som är part om det fullständiga innehållet i beslutet, om det inte är uppenbart obehövligt.

Nu tror jag du blandar ihop saker. Jag har visst rätten att reverse-engineera någonting och sälja det och ta betalt för det. Det är OK så länge jag inte olovligt tillförskaffat mig uppgifterna, använder saker kopierat direkt av så det bryter mot copyright-lagstiftning eller bryter mot patent då jag säljer det.

Inloggning eller inte, det spelar ingen roll, och därför jag skrev som jag gjorde att det inte spelar någon roll om man måste identifiera sig eller inte.

Precis poängen jag försöker göra.
Du skall inte behöva gräva i lagar och regler själv för att försöka gissa varför det är sekretessbelagt.
Se paragraf 33 i förvaltningslagen:
https://www.riksdagen.se/sv/dokument-lagar/dokument/svensk-fo...
Ett fullständigt beslut skall alltså innehålla varför just _du_ inte får se vad du efterfrågat så du kan överklaga det om du inte håller med i motiveringen.

Officiella lösningar utgör också säkerhetsrisker. Just Skolplattformen verkar ha utvecklats av folk som tycker om att göra program som är fullproppade med buggar och då skulle man kunna tänka sig att det bland dessa buggar finns en hel del säkerhetshål och därför skulle det kännas säkrare att använda en annan lösning än den officiella.

Jag kanske missförstod när du skrev "Frågan är väl snarare om de som gör webbläsaren har något ansvar?".

Det jag menade med "en applikation (ex. webbläsare) är ytterst ansvarig för sina egna APIn" är att den yttre gränsen går vid interfaces. Om APIet är till för att hämta känslig data ingår självklart ett ansvar att datan endast får hämtas på ett säkert sätt. Ex. om en webbapp vill ha access till mikrofon/kameran (via API) är det webbläsarens ansvar att verifiera användarens tillåtelse, hur datan sedan hanteras är utanför webbläsarens ansvar.

Min replik var till Xake då användaren skrev "Jag har visst rätten att reverse-engineera någonting och sälja det och ta betalt för det.", vilket generellt är fel. Finns vissa APIer som tillåter det och andra inte.

I min replik till Xake hävdade jag inte att inloggningen frånsäger Skolplattformens ansvar att skydda känslig data. Jag ville endast förtydliga att det fanns inloggning med BankID eftersom flera i diskussionstråden har missat det.

Huruvida ett API är "öppet" är dock en helt annan fråga. Absolut, finns flera öppna APIer som kräver autentisering med ex. en API-nyckel. Just Skolplattformens API kräver autentisering mot BankID, ger inte ut dokumentation och nekar förfrågningar om att integrera mot APIet. Ett sådant API är inte "öppet" i den vanliga bemärkelsen.

Men det har inget att göra med webbläsarens eventuella API:er. Vad jag menar är att de som har byggt denna app har använt publikt tillgänglig information (även om den inte är publicerad) för att komma åt publika resurser. Vem som helst hade kunnat granska anrop och svar mellan den vanliga webbapplikationen och tjänsten och sen använt dessa och fått åtkomst, appen är bara ett gränssnitt.

Det finns exempel från verkligheten. Microsoft byggde exempelvis en egen Windows Phone-app för Youtube då Google vägrade, Google blockerade sedan denna apps åtkomst. Skillnaden här (förutom då att lagarna i USA inte gäller här förstås) är att man behöver en utvecklarnyckel för att komma åt Youtubes API och för att få det godkänna vissa villkor som MS då bröt emot här, i Googles ögon i alla fall.
Jag förstår liknelsen, men i mitt exempel är webbläsaren klienten, i ditt exempel agerar den server. I fallet vi diskuterar är det, som du säger på ett något omvänt sätt, API:et som har ansvar för att autentisera användaren och bara ge ut de uppgifter användaren ska ha åtkomst till, via en säker överföring. Efter det har alltså tjänsten inget ansvar för att uppgifterna inte läcker ut utan där går "appens" ansvar in. Den ansvarar för att uppgifterna den får ifrån tjänsten inte läcker ut, mer än på de sätt användaren önskar. Utskrift på skärm eller papper exempelvis. Men appen har inget ansvar för att kontrollera att användaren faktiskt har rätt att få åtkomst till dessa uppgifter mer än via tjänstens auktorisering.
Det finns absolut API:er som har avtal man måste godkänna, jag har ingen aning om vad som är vanligast men i allmänhet innebär det ju en teknisk begränsning. Som i exemplet med Google och MS ovan. Du måste godkänna villkoren för att få åtkomst till det specifika API:et. Här är API:et öppet, man kan anropa det och få svar utan att skicka med en nyckel tillhandahållen av tjänsteleverantören. Jag kan inte juridiken specifikt här men i allmänhet är det svårt att tillhandahålla något öppet och gratis och sen anmäla de som nyttjar detta. Dock inte alltid, men då handlar det oftast om copyright, om man exempelvis scrapar nyheter från DN eller något.
Hur man autentiserar användaren spelar mindre roll i mina ögon. Det har aldrig handlat om att appen skulle fuska med något sånt, eller ge åtkomst till andra uppgifter än det som användaren får från API:et.
Nej, API:et kräver inte autentisering med bankid för att nyttja det utan det kräver att användarna autentiserar sig med bankid. Åtkomst till API:et är öppet, men åtkomst till informationen kräver autentisering.

Ok nu förstår jag vad du menade med "Frågan är väl snarare om de som gör webbläsaren har något ansvar?". Vi måste urskilja reverse engineering (ex. använda sin session för att testa APIer) från att bygga en app baserad på reverse engineering.

Reverse engineering är lagligt enligt EU direktivet 2009/24:
> Den person som har rätt att använda en kopia av ett datorprogram ska utan rättsinnehavarens tillstånd ha rätt att iaktta, undersöka eller prova programmets funktion i syfte att utröna de idéer och principer som ligger bakom programmets olika detaljer, under förutsättning att detta sker vid sådan laddning, visning, körning, överföring eller lagring av programmet som han har rätt att utföra.

Du har alltså rätt att peta i Chrome DevTools och använda din session för att undersöka APIerna. Det översätts inte till att du får bygga och distribuera en app, särskilt inte om det är i kommersiellt eller konkurrenssyfte.

Att YouTube APIet kräver nycklar som de kan styra spelar ingen roll. Slack har ett publikt API med Terms of Service som b.la. förbjuder alternativa appar:
> Further, you will not: [...] (C) access our APIs or documentation in order to replicate or compete with the Services;.

Jo, som vi alla vet är det tveksamt hur juridiskt hållbara mjukvarulicenser av denna typ är. Men oavsett så är Slack rätt annorlunda från vad vi pratar om här. Slack är en mjukvara och man måste godkänna villkoren för att kunna använda den, vilket inkluderar att använda deras API. Detta API är inte för att komma åt Slack i sig utan för att låta andra applikationer använda Slack.

Sen har jag förstås inte kollat, det kanske går att fånga anropen Slack gör från sin web-app till backenden och använda dem för att bygga ett eget UI mot Slacks backend, men användarvillkoren säger ju att det inte är tillåtet och man måste förstås ha godkänt dem för att ha kunnat komma åt web-appen från första början. Sannolikt funkar det inte dock då Slack lär begränsa åtkomsten till grundfunktionaliteten till deras egna appar eller liknande.

Sen vet ju inte jag hur skolplattformen ser ut heller. Man kanske har godkänt några villkor där som begränsar användning av API:erna, men sannolikt inte för då hade vi nog hört om det i detta fall. Motsvarande tjänst här i Göteborg verkar inte kräva något godkännande av något avtal eller liknande, och den är också baserad på Ping Pong och utvecklad av samma leverantör (och också ganska kass).

Du själv väljer att urskilja Slack från Skolplattformen men egentligen är det ingen skillnad. Alla webbapplikationer, inkl. Slack, går att reverse engineera och bygga en alternativ app (vad vissa kallar för "UI") genom att helt enkelt undersöka API anropen. Som sagt, du har rättighet som användare att undersöka APIerna, men att sedan bygga en app som integrerar mot APIet är ingen rättighet och krävs därmed att det är tillåtet.

Jag medger att vi inte vet hur Skolplattformen har satt upp sitt licensavtal. Jag har dock inte hört ÖSP motivera sin app med hänsyn till licens, endast hört resonemanget "det går ju att göra anropen i Chrome DevTools". Däremot i utredningsrapporten poängterar utbildningsförvaltningen att ÖSP saknar licens för att använda APIet.

Jag skulle säga att det är tillåtet om det inte specificeras att det inte är det. Sen vet jag inte hur kraven är på denna specifikation, om det krävs att det är som mjukvarulicenser där man liksom måste godkänna avtalet för att kunna använda applikationen och att ett öppet (åtkomligt) API utan krav på godkännande av avtal därmed betyder att det är fritt att använda. Är det inte så så är det lite som att ställa ut en skål med godis och sen anmäla alla som tar en liksom, vilket visserligen inte nödvändigtvis är juridiskt

Frågan är väl om licens krävs för att få åtkomst till API:t? Antingen rent tekniskt eller genom något avtal. Att de saknar licens spelar ju ingen roll om det inte finns krav på att ha en licens liksom.

Edit: Angående det fetmarkerade, att alla web-appar skulle gå att använda på detta sätt, så stämmer ju det inte alls. I allmänhet så krävs mer än bara API-anropen för att få ut något. Exempelvis någon form av signering så att bara appar godkända av den som tillhandahåller API:t kan komma åt resurserna. Se exempelvis: https://skat.dk/skat.aspx?oid=2242203&chk=217320 Danska skatteverket, öppna API:er, för att få åtkomst måste du registrera ett certifikat hos dem annars blir det bara 401/403.

Argumentet att "ÖSP saknar licens" implicerar ju att det krävs. Om/hur det är uppsatt vet vi inte, men som sagt enda motargumentet jag hört är att man kan anropa APIerna på samma sätt i ex. Chrome DevTools. Har inte hört något motargument i form av "Skolplattformen saknar licens" eller "Skolplattformens licens förhindrar inte detta".

Man kan absolut göra det svårare att reverse engineera med olika sätt för obscuring/obfuscating. Exempelvis är det praxis att inte inkludera "source map" i produktion av just den anledningen, vilket såvitt jag vet även Skolplattformen har gjort. APIerna däremot tycker jag är bra om de är relativt enkla att förstå.

Obscuring API tillför i grunden ingen säkerhet och påverkar inte ifall tredje parter har rätt att integrera mot APIet. Det gör det endast svårare för både utvecklarna och användarna att undersöka APIerna.

Missade detta när jag svarade. Det här borde varit varit ett separat inlägg. Jag kan tyvärr inte läsa danska, men i webbläsaren kan man inte signera JavaScript förutom med HTTPS. Just den här frågan går att söka sig fram i diverse Q/A forum, ex:
https://security.stackexchange.com/a/51052

Jag pratar inte om obfuskering utan att man kräver autentisering även av applikationen. Utvecklaren begär en nyckel eller ett certifikat av tjänsteleverantören, eller skapar ett eget certifikat och registrerar det hos tjänsteleverantören. För att få göra detta kan det räcka med att man godkänner villkoren vilket kan ske automatiskt där man registrerar sitt certifikat eller får sin nyckel, eller så måste man betala. Rätt vanligt är att det är gratis att använda ett API upp till ett visst antal anrop per dag eller månad, sen får man betala någon för form av produktionslicens. Det gör att man kan utveckla och testa med ett "gratiskonto" och sen betala när/om man lanserar sin applikation till allmänheten.

Edit som svar på din Edit:
Jag kan tyvärr inte danska, men för att en klient ska skicka en nyckel i anropen måste nyckeln finnas tillgänglig på något sätt i klienten (därmed tillgänglig för användaren). Om du inte kan det här kan du söka fram svaret på frågan i diverse Q/A forum, ex:
https://security.stackexchange.com/a/51052
https://security.stackexchange.com/a/246442

TL;DR det går alltid att reverse engineera klienten och man kan inte garantera att den klient som anropar APIet är ens egna klient.

Lyssnade på podden med en av de berörda personerna som var med och tog fram appen. Intressant att lyssna på. Vissa delar håller man helt klart med om medan andra är att anse som inspel i politiskt tyckande. De saker som berörde politiskt tyckande saknade underlag och därav gav felaktigt resultat av analysen han gjorde.

Men bra att de hade för avsikt att förbättra och öppen källkod medan mindre bra av stockholmsstad i hur de hanterade situationen. Hoppas det kommer förändra LOU, att stoppa privatisering där det inte är nödvändigt för samhällets intresse och fler IT-kunniga personer.