Добици:
- Способност захтевања дозвола са оправдањем, контекстом и сценаријем одбијања, користећи принцип најмање привилегија
- Могућност складиштења осетљивих података шифрованих помоћу Кеицхаин/Кеисторе-а, примене минимизације података и контроле тенденције вештачке интелигенције да дода превише дозвола
- Способност управљања протоком корисничких података у облак или услугу вештачке интелигенције као одлука о приватности, добијање сагласности корисника и коришћење безбедносних техника само у овлашћене, одбрамбене сврхе
Мобилна апликација ради на најприватнијем уређају корисника: зна његову локацију, контакте, фотографије, здравствене податке, микрофон. Овај приступ је велика моћ, а моћ значи одговорност. Приватност и безбедност нису „додатна карактеристика“ у развоју мобилних уређаја, већ принцип уткан у архитектуру од почетка; Ово се зове приватност по дизајну. Штавише, ово није само етички избор, то је законска (КВКК, ГДПР) и обавеза продавнице (Апп Сторе, Гоогле Плаи). У овој јединици ћемо научити како да исправно тражимо дозволе, безбедно обрађујемо податке, користимо вештачку интелигенцију као помоћника у овој области и да се заштитимо од њених замки. Постоји још један критичан проблем у контексту вештачке интелигенције: кориснички подаци који иду на АИ моделе (посебно у облак) су одлука о приватности за себе.
Уметност тражења дозволе: најмање привилегија
Основни принцип безбедности је најмање привилегија (не тражити више привилегија него што посао захтева). Ваша апликација треба само да тражи дозволу која јој је заиста потребна, у тренутку када јој је потребна. Ако нема функције камере, неће се тражити дозвола за камеру; Ако је локација потребна само када је мапа отворена, довољна је дозвола „док се користи“, а не „увек“. Прекомерне дозволе наносе троструку штету: подрива поверење корисника, доводи до одбијања продавнице и повећава ризик од цурења података.
Правилно време и објашњење тражења дозволе су од кључне важности. Затражите од корисника дозволу у контексту и са образложењем, као што је „Потребан је приступ камери за скенирање рачуна“. иОС захтева овај опис у Инфо.плист; Празан или обмањујући опис је одбијање продавнице.
Врста дозволе
лош приступ
добар приступ
тајминг
Захтевајте све при покретању
упита када користите функцију
Обим
„Увек локација”
„локација током коришћења“
Опис
Празан или генерички
Конкретно, конкретно оправдање
статус одбијања
Апликација се руши/руши
Љубазно нуди алтернативе
Савет: Ваша апликација би требало да може да настави да ради када је дозвола одбијена. Ако корисник одбије камеру, понудите опцију „ручно пријављивање“. Наметање „дозволи или апликација неће радити“ је и лоше искуство и проблем у продавници. Увек питајте за сценарио одбијања када штампате шифру дозволе на АИ.
Сагласност и кодекс приватности са АИ: разматрања
АИ брзо генерише код који захтева дозволу, али има две типичне замке. Прво, додавање више дозвола него што је потребно: локација, контакти могу масовно ставити дозволе за складиштење „за сваки случај“. Друго, прескакање сценарија одбијања: само напишите статус „дозвољено“ и игноришите одбијање. За сваку добијену дозволу биће вам постављено питање „да ли је ово заиста неопходно?“ и „шта се дешава ако буде одбијено?“ Поставите своја питања.
Опрез: Пример кода који генерише АИ може да складишти корисничке податке без шифровања или да их преноси несигурно. Осетљиве податке (лозинка, здравље, финансије) треба чувати у безбедном складишту на уређају (Кеицхаин — иОС, Кеисторе — Андроид; шифрована област трезора оперативног система) и пренети на мрежу путем шифроване везе (ХТТПС/ТЛС). АИ то не ради увек спонтано; Питајте јасно и проверите.
Минимизација података и слање података у АИ
Подаци које не прикупљате не могу да процуре. Минимизација података (прикупљање само оних података који су заиста потребни) је најмоћније средство за приватност. У функцијама вештачке интелигенције, овај принцип је двоструко важан: када шаљете податке у Цлоуд ЛЛМ или екстерну АИ услугу, ти подаци су ван ваше контроле. Пре него што пошаљете корисничку здравствену белешку, садржај разговора или личне податке у облак, поставите три питања: (1) Да ли су ови подаци заиста неопходни? (2) Може ли се обрадити на уређају? (3) Ако треба да се пошаље, да ли корисник то зна и одобрава? И законски и етички захтев је да се корисник јасно обавести да његови подаци иду у услугу вештачке интелигенције.
Безбедна употреба и фокус на одбрану
Упозорење из ИТ и безбедносне перспективе: технике научене у овом модулу су само за овлашћену и одбрамбену употребу. Легитимно је тестирати безбедност сопствене апликације, заштитити корисничке податке и затворити рањивости. Обрнути инжењеринг туђе апликације без дозволе, прикупљање корисничких података без сагласности или коришћење вештачке интелигенције за креирање малвера је незаконито и неетично. Када тражите од вештачке интелигенције безбедносну помоћ, увек останите у оквиру одбране сопственог система.
три мини кофера
Случај 1 — Одбијање вишка одсуства. Апликација за белешке је при покретању захтевала дозволе за камеру, микрофон, локацију и контакт са кодом који је произвела АИ. Гоогле Плаи је одбацио издање, наводећи „дозволе које нису релевантне за функцију“. Издање је одобрено када је тим издао само дозволу за складиштење која је стварно коришћена. Поука: свако додатно одсуство је ризик.
Случај 2 — Складиштење без лозинке. Здравствена апликација чува мерења корисника у обичној текстуалној датотеци као у примеру АИ. Безбедносна ревизија је открила да свако ко је набавио уређај може да прочита све здравствене податке. Подаци су премештени у шифровано складиште помоћу Кеисторе/Кеицхаин-а. Поука: осетљиви подаци увек остају шифровани.
Случај 3 — Ненајављено слање у облак. Апликација је слала дневне белешке корисника у Цлоуд ЛЛМ да их сумира, али није рекла кориснику. Када је то објављено у штампи, дошло је до губитка поверења и правне контроле. Тим је додао јасно обавештење и потврду, као и опцију на уређају. Поука: корисник мора знати и потврдити да подаци иду у АИ.
Слаби промпт / Јаки промпт
Слаб упит: „Затражите дозволу за локацију.“
Снажан упит: „Затражите дозволу за локацију на иОС/Свифт-у по принципу најмање привилегија. - Само дозволу 'када се користи', а не 'увек' - Инфо.плист опис: 'За приказ оближњих продавница' - Ако је дозвола одбијена: понудите опцију за ручно бирање града, пад - Ако је дозвола одбијена раније, не додајте више подешавања за В него што је потребно за преусмеравање. такође."
Шаблони који се могу копирати
Шаблон за тражење дозволе: „Захтевајте [тип дозволе] дозволу за [платформу].- Минимални обим (када се користи/по потреби)- У контексту, са образложеним објашњењем- Љубазна алтернатива у случају одбијања, никада не руши- Дајте и унос Инфо.плист / Манифест. Немојте додавати додатне дозволе; оправдајте сваку дозволу.“
Шаблон ревизије дозвола: „Проверите дозволе које захтева моја апликација: [листа дозвола + својства]. За сваку дозволу: да ли је заиста потребна? Да ли би ужи опсег био довољан? Да ли би то довело до одбијања продавнице? Означите непотребно.“
Шаблон безбедног складиштења података: „Сигурно чувајте осетљиве податке ([тип]) за [платформу]:- Шифровано помоћу Кеицхаин/Кеисторе- Не чувајте у меморији непотребно дуго- Не пропуштајте у евиденције и резервне копије Обезбедите код и кораке за верификацију.“
Шаблон за слање података АИ: „Размишљам о слању следећих података АИ сервису у облаку: [подаци]. Процена: да ли је заиста потребно? Да ли се могу обрадити на уређају? Ако се шаљу, која поља треба да буду маскирана? Како треба добити сагласност корисника? Препоручите најбезбеднији дизајн у смислу приватности.“
Уобичајене грешке
- Тражите више дозволе него што је потребно. Трострука опасност за поверење, одобрење продавнице и безбедност.
- Групно тражење дозвола при покретању. Захтев за дозволу без контекста је одбијен; затражите функцију одмах.
- Не пишем сценарио одбијања. Апликација која се руши када је дозвола одбијена је и лоша и одбијена.
- Чување осетљивих података без лозинке. Здравље, финансије и лозинке морају се чувати у безбедном складишту.
- Слање података у облак/АИ без обавештавања корисника. Правна и етичка повреда; Обавезно је обавештење и одобрење.
- Неовлашћено коришћење безбедносних техника. То је легитимно само за одбрамбене сврхе вашег сопственог система.
Укратко
Приватност и безбедност су дизајнирани од почетка, а не додавани касније. Основни принцип је најмање привилегија: тражите само неопходну дозволу, када је то потребно, са оправдањем, и понудите љубазну алтернативу у случају одбијања. Осетљиви подаци се чувају у шифрованом складишту и преносе преко шифроване везе. Минимизација података је најјача заштита: подаци које не прикупљате не могу да процуре. Слање података у вештачку интелигенцију, посебно у облак, само по себи је одлука о приватности; Доводи се у питање његова неопходност, ако је могуће, преферира се на уређају, корисник се информише и добија његово/њено одобрење. Сваки произведени код се проверава у односу на тенденције вештачке интелигенције да додаје прекомерне дозволе и небезбедно складишти. Сигурносне технике се користе само у одобрене и одбрамбене сврхе.
Задатак апликације
Направите листу дозвола које апликација (ваш сопствени пројекат или имагинарни) захтева и нека АИ провери које су непотребне или претеране помоћу „Шаблона ревизије дозвола“. Прецизирајте или уклоните бар једну дозволу и напишите сценарио одбијања за ту функцију. Поред тога, ако шаљете корисничке податке у облак, одредите најбезбеднији дизајн помоћу „Шаблона одлуке о слању података у АИ“ и напишите текст одобрења корисника.
контролна листа
- [ ] Тражио сам сваку дозволу са оправдањем, уз принцип најмање привилегија.
- [ ] Тражио сам дозволе у контексту, у време функције, а не масовно при покретању
- [ ] Написао сам скрипту за одбијање за сваку дозволу, без рушења
- [ ] Чувао сам осетљиве податке шифроване помоћу Кеицхаин/Кеисторе
- [ ] Минимизирао сам податке који иду у облак/АИ и додао одобрење корисника
- [ ] Користио сам сигурносне технике само на свом систему у одбрамбене сврхе