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