Tillåt anonym användning av öppna apier

[jonas]

Tillåt anonym användning av öppna apier

Förslaget bygger på principen att det ska vara frivilligt att ange vem man är vid interaktion med det offentligas öppna data, förslaget i sin korthet innebär att:

1. det ska vara frivilligt att ange vem man är
2. ett spårbarhets-id kan anges vid interaktion med offentliga öppna API:er ^[1]
3. offentliga aktörer kan använda DIGG:s forum som utfärdare av id:n för spårbarhet

Definitionen av öppna data säger:

Öppna data är sådana data som vem som helst fritt får använda, återanvända och distribuera med som största motprestation att ange källa eller krav på att dela data på samma sätt.
– Open Knowledge Foundation, en ideell organisation som verkar för utveckling av öppna data ^[2]

En tvingande identifiering av användare bör ses som icke förenlig med intentionen i PSI-lagstiftningen ^[3] och kommande öppna data direktiv 2019/1024. En rimlig tolkning är att det offentliga ska undvika att ställa motkrav på konsumenterna av offentlig information vilket inkluderar identifiering av användaren.

Organisationer som tillhandahåller öppna data vill kunna stävja missanvändning och följa hur öppna data skapar nytta, det blir rimligen svårare när det finns en osäkerhet angående vem som använder ett API. Från användarens synvinkel föreligger oftast behov av att få regelbunden information om kommande uppdateringar och inträffade incidenter etc. Med en genomtänkt arkitektur föreligger ingen motsättning i att tillhandahålla en anonym tillgång och samtidigt ha en dialog med användarna i en separat kanal. Möjlighet att följa användningen och att garantera driftsäkerhet går alltså att kombinera med anonym tillgång till API:et där alternativet att spåra användning erbjuds som ett tillägg.

Förslag till lösning

I korthet innebär lösningen att användaren:

• kan prova eller använda API:er i produktion utan att ange sin identitet.
• frivilligt kan förmedla en identitet som används för att följa användningen och kan vara krav för att erbjuda en högre servicenivå.
• kan kvittera ut ett id baserat på sitt användarkonto i Sveriges utvecklarportal ^[4].

Hur förmedlar användaren sin identitet?

I HTTP-protokollet finns attributet referer ^[5]. Detta attribut kan med fördel användas för att förmedla från vilken del av en webbtjänst som anropet görs. Informationen från referer är lämplig att använda för analys, logging med mera.
Attribut from kan användas för att frivilligt förmedla en identitet. Ursprungligen användes attributet för att förmedla en e-mailadress. Men i denna rekommendation föreslås en kryptologisk hashad URL (till ett användarkonto) som inte kan återskapas av tredje part. Processen för att hasha URL:en föreslås ske från ett redan öppet forum såsom DIGG:s utvecklarportal där användaren frivilligt har skapat ett användarkonto.

Referer

HTTP headers är ett sätt för en klient att skicka ytterligare information till en server. Mozilla beskriver syftet enligt följande.

When making resource requests to another domain, this would be the address of the page using the resource

Exempel på information som kan förmedlas till API:et via en http header:

Referer: https://jobbsajt.se/jobbsök 

Vilken del av URL som förmedlas till servern bestäms av den referrer-policy ^[6] som klienten väljer.

• Referrer-Policy: no-referrer
• Referrer-Policy: no-referrer-when-downgrade
• Referrer-Policy: origin
• Referrer-Policy: origin-when-cross-origin
• Referrer-Policy: same-origin
• Referrer-Policy: strict-origin
• Referrer-Policy: strict-origin-when-cross-origin
• Referrer-Policy: unsafe-url

From

Myndigheter har användarforum för att diskutera med sina användare, antingen i form av den nationella Community på Sveriges dataportal eller domänspecifika som exempelvis Jobtechdev.se/forum. För dessa forum finns redan existerande användarprofiler och det är utifrån dessa användarprofiler som ett spårbarhets-id kan skapas. Attributet from i HTTP specificerar från början en email för den användaren som kontrollerar anropet. Föreslagen lösning är är att användaren av offentliga API:er frivilligt kan ange sin hashade URI som värde i detta attribut.

Exempel på http header för en användare

From: 4cdf99d62d21f5f81dd6880e01a5390e 

Exempel på hur användaren hämtar sitt id genom att logga in på portalen

Hur kan DIGG eller annan myndighet skapa ett id för användaren Profil - jonas - JobTech Development forum

echo -n https://forum1.jobtechdev.se/u/jonas/ | md5 
4cdf99d62d21f5f81dd6880e01a5390e 

Notera! Istället för md5 bör kanske sha256 användas och eventuellt med en HMAC (innehåller en privat nyckel) så att inte tredjepart kan återskapa hashsumman från de publika profilerna.

echo -n "URI-till-publik-profil" | openssl dgst -sha256 -hmac "hemlig-nyckel" -binary | openssl enc -base64 -A

Lösningen är alltså inte en autentiseringslösning och ska inte heller användas för att bestämma åtkomst till en resurs.

En lösning som skalar

Fördelen med att identiteten skapas baserat på att användaren finns i DIGG:s Community på Sveriges dataportal underlättar både för användaren och de myndigheter som tillhandahåller öppna data. Användaren kan skapa ett konto med tillhörande “nyckel” för alla myndigheters API:er samtidigt som myndigheter inte behöver ha en egen kontohantering.

Införande

Arbetsförmedlinges plattform jobtechdev.se planerar att prova ovan koncept i Q2 och vi är väldigt intresserade av återkoppling.

Referenslista

---

1. Open API - Wikipedia ↩︎

2. Open Definition 2.1 - Open Definition - Defining Open in Open Data, Open Content and Open Knowledge, 2019-10-16. ↩︎

3. Lag (2010:566) om vidareutnyttjande av handlingar från den offentliga förvaltningen | Sveriges riksdag ↩︎

4. https://community.dataportal.se/ ↩︎

5. Referer - HTTP | MDN ↩︎

6. Referrer-Policy - HTTP | MDN ↩︎

[salgo60]

Vad är problemet med anonyma användare? Gissar att problemet med Öppen data är mer att få folk att börja använda det

Kollar du på WIkidata grafana “Wikibase API wbgetentities Last 90 days” så ligger man på 5 miljoner requests per minut

Den lösning Wikidata har gjort är att man vill att programmerare skall ange en user-agent se User-Agent_policy

[jonas]

Att undvika nycklar kan vara ett sätt att minska trösklarna för att just komma igång med användningen av öppna data. Låt säga att någon länkar till taxonomin i enlighet med länkad data och möts av " 401 Unauthorized". Det omöjliggör den länkade webben i mångt och mycket.

[bengtb]

Intressant exempel och relationen till den länkade webben. Här ser inte jag att ditt förslag oavn är tillämpbart eftersom anropet görs av webbläsaren och den anger väl automatisk den aktuella webbsidan som referer?

Ett av de vanligaste motiven till att kräva en nyckel av något slag är att enkelt kunna stänga av en användare som oavsiktligt eller avsiktligt gör felaktiga anrop eller för många anrop. Med en nyckel i anropet kan en smart brandväggsfunktion ignorera anropet. Hur kan man tänkta sig att detta funkar i den länkade webben?

[jonas]

Ett resonemang kan vara att för exempelvis ddos-attacker på vanliga sajter såsom arbetsformedlingen.se eller annan så brukar inte attackeraren berätta vem de är. Tror också att smarta brandväggar verkligen behövs för att hantera avstängningar, men snarare baserat på ip-nummer etc.

[bengtb]

Jag tror att ip-nummer kan vara svårt för alla som använder NAT, vilket väl är de flesta idag när antalet ipv4 nummer är slut.

Jag tycker att den länkade webben ställer tidigare sanningar om hur API:er ska skyddas på huvudet. För att den länkade webben ska fungera så måste ju öppna data vara just öppna. Helt öppna. Här gäller det att tänka om och hitta andra sätt att skydda sig.

Intressant!

[salgo60]

Långt ifrån expert på detta men om jag minns rätt så sätter GITHUB olika ratelimit på hur man kan hämta data vilket känns fare…

Enklast är väl bara att släppa på användare och se hur mönstret är…

• Grafana WIkidata Query Service
• Wikidata change stream

[jonas.cl]

Jag fattar det som att vi vill lösa två saker:

1. Man ska komma åt öppna api:er utan nycklar
2. Man ska kunna få uppdateringar om api:erna man använder.

Skulle inte RSS vara en lösning på problem 2? Problem 1 löses genom att bara ta bort nyckel hanteringen helt och hållet. Hashning av kontaktuppgifter skulle väl också gå men det känns som att det skapar onödig komplexitet jämfört med RSS om vi bara vill lösa problem 2.

[jonas]

@jonas.cl jag skulle komplettera med att det offentliga också vill få en bild över vilka användare de har, och detta steg skulle kunna baseras på frivillighet. Så behoven kanske kan sammanfattas som.

1. Man ska komma åt öppna api:er utan nycklar
2. Man ska kunna få uppdateringar om api:erna man använder.

3. Och för att bedriva uppföljning och kundvård så behöver man veta vem användaren är.

[PeterB]

Men vad är behoven?

Som jag ser det då finns det flera vägar att gå för olika behov - dock är jag inte övertygad om modellen med att koppla API-nycklar till forumkonton. Att knyta dem till ett forumkonto medför användarvillkor för forumet, eventuell personuppgiftshantering m.m. - om man vill ha ett öppet API med nycklar så vill man kunna stödja även användningsfall som exempelvis en app-utvecklare som låter varje användare skaffa en egen nyckel första gången appen startas.

Bättre vore väl att ha en nyckeltjänst kopplad till API:et (eller som en del av det) där en (permanent) nyckel checkas ut i utbyte mot lösningen på en CAPTCHA.

Syftet med en sådan nyckel kan exempelvis vara någon av följande:

• Stödja framtida identifiering för exempelvis support/felsökning
• Stödja rate-limiting
• Göra det lite svårare för ddos attacker

Vill man koppla sina nycklar till ett forum så är det kanske bättre att man kan ange dem i användarprofilen där istället (framtida identifiering). Exempelvis för support.

Vad gäller information om uppdateringar så verkar det också lite udda att koppla det till en nyckel. API:er kan ju byggas så att de levererar information om vilken version man använder och om det finns senare versioner.

Ett sessionslöst API kan ha ett enkelt anrop för detta - vilket bör anges som rekommenderat i dokumentationen.

Ett sessionsbaserat API kan rentav stödja att klienten begär en version och får veta om den inte längre stöds eller om den är på väg att tas ur bruk - med en URL till dokumentation.

Vill man ha ett API utan nycklar så är det inget problem heller, det beror snarast på vilka behov man har om en nyckel är lämplig eller inte. Men om man ser behov av en nyckel så verkar det tveksamt att koppla det till kundvård/support så direkt - lite som ordspråket “Du kan leda en häst till vatten, men du kan inte tvinga den att dricka.”

[jonas.cl]

Så som jag förstod det handlade punkt 3 mest om att kunna få fram bra statistik på användandet av tjänsten. Dvs, hur många organisationer och produkter använder tjänsten, och till vilken utsträckning. Vilka produkter som använder en tjänst får vi tillgång till via referer, och tanken är att from headern (From - HTTP | MDN) ska användas för att veta vilken organisation som använder tjänsten. En organisation kan äga flera olika produkter som anropar tjänsten.

Det finns i vissa fall krav på att sätta en rate-limit på vissa tjänster om kostnaderna för att hantera dessa inte kan motiveras. Detta ska inte hanteras av tjänsten själv utan av redan färdiga tjänster för detta ändamålet. För organisationer som ändå vill göra fler anrop än begränsningen ska det kunna finnas möjlighet att betala för det, eller att drifta tjänsten själv.

@jonas Tycker du det var en bra sammanfattning av diskussionen på mötet?

[Daniel]

När personer begär ut allmänna handlingar från en myndighet, har de alltid rätt att vara anonyma. Denna rätt att vara anonym är skyddad i grundlagen, 2 kap. 18 § tryckfrihetsförordningen. Det är en rätt lika gammal som offentlighetsprincipen själv, d.v.s. från 1700-talet, och handlar om att skydda den som begär ut handlingarna.

En möjlighet att anonymt kunna ta del av öppna data från en myndighet skulle stämma väl överens med rätten att vara anonym för den som begär ut allmänna handlingar.

[jonas.cl]

Diskussionen har aldrig handlat om att man inte ska kunna använda api:erna anonymt, det ska man kunna. Det vi diskuterar är hur vi ska kunna kommunicera med klienter som aktivt väljer det, och hur vi ska kunna få fram data på hur api:erna används.

[jonas]

Bra kommentar @Daniel. Syftet med förslaget är verkligen att fånga intentionen med öppna data och erbjuda data med rätten att vara anonym inom en rimlig servicenivå. Sedan om det finns höga krav på tillgänglighet och prestanda är det inte orimligt att man måste ge sig till känna för att få den servicen. Tänker att det offentliga inte kan dimensionera för en hög last utan dialog.

[Daniel]

Tack för klargörandet, det framgick inte tydligt av ditt inledande inlägg.

Den som väljer att vara anonym, väljer rimligtvis också att inte kunna bli kontaktad. Då får myndigheterna acceptera det.