Прибуток:
- Можливість запитувати дозволи з обґрунтуванням, контекстом і сценарієм відхилення, використовуючи принцип найменших привілеїв
- Можливість зберігати конфіденційні дані, зашифровані за допомогою Keychain/Keystore, застосовувати мінімізацію даних і контролювати схильність штучного інтелекту додавати занадто багато дозволів
- Можливість керувати потоком даних користувача в хмарі або службі штучного інтелекту як рішення щодо конфіденційності, отримувати згоду користувача та використовувати методи безпеки лише для авторизованих захисних цілей
Мобільний додаток працює на найбільш закритому пристрої користувача: він знає його місцезнаходження, контакти, фотографії, дані про здоров’я, мікрофон. This access is great power, and power means responsibility. Конфіденційність і безпека — це не «додаткова функція» мобільної розробки, а принцип, закладений в архітектуру з самого початку; Це називається конфіденційністю за проектом. Крім того, це не лише етичний вибір, це юридичне (KVKK, GDPR) і зобов’язання магазину (App Store, Google Play). У цьому розділі ми навчимося правильно запитувати дозволи, безпечно обробляти дані, використовувати ШІ як помічника в цій сфері та захистити себе від його пасток. Існує додаткова критична проблема в контексті штучного інтелекту: дані користувача, що надходять до моделей штучного інтелекту (особливо хмари), самі по собі є рішенням щодо конфіденційності.
Мистецтво питати дозволу: найменший привілей
Основний принцип безпеки — найменші привілеї (не вимагати більше привілеїв, ніж вимагає робота). Ваша програма має запитувати лише той дозвіл, який їй дійсно потрібен, у той час, коли вона потрібна. Якщо функція камери відсутня, дозвіл камери не запитуватиметься; Якщо місцезнаходження потрібне лише під час відкритої карти, достатньо дозволу «під час використання», а не «завжди». Надмірні дозволи завдають потрійної шкоди: підривають довіру користувачів, призводять до відхилення сховища та збільшують ризик витоку даних.
Правильний час і пояснення щодо запиту дозволу є критично важливими. Попросіть користувача дозволу в контексті та з обґрунтуванням, наприклад «Для сканування квитанції потрібен доступ до камери». iOS вимагає цього опису в Info.plist; Порожній або оманливий опис означає відмову магазину.
Тип дозволу
поганий підхід
хороший підхід
терміни
Запитувати всі під час запуску
запит під час використання функції
Область застосування
«Завжди місцезнаходження»
"розташування під час використання"
опис
Пустий або загальний
Конкретне, конкретне обґрунтування
статус відхилення
Збої/збої програми
Люб'язно пропонує альтернативи
Порада. Ваша програма повинна мати можливість продовжувати працювати, якщо дозвіл буде відмовлено. Якщо користувач відхиляє камеру, запропонуйте опцію «вхід вручну». Нав’язування «дозвольте, інакше програма не працюватиме» є одночасно поганим досвідом і проблемою магазину. Завжди запитуйте сценарій відхилення під час друку коду дозволу в ШІ.
Код згоди та конфіденційності з AI: міркування
Штучний інтелект швидко генерує код із запитом на дозвіл, але він має дві типові підводні камені. По-перше, додайте більше дозволів, ніж потрібно: місцезнаходження, контакти можуть масово розміщувати дозволи на зберігання «про всяк випадок». По-друге, пропуск сценарію відхилення: просто напишіть статус «дозволено» та проігноруйте відхилення. Для кожного згенерованого дозволу вас запитають "чи це дійсно необхідно?" і «що станеться, якщо відхилять?» Задайте свої запитання.
Застереження: Зразок коду, створений штучним інтелектом, може зберігати дані користувача без шифрування або передавати їх незахищено. Конфіденційні дані (пароль, здоров’я, фінанси) повинні зберігатися в безпечному сховищі на пристрої (Keychain — iOS, Keystore — Android; зашифрована область сховища операційної системи) і передаватись у мережі через зашифроване з’єднання (HTTPS/TLS). ШІ не завжди робить це спонтанно; Запитайте чітко і перевірте.
Мінімізація даних і надсилання даних до ШІ
Дані, які ви не збираєте, не можуть витікати. Мінімізація даних (збір лише тих даних, які дійсно потрібні) є найпотужнішим інструментом забезпечення конфіденційності. У функціях штучного інтелекту цей принцип важливий подвійно: під час надсилання даних до хмарної LLM або зовнішньої служби штучного інтелекту ці дані виходять з-під вашого контролю. Перш ніж надсилати повідомлення про стан здоров’я користувача, вміст розмови чи особисту інформацію до хмари, поставте три запитання: (1) Чи справді ці дані потрібні? (2) Чи можна обробити на пристрої? (3) Якщо його буде надіслано, чи знає користувач про це та погоджується? Це як юридична, так і етична вимога чітко інформувати користувача про те, що його дані спрямовуються до служби ШІ.
Безпечне використання та захист
Попередження з точки зору інформаційних технологій і безпеки: методи, вивчені в цьому модулі, призначені лише для авторизованого та захисного використання. Тестувати безпеку власного додатка, захищати дані користувачів і закривати вразливості цілком законно. Зворотне проектування чужої програми без дозволу, збір даних користувача без згоди або використання ШІ для створення зловмисного програмного забезпечення є незаконним і неетичним. Звертаючись до штучного інтелекту по допомогу з безпеки, завжди залишайтеся в рамках захисту власної системи.
три міні-чохла
Випадок 1 — Надмірна відмова у відпустці. Додаток для нотаток запитував дозволи на камеру, мікрофон, місцезнаходження та контакт під час запуску за допомогою коду, створеного ШІ. Google Play відхилив випуск, посилаючись на «невідповідні функції дозволи». Випуск було схвалено, коли команда видала лише той дозвіл на зберігання, який фактично використовувався. Урок: кожна додаткова відпустка – це ризик.
Випадок 2 — Зберігання без пароля. Додаток для здоров’я зберігав вимірювання користувача у звичайному текстовому файлі, як у прикладі зі штучним інтелектом. Аудит безпеки виявив, що кожен, хто отримав пристрій, міг прочитати всі дані про здоров’я. Дані переміщуються в зашифроване сховище за допомогою Keystore/Keychain. Урок: конфіденційні дані завжди залишаються зашифрованими.
Випадок 3 — неоголошене надсилання в хмару. Додаток надсилав щоденні нотатки користувачів до хмарної LLM, щоб узагальнити їх, але не повідомляв користувача. Коли про це повідомили в пресі, відбулася втрата довіри та правового контролю. Команда додала чітке сповіщення та підтвердження, а також опцію на пристрої. Урок: користувач повинен знати та підтвердити, що дані надходять до ШІ.
Слабка підказка / Сильна підказка
Слабка підказка: "Запитувати дозвіл на місцезнаходження".
Потужна підказка: «Подати запит на дозвіл розташування в iOS/Swift із принципом найменших привілеїв. - Дозвіл лише «під час використання», а не «завжди» - Опис Info.plist: «Щоб показати найближчі магазини» - Якщо дозвіл відхилено: запропонуйте опцію вручну вибрати місто, збій - Якщо дозвіл було відхилено раніше, переспрямуйте до налаштувань. Не додавайте більше дозволів, ніж потрібно. Також напишіть потік відмови».
Шаблони, які можна копіювати
Шаблон для запиту дозволу: «Запит [тип дозволу] дозволу для [платформи].- Мінімальний обсяг (при використанні/якщо потрібно)- У контексті, з аргументованим поясненням- Ввічлива альтернатива в разі відхилення, ніколи не завершувати роботу- Надайте також запис Info.plist / Manifest. Не додавайте додаткових дозволів; обґрунтуйте кожен дозвіл.»
Шаблон перевірки дозволів: «Перевірте дозволи, які запитує мій додаток: [список дозволів + властивості]. Для кожного дозволу: чи справді він потрібен? Чи буде достатньо вужчого обсягу? Чи призведе це до відхилення магазину? Позначити непотрібним».
Шаблон безпечного зберігання даних: «Безпечно зберігайте конфіденційні дані ([тип]) для [платформи]:- Зашифровані за допомогою Keychain/Keystore- Не зберігайте в пам’яті надто довго- Не витоку в журнали та резервні копії Надайте код і кроки перевірки.»
Шаблон для надсилання даних до ШІ: «Я розглядаю можливість надсилання таких даних до хмарної служби ШІ: [дані]. Оцініть: чи справді це необхідно? Чи можна їх обробити на пристрої? Якщо надсилати, які поля слід маскувати? Як отримати згоду користувача? Порекомендуйте найбільш безпечний дизайн з точки зору конфіденційності».
Поширені помилки
- Запитує більше дозволу, ніж потрібно. Потрійна загроза довіри, схвалення магазину та безпеки.
- Груповий запит дозволів під час запуску. Запит на дозвіл без контексту відхилено; запросити функцію миттєво.
- Не написання сценарію відмови. Збій програми, коли дозвіл відмовлено, є поганою та відхиленою.
- Зберігання конфіденційних даних без пароля. Здоров'я, фінанси та паролі повинні зберігатися в надійному сховищі.
- Надсилання даних у хмару/AI без інформування користувача. Порушення правових та етичних норм; Потрібне повідомлення та схвалення.
- Несанкціоноване використання техніки безпеки. Це законно лише для оборонних цілей вашої власної системи.
Підсумовуючи
Конфіденційність і безпека розроблені з самого початку, а не додані пізніше. Основним принципом є найменші привілеї: запитуйте лише необхідний дозвіл, коли це необхідно, з обґрунтуванням, і пропонуйте ввічливу альтернативу в разі відмови. Конфіденційні дані зберігаються в зашифрованому сховищі та передаються через зашифроване з’єднання. Мінімізація даних є найсильнішим захистом: дані, які ви не збираєте, не можуть витікати. Надсилання даних до ШІ, особливо до хмари, само по собі є рішенням щодо конфіденційності; Її необхідність ставиться під сумнів, якщо можливо, перевага віддається на пристрої, користувач інформується та отримується його/її схвалення. Кожен створений код перевіряється на схильність штучного інтелекту додавати надмірні дозволи та небезпечно зберігати. Методи безпеки використовуються лише для авторизованих і захисних цілей.
Аплікаційне завдання
Складіть список дозволів, які запитує програма (ваш власний проект або уявна), і попросіть штучний інтелект перевірити, які з них непотрібні чи надмірні за допомогою «шаблону аудиту дозволів». Уточніть або видаліть принаймні один дозвіл і напишіть сценарій відмови для цієї функції. Крім того, якщо ви надсилаєте дані користувача в хмару, визначте найбільш безпечний дизайн за допомогою «Шаблону рішення про надсилання даних до ШІ» та напишіть текст схвалення користувача.
контрольний список
- [ ] Я запитував кожен дозвіл із обґрунтуванням, дотримуючись принципу найменших привілеїв.
- [ ] Я запитував дозволи в контексті, під час функції, а не групово під час запуску
- [ ] Я написав сценарій відхилення для кожного дозволу, жодних збоїв
- [ ] Я зберіг конфіденційні дані, зашифровані за допомогою Keychain/Keystore
- [ ] Я мінімізував дані, що надходять у хмару/AI, і додав схвалення користувача
- [ ] Я використовував методи безпеки лише у власній системі з метою захисту