Sekretessetiketter för iOS 14 räcker inte

0 Shares

Apple ägnar mer uppmärksamhet åt integritetsskyddsfrågor än sina konkurrenter. Väl definierade sekretesspolicyer och ganska allvarliga begränsningar för vilken användarinformation en app eller ett tillägg kan göra Apple-produkter säkrare för användarna.

Men ur perspektivet av öppenhet var allt inte så uppenbart för Apple. Det senaste tillkännagivandet visar att företaget är redo att ta några steg till för att öka transparensen inom sekretessskyddet.

Sekretessetiketter är att informera användaren, inte att blockera spårare

En hög nivå av centralisering och informationsskydd gjorde det möjligt för oss att säga att Apples policy fortsätter att vara selektiv. Även erfarna iOS-användare vet inte var deras webbhistorik läcker, eftersom de vanligtvis inte ser vid vilken tidpunkt appar ansluter till nätverket eller vilka servrar som behandlar förfrågningar.

En av de viktigaste ändringarna av iOS 14 är relaterad till bearbetning av platsspårning. I den nya versionen kommer det att vara möjligt att säkert dela ungefärliga platsdata. Ungefärlig plats gör det möjligt att anpassa innehåll korrekt, men det avslöjar inte användarens verkliga vistelseort. Apple tillkännagav också skydd mot att använda kameror eller mikrofoner utan användarens vetskap.

Etiketterna som visas i iOS 14 hjälper användarna att kontrollera hur en app tillämpar deras personuppgifter och huruvida denna information delas med tredje part. Baserat på dessa etiketter kan användarna ha lättare att fatta sitt eget beslut och vägra att installera appen om det behövs. Dessa etiketter är dock inte utformade för att blockera spårning. Allt implementeras på den enklaste nivån. Utvecklare uppmuntras att informera om hur användarens personuppgifter kommer att tillämpas.

På så sätt ökar Apple transparensen kraftigt. Du behöver inte läsa hela texten i sekretesspolicyn för att förstå vilken information appen samlar in. Detta meddelas omedelbart. Och sedan måste användaren bestämma om de är villiga att fortsätta använda appen vid den här tiden eller inte. Eller så kan han / hon FRÅGA appen att inte spåra dem.

Men till exempel, låt oss överväga situationen med Safari Content Blockers. Apple ger användarverktygen för att skydda sig mot spårning. Med andra ord, när det gäller Safari är situationen som följer: en användare som inte vill spåras blockerar spårarna automatiskt. Och webbplatsen kan FRÅGA användaren om tillstånd att spåra dem eller visa dem annonser.

Vad är orsaken till en sådan avvikelse? Varför tror folket i Apple att det här är appanvändaren som borde “be om det” och inte tvärtom? Och varför kan inte Apple förse apputvecklare med verktyg som liknar Safari Content Blocking, och varför på jorden dämpar det utvecklingen av sina egna mekanismer (låt oss komma ihåg vad som hände med AdGuard Pro)?

Problemet är att Apple inte kan och inte planerar att testa utvecklarens integritet, och utan effektiv kontroll måste användarna ta det på förtroende och ta signaler endast från vad utvecklarna själva säger. I detta avseende är det möjligt att användaren riskerar att skapa ett falskt intryck av appen genom att lita på alla etiketter implicit.

Safari WebExtension stöd

macOS Big Sur introducerade nya funktioner i Safari. Det har nämligen lagt till stöd för plattforms-WebExtensions API som används av webbläsare Chrome, Firefox och Edge. Detta steg bör underlätta arbetet för utvecklare av webbläsartillägg som hanterar Safari och sedan distribuerar tillägg via Mac App Store. Det verkar som om Apple äntligen har insett att dess API begränsar sin egen plattform och att den inte drar nytta av denna metod.

På grund av dessa begränsningar har utvecklare alltid skapat tillägg för Chrome och Firefox först (där det var lättare att göra detta), och först sedan skapade de tillägg för Safari. Samma kan sägas om stöd. Tillägg för Chrome- och Firefox-webbläsarna uppdateras nästan alltid med förstprioritetsbasis. När allt kommer omkring är det ingen mening att spendera ett enormt försök att stödja Safari-webbläsaren, som bara rymmer 10 procent av marknaden.

När det gäller utvecklare av annons- och spårningsblockerare var deras rättigheter till Mac App Store redan kraftigt begränsade. Till skillnad från andra webbläsare tillhandahöll Apple sitt eget API för innehållsblockerare. Å ena sidan är det naturligtvis väldigt bra, men å andra sidan var Apples API inte lika flexibel som de som används av Firefox och Chrome. Och dessutom har det knappast utvecklats de senaste åren.

I iOS 14 implementeras stöd för WebExtensions API endast delvis. Inget användbart har förverkligats i den del som innehållsblockerare behöver. Till exempel finns det inga blockeringsförfrågningar med webRequest. Denna policy skapar ett problem med att utöka funktionaliteten för alla appar som skyddar integriteten.

Det kommer inte att ske några snabba förändringar

Sammanfattningsvis anger integritetsetiketter och WebExtensions API för Firefox och Chrome rätt utvecklingsriktning för Apple och ger hopp om en ljusare framtid för annonsblockerare. Det finns dock fortfarande en lång väg att gå och vi bör inte förvänta oss omedelbara förändringar eftersom:

    Det är inte klart hur etiketter kommer att implementeras när de är färdiga, eller om denna policy kommer att tillämpas. Återigen, vad gäller stöd för WebExtensions – inget helt nytt har införts för blockerare, så det är för tidigt att prata om ett korrekt API.

Utvecklare och användare förväntar sig att Apple tar en konsekvent inställning. Om företaget av någon anledning inte är redo / inte vill implementera integritetsskyddsverktyg själv, bör utvecklare åtminstone få ett API och möjlighet att göra det. Vi tror att detta är vad många andra Apple-utvecklare världen över väntar på.

Andrey Meshkov är en av grundarna och CTO för AdGuard ad blockerare. Han har arbetat inom IT i över 15 år och har samlat massor av erfarenhet inte bara inom sitt primära arbetsområde, utan också i relaterade sådana, som online-integritetsfrågor. Ibland blir uppmaningen att dela sina tankar för outhärdlig och han tar en paus från kodningen för att skriva en artikel eller två.

0 Shares