Приватність
Приватність починається з чесного опису того, що існує сьогодні.
Ця сторінка проєкту відділяє публічний презентаційний сайт від майбутньої обробки даних у продукті Huddle, дослідженнях і сімейному контексті.
Два контексти
Публічний сайт і майбутній продукт потребують окремих обіцянок.
Поточний обсяг
Публічний сайт `.com` пояснює проєкт Huddle і напрям прототипу. Він має описувати лише ті потоки даних, які реально існують на опублікованому сайті, наприклад перевірений канал зв’язку, технічну доставку або затверджену форму інтересу до дослідження, якщо й коли такі функції з’являться.
Майбутні облікові записи, сімейні профілі, контекст дітей, рекомендації, дії на маркетплейсі й інституційна аналітика потребують окремих повідомлень для кожної мети до початку обробки. Концепція продукту не доводить, що такі операції з даними діють сьогодні.
Ця сторінка проєкту відділяє публічний презентаційний сайт від майбутньої обробки даних у продукті Huddle, дослідженнях і сімейному контексті.
Пояснити поточні межі приватності, визначити факти, які ще потребують перевірки, і не подавати майбутні продуктові наміри як чинну практику обробки даних.
Приватність у дизайні
Збирати менше. Пояснювати мету. Залишати контроль сім’ї.
Мінімізація даних
До публікації перевіреного повідомлення й безпечного каналу для конкретної мети відвідувачам не слід надсилати через загальні контактні поля дані, що ідентифікують дитину, медичні відомості, повідомлення про загрози, облікові дані, матеріали справ або іншу чутливу інформацію.
Заплановані принципи дизайну Huddle включають обмеження мети, контроль дорослих, розділення сімейної та інституційної видимості, обмежений доступ і строки зберігання. Це проєктні зобов’язання, які потребують юридичної, приватнісної, безпекової й технічної валідації.
- 01◎Мета до збору
- 02◇Лише необхідні дані
- 03✓Окремі згоди й повідомлення
- 04↺Виправлення, видалення та строки
До production
Що ще потрібно перевірити
Повне повідомлення про приватність потребує конкретних фактів, а не заповнювачів чи припущень.
До публікації у продуктивному середовищі відповідальний власник має перевірити видавця сайту, контролера, канал зв’язку, цілі, категорії даних, правові підстави, одержувачів і обробників, міжнародні передачі, строки зберігання, заходи безпеки та процедури реалізації прав.
Ця чернетка не підтверджує зареєстровану юридичну особу, уповноваженого із захисту даних, перелік обробників, правову підставу, строк зберігання, продуктивну обробку чи відповідність законодавству. Остаточний текст потребує підтвердження власника та юридичної і приватнісної перевірки за фактично розгорнутою системою.
Мета й походження
Кожен елемент даних потребує джерела, мети, відповідального й кінцевої дати.
Майбутні повідомлення продукту мають розрізняти дані, введені сім’єю, факти провайдера, публічні джерела, технічні записи й згенеровані висновки. Мета і правова підстава можуть відрізнятися для облікового запису, дослідження, підтримки, безпеки, комерції та агрегованого інституційного навчання; одна згода не повинна приховано дозволяти всі використання.
Сім’я має розуміти маршрути доступу, виправлення, видалення, перенесення, заперечення й відкликання, де вони застосовні. Запити потребують автентифікованого безпечного процесу, який не розкриває іншого члена домогосподарства й без пояснення не видаляє записи, що мають зберігатися на законній підставі.
Чутливий контекст
Huddle не повинен виводити про сім’ю більше, ніж потрібно для завдання.
Сімейний контекст може розкривати інвалідність, фінанси, міграцію, релігію, здоров’я, стосунки або розклад дитини, навіть якщо ці поля не запитуються прямо. Дизайн продукту має не допускати поєднання звичайних сигналів у чутливий профіль і забороняти рейтинги сімей, батьків, дітей та соціальні рейтинги.
Місце слід використовувати в найменш точній формі, достатній для завдання. Для пошуку може знадобитися район, оцінка дороги або вибрана початкова точка; це не виправдовує фонове відстеження, історію місць чи інституційний доступ до пересувань сім’ї.
Оцінювання до обробки
Обробка високого ризику потребує оцінювання до того, як код або згода створять враження її прийнятності.
DPIA або еквівалентна фахова оцінка може бути потрібна для контексту дітей, систематичних рекомендацій, чутливих висновків, моніторингу, геолокації, масштабних досліджень чи інституційної аналітики. Оцінювання має охоплювати необхідність, пропорційність, загрози, постраждалих осіб, заходи, залишковий ризик і відповідальне рішення про схвалення.
Архітектура безпеки має охоплювати ідентичність, рольовий доступ, шифрування, журнали, резервні копії, видалення, контроль постачальників, тестування, реагування на порушення й відновлення. Це вимоги до майбутньої роботи; сторінка не підтверджує існування продуктивної системи сімейних даних або відповідність конкретному режиму.
Наступний відповідальний крок