Fitimet:
- Aftësia për të kërkuar leje me arsyetim, kontekst dhe skenar refuzimi, duke përdorur parimin e privilegjit më të vogël
- Aftësia për të ruajtur të dhëna të ndjeshme të koduara me Keychain/Keystore, për të aplikuar minimizimin e të dhënave dhe për të kontrolluar tendencën e inteligjencës artificiale për të shtuar shumë leje
- Aftësia për të menaxhuar rrjedhën e të dhënave të përdoruesit në cloud ose shërbimin e inteligjencës artificiale si një vendim privatësie, për të marrë pëlqimin e përdoruesit dhe për të përdorur teknikat e sigurisë vetëm për qëllime të autorizuara dhe mbrojtëse
Aplikacioni celular funksionon në pajisjen më private të përdoruesit: ai njeh vendndodhjen e tij, kontaktet, fotot, të dhënat shëndetësore, mikrofonin. Kjo qasje është fuqi e madhe, dhe fuqia do të thotë përgjegjësi. Privatësia dhe siguria nuk janë një "tipar shtesë" në zhvillimin e celularëve, por një parim i gërshetuar në arkitekturë që në fillim; Kjo quhet privatësi sipas dizajnit. Për më tepër, kjo nuk është vetëm një zgjedhje etike, por është një detyrim ligjor (KVKK, GDPR) dhe i dyqanit (App Store, Google Play). Në këtë njësi, ne do të mësojmë se si të kërkojmë leje në mënyrë korrekte, të përpunojmë të dhënat në mënyrë të sigurt, të përdorim AI si asistent në këtë fushë dhe të mbrohemi nga kurthet e saj. Ekziston një çështje kritike shtesë në kontekstin e AI: të dhënat e përdoruesve që shkojnë në modelet e AI (veçanërisht cloud) janë një vendim privatësie në vetvete.
Arti i të kërkuarit leje: privilegji më i vogël
Parimi bazë i sigurisë është privilegji më i vogël (të mos kërkosh më shumë privilegje sesa kërkon një punë). Aplikacioni juaj duhet të kërkojë vetëm lejen që i nevojitet vërtet, në kohën kur i nevojitet. Nëse nuk ka veçori të kamerës, nuk do të kërkohet leja e kamerës; Nëse vendndodhja kërkohet vetëm kur harta është e hapur, leja "gjatë përdorimit" është e mjaftueshme, jo "gjithmonë". Lejet e tepërta shkaktojnë dëm të trefishtë: minon besimin e përdoruesit, çon në refuzimin e dyqaneve dhe zmadhon rrezikun e rrjedhjes së të dhënave.
Koha dhe shpjegimi i duhur për të kërkuar leje është kritike. Kërkoni leje nga përdoruesi në kontekst dhe me arsyetim, si p.sh. "Kërkohet qasja në kamerë për të skanuar faturën tuaj". iOS kërkon këtë përshkrim në Info.plist; Përshkrimi bosh ose mashtrues është refuzim i dyqanit.
Lloji i lejes
qasje e keqe
qasje e mirë
koha
Kërkoni të gjitha në nisje
të shpejtë kur përdorni veçorinë
Fushëveprimi
"Gjithmonë vendndodhja"
"vendndodhja gjatë përdorimit"
Përshkrimi
Bosh ose gjenerik
Arsyetim konkret, specifik
statusi i refuzimit
Rrëzohet/dështon aplikacioni
Me mirësi ofron alternativa
Këshillë: Aplikacioni juaj duhet të jetë në gjendje të vazhdojë të funksionojë kur i refuzohet leja. Nëse përdoruesi refuzon kamerën, ofroni një opsion "hyrje manuale". Imponimi i "lejo ose aplikacioni nuk do të funksionojë" është një përvojë e keqe dhe një problem dyqani. Kërkoni gjithmonë skenarin e refuzimit kur printoni një kod leje në AI.
Pëlqimi dhe kodi i privatësisë me AI: konsiderata
AI gjeneron shpejt kodin që kërkon leje, por ka dy gracka tipike. Së pari, duke shtuar më shumë leje sesa duhet: vendndodhjen, kontaktet mund të vendosin në masë lejet e ruajtjes "për çdo rast". Së dyti, anashkalimi i skenarit të refuzimit: thjesht shkruani statusin "e lejuar" dhe injoroni refuzimin. Për çdo leje të krijuar do të pyeteni "a është vërtet e nevojshme kjo?" dhe "çfarë ndodh nëse refuzohet?" Bëni pyetjet tuaja.
Kujdes: Kodi i mostrës i krijuar nga AI mund të ruajë të dhënat e përdoruesit pa kriptim ose t'i transmetojë ato në mënyrë të pasigurt. Të dhënat e ndjeshme (fjalëkalimi, shëndeti, financat) duhet të mbahen në ruajtje të sigurt në pajisje (Keychain — iOS, Keystore — Android; zona e koduar e kasafortës së sistemit operativ) dhe të transmetohen në rrjet nëpërmjet një lidhjeje të koduar (HTTPS/TLS). AI jo gjithmonë e bën këtë në mënyrë spontane; Pyetni qartë dhe verifikoni.
Minimizimi i të dhënave dhe dërgimi i të dhënave në AI
Të dhënat që nuk mbledh nuk mund të rrjedhin. Minimizimi i të dhënave (duke mbledhur vetëm të dhënat që nevojiten në të vërtetë) është mjeti më i fuqishëm për privatësinë. Në veçoritë e AI, ky parim është dyfish i rëndësishëm: kur dërgoni të dhëna në një LLM cloud ose shërbim të jashtëm të AI, ato të dhëna janë jashtë kontrollit tuaj. Përpara se të dërgoni shënimin shëndetësor të një përdoruesi, përmbajtjen e bisedës ose informacionin personal në cloud, bëni tre pyetje: (1) A janë vërtet të nevojshme këto të dhëna? (2) A mund të përpunohet në pajisje? (3) Nëse do të dërgohet, a e di dhe e aprovon përdoruesi atë? Është një kërkesë ligjore dhe etike për të informuar qartë përdoruesin se të dhënat e tij po shkojnë në një shërbim AI.
Përdorimi i sigurt dhe fokusi në mbrojtje
Një paralajmërim nga këndvështrimi i TI-së dhe sigurisë: teknikat e mësuara në këtë modul janë vetëm për përdorim të autorizuar dhe mbrojtës. Është legjitime të testoni sigurinë e aplikacionit tuaj, të mbroni të dhënat e përdoruesit dhe të mbyllni dobësitë. Inxhinieria e kundërt e aplikacionit të dikujt tjetër pa leje, mbledhja e të dhënave të përdoruesit pa pëlqim ose përdorimi i AI për të krijuar malware është i paligjshëm dhe joetik. Kur kërkoni ndihmë nga AI për sigurinë, qëndroni gjithmonë brenda kornizës së mbrojtjes së sistemit tuaj.
tre mini kuti
Rasti 1 - Refuzim i tepërt i lejes. Një aplikacion shënimi kërkoi leje për kamerën, mikrofonin, vendndodhjen dhe kontaktin në nisje me kodin e prodhuar nga AI. Google Play e refuzoi lëshimin, duke përmendur "lejet që nuk kanë lidhje me funksionin". Lëshimi u miratua kur ekipi lëshoi vetëm lejen e ruajtjes që ishte përdorur në të vërtetë. Mësimi: çdo pushim shtesë është një rrezik.
Rasti 2 - Ruajtja pa fjalëkalim. Një aplikacion shëndetësor ruante matjet e përdoruesve në një skedar teksti të thjeshtë si në shembullin e AI. Një auditim sigurie zbuloi se kushdo që merrte pajisjen mund të lexonte të gjitha të dhënat shëndetësore. Të dhënat u zhvendosën në hapësirën ruajtëse të koduar me Keystore/Keychain. Mësimi: të dhënat e ndjeshme mbeten gjithmonë të koduara.
Rasti 3 - Shtytje e paparalajmëruar në re. Një aplikacion po dërgonte shënimet ditore të përdoruesve në një cloud LLM për t'i përmbledhur ato, por nuk ia tregonte përdoruesit. Kur u raportua në shtyp, pati një humbje besimi dhe shqyrtimi ligjor. Ekipi shtoi një njoftim dhe konfirmim të qartë, si dhe një opsion në pajisje. Mësimi: përdoruesi duhet të dijë dhe të konfirmojë që të dhënat po shkojnë në AI.
Prompt i dobët / Prompt i fortë
Prompt i dobët: "Kërko lejen e vendndodhjes."
Prompt i fuqishëm: "Kërkoni leje për vendndodhjen në iOS/Swift me parimin e privilegjit më të vogël. - Vetëm leje "kur përdoret", jo "gjithmonë" - Përshkrimi i Info.plist: "Për të shfaqur dyqanet në afërsi" - Nëse leja refuzohet: ofroni opsionin për të zgjedhur me dorë qytetin, përplasje - Nëse leja është refuzuar. gjithashtu."
Modele të kopjueshme
Shablloni për të kërkuar leje: "Kërkoni leje [lloji i lejes] për [platformën].- Shtrirja minimale (kur përdoret/sipas nevojës)- Në kontekst, me shpjegim të arsyetuar- Alternativë e sjellshme në rast refuzimi, mos u rrëzoni kurrë- Jepni Info.plist / Manifestoni gjithashtu hyrjen Mos shtoni leje shtesë; justifikoni secilën leje."
Modeli i auditimit të lejeve: "Kontrollo lejet që kërkon aplikacioni im: [lista e lejeve + vetitë]. Për çdo leje: a nevojitet vërtet? A do të mjaftonte një shtrirje më e ngushtë? A do të çonte në refuzim të dyqanit? Flamuri i panevojshëm."
Shablloni i ruajtjes së sigurt të të dhënave: "Ruaj në mënyrë të sigurt të dhënat e ndjeshme ([lloj]) për [platformën]:- Të koduara me Keychain/Keystore- Mos ruani në memorie për një kohë të gjatë të panevojshme- Mos rrjedhni në regjistrat dhe kopjet rezervë Jepni kodin dhe hapat e verifikimit."
Modeli për dërgimin e të dhënave te AI: "Po shqyrtoj dërgimin e të dhënave të mëposhtme në një shërbim të AI-së në renë kompjuterike: [të dhëna]. Vlerësoni: a është vërtet e nevojshme? A mund të përpunohet në pajisje? Nëse dërgohet, cilat fusha duhet të maskohen? Si duhet të merret pëlqimi i përdoruesit? Rekomandoni modelin më të sigurt për sa i përket privatësisë."
Gabimet e zakonshme
- Kërkoni më shumë leje sesa duhet. Rrezik i trefishtë i besimit, miratimit të dyqanit dhe sigurisë.
- Kërkimi i lejeve në masë gjatë nisjes. Një kërkesë për leje pa kontekst refuzohet; kërkoni funksionin në çast.
- Mos shkrimi i skenarit të refuzimit. Dështimi i aplikacionit kur refuzohet leja është i keq dhe i refuzuar.
- Ruajtja e të dhënave të ndjeshme pa fjalëkalim. Shëndeti, financat dhe fjalëkalimet duhet të mbahen në një ruajtje të sigurt.
- Dërgimi i të dhënave në cloud/AI pa informuar përdoruesin. Shkelje ligjore dhe etike; Kërkohet njoftim dhe miratim.
- Përdorimi i paautorizuar i teknikave të sigurisë. Është e ligjshme vetëm për qëllime mbrojtëse në sistemin tuaj.
Në përmbledhje
Privatësia dhe siguria janë krijuar që në fillim, nuk shtohen më vonë. Parimi bazë është privilegji më i vogël: kërkoni vetëm lejen e nevojshme, kur është e nevojshme, me arsyetim dhe ofroni një alternativë të sjellshme në rast refuzimi. Të dhënat e ndjeshme ruhen në ruajtje të koduar dhe transmetohen nëpërmjet lidhjes së koduar. Minimizimi i të dhënave është mbrojtja më e fortë: të dhënat që nuk grumbulloni nuk mund të rrjedhin. Dërgimi i të dhënave në AI, veçanërisht në cloud, është një vendim privatësie në vetvete; Domosdoshmëria e tij vihet në dyshim, nëse është e mundur, preferohet në pajisje, përdoruesi informohet dhe merret miratimi i tij/saj. Çdo kod i prodhuar kontrollohet kundrejt tendencave të AI për të shtuar leje të tepërta dhe për të ruajtur në mënyrë të pasigurt. Teknikat e sigurisë përdoren vetëm për qëllime të autorizuara dhe mbrojtëse.
Detyra e aplikimit
Bëni një listë të lejeve që kërkon një aplikacion (projekti juaj ose imagjinar) dhe kontrolloni AI-n se cilat janë të panevojshme ose të tepërta me "Modelin e auditimit të lejeve". Përsosni ose hiqni të paktën një leje dhe shkruani skenarin e mohimit për atë veçori. Për më tepër, nëse po dërgoni të dhënat e përdoruesit në cloud, përcaktoni modelin më të sigurt me "modelin e vendimit për dërgimin e të dhënave në AI" dhe shkruani tekstin e miratimit të përdoruesit.
listë kontrolli
- [ ] Çdo leje e kam kërkuar me arsyetim, me parimin e privilegjit më të vogël.
- [ ] Kërkova leje në kontekst, në kohën e funksionit, jo në masë në nisje
- [ ] Kam shkruar një skenar refuzimi për çdo leje, pa përplasje
- [ ] Kam ruajtur të dhëna të ndjeshme të koduara me Keychain/Keystore
- [ ] Kam minimizuar të dhënat që shkojnë në cloud/AI dhe shtova miratimin e përdoruesit
- [ ] Kam përdorur teknika sigurie vetëm në sistemin tim për qëllime mbrojtëse