Gevinster:
- Evne til å be om tillatelser med begrunnelse, kontekst og avvisningsscenario, ved å bruke prinsippet om minste privilegium
- Evne til å lagre sensitive data kryptert med nøkkelring/nøkkellager, bruke dataminimering og kontrollere tendensen til kunstig intelligens til å legge til for mange tillatelser
- Evne til å administrere flyten av brukerdata til skyen eller kunstig intelligens-tjenesten som en personvernbeslutning, innhente brukersamtykke og bruke sikkerhetsteknikker kun for autoriserte, defensive formål
Mobilapplikasjonen fungerer på brukerens mest private enhet: den kjenner posisjonen hans, kontakter, bilder, helsedata, mikrofon. Denne tilgangen er stor makt, og makt betyr ansvar. Personvern og sikkerhet er ikke en "tilleggsfunksjon" i mobilutvikling, men et prinsipp vevd inn i arkitekturen fra begynnelsen; Dette kalles privacy by design. Dessuten er dette ikke bare et etisk valg, det er en juridisk (KVKK, GDPR) og butikk (App Store, Google Play) forpliktelse. I denne enheten lærer vi hvordan vi ber om tillatelser på riktig måte, behandler data på en sikker måte, bruker AI som assistent på dette feltet og beskytter oss mot fellene. Det er et ekstra kritisk problem i AI-konteksten: brukerdata som går til AI-modeller (spesielt skyen) er en personvernbeslutning i seg selv.
Kunsten å be om tillatelse: minst privilegium
Grunnprinsippet for sikkerhet er minst privilegium (ikke å be om flere privilegier enn en jobb krever). Appen din bør bare be om tillatelsen den virkelig trenger, på det tidspunktet den trenger den. Hvis det ikke er noen kamerafunksjon, vil ikke kameratillatelse bli bedt om; Hvis posisjonen bare kreves når kartet er åpent, er tillatelsen "mens du bruker" tilstrekkelig, ikke "alltid". Overdrevne tillatelser forårsaker trippel skade: det undergraver brukertilliten, fører til butikkavvisning og forstørrer risikoen for datalekkasje.
Riktig timing og forklaring av å be om tillatelse er kritisk. Spør brukeren om tillatelse i kontekst og med begrunnelse, for eksempel "Kameratilgang kreves for å skanne kvitteringen." iOS krever denne beskrivelsen i Info.plist; Tom eller misvisende beskrivelse er butikkavvisning.
Tillatelsestype
dårlig tilnærming
god tilnærming
timing
Be om alt ved lansering
ledetekst når du bruker funksjonen
Omfang
"Alltid plassering"
"plassering mens du bruker"
Beskrivelse
Blank eller generisk
Konkret, konkret begrunnelse
avvisningsstatus
Appen krasjer/krasjer
Tilbyr gjerne alternativer
Tips: Appen din skal kunne fortsette å kjøre når tillatelse nektes. Hvis brukeren avviser kameraet, tilby et "manuell pålogging"-alternativ. Pålegget "tillat det ellers vil appen ikke fungere" er både en dårlig opplevelse og et butikkproblem. Spør alltid om avvisningsscenariet når du skriver ut en tillatelseskode til AI.
Samtykke og personvernkode med AI: hensyn
AI genererer raskt kode som ber om tillatelse, men den har to typiske fallgruver. Først, å legge til flere tillatelser enn nødvendig: plassering, kontakter kan bulk legge lagringstillatelser "bare i tilfelle". For det andre, hoppe over avvisningsscenariet: bare skriv statusen "tillatt" og ignorer avslaget. For hver tillatelse som genereres vil du bli spurt "er dette virkelig nødvendig?" og "hva skjer hvis de blir avvist?" Still spørsmålene dine.
Forsiktig: Eksempelkoden generert av AI kan lagre brukerdata uten kryptering eller overføre dem på en usikker måte. Sensitive data (passord, helse, økonomi) bør oppbevares i sikker lagring på enheten (nøkkelring — iOS, nøkkellager — Android; kryptert hvelvområde i operativsystemet) og overføres på nettverket via en kryptert tilkobling (HTTPS/TLS). AI gjør ikke alltid dette spontant; Spør tydelig og bekreft.
Dataminimering og sending av data til AI
Data du ikke samler inn kan ikke lekke. Dataminimering (samler kun data som faktisk er nødvendig) er det kraftigste verktøyet for personvern. I AI-funksjoner er dette prinsippet dobbelt viktig: når du sender data til en cloud LLM eller ekstern AI-tjeneste, er disse dataene utenfor din kontroll. Still tre spørsmål før du sender en brukers helsenotat, samtaleinnhold eller personlig informasjon til skyen: (1) Er disse dataene virkelig nødvendige? (2) Kan det behandles på enheten? (3) Hvis den skal sendes, vet og godkjenner brukeren den? Det er både et juridisk og etisk krav å tydelig informere brukeren om at dataene deres går til en AI-tjeneste.
Trygg bruk og forsvarsfokus
En advarsel fra et IT- og sikkerhetsperspektiv: teknikkene som er lært i denne modulen er kun for autorisert og defensiv bruk. Det er legitimt å teste sikkerheten til din egen applikasjon, beskytte brukerdata og lukke sårbarheter. Omvendt utvikling av andres applikasjon uten tillatelse, innsamling av brukerdata uten samtykke eller bruk av kunstig intelligens for å lage skadevare er ulovlig og uetisk. Når du ber AI om sikkerhetshjelp, hold deg alltid innenfor rammen av å forsvare ditt eget system.
tre minisaker
Sak 1 - Overskytende permisjonsnektelse. En notatapplikasjon ba om kamera-, mikrofon-, plasserings- og kontakttillatelser ved oppstart med koden produsert av AI. Google Play avviste utgivelsen med henvisning til "funksjonsirrelevante tillatelser". Utgivelsen ble godkjent da teamet bare ga ut lagringstillatelsen som faktisk ble brukt. Leksjon: hver ekstra permisjon er en risiko.
Tilfelle 2 — Lagring uten passord. En helseapp lagret brukermålinger i en ren tekstfil som i AI-eksemplet. En sikkerhetsrevisjon fant at alle som fikk tak i enheten kunne lese alle helsedata. Data flyttet til kryptert lagring med nøkkellager/nøkkelring. Leksjon: sensitive data forblir alltid kryptert.
Tilfelle 3 – Uanmeldt push to cloud. En app sendte brukernes daglige notater til en cloud LLM for å oppsummere dem, men den fortalte ikke brukeren det. Da det ble omtalt i pressen, var det tap av tillit og juridisk gransking. Teamet la til et tydelig varsel og bekreftelse, samt et alternativ på enheten. Leksjon: brukeren må vite og bekrefte at dataene går til AI.
Svak forespørsel / Sterk forespørsel
Svak melding: "Be om plasseringstillatelse."
Kraftig ledetekst: "Be om plasseringstillatelse på iOS/Swift med prinsippet om minste privilegium. - Bare 'når i bruk'-tillatelse, ikke 'alltid' - Info.plist-beskrivelse: 'For å vise butikker i nærheten' - Hvis tillatelse nektes: tilby mulighet for å manuelt velge by, krasj - Hvis tillatelse har blitt nektet før, omdiriger til innstillinger avslå flyten, ikke legg til flere tillatelser.
Kopierbare maler
Mal for forespørsel om tillatelse: "Be om [tillatelsestype] tillatelse for [plattform].- Minimalt omfang (ved bruk/etter behov)- I kontekst, med begrunnet forklaring- Høflig alternativ i tilfelle avvisning, aldri krasj- Gi Info.plist / Manifest-oppføring også Ikke legg til ekstra tillatelser; begrunn hver tillatelse."
Tillatelsesrevisjonsmal: "Sjekk tillatelsene appen min ber om: [tillatelsesliste + egenskaper]. For hver tillatelse: er det virkelig nødvendig? Ville et smalere omfang være nok? Vil det føre til avvisning av butikk? Flagg unødvendig."
Sikker datalagringsmal: "Sikker lagring av sensitive data ([type]) for [plattform]:- Kryptert med nøkkelring/nøkkellager- Ikke oppbevar i minnet i unødvendig lang tid- Ikke lekk inn i logger og sikkerhetskopier. Gi kode og bekreftelsestrinn."
Mal for å sende data til AI: "Jeg vurderer å sende følgende data til en sky-AI-tjeneste: [data]. Vurder: er det virkelig nødvendig? Kan det behandles på enheten? Hvilke felt skal maskeres hvis de sendes? Hvordan skal brukerens samtykke innhentes? Anbefal den sikreste utformingen med tanke på personvern."
Vanlige feil
- Ber om mer tillatelse enn nødvendig. Trippel fare for tillit, butikkgodkjenning og sikkerhet.
- Ber om tillatelser i bulk ved oppstart. En forespørsel om tillatelse uten kontekst avvises; be om funksjonen umiddelbart.
- Skriver ikke avslagsmanuset. Appen som krasjer når tillatelsen nektes, er både dårlig og avvist.
- Lagring av sensitive data uten passord. Helse, økonomi og passord skal oppbevares på en sikker lagring.
- Sender data til skyen/AI uten å informere brukeren. Lovlig og etisk brudd; Melding og godkjenning kreves.
- Uautorisert bruk av sikkerhetsteknikker. Det er kun legitimt for defensive formål på ditt eget system.
Oppsummert
Personvern og sikkerhet er designet fra begynnelsen, ikke lagt til senere. Grunnprinsippet er minste privilegium: be bare om nødvendig tillatelse, når det er nødvendig, med begrunnelse, og tilby et høflig alternativ i tilfelle avslag. Sensitive data lagres i kryptert lagring og overføres via kryptert tilkobling. Dataminimering er den sterkeste beskyttelsen: data du ikke samler inn, kan ikke lekke. Å sende data til AI, spesielt til skyen, er en personvernbeslutning i seg selv; Det stilles spørsmål ved nødvendigheten av det, hvis mulig, på enheten foretrekkes, brukeren blir informert og hans/hennes godkjenning er innhentet. Hver kode som produseres blir sjekket mot AIs tendenser til å legge til overdrevne tillatelser og lagre usikkert. Sikkerhetsteknikker brukes kun til autoriserte og defensive formål.
Søknadsoppgave
Lag en liste over tillatelsene en applikasjon (ditt eget prosjekt eller imaginære) ber om, og få AI til å sjekke hvilke som er unødvendige eller overskridende med "Tillatelsesrevisjonsmalen". Avgrens eller fjern minst én tillatelse og skriv avslagsscenarioet for den funksjonen. I tillegg, hvis du sender brukerdata til skyen, bestemmer du det sikreste designet med "Beslutningsmal for datasending til AI" og skriv brukergodkjenningsteksten.
sjekkliste
- [ ] Jeg ba om hver tillatelse med begrunnelse, med prinsippet om minste privilegium.
- [ ] Jeg ba om tillatelser i kontekst, på spilletidspunktet, ikke massevis ved lansering
- [ ] Jeg skrev et avvisningsskript for hver tillatelse, ingen krasj
- [ ] Jeg lagret sensitive data kryptert med nøkkelring/nøkkellager
- [ ] Jeg minimerte dataene som gikk til skyen/AI og la til brukergodkjenning
- [ ] Jeg brukte sikkerhetsteknikker kun på mitt eget system for defensive formål