Öppna Skolplattformen polisanmäls av Stockholms stad

Permalänk
Medlem

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.

Permalänk
Medlem
Skrivet av Xake:

Jag vill se dem ens försöka förbjuda användandet av APIerna.
Hur många sidor är byggda idag är att du har en frontend i din webläsare som frågar efter data från en backend, och sedan presenterar denna på ett läsbart sätt.
Dra igång utvecklarverktygen i chrome, gå till google.se och börja skriv något i sökfältet. Du kommer se att websidan skickar lite data till google som skickar tillbaka en json med de mest troliga sakerna du kommer fortsätta skriva. Börja skriva ett ord du inte ser i json-datan om du kommer se samma sak igen.
Din webbläsare skickar data till APIer den får skicka till. Backend svarar med data som din inloggningsnivå tillåter.
Appar fungerar likadant. Bara lite mer omständigt då de inte brukar ha en utvecklarkonsol likt den som Chrome och Firefox har.

Min misstanke är att det är precis detta föräldrarna gjort. Loggat in, använt funktioner. sett vad för svar de fått. Imiterat detta i sin app. Kallas reverse engineering.
Och det är nästan omöjligt för servern att avgöra vilken av webapplikationerna det är. De kanske kan se det på "UserAgent" om de inte imiterar den med. Vilket inte heller är olagligt, då det inte anses att förfalska något.
Annars är verkligen det enda man har att gå på saker som hur APIerna används i förhållande till varandra. Kan inte uppslag x följas av uppslag y i vanliga appen är det nog imitationen. Eller om webappen inte skickar med skräp x. Men inte ens det är säkert, för de kanske har webappen öppen i två flikar samtidigt, skickar med extra skräp "bara för att" osv.

Och inget jag bekrivit ovan är olagligt. Och svårt att göra olagligt. Det närmsta man kommer är om Sthlms stad skulle inför DRM på sina APIer, för då är vi inne på copyright-lagstiftningen och hur det är olagligt att ta sig förbi den sortens begränsningar, på samma sätt som det är olagligt att ta sig förbi behov av inloggningar, vilket man inte heller gjort här.

Över lag tycker jag hela detta mest låter som tekniskt okunniga personer, både anställda och politiskt tillsatta som mest är salty över att några tycker deras superba system är skit och utvecklat sin egna, och om de har problem med hur mycket data som den Öppna platformen kan visa så beror det på att de inte förstår hur mycket data de själva exponerar ut i sina APIer i webappen, vilket vem som helst kan se genom hålla inne Ctrl+Shift och trycka på "i" i webläsaren, för att sedan trycka på någon funktion på deras sida.
Och det roliga är just det sistnämnda. Skulle det visa sig att den Öppna kan exponera data som inte borde kunna exponeras så är det mer troligt att Stockholms stad kommer få en motstämning som är mer vattentät på hur mycket de låter sina APIer exponera oavsett om det krävs login eller inte.

Just precis det jag menar, man kan inte förbjuda användandet utav APIerna. Hade man haft någon typ av DRM så hade det varit lätt för Stockholms stad att skicka en DMCA begäran.

Permalänk
Medlem
Skrivet av Pepe Silvia:

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

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.

Citat:

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.

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

Permalänk
Medlem
Skrivet av snajk:

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.

En applikation (ex. webbläsare) är ytterst ansvarig för sina egna APIn, inte vad APIerna används till. Tycker det är rimligt att den applikationen som hämtar känsliga uppgifter och hanterar datan i koden även är ansvarig för att det hanteras säkert.

Skrivet av snajk:

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

Aha då är vi överens väl? Dvs "till och med appen" inkluderar själva appen?

Permalänk
Medlem
Skrivet av Pepe Silvia:

MEN det är inte samma sak som att man har rätt att publicera, distribuera och ta betalt för något som är byggt på reverse engineering. Det många missar är skillnaden mellan att rota i APIer och att distribuera ex. mobilappar baserade på det.

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.
Så länge man inte kan göra en koppling liknande ovan - genom att jag exempelvis jobbat på företaget som tagit fram det och vet orginalkällkoden eller liknande - så är det inget olagligt i det.
Hade jag inte fått göra det hade läkemedelsindustrin sett mycket annorlunda ut, något du märker om du försöker hämta ut ett recept. Eller för den delen linux, där många drivrutiner är reverse-engineerade, såsom nouvea. Hade du inte fått göra det hade Red Hat som säljer koden och dessutom har utvecklare som jobbar på koden anställd verkligen suttit i skiten.

Skrivet av Pepe Silvia:

Framgår inte i nyhetsartikeln men Skolplattformens API kräver autentisering med BankID. Vad som däremot framgår är att Skolplattformen tidigare haft säkerhetsbrister, vad jag känner till kunde en inloggad användare komma åt delar av andra användares personuppgifter.

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.
Jämför med att du kan logga in och kolla dina sjukjournaler. Bara för du måste logga in för att komma åt dina så gör det inte det mindre allvarligt om det visar sig du kan komma åt hela regeringens när du ändå är inloggad. För kan du så kan någon annan med som kan använda den informationen för utpressning med mera.
Sedan vad du använder kunskapen till är något annat. Men du kanske heller inte vill att hela din umgängeskrets bara "råkat" kolla din journal och vet om den där vårtan på det där stället, du vet vad jag pratar om.

Skrivet av Pepe Silvia:

Det kan mycket väl finnas fler brister i APIet vilket ev. kan användas som försvar men inte motstämning. Att stämma kors och tvärs görs i USA men inte i Sverige. Datainspektionen (IMY) ansvarar för personuppgiftsincidenter och relaterade bötfällningar.

Jaja, ok. Jag borde skrivit en "polisanmälan". Vet också att det inte fungerar riktigt lika dant, men att anmäla och motanmäla är en princip som används även i sverige för att få målsäganden att lägga ner sin polisanmälan och hantera saker utanför domstolen.

Permalänk
Medlem
Skrivet av Pepe Silvia:

Icke-officiella appar är en säkerhetsrisk om det saknas strikta kontroller.

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.

Permalänk
Medlem
Skrivet av Pepe Silvia:

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.

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...

Citat:

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.

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.

Permalänk
Medlem
Skrivet av Xake:

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.

Det finns Terms of Use även för APIer, dvs de som tillhandahåller APIet har rätt att bestämma hur det får användas. Att vissa tillåter detta betyder inte att det är fritt fram.

Skrivet av Xake:

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.

Håller med, jag ville bara förtydliga att inloggning bör krävas eftersom du skrev "oavsett om det krävs login eller inte". Instämmer att om ett visst API endpoint saknar autentisering spelar ingen roll, huvudsaken är ifall det läcker personuppgifter.

Permalänk
Medlem
Skrivet av Xake:

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.

Jo, jag håller helt med dig om att beslutet måste motiveras.

Själv har jag endast läst att dokumentation nekades pga sekretess men inget mer än så. Dvs jag vet inte hur motiveringen löd. Nån får gärna fylla i om dem kan citera Stockholm Stads motivering.

Permalänk
Medlem
Skrivet av Kommenterande 2:

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.

Jo, jag tycker definitivt det bäste vore ifall Stockholm Stad hade ett biträdesavtal med Öppna Skolplattformen. Så funkar det i alla fall på firman jag jobbar på, vi är personuppgiftsbiträde för en myndighet och har tillåtelse att hantera personuppgifter från deras API i vår webbapp med vissa säkerhetskontroller.

Permalänk
Medlem
Skrivet av Pepe Silvia:

En applikation (ex. webbläsare) är ytterst ansvarig för sina egna APIn, inte vad APIerna används till. Tycker det är rimligt att den applikationen som hämtar känsliga uppgifter och hanterar datan i koden även är ansvarig för att det hanteras säkert.

Ja självklart, men om API:t exempelvis plötsligt ger åtkomst till kungens personuppgifter snarare än den inloggade användarens, är det då den som utnyttjar API:et i sin applikation som borde stoppat det eller det de som tillhandahåller API:et som gjort fel? Sen blandar du ihop det lite, det är inte webbläsarens API vi snackar om utan tjänstens.

Citat:

Aha då är vi överens väl? Dvs "till och med appen" inkluderar själva appen?

Precis. Det var exakt samma formulering som jag hade i inlägget du svarade på så det finns ingen konflikt där.

Skrivet av Pepe Silvia:

Det finns Terms of Use även för APIer, dvs de som tillhandahåller APIet har rätt att bestämma hur det får användas. Att vissa tillåter detta betyder inte att det är fritt fram.

Det kan finnas. Men om API:et är öppet och inte kräver att "utvecklaren" godkänner licensen eller användaravtalet för att komma åt API:et så kan den ju inte vara bunden av licensen eller avtalet.

Citat:

Håller med, jag ville bara förtydliga att inloggning bör krävas eftersom du skrev "oavsett om det krävs login eller inte". Instämmer att om ett visst API endpoint saknar autentisering spelar ingen roll, huvudsaken är ifall det läcker personuppgifter.

Hade man haft ett API som ger åtkomst till personuppgifter utan autentisering eller kontroll av att användaren har rätt att komma åt dessa uppgifter hade varit ett rätt allvarligt brott mot GDPR och sannolikt flera svenska lagar. Men huruvida ett API kräver inloggning/autentisering eller ej har inget att göra med ifall det är öppet eller inte.

Permalänk
Medlem
Skrivet av snajk:

Ja självklart, men om API:t exempelvis plötsligt ger åtkomst till kungens personuppgifter snarare än den inloggade användarens, är det då den som utnyttjar API:et i sin applikation som borde stoppat det eller det de som tillhandahåller API:et som gjort fel? Sen blandar du ihop det lite, det är inte webbläsarens API vi snackar om utan tjänstens.

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.

Skrivet av snajk:

Det kan finnas. Men om API:et är öppet och inte kräver att "utvecklaren" godkänner licensen eller användaravtalet för att komma åt API:et så kan den ju inte vara bunden av licensen eller avtalet.

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.

Skrivet av snajk:

Hade man haft ett API som ger åtkomst till personuppgifter utan autentisering eller kontroll av att användaren har rätt att komma åt dessa uppgifter hade varit ett rätt allvarligt brott mot GDPR och sannolikt flera svenska lagar. Men huruvida ett API kräver inloggning/autentisering eller ej har inget att göra med ifall det är öppet eller 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.

Trodde snajk var Xake, tydligen två olika användare
Permalänk
Medlem
Skrivet av Pepe Silvia:

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?".

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.

Citat:

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.

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.

Citat:

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.

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.

Citat:

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.

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.

Citat:

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.

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.

Permalänk
Medlem
Skrivet av snajk:

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;.

Permalänk
Medlem

Det jag känner kan anses möjligen graverande är att de tar betalt för appen. Det är en skräddarsydd applikation som nyttjar någon annans infrastruktur utan avtal eller tillåtelse, som man sedan har ekonomisk vinning av. Jag säger inte att de blir jätterika, men det har inte riktigt med saken att göra.

Med det sagt så åtgärdar appen den problem jag har med "orginal" appen, så jag använder den och gillar den. Koden är välskriven och fint organiserad, UX är genomtänkt och UI är helt OK.

Jag tror inte det är helt omöjligt att de kommer kunna åka på det här, eftersom appen är så specifik. Hade de byggt en webbläsare eller Postman, etc, så hade det inte varit en issue, men den här appen riktar sig enbart mot en tjänst som man inte äger eller har tillåtelse att nyttja i kommerciellt syfte.

Permalänk
Medlem
Skrivet av Pepe Silvia:

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).

Permalänk
Medlem
Skrivet av snajk:

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 undersöka i Chrome DevTools. Som sagt, i EU har man 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äver 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.

Permalänk
Medlem
Skrivet av Pepe Silvia:

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 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

Citat:

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.

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.

Permalänk
Medlem
Skrivet av snajk:

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.

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.

Skrivet av snajk:

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.

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.

Svarade på snajks Edit
Permalänk
Medlem
Skrivet av Pepe Silvia:

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.

Permalänk
Medlem
Skrivet av snajk:

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.

Vissa APIer riktade mot tredjeparts utvecklare fungerar så, inte APIer riktade mot klienten. Se mitt Edit svar:

Skrivet av Pepe Silvia:

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.

Lade till TL;DR för att vara tydligare
Permalänk
Medlem

Stockholms stad fortfarande i händerna på konsulter.

Jag sätter en spänn på att det är samma konsulter som sålde in och implementerade den usla lösningen som nu har övertygat beslutsfattarna om att konsulterna minsann har gjort jättebra grejer hela tiden och att staden måste sätta in kraftiga åtgärder mot de dumma hackarna, vilket man så klart kan hjälpa staden med - mot rimlig kostnad på ytterligare hundratals miljoner kronor.

Någon som på riktigt tror att det gått till på annat sätt?

Permalänk
Medlem

Alltså, jag skummade "rättsutredningen" tidigare och en hel del av argumentationen i den faller ju platt framlänges och slår ut tänderna när man ser det här...

Inte för att jag är förvånad, då skummandet ledde till en ständigt stigande känsla av att man bestämt resultatet först och gjort utredningen därefter. Jag hade gärna tittat själv, men man måste ju ha en skolplacerad liten "trojan" för att kunna göra det.

Permalänk
Hedersmedlem
Skrivet av ztenlund:

Jag hade gärna tittat själv, men man måste ju ha en skolplacerad liten "trojan" för att kunna göra det.

Little Bobby Tables, we call him.

Permalänk
Medlem
Skrivet av Aphex:

Little Bobby Tables, we call him.

Nu sätter förstås Skatteverket stopp, men med tanke på nivån så kanske något i den stilen skulle fungera...

För den som inte förstår syftningen:
https://xkcd.com/327/