Печалби:
- Възможност за искане на разрешения с обосновка, контекст и сценарий за отхвърляне, като се използва принципът на най-малката привилегия
- Възможност за съхраняване на чувствителни данни, криптирани с Keychain/Keystore, прилагане на минимизиране на данните и контролиране на тенденцията на изкуствения интелект да добавя твърде много разрешения
- Възможност за управление на потока от потребителски данни към облака или услуга за изкуствен интелект като решение за поверителност, получаване на потребителско съгласие и използване на техники за сигурност само за разрешени, защитни цели
Мобилното приложение работи на най-личното устройство на потребителя: то знае неговото местоположение, контакти, снимки, здравни данни, микрофон. Този достъп е голяма сила, а властта означава отговорност. Поверителността и сигурността не са „допълнителна функция“ в мобилното развитие, а принцип, вплетен в архитектурата от самото начало; Това се нарича поверителност по дизайн. Освен това, това не е само етичен избор, това е законово (KVKK, GDPR) и задължение за магазин (App Store, Google Play). В този урок ще се научим как да изискваме разрешения правилно, да обработваме данните сигурно, да използваме AI като помощник в тази област и да се предпазваме от неговите капани. Има допълнителен критичен проблем в контекста на AI: потребителските данни, отиващи към AI моделите (особено в облака), сами по себе си са решение за поверителност.
Изкуството да искаш разрешение: най-малката привилегия
Основният принцип на сигурността е най-малко привилегии (да не се искат повече привилегии, отколкото изисква работата). Вашето приложение трябва да иска само разрешението, от което наистина се нуждае, в момента, в който се нуждае. Ако няма функция за камера, няма да бъде поискано разрешение за камера; Ако местоположението се изисква само когато картата е отворена, разрешението „докато се използва“ е достатъчно, а не „винаги“. Прекомерните разрешения причиняват тройна вреда: подкопават доверието на потребителите, водят до отхвърляне на хранилището и увеличават риска от изтичане на данни.
Правилното определяне на времето и обяснението на искането за разрешение е от решаващо значение. Помолете потребителя за разрешение в контекст и с обосновка, като например „Необходим е достъп до камерата, за да сканирате разписката си“. iOS изисква това описание в Info.plist; Празно или подвеждащо описание е отхвърляне на магазина.
Тип разрешение
лош подход
добър подход
синхронизация
Поискайте всички при стартиране
подкана при използване на функцията
Обхват
„Винаги местоположение“
"местоположение при използване"
Описание
Празно или общо
Конкретна, конкретна обосновка
състояние на отхвърляне
Приложението се срива/срива
Любезно предлага алтернативи
Съвет: Приложението ви трябва да може да продължи да работи, когато разрешението е отказано. Ако потребителят отхвърли камерата, предложете опция „ръчно влизане“. Налагането на „разрешете или приложението няма да работи“ е както лош опит, така и проблем на магазина. Винаги питайте за сценария на отхвърляне, когато отпечатвате код за разрешение към AI.
Съгласие и код за поверителност с AI: съображения
AI бързо генерира код за искане на разрешение, но има два типични клопки. Първо, добавяне на повече разрешения от необходимото: местоположение, контактите могат групово да поставят разрешения за съхранение „за всеки случай“. Второ, пропускане на сценария за отхвърляне: просто напишете статуса „разрешено“ и игнорирайте отхвърлянето. За всяко генерирано разрешително ще бъдете попитани "това наистина ли е необходимо?" и „какво се случва, ако бъде отхвърлен?“ Задайте вашите въпроси.
Внимание: Примерният код, генериран от AI, може да съхранява потребителски данни без криптиране или да ги предава несигурно. Чувствителните данни (парола, здраве, финанси) трябва да се съхраняват в защитено хранилище на устройството (Keychain — iOS, Keystore — Android; криптирана зона на трезора на операционната система) и да се предават в мрежата чрез криптирана връзка (HTTPS/TLS). AI не винаги прави това спонтанно; Попитайте ясно и проверете.
Минимизиране на данни и изпращане на данни към AI
Данните, които не събирате, не могат да изтекат. Минимизирането на данни (събиране само на данните, които действително са необходими) е най-мощният инструмент за поверителност. При функциите на AI този принцип е двойно важен: когато изпращате данни към облачен LLM или външна AI услуга, тези данни са извън вашия контрол. Преди да изпратите здравна бележка на потребител, съдържание на разговор или лична информация в облака, задайте три въпроса: (1) Тези данни наистина ли са необходими? (2) Може ли да се обработва на устройството? (3) Ако трябва да бъде изпратен, потребителят знае ли и одобрява ли го? Както правно, така и етично изискване е ясно да се информира потребителят, че неговите данни отиват към услуга за изкуствен интелект.
Безопасна употреба и фокус върху защитата
Предупреждение от гледна точка на ИТ и сигурността: техниките, научени в този модул, са само за разрешена и отбранителна употреба. Легитимно е да тествате сигурността на собственото си приложение, да защитите потребителските данни и да затворите уязвимостите. Обратното инженерство на нечие друго приложение без разрешение, събирането на потребителски данни без съгласие или използването на AI за създаване на зловреден софтуер е незаконно и неетично. Когато търсите AI за помощ за сигурността, винаги оставайте в рамките на защитата на вашата собствена система.
три мини калъфа
Случай 1 — Прекомерен отказ за отпуск. Приложение за бележки поиска разрешения за камера, микрофон, местоположение и контакт при стартиране с кода, създаден от AI. Google Play отхвърли изданието, цитирайки „разрешения, които не са свързани с функцията“. Изданието беше одобрено, когато екипът пусна само разрешението за съхранение, което действително беше използвано. Урок: всеки допълнителен отпуск е риск.
Случай 2 — Съхранение без парола. Здравно приложение съхранява потребителски измервания в обикновен текстов файл, както в примера с AI. Проверка на сигурността установи, че всеки, който се сдобие с устройството, може да прочете всички здравни данни. Данните се преместват в криптирано хранилище с Keystore/Keychain. Урок: чувствителните данни винаги остават криптирани.
Случай 3 — Необявено насочване към облак. Едно приложение изпращаше ежедневни бележки на потребителите до облачен LLM, за да ги обобщи, но не каза на потребителя. Когато беше съобщено в пресата, имаше загуба на доверие и правен контрол. Екипът добави ясно известие и потвърждение, както и опция на устройството. Урок: потребителят трябва да знае и потвърди, че данните отиват към AI.
Слаба подкана / Силна подкана
Слаба подкана: „Искане на разрешение за местоположение.“
Мощна подкана: „Искане на разрешение за местоположение на iOS/Swift с принципа на най-малка привилегия. – Разрешение само „когато се използва“, а не „винаги“ – Описание на Info.plist: „За показване на близки магазини“ – Ако разрешението е отказано: предлагайте опция за ръчно избиране на град, срив – Ако разрешението е било отказано преди, пренасочете към настройките Не добавяйте повече разрешения от необходимото. Напишете и потока за отказ.“
Копируеми шаблони
Шаблон за искане на разрешение: „Искане на [тип разрешение] разрешение за [платформа].- Минимален обхват (при използване/при необходимост)- В контекст, с мотивирано обяснение- Учтива алтернатива в случай на отхвърляне, никога не се срива- Дайте също Info.plist / запис в манифест Не добавяйте допълнителни разрешения; оправдайте всяко разрешение.“
Шаблон за проверка на разрешения: „Проверете разрешенията, които моето приложение иска: [списък с разрешения + свойства]. За всяко разрешение: наистина ли е необходимо? Ще бъде ли достатъчен по-тесен обхват? Ще доведе ли до отхвърляне на магазина? Маркирайте ненужно.“
Шаблон за защитено съхранение на данни: „Съхранявайте сигурно чувствителни данни ([тип]) за [платформа]:- Шифровани с Keychain/Keystore- Не съхранявайте в паметта за ненужно дълго време- Не изтичайте в регистрационни файлове и архиви Осигурете код и стъпки за проверка.“
Шаблон за изпращане на данни към AI: "Обмислям да изпратя следните данни към облачна AI услуга: [данни]. Оценете: наистина ли е необходимо? Могат ли да бъдат обработени на устройството? Ако бъдат изпратени, кои полета трябва да бъдат маскирани? Как трябва да се получи съгласието на потребителя? Препоръчайте най-сигурния дизайн по отношение на поверителността."
Често срещани грешки
- Искане на повече разрешения от необходимото. Тройна опасност за доверието, одобрението на магазина и сигурността.
- Групово искане на разрешения при стартиране. Искане за разрешение без контекст се отхвърля; поискайте незабавно функцията.
- Без писане на сценария за отхвърляне. Приложението, което се срива, когато разрешението е отказано, е както лошо, така и отхвърлено.
- Съхраняване на чувствителни данни без парола. Здравето, финансите и паролите трябва да се съхраняват в сигурно хранилище.
- Изпращане на данни към облака/AI без информиране на потребителя. Законови и етични нарушения; Изисква се уведомление и одобрение.
- Неразрешено използване на техники за сигурност. Това е легитимно само за отбранителни цели на вашата собствена система.
В обобщение
Поверителността и сигурността са проектирани от самото начало, не са добавени по-късно. Основният принцип е най-малката привилегия: поискайте само необходимото разрешение, когато е необходимо, с обосновка и предложете учтива алтернатива в случай на отказ. Чувствителните данни се съхраняват в криптирано хранилище и се предават чрез криптирана връзка. Минимизирането на данните е най-силната защита: данните, които не събирате, не могат да изтекат. Изпращането на данни към AI, особено към облака, само по себе си е решение за поверителност; Неговата необходимост се поставя под въпрос, при възможност се предпочита on-device, потребителят се информира и се получава неговото одобрение. Всеки произведен код се проверява срещу тенденциите на AI да добавя прекомерни разрешения и да съхранява несигурно. Техниките за сигурност се използват само за разрешени и защитни цели.
Задача за приложение
Направете списък с разрешенията, които дадено приложение (ваш собствен проект или въображаемо) иска и накарайте AI да провери кои от тях са ненужни или прекомерни с „Шаблон за проверка на разрешения“. Прецизирайте или премахнете поне едно разрешение и напишете сценария за отказ за тази функция. Освен това, ако изпращате потребителски данни към облака, определете най-сигурния дизайн с „Шаблон за решение за изпращане на данни към AI“ и напишете текста за одобрение на потребителя.
контролен списък
- [ ] Поисках всяко разрешение с обосновка, с принципа на най-малката привилегия.
- [ ] Поисках разрешения в контекста, по време на функцията, а не групово при стартиране
- [ ] Написах скрипт за отхвърляне за всяко разрешение, без сривове
- [ ] Съхраних чувствителни данни, криптирани с Keychain/Keystore
- [ ] Минимизирах данните, отиващи към облака/AI и добавих одобрение от потребителя
- [ ] Използвах техники за сигурност само в собствената си система за отбранителни цели