Gevinster:
- Evne til at anmode om tilladelser med begrundelse, kontekst og afvisningsscenarie ved at bruge princippet om mindste privilegium
- Evne til at gemme følsomme data krypteret med Nøglering/Nøglelager, anvende dataminimering og kontrollere kunstig intelligenss tendens til at tilføje for mange tilladelser
- Evne til at styre strømmen af brugerdata til skyen eller kunstig intelligens-tjenesten som en privatlivsbeslutning, indhente brugerens samtykke og kun bruge sikkerhedsteknikker til autoriserede, defensive formål
Mobilapplikationen fungerer på brugerens mest private enhed: den kender hans placering, kontakter, fotos, sundhedsdata, mikrofon. Denne adgang er stor magt, og magt betyder ansvar. Privatliv og sikkerhed er ikke en "add-on feature" i mobiludvikling, men et princip indvævet i arkitekturen fra begyndelsen; Dette kaldes privacy by design. Desuden er dette ikke kun et etisk valg, det er en juridisk (KVKK, GDPR) og butiks (App Store, Google Play) forpligtelse. I denne enhed lærer vi, hvordan vi anmoder om tilladelser korrekt, behandler data sikkert, bruger AI som assistent på dette felt og beskytter os selv mod dets fælder. Der er et yderligere kritisk problem i AI-konteksten: brugerdata, der går til AI-modeller (især skyen) er en privatlivsbeslutning i sig selv.
Kunsten at bede om tilladelse: mindste privilegium
Det grundlæggende princip for sikkerhed er mindste privilegium (ikke at bede om flere privilegier, end et job kræver). Din app bør kun bede om den tilladelse, den virkelig har brug for, på det tidspunkt, den har brug for det. Hvis der ikke er nogen kamerafunktion, vil der ikke blive anmodet om kameratilladelse; Hvis placeringen kun er påkrævet, når kortet er åbent, er tilladelsen "mens du bruger" tilstrækkelig, ikke "altid". Overdrevne tilladelser forårsager tredobbelt skade: det underminerer brugernes tillid, fører til butiksafvisning og forstørrer risikoen for datalækage.
Korrekt timing og forklaring på at bede om tilladelse er afgørende. Spørg brugeren om tilladelse i kontekst og med begrundelse, såsom "Kameraadgang er påkrævet for at scanne din kvittering." iOS kræver denne beskrivelse i Info.plist; Tom eller vildledende beskrivelse er butiksafvisning.
Tilladelsestype
dårlig tilgang
god tilgang
timing
Anmod om alt ved lanceringen
prompt, når du bruger funktionen
Omfang
"Altid placering"
"placering under brug"
Beskrivelse
Blank eller generisk
Konkret, specifik begrundelse
afvisningsstatus
App går ned/nedbrud
Tilbyder gerne alternativer
Tip: Din app skal kunne fortsætte med at køre, når tilladelse nægtes. Hvis brugeren afviser kameraet, skal du tilbyde en "manuel login" mulighed. Indførelsen af "tillad det, ellers virker appen ikke" er både en dårlig oplevelse og et butiksproblem. Bed altid om afvisningsscenariet, når du udskriver en tilladelseskode til AI.
Samtykke og privatlivskode med AI: overvejelser
AI genererer hurtigt kode, der anmoder om tilladelse, men den har to typiske faldgruber. For det første, tilføjelse af flere tilladelser end nødvendigt: placering, kontakter kan masseudsætte lagringstilladelser "for en sikkerheds skyld". For det andet, spring afvisningsscenariet over: skriv blot status "tilladt" og ignorer afvisningen. For hver genereret tilladelse vil du blive spurgt "er det virkelig nødvendigt?" og "hvad sker der, hvis det bliver afvist?" Stil dine spørgsmål.
Forsigtig: Eksempelkoden genereret af AI kan gemme brugerdata uden kryptering eller overføre dem på en usikker måde. Følsomme data (adgangskode, sundhed, økonomi) skal opbevares sikkert på enheden (Nøglering — iOS, Keystore — Android; krypteret hvælvingsområde i operativsystemet) og transmitteres på netværket via en krypteret forbindelse (HTTPS/TLS). AI gør ikke altid dette spontant; Spørg tydeligt og bekræft.
Dataminimering og afsendelse af data til AI
Data, du ikke indsamler, kan ikke lække. Dataminimering (kun indsamler de data, der faktisk er nødvendige) er det mest kraftfulde værktøj til privatliv. I AI-funktioner er dette princip dobbelt vigtigt: Når du sender data til en cloud LLM eller ekstern AI-tjeneste, er disse data uden for din kontrol. Før du sender en brugers helbredsnotat, samtaleindhold eller personlige oplysninger til skyen, skal du stille tre spørgsmål: (1) Er disse data virkelig nødvendige? (2) Kan det behandles på enheden? (3) Hvis det skal sendes, kender og godkender brugeren det så? Det er både et juridisk og etisk krav klart at informere brugeren om, at deres data går til en AI-tjeneste.
Sikker brug og forsvarsfokus
En advarsel fra et IT- og sikkerhedsperspektiv: Teknikkerne lært i dette modul er kun til autoriseret og defensiv brug. Det er legitimt at teste sikkerheden af din egen applikation, beskytte brugerdata og lukke sårbarheder. Reverse engineering af en andens applikation uden tilladelse, indsamling af brugerdata uden samtykke eller brug af AI til at skabe malware er ulovligt og uetisk. Når du beder AI om sikkerhedshjælp, skal du altid holde dig inden for rammerne af at forsvare dit eget system.
tre minisager
Tilfælde 1 — Overdreven orlovsnægtelse. En noteapplikation anmodede om kamera-, mikrofon-, placerings- og kontakttilladelser ved opstart med koden produceret af AI. Google Play afviste udgivelsen med henvisning til "funktionsirrelevante tilladelser". Udgivelsen blev godkendt, da teamet kun frigav den lagertilladelse, der faktisk blev brugt. Lektion: hver ekstra orlov er en risiko.
Tilfælde 2 — Opbevaring uden adgangskode. En sundhedsapp gemte brugermålinger i en almindelig tekstfil som i AI-eksemplet. En sikkerhedsrevision fandt ud af, at alle, der anskaffede enheden, kunne læse alle sundhedsdata. Data flyttet til krypteret lager med nøglelager/nøglering. Lektion: følsomme data forbliver altid krypteret.
Case 3 — Uanmeldt push to cloud. En app sendte brugernes daglige noter til en cloud LLM for at opsummere dem, men den fortalte det ikke brugeren. Da det blev omtalt i pressen, var der et tab af tillid og juridisk kontrol. Holdet tilføjede en klar notifikation og bekræftelse samt en mulighed på enheden. Lektion: Brugeren skal vide og bekræfte, at dataene går til AI.
Svag prompt / Stærk prompt
Svag prompt: "Anmod om placeringstilladelse."
Kraftig prompt: "Anmod om placeringstilladelse på iOS/Swift med princippet om mindste privilegium. - Kun 'når i brug' tilladelse, ikke 'altid' - Info.plist beskrivelse: 'For at vise butikker i nærheden' - Hvis tilladelse nægtes: tilbyde mulighed for manuelt at vælge by, gå ned - Hvis tilladelsen er blevet nægtet før, omdiriger til indstillingerne nægtelse, så skriv ikke mere tilladelse.
Kopierbare skabeloner
Skabelon til at anmode om tilladelse: "Anmod om [tilladelsestype] tilladelse til [platform].- Minimalt omfang (ved brug/efter behov)- I kontekst, med begrundet forklaring- Høfligt alternativ i tilfælde af afvisning, aldrig crash- Giv Info.plist / Manifest-indtastning også. Tilføj ikke ekstra tilladelser; begrund hver tilladelse."
Tilladelsesauditskabelon: "Tjek de tilladelser, som min app anmoder om: [tilladelsesliste + egenskaber]. For hver tilladelse: er det virkelig nødvendigt? Ville et snævrere omfang være nok? Ville det føre til afvisning af butik? Markering unødvendig."
Sikker datalagringsskabelon: "Sikker opbevaring af følsomme data ([type]) for [platform]:- Krypteret med nøglering/nøglelager- Må ikke opbevares i hukommelsen i unødvendigt lang tid- Må ikke lække ind i logfiler og sikkerhedskopier Angiv kode og verifikationstrin."
Skabelon til afsendelse af data til AI: "Jeg overvejer at sende følgende data til en cloud AI-tjeneste: [data]. Evaluer: er det virkelig nødvendigt? Kan det behandles på enheden? Hvis det sendes, hvilke felter skal maskeres? Hvordan skal brugerens samtykke indhentes? Anbefal det mest sikre design i forhold til privatlivets fred."
Almindelige fejl
- Beder om mere tilladelse end nødvendigt. Tredobbelt fare for tillid, butiksgodkendelse og sikkerhed.
- Anmoder om tilladelser i bulk ved opstart. En anmodning om tilladelse uden kontekst afvises; anmod om funktionen med det samme.
- Ikke at skrive afvisningsmanuskriptet. Appen, der går ned, når tilladelsen nægtes, er både dårlig og afvist.
- Lagring af følsomme data uden adgangskode. Sundhed, økonomi og adgangskoder skal opbevares på et sikkert lager.
- Sender data til skyen/AI uden at informere brugeren. Lovlig og etisk krænkelse; Anmeldelse og godkendelse er påkrævet.
- Uautoriseret brug af sikkerhedsteknikker. Det er kun legitimt til defensive formål på dit eget system.
Sammenfattende
Privatliv og sikkerhed er designet fra begyndelsen, ikke tilføjet senere. Grundprincippet er mindste privilegium: Spørg kun om den nødvendige tilladelse, når det er nødvendigt, med begrundelse, og giv et høfligt alternativ i tilfælde af afslag. Følsomme data gemmes i krypteret lager og transmitteres via krypteret forbindelse. Dataminimering er den stærkeste beskyttelse: data, du ikke indsamler, kan ikke lække. At sende data til AI, især til skyen, er en privatlivsbeslutning i sig selv; Der sættes spørgsmålstegn ved dets nødvendighed, hvis det er muligt, foretrækkes on-device, brugeren informeres og hans/hendes godkendelse opnås. Hver produceret kode kontrolleres mod AI's tendenser til at tilføje overdrevne tilladelser og opbevare usikkert. Sikkerhedsteknikker bruges kun til autoriserede og defensive formål.
Ansøgningsopgave
Lav en liste over de tilladelser, som en applikation (dit eget projekt eller imaginære) anmoder om, og få AI til at tjekke, hvilke der er unødvendige eller overskrider med "Tilladelsesauditskabelonen". Forfin eller fjern mindst én tilladelse, og skriv afvisningsscenariet for den funktion. Derudover, hvis du sender brugerdata til skyen, skal du bestemme det mest sikre design med "Data-afsendelsesbeslutningsskabelonen til AI" og skrive brugergodkendelsesteksten.
tjekliste
- [ ] Jeg anmodede om hver tilladelse med begrundelse, med princippet om mindste privilegium.
- [ ] Jeg bad om tilladelser i kontekst, på spilletidspunktet, ikke bulk ved lanceringen
- [ ] Jeg skrev et afvisningsscript for hver tilladelse, ingen nedbrud
- [ ] Jeg gemte følsomme data krypteret med Nøglering/Nøglelager
- [ ] Jeg minimerede de data, der gik til skyen/AI og tilføjede brugergodkendelse
- [ ] Jeg brugte kun sikkerhedsteknikker på mit eget system til defensive formål