Jedinica 9 / 11

Privatnost, dopuštenja i sigurna upotreba

Dobici:

  • Mogućnost traženja dopuštenja s obrazloženjem, kontekstom i scenarijem odbijanja, korištenjem načela najmanje privilegije
  • Sposobnost pohranjivanja osjetljivih podataka šifriranih s Keychain/Keystore, primjene minimizacije podataka i kontrole sklonosti umjetne inteligencije da doda previše dopuštenja
  • Sposobnost upravljanja protokom korisničkih podataka u oblaku ili usluzi umjetne inteligencije kao odluka o privatnosti, dobivanje pristanka korisnika i korištenje sigurnosnih tehnika samo u ovlaštene, obrambene svrhe

Mobilna aplikacija radi na najprivatnijem uređaju korisnika: zna njegovu lokaciju, kontakte, fotografije, zdravstvene podatke, mikrofon. Ovaj pristup je velika moć, a moć znači odgovornost. Privatnost i sigurnost nisu "dodatna značajka" u mobilnom razvoju, već načelo utkano u arhitekturu od početka; To se zove privatnost prema dizajnu. Štoviše, ovo nije samo etički izbor, to je zakonska (KVKK, GDPR) i obveza trgovine (App Store, Google Play). U ovoj jedinici naučit ćemo kako ispravno zatražiti dopuštenja, sigurno obrađivati ​​podatke, koristiti AI kao pomoćnika u ovom polju i zaštititi se od njegovih zamki. Postoji dodatno kritično pitanje u kontekstu umjetne inteligencije: korisnički podaci koji idu u modele umjetne inteligencije (osobito u oblak) sami su po sebi odluka o privatnosti.

Umijeće traženja dopuštenja: najmanja privilegija

Osnovno načelo sigurnosti je najmanja privilegija (ne tražiti više privilegija nego što posao zahtijeva). Vaša bi aplikacija trebala tražiti samo ono dopuštenje koje joj je stvarno potrebno, u trenutku kada je potrebno. Ako nema značajke kamere, dopuštenje kamere neće biti zatraženo; Ako je lokacija potrebna samo kada je karta otvorena, dovoljna je dozvola "dok se koristi", a ne "uvijek". Pretjerana dopuštenja uzrokuju trostruku štetu: potkopavaju povjerenje korisnika, dovode do odbijanja pohrane i povećavaju rizik od curenja podataka.

Pravilno vrijeme i objašnjenje traženja dopuštenja su ključni. Pitajte korisnika za dopuštenje u kontekstu i s obrazloženjem, kao što je "Potreban je pristup kameri za skeniranje vašeg računa." iOS zahtijeva ovaj opis u Info.plist; Prazan ili pogrešan opis je odbijanje trgovine.

Vrsta dopuštenja

loš pristup

dobar pristup

vrijeme

Zatražite sve pri pokretanju

upit prilikom korištenja značajke

Opseg

"Uvijek lokacija"

"lokacija tijekom korištenja"

Opis

Prazan ili generički

Konkretno, konkretno obrazloženje

status odbijanja

Aplikacija pada/pada

Ljubazno nudi alternative

Savjet: vaša bi aplikacija trebala moći nastaviti s radom kada je dopuštenje odbijeno. Ako korisnik odbije kameru, ponudite opciju "ručna prijava". Nametanje "dopusti ili aplikacija neće raditi" je i loše iskustvo i problem trgovine. Uvijek tražite scenarij odbijanja kada ispisujete kod dopuštenja AI-u.

Kodeks pristanka i privatnosti s umjetnom inteligencijom: razmatranja

AI brzo generira kod za traženje dopuštenja, ali ima dvije tipične zamke. Prvo, dodavanje više dopuštenja nego što je potrebno: ​​lokacija, kontakti mogu skupno staviti dopuštenja za pohranu "za svaki slučaj". Drugo, preskakanje scenarija odbijanja: samo napišite status "dopušteno" i zanemarite odbijanje. Za svaku generiranu dozvolu bit ćete upitani "je li ovo stvarno potrebno?" i "što se događa ako se odbije?" Postavite svoja pitanja.

Oprez: Uzorak koda koji generira AI može pohraniti korisničke podatke bez enkripcije ili ih nesigurno prenositi. Osjetljive podatke (lozinka, zdravlje, financije) treba čuvati u sigurnoj pohrani na uređaju (Keychain — iOS, Keystore — Android; šifrirano područje trezora operativnog sustava) i prenositi ih mrežom putem šifrirane veze (HTTPS/TLS). AI to ne radi uvijek spontano; Jasno pitajte i potvrdite.

Minimizacija podataka i slanje podataka AI

Podaci koje ne prikupite ne mogu procuriti. Minimizacija podataka (prikupljanje samo onih podataka koji su stvarno potrebni) je najmoćniji alat za privatnost. U značajkama umjetne inteligencije ovo je načelo dvostruko važno: kada šaljete podatke u LLM u oblaku ili vanjsku uslugu umjetne inteligencije, ti su podaci izvan vaše kontrole. Prije slanja korisničke zdravstvene obavijesti, sadržaja razgovora ili osobnih podataka u oblak, postavite tri pitanja: (1) Jesu li ti podaci stvarno potrebni? (2) Može li se obraditi na uređaju? (3) Ako se šalje, da li korisnik to zna i odobrava? Jasno obavijestiti korisnika da njegovi podaci idu u uslugu umjetne inteligencije zakonski je i etički zahtjev.

Sigurna uporaba i obrambeni fokus

Upozorenje iz informatičke i sigurnosne perspektive: tehnike koje se uče u ovom modulu samo su za ovlaštenu i obrambenu upotrebu. Legitimno je testirati sigurnost vlastite aplikacije, zaštititi korisničke podatke i zatvoriti ranjivosti. Obrnuti inženjering tuđe aplikacije bez dopuštenja, prikupljanje korisničkih podataka bez pristanka ili korištenje umjetne inteligencije za stvaranje zlonamjernog softvera nezakonito je i neetično. Kada tražite AI za sigurnosnu pomoć, uvijek ostanite unutar okvira obrane vlastitog sustava.

tri mini kućišta

Slučaj 1 — Pretjerano odbijanje dopusta. Aplikacija za bilješke tražila je dozvole za kameru, mikrofon, lokaciju i kontakt pri pokretanju s kodom koji je izradio AI. Google Play odbacio je izdanje, navodeći "dozvole koje nisu relevantne za funkciju". Izdanje je odobreno kada je tim izdao samo dozvolu za pohranu koja je stvarno korištena. Pouka: svaki dodatni dopust je rizik.

Slučaj 2 — Pohrana bez lozinke. Zdravstvena aplikacija pohranjuje korisnička mjerenja u običnoj tekstualnoj datoteci kao u AI primjeru. Sigurnosna revizija otkrila je da svatko tko nabavi uređaj može pročitati sve zdravstvene podatke. Podaci premješteni u šifriranu pohranu pomoću Keystorea/Keychaina. Lekcija: osjetljivi podaci uvijek ostaju šifrirani.

Slučaj 3 — Nenajavljeno slanje u oblak. Aplikacija je slala dnevne bilješke korisnika LLM-u u oblaku da ih sažme, ali nije rekla korisniku. Kad je to objavljeno u tisku, došlo je do gubitka povjerenja i pravne kontrole. Tim je dodao jasnu obavijest i potvrdu, kao i opciju na uređaju. Lekcija: korisnik mora znati i potvrditi da podaci idu u AI.

Slab upit / Jak upit

Slab upit: "Zatraži dopuštenje za lokaciju."

Snažan upit: "Zahtjev za dopuštenje lokacije na iOS-u/Swiftu s načelom najmanje privilegije. - Dopuštenje samo 'kada je u upotrebi', ne 'uvijek' - Opis Info.plist: 'Za prikaz obližnjih trgovina' - Ako je dopuštenje odbijeno: ponudi opciju za ručni odabir grada, rušenje - Ako je dopuštenje prije bilo odbijeno, preusmjerite na postavke Nemojte dodavati više dopuštenja nego što je potrebno. Napišite i tijek odbijanja."

Predlošci koji se mogu kopirati

Predložak za traženje dopuštenja: "Zahtjev [vrsta dopuštenja] dopuštenje za [platformu]. - Minimalni opseg (kada se koristi/po potrebi) - U kontekstu, s obrazloženim objašnjenjem - Pristojna alternativa u slučaju odbijanja, nikada se ne sruši - Dajte Info.plist / Manifest unos također Nemojte dodavati dodatna dopuštenja; opravdajte svako dopuštenje."

Predložak revizije dopuštenja: "Provjerite dopuštenja koja moja aplikacija zahtijeva: [popis dopuštenja + svojstva]. Za svako dopuštenje: je li stvarno potrebno? Bi li uži opseg bio dovoljan? Bi li to dovelo do odbijanja trgovine? Označite nepotrebno."

Predložak za sigurno pohranjivanje podataka: "Sigurno pohranjujte osjetljive podatke ([vrsta]) za [platformu]: - Šifrirano s Keychain/Keystore - Nemojte držati u memoriji nepotrebno dugo - Nemojte curiti u zapisnike i sigurnosne kopije Navedite kod i korake za provjeru."

Predložak za slanje podataka u AI: "Razmišljam o slanju sljedećih podataka u uslugu AI u oblaku: [podaci]. Procijenite: jesu li stvarno potrebni? Mogu li se obraditi na uređaju? Ako se pošalju, koja polja treba maskirati? Kako treba dobiti pristanak korisnika? Preporučite najsigurniji dizajn u smislu privatnosti."

Uobičajene greške

  • Traži više dopuštenja nego što je potrebno. Trostruka opasnost za povjerenje, odobrenje trgovine i sigurnost.
  • Skupno traženje dozvola pri pokretanju. Zahtjev za dopuštenjem bez konteksta je odbijen; odmah zatražite značajku.
  • Ne pisanje scenarija odbijanja. Aplikacija koja se ruši kada je dopuštenje odbijeno je i loša i odbijena.
  • Pohranjivanje osjetljivih podataka bez lozinke. Zdravlje, financije i lozinke moraju se čuvati u sigurnoj pohrani.
  • Slanje podataka u oblak/AI bez obavještavanja korisnika. Pravno i etičko kršenje; Potrebna je obavijest i odobrenje.
  • Neovlaštena uporaba sigurnosnih tehnika. To je legitimno samo u obrambene svrhe na vašem vlastitom sustavu.

Ukratko

Privatnost i sigurnost osmišljene su od početka, nisu dodane kasnije. Osnovno načelo je najmanja privilegija: tražiti samo potrebno dopuštenje, kada je potrebno, uz obrazloženje, i ponuditi uljudnu alternativu u slučaju odbijanja. Osjetljivi podaci pohranjuju se u kriptiranoj pohrani i prenose putem kriptirane veze. Minimizacija podataka je najjača zaštita: podaci koje ne prikupite ne mogu procuriti. Slanje podataka umjetnoj inteligenciji, posebno u oblak, sama je po sebi odluka o privatnosti; Propituje se njegova nužnost, ako je moguće, preferira se on-uređaj, korisnik se informira i dobiva njegovo/njezino odobrenje. Svaki proizvedeni kod provjerava se protiv sklonosti umjetne inteligencije da doda prekomjerna dopuštenja i nesigurno pohranjuje. Sigurnosne tehnike koriste se samo u ovlaštene i obrambene svrhe.

Zadatak aplikacije

Napravite popis dozvola koje aplikacija (vaš vlastiti projekt ili imaginarna) zahtijeva i neka AI provjeri koje su nepotrebne ili pretjerane pomoću "Predloška revizije dozvola". Pročistite ili uklonite barem jedno dopuštenje i napišite scenarij odbijanja za tu značajku. Osim toga, ako šaljete korisničke podatke u oblak, odredite najsigurniji dizajn s "Predloškom odluke o slanju podataka AI-ju" i napišite tekst odobrenja korisnika.

popis za provjeru

  • [ ] Svaku sam dozvolu tražio s obrazloženjem, s načelom najmanje privilegije.
  • [ ] Tražio sam dopuštenja u kontekstu, u vrijeme značajke, a ne skupno pri pokretanju
  • [ ] Napisao sam skriptu odbijanja za svaku dozvolu, nema rušenja
  • [ ] Pohranio sam osjetljive podatke šifrirane pomoću Keychaina/Keystorea
  • [ ] Minimizirao sam podatke koji idu u oblak/AI i dodao odobrenje korisnika
  • [ ] Koristio sam sigurnosne tehnike samo na vlastitom sustavu u obrambene svrhe