Winst:
- Mogelijkheid om toestemmingen aan te vragen met rechtvaardiging, context en afwijzingsscenario, gebruikmakend van het principe van de minste privileges
- Mogelijkheid om gevoelige gegevens versleuteld op te slaan met Keychain/Keystore, gegevensminimalisatie toe te passen en de neiging van kunstmatige intelligentie om te veel machtigingen toe te voegen te beheersen
- Mogelijkheid om de stroom gebruikersgegevens naar de cloud of kunstmatige-intelligentiedienst te beheren als een privacybeslissing, toestemming van de gebruiker te verkrijgen en beveiligingstechnieken alleen te gebruiken voor geautoriseerde, defensieve doeleinden
De mobiele applicatie werkt op het meest privéapparaat van de gebruiker: hij kent zijn locatie, contacten, foto's, gezondheidsgegevens, microfoon. Deze toegang betekent grote macht, en macht betekent verantwoordelijkheid. Privacy en veiligheid zijn geen “add-on feature” bij mobiele ontwikkeling, maar een principe dat vanaf het begin in de architectuur verweven is; Dit heet privacy by design. Bovendien is dit niet alleen een ethische keuze, het is een wettelijke (KVKK, AVG) en winkelverplichting (App Store, Google Play). In deze unit leren we hoe we op de juiste manier toestemming kunnen vragen, gegevens veilig kunnen verwerken, AI als assistent op dit gebied kunnen gebruiken en onszelf tegen de valkuilen kunnen beschermen. Er is nog een cruciaal probleem in de AI-context: gebruikersgegevens die naar AI-modellen (vooral de cloud) gaan, zijn op zichzelf een privacybeslissing.
De kunst van het vragen van toestemming: minste privileges
Het basisprincipe van veiligheid is ‘least privilege’ (niet vragen om meer privileges dan een baan vereist). Uw app mag alleen de toestemming vragen die hij echt nodig heeft, op het moment dat hij die nodig heeft. Als er geen camerafunctie is, wordt er geen cameratoestemming gevraagd; Als de locatie alleen vereist is als de kaart geopend is, is de toestemming 'tijdens gebruik' voldoende, niet 'altijd'. Overmatige machtigingen veroorzaken drievoudige schade: het ondermijnt het vertrouwen van gebruikers, leidt tot winkelafwijzing en vergroot het risico op gegevenslekken.
Een goede timing en uitleg bij het vragen om toestemming is van cruciaal belang. Vraag de gebruiker om toestemming in context en met motivering, bijvoorbeeld 'Cameratoegang is vereist om uw kassabon te scannen'. iOS vereist deze beschrijving in Info.plist; Een lege of misleidende beschrijving is winkelafwijzing.
Toestemmingstype
slechte aanpak
goede aanpak
timing
Vraag alles aan bij de lancering
vragen wanneer u de functie gebruikt
Reikwijdte
"Altijd locatie"
"locatie tijdens gebruik"
Beschrijving
Leeg of algemeen
Concrete, specifieke rechtvaardiging
afwijzingsstatus
App crasht / crasht
Biedt graag alternatieven
Tip: Uw app zou moeten kunnen blijven werken wanneer toestemming wordt geweigerd. Als de gebruiker de camera afwijst, bied dan een 'handmatige login'-optie aan. Het opleggen van "sta het toe, anders werkt de app niet" is zowel een slechte ervaring als een winkelprobleem. Vraag altijd naar het afwijzingsscenario wanneer u een toestemmingscode naar de AI afdrukt.
Toestemmings- en privacycode met AI: overwegingen
AI genereert snel code voor het aanvragen van toestemming, maar kent twee typische valkuilen. Ten eerste, het toevoegen van meer rechten dan nodig: locatie, contacten kunnen opslagrechten in bulk plaatsen "voor het geval dat". Ten tweede: sla het afwijzingsscenario over: schrijf gewoon de status "toegestaan" en negeer de afwijzing. Bij iedere gegenereerde vergunning wordt u gevraagd: “Is dit echt nodig?” en “wat gebeurt er als het wordt afgewezen?” Stel uw vragen.
Let op: De door de AI gegenereerde voorbeeldcode kan gebruikersgegevens zonder versleuteling opslaan of onveilig verzenden. Gevoelige gegevens (wachtwoord, gezondheid, financiën) moeten veilig worden opgeslagen op het apparaat (sleutelhanger – iOS, Keystore – Android; gecodeerde kluisruimte van het besturingssysteem) en via een gecodeerde verbinding (HTTPS/TLS) op het netwerk worden verzonden. AI doet dit niet altijd spontaan; Vraag duidelijk en verifieer.
Dataminimalisatie en het verzenden van gegevens naar AI
Gegevens die u niet verzamelt, kunnen niet lekken. Dataminimalisatie (alleen de gegevens verzamelen die daadwerkelijk nodig zijn) is het krachtigste hulpmiddel voor privacy. Bij AI-functies is dit principe dubbel belangrijk: wanneer u gegevens naar een cloud-LLM of externe AI-service verzendt, heeft u geen controle over die gegevens. Voordat u de gezondheidsnota, gespreksinhoud of persoonlijke informatie van een gebruiker naar de cloud verzendt, moet u drie vragen stellen: (1) Zijn deze gegevens echt nodig? (2) Kan het op het apparaat worden verwerkt? (3) Als het verzonden moet worden, weet de gebruiker het dan en keurt het het goed? Het is zowel een wettelijke als een ethische vereiste om de gebruiker duidelijk te informeren dat zijn gegevens naar een AI-dienst gaan.
Veilig gebruik en verdedigingsfocus
Een waarschuwing vanuit IT- en beveiligingsperspectief: de technieken die in deze module worden geleerd, zijn uitsluitend bedoeld voor geautoriseerd en defensief gebruik. Het is legitiem om de veiligheid van uw eigen applicatie te testen, gebruikersgegevens te beschermen en kwetsbaarheden te dichten. Reverse-engineering van de applicatie van iemand anders zonder toestemming, het verzamelen van gebruikersgegevens zonder toestemming of het gebruik van AI om malware te maken is illegaal en onethisch. Wanneer u AI om beveiligingshulp vraagt, blijf dan altijd binnen het kader van de verdediging van uw eigen systeem.
drie minikoffers
Casus 1 — Weigering van te veel verlof. Een notitietoepassing vroeg bij het opstarten om camera-, microfoon-, locatie- en contactrechten met de door AI geproduceerde code. Google Play heeft de release afgewezen onder vermelding van "functie-irrelevante rechten". De release werd goedgekeurd toen het team alleen de opslagtoestemming vrijgaf die daadwerkelijk werd gebruikt. Les: elk extra verlof is een risico.
Geval 2 — Opslag zonder wachtwoord. Een gezondheidsapp sloeg gebruikersmetingen op in een tekstbestand zoals in het AI-voorbeeld. Uit een beveiligingsaudit bleek dat iedereen die het apparaat had verkregen, alle gezondheidsgegevens kon lezen. Gegevens verplaatst naar gecodeerde opslag met Keystore/Keychain. Les: gevoelige gegevens blijven altijd gecodeerd.
Casus 3 — Onaangekondigde overstap naar de cloud. Een app stuurde de dagelijkse aantekeningen van gebruikers naar een cloud LLM om ze samen te vatten, maar vertelde de gebruiker niets. Toen het in de pers verscheen, was er sprake van een verlies aan vertrouwen en juridisch toezicht. Het team heeft een duidelijke melding en bevestiging toegevoegd, evenals een optie op het apparaat. Les: de gebruiker moet weten en bevestigen dat de gegevens naar de AI gaan.
Zwakke prompt/sterke prompt
Zwakke prompt: "Vraag locatietoestemming aan."
Krachtige prompt: "Vraag locatietoestemming op iOS/Swift aan met het principe van de minste privileges. - Alleen toestemming 'wanneer in gebruik', niet 'altijd' - Info.plist-beschrijving: 'Om winkels in de buurt te tonen' - Als toestemming wordt geweigerd: optie aanbieden om handmatig een stad te selecteren, crash - Als toestemming al eerder is geweigerd, stuur dan door naar instellingen Voeg niet meer rechten toe dan nodig. Schrijf ook de weigeringsstroom."
Kopieerbare sjablonen
Sjabloon voor het aanvragen van toestemming: "Vraag [toestemmingstype] toestemming aan voor [platform]. - Minimale reikwijdte (bij gebruik/indien nodig) - In context, met beredeneerde uitleg - Beleefd alternatief in geval van afwijzing, nooit crashen - Geef ook Info.plist / Manifest-invoer Voeg geen extra rechten toe; motiveer elke toestemming."
Toestemmingsauditsjabloon: "Controleer de machtigingen die mijn app vraagt: [machtigingslijst + eigenschappen]. Voor elke machtiging: is deze echt nodig? Zou een smaller bereik voldoende zijn? Zou dit leiden tot winkelafwijzing? Markering onnodig."
Sjabloon voor veilige gegevensopslag: "Sla gevoelige gegevens ([type]) veilig op voor [platform]: - Gecodeerd met sleutelhanger/sleutelopslag - Bewaar niet onnodig lang in het geheugen - Lek niet in logs en back-ups. Geef code en verificatiestappen."
Sjabloon voor het verzenden van gegevens naar AI: "Ik overweeg om de volgende gegevens naar een cloud-AI-service te sturen: [gegevens]. Evalueer: is het echt nodig? Kan het op het apparaat worden verwerkt? Indien verzonden, welke velden moeten worden gemaskeerd? Hoe moet toestemming van de gebruiker worden verkregen? Beveel het meest veilige ontwerp aan op het gebied van privacy."
Veel voorkomende fouten
- Meer toestemming vragen dan nodig is. Drievoudig gevaar voor vertrouwen, winkelgoedkeuring en veiligheid.
- Bij het opstarten bulksgewijs toestemming vragen. Een verzoek om toestemming zonder context wordt afgewezen; vraag de functie onmiddellijk aan.
- Het afwijzingsscript niet schrijven. De app die crasht wanneer de toestemming wordt geweigerd, is zowel slecht als afgewezen.
- Gevoelige gegevens opslaan zonder wachtwoord. Gezondheid, financiën en wachtwoorden moeten in een veilige opslag worden bewaard.
- Gegevens naar de cloud/AI verzenden zonder de gebruiker hiervan op de hoogte te stellen. Juridische en ethische overtreding; Kennisgeving en goedkeuring zijn vereist.
- Ongeautoriseerd gebruik van beveiligingstechnieken. Het is alleen legitiem voor defensieve doeleinden op uw eigen systeem.
Samengevat
Privacy en beveiliging zijn vanaf het begin ontworpen en niet later toegevoegd. Het basisprincipe is ‘least privilege’: vraag alleen de noodzakelijke toestemming, indien nodig, met motivering, en bied bij weigering een hoffelijk alternatief. Gevoelige gegevens worden opgeslagen in gecodeerde opslag en verzonden via een gecodeerde verbinding. Dataminimalisatie is de sterkste bescherming: gegevens die u niet verzamelt, kunnen niet lekken. Het verzenden van gegevens naar AI, vooral naar de cloud, is op zichzelf een privacybeslissing; De noodzaak ervan wordt in twijfel getrokken, indien mogelijk wordt de voorkeur gegeven aan on-device, de gebruiker wordt geïnformeerd en zijn/haar goedkeuring wordt verkregen. Elke geproduceerde code wordt getoetst aan de neiging van AI om buitensporige machtigingen toe te voegen en onveilig op te slaan. Beveiligingstechnieken worden alleen gebruikt voor geautoriseerde en defensieve doeleinden.
Applicatie taak
Maak een lijst van de rechten die een applicatie (uw eigen project of denkbeeldig) vraagt en laat de AI controleren welke niet nodig zijn of te veel reiken met de "Permission audit template". Verfijn of verwijder ten minste één machtiging en schrijf het weigeringsscenario voor die functie. Als u gebruikersgegevens naar de cloud verzendt, bepaalt u bovendien het veiligste ontwerp met de 'Besluitsjabloon voor gegevens verzenden naar AI' en schrijft u de gebruikersgoedkeuringstekst.
controlelijst
- [ ] Ik vroeg elke toestemming met rechtvaardiging, met het principe van de minste privileges.
- [ ] Ik vroeg om toestemming in context, tijdens de release, niet in bulk bij de lancering
- [ ] Ik heb voor elke toestemming een afwijzingsscript geschreven, geen crashes
- [ ] Ik heb gevoelige gegevens gecodeerd opgeslagen met Keychain/Keystore
- [ ] Ik heb de gegevens die naar de cloud/AI gaan geminimaliseerd en gebruikersgoedkeuring toegevoegd
- [ ] Ik gebruikte beveiligingstechnieken alleen op mijn eigen systeem voor defensieve doeleinden