Gains:
- Ability to request permissions with justification, context and rejection scenario, using the principle of least privilege
- Ability to store sensitive data encrypted with Keychain/Keystore, apply data minimization and control the tendency of artificial intelligence to add too many permissions
- Ability to manage the flow of user data to the cloud or artificial intelligence service as a privacy decision, obtain user consent, and use security techniques only for authorized, defensive purposes
The mobile application works on the user's most private device: it knows his location, contacts, photos, health data, microphone. This access is great power, and power means responsibility. Privacy and security are not an “add-on feature” in mobile development, but a principle woven into the architecture from the beginning; This is called privacy by design. Moreover, this is not only an ethical choice, it is a legal (KVKK, GDPR) and store (App Store, Google Play) obligation. In this unit, we will learn how to request permissions correctly, process data securely, use AI as an assistant in this field and protect ourselves from its traps. There is an additional critical issue in the AI context: user data going to AI models (especially the cloud) is a privacy decision in itself.
The art of asking permission: least privilege
The basic principle of security is least privilege (not asking for more privileges than a job requires). Your app should only ask for the permission it really needs, at the time it needs it. If there is no camera feature, camera permission will not be requested; If the location is required only when the map is open, the "while using" permission is sufficient, not "always". Excessive permissions cause triple harm: it undermines user trust, leads to store rejection, and magnifies the risk of data leakage.
Proper timing and explanation of asking for permission is critical. Ask the user for permission in context and with justification, such as "Camera access is required to scan your receipt." iOS requires this description in Info.plist; Empty or misleading description is store rejection.
Permission type
bad approach
good approach
timing
Request all at launch
prompt when using the feature
Scope
"Always location"
"location while using"
Description
Blank or generic
Concrete, specific justification
rejection status
App crashes/crashes
Kindly offers alternatives
Tip: Your app should be able to continue running when permission is denied. If the user rejects the camera, offer a "manual login" option. The imposition of "allow it or the app won't work" is both a bad experience and a store problem. Always ask for the rejection scenario when printing a permission code to the AI.
Consent and privacy code with AI: considerations
AI quickly generates permission-requesting code, but it has two typical pitfalls. First, adding more permissions than necessary: location, contacts can bulk put storage permissions "just in case". Second, skipping the rejection scenario: just write the status "allowed" and ignore the rejection. For every permit generated you will be asked "is this really necessary?" and “what happens if rejected?” Ask your questions.
Caution: The sample code generated by the AI may store user data without encryption or transmit it insecurely. Sensitive data (password, health, finance) should be kept in secure storage on the device (Keychain — iOS, Keystore — Android; encrypted vault area of the operating system) and transmitted on the network via an encrypted connection (HTTPS/TLS). AI doesn't always do this spontaneously; Ask clearly and verify.
Data minimization and sending data to AI
Data you don't collect cannot leak. Data minimization (collecting only the data that is actually needed) is the most powerful tool for privacy. In AI features, this principle is doubly important: when sending data to a cloud LLM or external AI service, that data is out of your control. Before sending a user's health note, conversation content, or personal information to the cloud, ask three questions: (1) Is this data really necessary? (2) Can it be processed on the device? (3) If it is to be sent, does the user know and approve it? It is both a legal and ethical requirement to clearly inform the user that their data is going to an AI service.
Safe use and defense focus
A warning from an IT and security perspective: the techniques learned in this module are for authorized and defensive use only. It is legitimate to test the security of your own application, protect user data, and close vulnerabilities. Reverse engineering someone else's application without permission, collecting user data without consent, or using AI to create malware is illegal and unethical. When asking AI for security help, always stay within the framework of defending your own system.
three mini cases
Case 1 — Excess leave denial. A note application requested camera, microphone, location and contact permissions at startup with the code produced by AI. Google Play rejected the release, citing "function-irrelevant permissions". The release was approved when the team only released the storage permission that was actually used. Lesson: every extra leave is a risk.
Case 2 — Storage without password. A health app stored user measurements in a plain text file like in the AI example. A security audit found that anyone who obtained the device could read all health data. Data moved to encrypted storage with Keystore/Keychain. Lesson: sensitive data always remains encrypted.
Case 3 — Unannounced push to cloud. An app was sending users' daily notes to a cloud LLM to summarize them, but it didn't tell the user. When it was reported in the press, there was a loss of trust and legal scrutiny. The team added a clear notification and confirmation, as well as an on-device option. Lesson: the user must know and confirm that the data is going to the AI.
Weak prompt / Strong prompt
Weak prompt: "Request location permission."
Powerful prompt: "Request location permission on iOS/Swift with the principle of least privilege. - Only 'when in use' permission, not 'always' - Info.plist description: 'To show nearby stores' - If permission is denied: offer option to manually select city, crash - If permission has been denied before, redirect to settings Don't add more permissions than necessary. Write the denial flow too."
Copiable templates
Template for requesting permission: "Request [permission type] permission for [platform].- Minimal scope (when using/as needed)- In context, with reasoned explanation- Polite alternative in case of rejection, never crash- Give Info.plist / Manifest entry too Don't add extra permissions; justify each permission."
Permission audit template: "Check the permissions my app requests: [permission list + properties]. For each permission: is it really needed? Would a narrower scope be enough? Would it lead to store rejection? Flag unnecessary."
Secure data storage template: "Securely store sensitive data ([type]) for [platform]:- Encrypted with Keychain/Keystore- Do not keep in memory for unnecessarily long time- Do not leak into logs and backups Provide code and verification steps."
Template for sending data to AI: "I am considering sending the following data to a cloud AI service: [data]. Evaluate: is it really necessary? Can it be processed on-device? If sent, which fields should be masked? How should user consent be obtained? Recommend the most secure design in terms of privacy."
Common mistakes
- Asking for more permission than necessary. Triple jeopardy of trust, store approval and security.
- Requesting permissions in bulk at startup. A request for permission without context is rejected; request the feature instantly.
- Not writing the rejection script. The app crashing when the permission is denied is both bad and rejected.
- Storing sensitive data without password. Health, finance and passwords must be kept in a secure storage.
- Sending data to the cloud/AI without informing the user. Legal and ethical violation; Notification and approval are required.
- Unauthorized use of security techniques. It is only legitimate for defensive purposes on your own system.
In summary
Privacy and security are designed from the beginning, not added later. The basic principle is least privilege: ask only for the necessary permission, when necessary, with justification, and offer a courteous alternative in case of refusal. Sensitive data is stored in encrypted storage and transmitted via encrypted connection. Data minimization is the strongest protection: data you don't collect cannot leak. Sending data to AI, especially to the cloud, is a privacy decision in itself; Its necessity is questioned, if possible, on-device is preferred, the user is informed and his/her approval is obtained. Every code produced is checked against AI's tendencies to add excessive permissions and store insecurely. Security techniques are used for authorized and defensive purposes only.
Application task
Make a list of the permissions an application (your own project or imaginary) requests and have the AI check which ones are unnecessary or overreaching with the "Permission audit template". Refine or remove at least one permission and write the denial scenario for that feature. Additionally, if you are sending user data to the cloud, determine the most secure design with the "Data sending decision template to AI" and write the user approval text.
checklist
- [ ] I requested each permission with justification, with the principle of least privilege.
- [ ] I asked for permissions in context, at feature time, not bulk at launch
- [ ] I wrote a rejection script for each permission, no crashes
- [ ] I stored sensitive data encrypted with Keychain/Keystore
- [ ] I minimized the data going to the cloud/AI and added user approval
- [ ] I used security techniques only on my own system for defensive purposes