Приватність читачів

Власна читацька аналітика

Порахувати перегляд опублікованого матеріалу без рекламного профілювання або ідентифікації читача.

• Після згоди сервер створює випадковий псевдонімний consent UUID. Це не акаунт читача й не анонімний ідентифікатор: UUID пов’язує вибір лише з дозволеними подіями перегляду.
• Analytics UUID — випадкова 122-бітна bearer capability для event/revoke, але не доказ права на експорт або стирання. До consent POST браузер створює й зберігає окрему aimr_<128-bit access id>_<256-bit secret> capability. Сервер отримує лише access id та SHA-256 secret; raw secret не повертається у відповіді й не зберігається сервером.
• Браузер зберігає у localStorage версії policy/vendor-set, стан accepted/rejected/revocation_pending, цей UUID, created_at, revoked_at та retention_expires_at за ключем aimpost.reader-analytics-consent.v2. До 8 незавершених або активних aimr epochs зберігаються однією строгою колекцією за ключем aimpost.reader-privacy-dsar.v2, а до 16 detached receipts — за aimpost.reader-privacy-receipt.v2. Ліміти відмовляють до мережі; автоматичного витіснення чи перезапису немає. Cookies не створюються; sessionStorage, IndexedDB, CacheStorage та service workers для цього контуру не використовуються.
• Дозвіл діє лише коли проміжок від created_at до retention_expires_at дорівнює 395 дням. Після дедлайну запис більше не дає дозволу на подію. Його байти видаляються під час наступного завантаження consent manager, успішного відкликання, відповіді not_recorded або очищення storage читачем; сервер не може дистанційно стерти localStorage браузера, який більше не відкриває AIMPOST.
• Сервер зберігає згоду й події у PostgreSQL, у таблицях reader_analytics_consents та analytics_events.
• Згода зберігається 395 днів після вибору. Кожна подія зберігається до 395 днів, але ніколи не довше за строк батьківської згоди. Після дедлайну дані видаляє обмежений серверний sweeper.
• Це first-party аналітика AIMPOST. Набір зовнішніх аналітичних вендорів порожній; сторонні скрипти, pixels і рекламне профілювання не використовуються.
• Legacy-ключ aimpost.reader-analytics-consent.v1 видаляється без міграції в v2. Видалення локального v1 запису не є authenticated remediation: для legacy-сеансу AIMPOST не заявляє, що виконав експорт, rectification або erasure.

Подія містить лише client event UUID, consent UUID, story UUID, назву story_viewed, версії та часові поля. До аналітичної події не потрапляють IP-адреса, user-agent, URL, referrer, акаунт або довільні властивості.

Права читача: export, rectification та erasure

Дозволити власнику локальної capability запросити обмежений експорт, видалення помилково пов’язаних подій або стирання і перевірити відокремлену квитанцію.

• Raw aimr або aimrr capability передається тільки як Authorization: Bearer. В URL, query string і JSON body немає DSAR secret, consent id, request id або receipt secret.
• Клієнт сам створює одноразову detached receipt capability формату aimrr_<32 lowercase hex>_<43 base64url>. До mutation body потрапляють лише 128-бітний receipt access id та SHA-256 його 256-бітного secret; запит має окремий Idempotency-Key.
• Незавершений receipt блокує нову операцію, але зберігає точний retry. Після terminal response браузер залишає лише detached aimrr, operation, timestamps і proof expiry: epoch_ref, request payload та Idempotency-Key стають null. Явне видалення в UI вимагає попередження; доступний export receipt не можна забути до останньої сторінки.
• Export повертається сторінками від 1 до 100 записів. Його bytes не записуються в localStorage, sessionStorage, IndexedDB або CacheStorage; тимчасовий Blob URL відкликається відразу після передачі браузеру.
• Rectification у цій фазі означає тільки delete_inaccurate_story_view: від 1 до 100 унікальних event UUID і одна з трьох закритих причин. Вільного action/reason немає.
• Після receipt зі станом completed для erasure браузер видаляє поточний analytics record та лише відповідний aimr epoch, а інші не прострочені v2 epochs зберігає. Detached aimrr лишається без consent id, epoch link, event UUID або retry payload. Інша вкладка синхронізує видалення й abort in-flight.
• Receipt окремо показує межі server-live scope, browser storage та backup erasure. Завершення server-live операції не означає фізичне стирання старих bytes з backup. Серверний proof має технічний строк 1095 днів; локальні aimrr bytes можуть лишатися до очищення браузером, але не продовжують цей строк. Правова підстава й retention ще очікують counsel approval.
• Відсутність локальної aimr capability зупиняє автоматичні events в офіційному Web-клієнті v2, щоб не збирати дані без доступного self-service. Це не змінює серверний event-auth контракт: API як і раніше перевіряє analytics consent UUID.

Суворе обмеження записів аналітики

Обмежувати неавтентифіковані запити, що створюють згоду, відкликають її або записують подію, і відмовляти в записі, якщо захист недоступний.

• Consent, revoke та event мають окремі Redis namespace, тому трафік подій не витрачає бюджет відкликання. У staging/production обов’язковий окремий секрет, і ключ містить лише HMAC-SHA256 псевдонім IP-адреси. Глобальний bucket на кожну операцію дозволений тільки в development/test; raw IP до суворого ключа не потрапляє.
• Логічний TTL активного Redis-ключа — 600 секунд типово, максимум — 3600 секунд. Типовий ліміт — 20 запитів, жорсткий максимум — 1000.
• У ключ не входять consent UUID, story UUID, тіло запиту чи зв’язок з аналітичною подією. Якщо цей захист недоступний, mutation відхиляється, а не виконується без ліміту.
• Redis наразі persistent: після TTL ключ уже не читається, однак старі байти команди можуть лишатися в AOF або backup до rewrite та видалення резервної копії. TTL не заявляється як фізичне стирання байтів.

Це first-party технічна мета без browser storage або зовнішнього сервісу; правова підстава має статус PENDING_COUNSEL_APPROVAL.

Короткочасний захист API від зловживань

Тимчасово обмежувати надмірні запити до публічних API та захищати доступність сервісу.

• Пряма IP-адреса клієнта входить до тимчасового ключа Redis aimpost:public-rl:<client IP> разом із лічильником і TTL.
• Логічний TTL активного ключа — 60 секунд типово, максимум — 3600 секунд.
• Це окрема first-party мета без browser storage, зовнішнього сервісу, постійного профілю читача або зв’язку з аналітичними подіями.
• Persistent Redis може зберігати старі байти команди в AOF або backup після логічного TTL до rewrite та завершення backup lifecycle; це відкрита частина production-like restore/retention gate.

Цей технічний захист не залежить від згоди на необов’язкову аналітику. Його правова підстава має статус PENDING_COUNSEL_APPROVAL.

Які Telegram-дані обробляються

• Telegram user ID і chat ID приватного чату — щоб прив’язати та доставити підписку.
• Обрана тема або сутність, частота, часовий пояс, тихі години, денний ліміт і згода на термінові сповіщення.
• Версія, джерело й час згоди, а також стан активації або відписки.
• Технічні записи про постановку повідомлення в чергу, спробу доставки, Telegram message ID і обмежений код помилки, якщо доставка не вдалася.

Одноразове посилання на підписку містить випадковий секрет. Сервер зберігає лише його криптографічний відбиток; посилання має обмежений строк дії.

Telegram як зовнішній сервіс

Підтвердити налаштування читача, запланувати й доставити вибрані сповіщення та розслідувати технічні збої.

Після відкриття бота взаємодія відбувається через Telegram. Telegram отримує дані акаунта, чату та повідомлень і обробляє їх за власними правилами. Простий перегляд кнопки підписки на сайті не передає Telegram дані; перехід відбувається лише після дії читача. Юридична роль Telegram ще очікує окремого погодження.

Telegram: зберігання та видалення

Прямі Telegram-ідентифікатори зберігаються, поки потрібна активна читацька прив’язка. Щоб видалити її, надішліть команду /delete у приватному чаті з ботом. Система обнулить Telegram user/chat ID та внутрішні прив’язки, деактивує підписки й скасує ще не відправлені доставки.

Технічна історія операцій може залишатися з непрямими внутрішніми UUID для цілісності доставки, аудиту та безпеки, без активної прив’язки до Telegram ID. Строк зберігання має статус PENDING_COUNSEL_APPROVAL і потребує погодження до публічного запуску.

Без відстеження відкриттів

AIMPOST не додає до Telegram-повідомлень пікселі відкриття й не має надійного сигналу, що повідомлення було прочитано. Тому показники відкриттів і скарг не підміняються припущеннями: за відсутності підтверджених даних вони позначаються як недоступні.