Vinster:
- Möjlighet att begära tillstånd med motivering, sammanhang och avvisningsscenario, med hjälp av principen om minsta privilegium
- Möjlighet att lagra känslig data krypterad med nyckelring/nyckellager, tillämpa dataminimering och kontrollera artificiell intelligenss tendens att lägga till för många behörigheter
- Möjlighet att hantera flödet av användardata till molnet eller artificiell intelligens som ett integritetsbeslut, erhålla användarens samtycke och använda säkerhetstekniker endast för auktoriserade, defensiva ändamål
Mobilapplikationen fungerar på användarens mest privata enhet: den känner till hans plats, kontakter, foton, hälsodata, mikrofon. Denna tillgång är stor makt, och makt innebär ansvar. Sekretess och säkerhet är inte en "tilläggsfunktion" i mobilutveckling, utan en princip invävd i arkitekturen från början; Detta kallas integritet by design. Dessutom är detta inte bara ett etiskt val, det är en laglig skyldighet (KVKK, GDPR) och butik (App Store, Google Play). I den här enheten kommer vi att lära oss hur vi begär behörigheter korrekt, bearbetar data säkert, använder AI som assistent inom detta område och skyddar oss från dess fällor. Det finns ytterligare en kritisk fråga i AI-sammanhang: användardata som går till AI-modeller (särskilt molnet) är ett integritetsbeslut i sig.
Konsten att be om lov: minsta privilegium
Grundprincipen för säkerhet är minsta privilegium (att inte begära fler privilegier än ett jobb kräver). Din app ska bara be om den tillstånd den verkligen behöver, vid den tidpunkt den behöver den. Om det inte finns någon kamerafunktion kommer kameratillstånd inte att begäras; Om platsen krävs endast när kartan är öppen, är behörigheten "medan du använder" tillräcklig, inte "alltid". Överdrivna behörigheter orsakar tredubbla skador: det undergräver användarnas förtroende, leder till att butiker avvisas och ökar risken för dataläckage.
Korrekt timing och förklaring av att fråga om lov är avgörande. Be användaren om tillåtelse i sammanhang och med motivering, till exempel "Kameraåtkomst krävs för att skanna ditt kvitto." iOS kräver den här beskrivningen i Info.plist; Tom eller vilseledande beskrivning är butiksavvisning.
Typ av behörighet
dåligt tillvägagångssätt
bra tillvägagångssätt
timing
Begär allt vid lanseringen
uppmaning när du använder funktionen
Omfattning
"Alltid plats"
"plats vid användning"
Beskrivning
Tom eller generisk
Konkret, specifik motivering
avslagsstatus
Appen kraschar/kraschar
Erbjuder gärna alternativ
Tips: Din app bör kunna fortsätta köras när behörighet nekas. Om användaren avvisar kameran, erbjuda ett "manuell inloggning"-alternativ. Införandet av "tillåt det annars fungerar inte appen" är både en dålig upplevelse och ett butiksproblem. Fråga alltid efter avvisningsscenariot när du skriver ut en behörighetskod till AI:n.
Samtycke och sekretesskod med AI: överväganden
AI genererar snabbt tillståndsbegärande kod, men den har två typiska fallgropar. Först, lägga till fler behörigheter än nödvändigt: plats, kontakter kan bulk lägga lagringsbehörigheter "för säkerhets skull". För det andra, hoppa över avvisningsscenariot: skriv bara statusen "tillåten" och ignorera avslaget. För varje tillstånd som genereras kommer du att få frågan "är detta verkligen nödvändigt?" och "vad händer om de avvisas?" Ställ dina frågor.
Varning: Exempelkoden som genereras av AI kan lagra användardata utan kryptering eller överföra den på ett osäkert sätt. Känsliga data (lösenord, hälsa, ekonomi) bör förvaras i säker lagring på enheten (Nyckelring — iOS, Keystore — Android; krypterad valvområde i operativsystemet) och överföras på nätverket via en krypterad anslutning (HTTPS/TLS). AI gör inte alltid detta spontant; Fråga tydligt och verifiera.
Dataminimering och skicka data till AI
Data du inte samlar in kan inte läcka. Dataminimering (att bara samla in den data som faktiskt behövs) är det mest kraftfulla verktyget för integritet. I AI-funktioner är den här principen dubbelt viktig: när du skickar data till en moln LLM eller extern AI-tjänst är den data utom din kontroll. Innan du skickar en användares hälsoanteckning, konversationsinnehåll eller personlig information till molnet, ställ tre frågor: (1) Är dessa uppgifter verkligen nödvändiga? (2) Kan det bearbetas på enheten? (3) Om det ska skickas, känner användaren till och godkänner det? Det är både ett juridiskt och etiskt krav att tydligt informera användaren om att deras data går till en AI-tjänst.
Säker användning och försvarsfokus
En varning ur ett IT- och säkerhetsperspektiv: teknikerna som lärs ut i denna modul är endast för auktoriserad och defensiv användning. Det är legitimt att testa säkerheten för din egen applikation, skydda användardata och åtgärda sårbarheter. Att omvända någon annans applikation utan tillstånd, samla in användardata utan samtycke eller använda AI för att skapa skadlig programvara är olagligt och oetiskt. När du ber AI om säkerhetshjälp, håll dig alltid inom ramen för att försvara ditt eget system.
tre minifodral
Fall 1 — Överskjutande avslag på ledighet. En anteckningsapplikation begärde kamera-, mikrofon-, plats- och kontaktbehörigheter vid start med koden producerad av AI. Google Play avvisade utgåvan med hänvisning till "funktionsirrelevanta behörigheter". Releasen godkändes när teamet bara släppte den lagringsbehörighet som faktiskt användes. Lärdom: varje extra ledighet är en risk.
Fall 2 — Lagring utan lösenord. En hälsoapp lagrade användarmätningar i en vanlig textfil som i AI-exemplet. En säkerhetsgranskning visade att alla som fick enheten kunde läsa all hälsodata. Data flyttas till krypterad lagring med nyckellager/nyckelring. Lärdom: känslig data förblir alltid krypterad.
Fall 3 — Oannonserad push to cloud. En app skickade användarnas dagliga anteckningar till ett moln LLM för att sammanfatta dem, men det berättade inte för användaren. När det rapporterades i pressen förlorades förtroendet och den juridiska granskningen. Teamet lade till ett tydligt meddelande och bekräftelse, samt ett alternativ på enheten. Lärdom: användaren måste veta och bekräfta att data går till AI.
Svag prompt / Stark prompt
Svag uppmaning: "Begär platstillstånd."
Kraftfull uppmaning: "Begär platsbehörighet på iOS/Swift med principen om minsta privilegium. - Endast 'when in use'-behörighet, inte 'always' - Info.plist-beskrivning: 'To show near-stores' - Om tillstånd nekas: erbjuda möjlighet att manuellt välja stad, krascha - Om behörighet har nekats tidigare, omdirigera till inställningar nekat flödet, skriv inte till fler behörigheter.
Kopierbara mallar
Mall för att begära tillstånd: "Begär [behörighetstyp]-behörighet för [plattform].- Minimalt omfattning (vid användning/efter behov)- I sammanhang, med motiverad förklaring- Artigt alternativ vid avslag, kraschar aldrig- Ge Info.plist / Manifest-post också Lägg inte till extra behörigheter; motivera varje behörighet."
Tillståndsgranskningsmall: "Kontrollera de behörigheter som min app begär: [behörighetslista + egenskaper]. För varje behörighet: behövs den verkligen? Skulle det räcka med en snävare omfattning? Skulle det leda till att butiken avvisas? Flagga onödigt."
Säker datalagringsmall: "Säker lagra känslig data ([typ]) för [plattform]:- Krypterad med Nyckelring/Keystore- Förvara inte i minnet under onödigt lång tid-Läck inte in i loggar och säkerhetskopior Ange kod och verifieringssteg."
Mall för att skicka data till AI: "Jag överväger att skicka följande data till en moln AI-tjänst: [data]. Utvärdera: är det verkligen nödvändigt? Kan det behandlas på enheten? Om det skickas, vilka fält ska maskeras? Hur ska användarens samtycke erhållas? Rekommendera den säkraste designen när det gäller integritet."
Vanliga misstag
- Be om mer tillstånd än nödvändigt. Trippel risk för förtroende, butiksgodkännande och säkerhet.
- Begär behörigheter i bulk vid start. En begäran om tillstånd utan sammanhang avslås; begär funktionen omedelbart.
- Skriver inte avslagsmanuset. Appen som kraschar när tillåtelsen nekas är både dålig och avvisad.
- Lagring av känslig data utan lösenord. Hälsa, ekonomi och lösenord ska förvaras i ett säkert förråd.
- Skickar data till molnet/AI utan att informera användaren. Rättslig och etisk kränkning; Anmälan och godkännande krävs.
- Otillåten användning av säkerhetstekniker. Det är bara legitimt för defensiva syften på ditt eget system.
Sammanfattningsvis
Sekretess och säkerhet är designad från början, inte tillagd senare. Grundprincipen är minsta privilegium: be bara om det nödvändiga tillståndet, när det är nödvändigt, med motivering, och erbjuda ett artigt alternativ i händelse av avslag. Känsliga data lagras i krypterad lagring och överförs via krypterad anslutning. Dataminimering är det starkaste skyddet: data du inte samlar in kan inte läcka. Att skicka data till AI, särskilt till molnet, är ett integritetsbeslut i sig; Dess nödvändighet ifrågasätts, om möjligt föredras on-device, användaren informeras och hans/hennes godkännande erhålls. Varje kod som produceras kontrolleras mot AI:s tendenser att lägga till överdrivna behörigheter och lagra osäkert. Säkerhetstekniker används endast för auktoriserade och defensiva ändamål.
Applikationsuppgift
Gör en lista över de behörigheter en applikation (ditt eget projekt eller imaginära) begär och låt AI kontrollera vilka som är onödiga eller överskridande med "Tillståndsgranskningsmall". Förfina eller ta bort minst en behörighet och skriv avslagsscenariot för den funktionen. Dessutom, om du skickar användardata till molnet, bestäm den säkraste designen med "Data sändande beslutsmall till AI" och skriv användarens godkännandetext.
checklista
- [ ] Jag begärde varje tillstånd med motivering, med principen om minsta privilegium.
- [ ] Jag bad om behörigheter i sammanhanget, vid inspelningstid, inte i bulk vid lansering
- [ ] Jag skrev ett avslagsskript för varje behörighet, inga krascher
- [ ] Jag lagrade känslig data krypterad med nyckelring/nyckellager
- [ ] Jag minimerade data som gick till molnet/AI och lade till användargodkännande
- [ ] Jag använde bara säkerhetstekniker på mitt eget system i defensiva syften