Кабінет B2B відправника Укрпошти (неофіційний)

Політика конфіденційності

Статус: чинна редакція. Ця Політика конфіденційності є чинною і застосовується до обробки персональних даних Сервісом.

Версія: 1.2 Дата набрання чинності: 04.08.2026

Ця Політика пояснює, які персональні дані обробляє сервіс «Кабінет B2B відправника Укрпошти (неофіційний)» (далі — Сервіс), на яких підставах, кому передає, скільки зберігає і як реалізуються права суб'єктів даних. Текст описує фактичну поведінку працюючого коду, а не намір: там, де дані зберігаються довше або ширше, ніж хотілося б, це сказано прямо.

1. Хто є ким: володілець і розпорядник

1.1. Щодо даних отримувачів відправлень ролі розподілені так:

  • Користувач (відправник) — володілець персональних даних отримувачів. Він вносить ці дані, визначає мету і засоби їх обробки, гарантує наявність правової підстави та самостійно виконує обов'язки володільця перед суб'єктами даних.
  • Виконавець — розпорядник, який обробляє ці дані виключно за дорученням Користувача і в обсязі, потрібному для роботи Сервісу.

Це розмежування продубльовано в розділі 5 Умов використання і не є формальністю: звернення отримувача щодо його даних за загальним правилом адресується відправнику, який ці дані вніс. Виконавець сприяє в межах технічних можливостей (див. розділ 8) і в частині власних журналів діє як самостійний володілець.

1.2. Щодо даних самих користувачів Кабінету (обліковий запис, вхід, платежі) Виконавець є володільцем.

1.3. Володілець і його реквізити:

  • Найменування: Товариство з обмеженою відповідальністю «СМАРТ СЕЙЛЗ ХАУЗ ПРОМОБІЛЛ»
  • Код ЄДРПОУ: 40279347
  • Місцезнаходження: 02094, м. Київ, вул. Михайла Бойчука, буд. 9/12, кв. 7
  • Адреса для звернень суб'єктів персональних даних: support.ukrposhta@main.fish
  • Контакт особи, відповідальної за захист персональних даних: Директор, support.ukrposhta@main.fish

2. Які дані обробляються

Перелік нижче звірено з фактичною схемою бази даних Сервісу. Назви в дужках — технічні назви сутностей і полів.

2.1. Дані отримувачів у адресній книзі (Recipient)

Локальний довідник отримувачів, який веде Користувач. Зберігається у відкритому вигляді (без шифрування). Склад:

  • тип отримувача (RecipientType: фізична особа / юридична особа);
  • ім'я та прізвище (FirstName, LastName), назва юрособи (CompanyName), код ЄДРПОУ (Edrpou);
  • телефон у введеному вигляді (Phone) і нормалізований ключ телефону (RecipientPhoneNormalized) — останні 9 цифр номера; саме за ним працюють пошук і дедуплікація записів у межах підключення;
  • електронна пошта (Email);
  • адреса: індекс (Postcode), область (Region), населений пункт (City), вулиця (Street), будинок (HouseNumber), квартира (ApartmentNumber);
  • структурні ідентифікатори адресного класифікатора (RegionId, CityId, StreetId, PostOfficeId) і назва відділення (PostOfficeName);
  • UUID клієнта-отримувача в Укрпошті (ClientUuid), якщо вказано;
  • довільний коментар Користувача (Comment) — поле вільного тексту, вміст якого визначає виключно Користувач.

Правова підстава: обробка за дорученням володільця (Користувача) для виконання договору про надання доступу до ПЗ; підставу щодо самих суб'єктів даних забезпечує Користувач.

2.2. Дані відправників (SavedSender)

Картки відправників Користувача: відображуване ім'я (DisplayName), телефон (Phone), пошта (Email), індекс (Postcode), місто (City), тип (Type), код ЄДРПОУ (Edrpou), зовнішній ідентифікатор (ExternalId), UUID клієнта в Укрпошті (UkrClientUuid).

Окремо звертаємо увагу: поле Tin зберігає ІПН/РНОКПП (реєстраційний номер облікової картки платника податків) фізичної особи — підприємця. Це чутливий податковий ідентифікатор, і він зберігається у відкритому вигляді. Заповнюється Користувачем добровільно і лише тоді, коли відправником є ФОП.

Правова підстава: виконання договору з Користувачем (стаття 11 Закону України «Про захист персональних даних»).

2.3. Власні чорні списки отримувачів (RecipientBlacklistEntry)

Перелік отримувачів, за якими конкретний Користувач не бажає створювати відправлення: телефон (Phone), нормалізований телефон (PhoneNormalized, останні 9 цифр), код ЄДРПОУ (Edrpou), ПІБ/назва для показу (DisplayName), причина внесення вільним текстом (Reason) і рівень реакції (Level: «warn» — попередити, «block» — заборонити створення).

Правова підстава: законний інтерес Користувача у захисті від недобросовісних отримувачів (відмови від викупу, систематичні повернення). Наслідки для суб'єкта даних описані в пункті 7.3 — прочитайте його.

2.4. Дані отримувачів у самих відправленнях (Shipment)

Локальний реєстр створених ТТН зберігає ім'я отримувача (RecipientName), його телефон (RecipientPhone), пошту (RecipientEmail) і нормалізований телефон (RecipientPhoneNormalized), а також параметри відправлення (штрихкод, вага, оголошена вартість, накладний платіж, статуси трекінгу).

Правова підстава: виконання юридичного обов'язку зі зберігання первинних документів + законний інтерес у доказовій базі. Ці записи не видаляються — див. розділ 6.

2.5. Дані облікового запису (ApplicationUser)

Адреса електронної пошти (Email, успадковано від ASP.NET Core Identity), відображуване ім'я або назва компанії (FullName), ідентифікатор облікового запису Google (GoogleId — Google subject id, якщо вхід прив'язано до Google), хеш пароля (PasswordHash — зберігається у вигляді хешу, не самого пароля), час останнього входу (LastLoginAt), налаштування розсилки (EmailDigestOptOut, LastDigestSentAt).

Правова підстава: виконання договору з Користувачем; для розсилки дайджесту — законний інтерес з можливістю відмови.

2.6. Прив'язка Telegram (TelegramChat)

Ідентифікатор чату Telegram (ChatId) користувача-орендаря, момент прив'язки (LinkedAt) і прапорець активності (Enabled). Використовується лише для надсилання цьому Користувачеві сповіщень про статуси його відправлень.

Правова підстава: згода Користувача (прив'язка є добровільною дією).

2.7. Діагностичний журнал запитів до Укрпошти (ApiRequestLog)

Технічний журнал звернень Сервісу до API Укрпошти: користувач, від імені якого зроблено запит (UserId), підключення (ConnectionId), канал (Channel), метод (Method), URL з вирізаним токеном (Url), тіло запиту (RequestBody), код і тіло відповіді (ResponseStatus, ResponseBody), тривалість (DurationMs).

Читайте це місце уважно — тут персональні дані є. Тіла запитів і відповідей проходять через маскувальник (SecretMasker) і обрізаються за лімітом (16 384 символи). Маскувальник прибирає ЛИШЕ секрети — токени доступу, значення полів на кшталт token, apikey, password, secret, рядки «Bearer …». Персональні дані він не чіпає взагалі. Отже ПІБ, телефон, електронна пошта та адреса отримувача осідають у цьому журналі у відкритому вигляді, оскільки саме вони становлять тіло запиту на створення ТТН.

Строк зберігання: 30 днів (InvestigationsOptions.ApiLogRetentionDays). Прострочені рядки видаляє фонова служба InvestigationsCleanupService, яка виконує прогін раз на добу; тобто фактичний строк — до 30 днів плюс час до наступного добового прогону.

Правова підстава: законний інтерес у діагностиці, розслідуванні збоїв і захисті Сервісу.

2.8. Аудит дій у Кабінеті (AuditEvent)

Хто, коли і над чим виконав дію: канонічна дія (Action, напр. «shipment.create»), тип і ідентифікатор об'єкта (ObjectType, ObjectId), результат (Result), людиночитаний опис (Summary) і додаткові структуровані поля (DetailsJson). Опис і деталі можуть містити імена та інші дані отримувачів — вони пишуться для того, щоб рядок аудиту був зрозумілим.

Строк зберігання: 180 днів (InvestigationsOptions.AuditRetentionDays), прибирає та сама служба InvestigationsCleanupService добовим прогоном.

Правова підстава: законний інтерес у безпеці, розслідуванні інцидентів і вирішенні спорів.

2.9. Дані отримувача, зібрані напряму через хостований чекаут (CargoCollection)

На відміну від пунктів 2.1 і 2.4, де дані отримувача вносить сам Користувач, тут ідеться про дані, які покупець (отримувач) залишає напряму — на розміщеній Сервісом сторінці хостованого чекауту, перейшовши за згенерованим Сервісом посиланням. Запис створює інтегратор Користувача (реєстрація вантажу), а поля отримувача заповнює сам покупець при оформленні. Склад — той самий мінімум, що потрібен для формування ТТН, і дзеркалить адресну книгу (пункт 2.1):

  • тип отримувача (RecipientType: фізична / юридична особа), ім'я та прізвище (FirstName, LastName) або назва юрособи (CompanyName) і код ЄДРПОУ (Edrpou);
  • телефон у введеному вигляді (Phone) і нормалізований ключ телефону (RecipientPhoneNormalized, останні 9 цифр), електронна пошта (Email);
  • тип доставки (DeliveryType) та адреса: структурні ідентифікатори класифікатора й людські підписи (RegionId/RegionName, CityId/CityName, StreetId/StreetName, PostOfficeId/PostOfficeName), індекс (Postcode), будинок (HouseNumber), квартира (ApartmentNumber);
  • слід згоди покупця: версія тексту згоди (ConsentVersion), момент (ConsentAt) та IP (ConsentIp), з якого залишено дані, — щоб мати доказ у спорі «залишав / не залишав» адресу.

Дані зберігаються у відкритому вигляді (без шифрування), як і решта даних отримувачів (пункт 10.2). До хостованого чекауту застосовується розділ 15 Публічної оферти; чинний текст згоди покупця показується йому на сторінці чекауту окремим документом.

Правова підстава: обробка за дорученням володільця (Користувача-відправника) для формування ТТН та згода суб'єкта даних (покупця), яку він надає, залишаючи дані на сторінці чекауту. Щодо цих даних Виконавець є розпорядником і обробляє їх виключно в обсязі, потрібному для формування відправлення (пункт 1.1).

Строк зберігання. Зібрана адреса потрібна відправнику лише щоб сформувати відправлення, тому тримається обмежено й прибирається фоновою службою CheckoutRetentionService (добовий прогін):

  • незібрані прострочені вантажі (посилання, за яким покупець так і не залишив адресу) видаляються після спливу строку дії посилання (CargoCollection.ExpiresAt; за замовчуванням — 7 днів від реєстрації, Checkout:LinkTtl) — персональних даних у них немає;
  • зібрані дані видаляються за строком Checkout:CollectedDataRetention (за замовчуванням 30 днів від моменту збору). Після формування ТТН дані живуть уже в самій ТТН (пункт 2.4) як первинний документ — за строками розділу 6, незалежно від видалення цього запису.

Права суб'єкта реалізуються в порядку розділу 7. Оскільки щодо цих даних Виконавець є розпорядником, звернення покупця за загальним правилом адресується володільцю — Користувачеві-відправнику, який ці дані зібрав (пункт 8.4).

2.10. Журнал вхідних запитів до Сервісу (InboundRequestLog)

Дзеркальна пара до пункту 2.7: там записуються звернення Сервісу до API Укрпошти, тут — звернення до самого Сервісу. Журналюються всі точки входу: публічний машинний API (/api/v1), MCP-сервер (/mcp), Кабінет, а також анонімні звернення (хостований чекаут, серверний колбек платіжного оператора, вебхук Telegram). Не журналюються службова адреса моніторингу (/health), машинна специфікація API та статичні файли Кабінету.

Рядок створюється ЛИШЕ на невдачі — коли відповідь має код 400 і вище або запит обірвався помилкою. Успішне звернення рядка в цьому журналі не породжує взагалі. Сенс журналу саме такий: показати, що надіслав клієнт, якому Сервіс відмовив, — інакше відмову («400», «409», «429») нема чим розібрати.

Склад рядка: користувач і підключення, якщо їх удалося визначити (UserId, ConnectionId — у невдалих входах вони порожні), точка входу (Source), метод (Method), шлях разом із рядком запиту і вирізаними секретами (Path), тіло запиту (RequestBody), код і тіло відповіді (ResponseStatus, ResponseBody), тривалість (DurationMs), IP-адреса, з якої прийшов виклик (RemoteIp), рядок User-Agent (UserAgent), префікс ключа API, яким пред'явлено виклик (ApiKeyPrefix — перші символи, не сам ключ і не його хеш), машинний код помилки (ErrorCode), момент (CreatedAt).

Тут персональні дані є — рівно з тієї самої причини, що й у пункті 2.7. Тіла проходять через той самий маскувальник (SecretMasker) і той самий ліміт (16 384 символи), а маскувальник прибирає ЛИШЕ секрети й персональних даних не чіпає взагалі. Отже, коли зовнішній клієнт надіслав із помилкою запит на створення ТТН, ПІБ, телефон, електронна пошта та адреса отримувача осідають у цьому журналі у відкритому вигляді. Те саме стосується рядка запиту у складі Path: частина адрес Кабінету приймає номер телефону саме параметром адреси (перевірка телефону отримувача, звірка з чорним списком, картка номера), і при невдалій відповіді номер осідає в Path у відкритому вигляді — вирізаються звідти лише секрети, не персональні дані. Окремо назвемо прямо: IP-адреса та рядок User-Agent — це дані про самого Користувача (його інтегратора), а не про отримувача. Файлові вивантаження (multipart/…) у журнал не читаються зовсім, а бінарні відповіді (PDF/ZIP друкованих форм) не зберігаються — від них лишається тільки код відповіді. Так само не зберігається тіло запиту, більше за той самий ліміт (від нього лишається позначка з розміром): такий запит для журналу не читається взагалі. Запити на адреси, яких у Сервісі немає (помилка 404 «такого шляху немає»), потрапляють у журнал без тіл і з обмеженням за частотою (з однієї IP-адреси — не більше 30 таких рядків за хвилину; понад це рядок не створюється зовсім) — від записаних лишаються сама адреса, код відповіді й метадані. Так само з обмеженням за частотою з однієї IP-адреси (не більше 60 рядків за хвилину; понад це рядок не створюється) журналюються анонімні звернення за наявними адресами — виклик реального ендпоінта без установленої особи (без валідного ключа: битий, відкликаний або чужий ключ, брак потрібного скоупа чи перебір ліміта звернень). Натомість звернення, у якому особу вже встановлено на момент запису (перевірений ключ API або кабінетний вхід), обмеженню за частотою не підлягає — там рядок пишеться на кожну невдачу. Уточнимо для повноти: частину звернень Сервіс відбиває ще до перевірки ключа (захист від надмірної частоти запитів), і для журналу вони теж рахуються анонімними — тобто підпадають під те саме обмеження 60 рядків за хвилину, навіть якщо ключ був дійсний.

Строк зберігання: 30 днів (InvestigationsOptions.InboundLogRetentionDays). Прострочені рядки видаляє та сама фонова служба InvestigationsCleanupService добовим прогоном; фактичний строк — до 30 днів плюс час до наступного прогону.

На відміну від пункту 2.7, цей журнал очищається на вимогу суб'єкта даних. За підтвердженим номером телефону в усіх рядках, де цей номер трапляється у будь-якому написанні (+380…, 380…, 0…, самі значущі цифри, а також із пробілами, дефісами й дужками між групами): тіла запиту й відповіді затираються (разом із машинним кодом помилки — ErrorCode, бо він теж береться з тіла відповіді), а зі шляху вирізається весь рядок запиту (лишається сама адреса без параметрів). Решта метаданих рядка — код відповіді, адреса без параметрів, момент — лишаються: персональних даних у них немає. Порядок — розділ 7.

Правова підстава: законний інтерес у діагностиці, розслідуванні збоїв і захисті Сервісу — зокрема у виявленні зловживань, підбору ключів доступу та автоматизованого сканування.

3. Незмінний журнал-доказ (UkrposhtaApiLog) — зберігається безстроково

Це найважливіший розділ цієї Політики. Пропустити його не можна.

3.1. Що це. Окремо від діагностичного журналу (пункт 2.7) Сервіс веде незмінний журнал звернень до API Укрпошти як доказ того, що і коли сервіс Укрпошти нам відповів. Записи пишуться лише додаванням і входять у хеш-ланцюг: кожен рядок містить хеш попереднього (PrevHash) і власний хеш (RowHash). Правка або видалення рядка розриває ланцюг і виявляється перевіркою цілісності.

3.2. Строку зберігання немає. Записи цього журналу не видаляються взагалі — ні за строком, ні на запит. Це не недогляд, а наслідок самої конструкції: видалення рядка зламало б хеш-ланцюг, тобто знищило б доказову цінність усього журналу тенанта. Ретенція для цієї таблиці не налаштована й не передбачена.

3.3. Чи є там персональні дані — так, є, і це свідоме рішення. Механіка така (діє правило «за замовчуванням — не зберігати»):

  • Тіло запиту з каналів, що несуть персональні дані (eCom, Forms, адресний класифікатор, а також будь-який невідомий канал — тобто всі, крім трекінгу), у журнал не потрапляє: замість нього записується маркер «тіло запиту не збережено: канал «…» несе персональні дані». Причина — дані запиту не доводять нічого, тож підстави тримати їх безстроково немає.
  • Тіло відповіді з таких каналів потрапляє в журнал лише тоді, коли підставу явно заявлено в коді (EvidenceResponseBasis.PersonalDataAsProof); інакше замість нього лягає маркер «тіло відповіді не збережено…».
  • Єдиний канал, вільний від персональних даних, — трекінг (штрихкоди й коди подій); його тіла зберігаються повністю.

3.4. Наслідок, який треба назвати прямо. Сьогодні підстава PersonalDataAsProof заявлена для сканів повідомлення про вручення, які фіксуються на явну дію користувача. Такий скан і є доказ вручення, і він містить ПІБ, адресу та підпис/телефон отримувача у відкритому вигляді. Отже: для цих рядків персональні дані отримувача зберігаються безстроково, у відкритому вигляді, і на вимогу не видаляються.

3.5. Правова підстава: виконання юридичного обов'язку зі зберігання первинних документів та законний інтерес у формуванні доказової бази у претензійно-позовній роботі з АТ «Укрпошта» (спори про втрату, пошкодження, невручення відправлення). З цих рядків формується доказовий пакет по ТТН, який передається назовні — до АТ «Укрпошта», страховика чи суду; такий пакет не є знеособленим, і кожне його вивантаження фіксується в аудиті окремим записом (claim.package-export).

3.6. Обмеження. Розкривати й вивантажувати цей журнал ширше за претензійну роботу заборонено; доступ до перевірки та вивантаження мають лише користувачі з роллю «Менеджер» і вище в межах свого підключення.

3.7. Чесно про модель захисту. Журнал є tamper-evident, а не tamper-proof: наївна правка виявляється перевіркою, але особа з доступом на запис до бази могла б перерахувати хеші й пройти перевірку. Зовнішнього якоря ланцюга наразі немає.

4. Кому передаються дані

4.1. АТ «Укрпошта» — дані отримувача (ПІБ або назва, телефон, електронна пошта, адреса, код ЄДРПОУ) передаються до її API (eCom, Forms, StatusTracking) за вказівкою Користувача — щоб Укрпошта могла надати поштову послугу. Це передача самостійному володільцю: далі АТ «Укрпошта» обробляє ці дані за власними правилами і на підставі окремого договору, укладеного Користувачем із нею. Сервіс не є АТ «Укрпошта» і не афілійований з нею.

4.2. Amazon Web Services (AWS SES) — сервіс надсилання електронної пошти. Через нього йдуть листи Сервісу (одноразові посилання для входу, запрошення, сповіщення) з адреси noreply@main.fish. Передається адреса електронної пошти одержувача листа та вміст листа. Регіон обробки — eu-central-1 (Франкфурт, Німеччина), тобто має місце транскордонна передача персональних даних за межі України — до держави — члена Європейського Союзу, що забезпечує належний рівень захисту персональних даних у розумінні статті 29 Закону України «Про захист персональних даних».

4.3. Платіжний оператор (еквайринг) — поповнення балансу здійснюється через ліцензованого платіжного оператора (еквайра); його найменування та реквізити відображаються Користувачеві безпосередньо на сторінці оплати на стороні оператора. Тут — на нашу користь і чесно: у платіжному запиті не передаються персональні дані взагалі. Payload містить рівно: публічний ключ, версію протоколу, дію, суму, валюту, ідентифікатор замовлення (order_id), опис платежу та службові URL. Опис будується автоматично із суми та кількості придбаваних прав на створення ТТН; order_id — випадково згенерований ідентифікатор, який нікого не ідентифікує. Реквізити платіжної картки Користувач вводить безпосередньо на стороні платіжного оператора — до Сервісу вони не потрапляють, Сервісом не обробляються і ним не зберігаються.

4.4. Telegram (Bot API) — якщо Користувач добровільно прив'язав чат, до Telegram передаються ідентифікатор його чату та текст сповіщення про статуси його власних відправлень. Telegram є самостійним володільцем щодо даних свого користувача.

4.5. Персональні дані не продаються, не передаються рекламним мережам і не використовуються для профілювання чи автоматизованого прийняття рішень, що породжують юридичні наслідки для суб'єкта даних.

5. Файли cookie та сесії

Сервіс не використовує рекламних, маркетингових чи трекінгових cookie і не підключає сторонніх систем веб-аналітики. Використовуються виключно технічно необхідні механізми:

  • auth_exchange_token — короткоживучий cookie обміну для входу за одноразовим посиланням (magic link). Потрібен, щоб посилання з листа не спрацьовувало у сканерів пошти: обмін відбувається лише в тому браузері, який запитав вхід. Живе кілька хвилин і видаляється одразу після обміну.
  • ukrposhta_external — тимчасовий cookie процедури входу через Google (лише на час самого перенаправлення, до 10 хвилин).
  • Токен сесії після входу зберігається не в cookie, а в локальному сховищі браузера (localStorage) і додається до запитів заголовком Authorization. Він зникає при виході з Кабінету або очищенні даних сайту.

Підстава — виконання договору (без цих механізмів вхід до Кабінету неможливий), тому окремої згоди на них не вимагається.

6. Історія відправлень не видаляється

Це окреме і важливе застереження. Пом'якшувати його ми не будемо.

6.1. Дані отримувача, що потрапили до історії відправлень, за запитом про видалення не видаляються. Ідеться про:

  • записи реєстру ТТН (Shipment: RecipientName, RecipientPhone, RecipientEmail, RecipientPhoneNormalized);
  • сформовані реєстри за формою 103 та інші друковані форми відправлень;
  • незмінний журнал-доказ (UkrposhtaApiLog) — див. розділ 3.

6.2. Чому. Це первинні документи, що фіксують факт господарської операції. Їх зберігання є юридичним обов'язком Виконавця і Користувача (законодавство про бухгалтерський облік і фінансову звітність, податкове законодавство), а також необхідне для формування доказової бази у спорах щодо пересилання відправлень. Обробка на цій підставі не потребує згоди суб'єкта даних і не припиняється за його запереченням: право на видалення поступається обов'язку зберігання.

6.3. Строк зберігання первинних документів: 3 роки. Після спливу цього строку документи знищуються в установленому порядку — за винятком записів незмінного журналу-доказу (розділ 3), які не видаляються взагалі.

6.4. Тобто видалення адресної книги (розділ 7) не стирає слід про вже здійснені відправлення: воно прибирає запис із довідника, яким Користувач користується для створення нових ТТН, і не торкається історії.

7. Видалення персональних даних

7.1. Основний канал — звернення на пошту

Гарантований спосіб реалізувати свої права — надіслати звернення на support.ukrposhta@main.fish. Цей канал працює завжди, не залежить від наявності будь-яких технічних засобів і є достатнім у розумінні Закону України «Про захист персональних даних».

У зверненні слід зазначити, яких саме даних воно стосується (як мінімум — номер телефону або код ЄДРПОУ, за якими дані можна знайти), і чого суб'єкт вимагає.

Строк розгляду: 30 днів з дня отримання звернення. Про результат — задоволення вимоги повністю, частково або відмову з обґрунтуванням — суб'єкт повідомляється у відповідь.

Відповідь на звернення чесно назве межі можливого: те, що не видаляється (розділи 3 і 6) і те, що не видаляється, а хешується (пункт 7.3).

7.2. Додатковий канал — видалення через Telegram-бот

Окремо від пункту 7.1 передбачено самостійне видалення з адресних книг через Telegram-бот: t.me/ukrposhta_b2b_cabinet_bot.

Процедура рівно така:

  1. Суб'єкт відкриває бот і підтверджує свій номер телефону кнопкою «поділитися номером» — номер надходить безпосередньо від Telegram, а бот перевіряє, що поділився ним саме власник цього облікового запису Telegram. Ввести довільний чужий номер вручну неможливо — це і є верифікація.
  2. Після підтвердження видаляються записи адресних книг отримувачів (Recipient) в усіх користувачів Сервісу, у яких нормалізований номер (останні 9 цифр) збігається з підтвердженим.
  3. Тією самою операцією і теж в усіх користувачів Сервісу: видаляються незавершені записи про зміну отримувача ТТН (ShipmentRecipientChange — проміжний стан операції, яку не доведено до кінця) і очищається журнал вхідних запитів (пункт 2.10) там, де підтверджений номер трапляється в будь-якому написанні: затираються тіла запиту й відповіді разом із машинним кодом помилки, а зі шляху вирізається рядок запиту.

Межі цього каналу — прямо:

  • він зачіпає лише те, що названо в пунктах 2 і 3 вище: адресні книги отримувачів (Recipient), незавершені зміни отримувача та тіла, машинний код помилки й рядок запиту в журналі вхідних запитів;
  • він не видаляє дані з історії відправлень (розділ 6), з діагностичного журналу (пункт 2.7), з аудиту (пункт 2.8) та з незмінного журналу-доказу (розділ 3);
  • він не видаляє записи чорних списків — див. пункт 7.3;
  • він не є «повним стиранням даних» і не подається як таке.

Обмеженість цього каналу не звужує прав суб'єкта: повне за обсягом звернення слід надсилати на пошту (пункт 7.1).

7.3. Чорні списки не видаляються — телефон хешується

Записи чорних списків (RecipientBlacklistEntry) на запит про видалення не видаляються. Це чинне правило, і воно діє вже зараз.

Замість видалення номер телефону в такому записі замінюється на ключований хеш (keyed hash) — необоротне перетворення, з якого сам номер прочитати не можна; відкриті поля (Phone, PhoneNormalized) при цьому затираються.

Прямий наслідок для суб'єкта даних, який треба розуміти і який не залежить від хешування: звірка при створенні ТТН продовжує працювати. Тобто якщо профіль із тим самим номером телефону з'явиться знову, він і надалі підсвітиться у відправника попередженням або забороною створення ТТН — так само, як до запиту про видалення.

Це свідоме рішення, а не побічний ефект. Правова підстава — законний інтерес відправника у захисті від недобросовісних отримувачів: сенс чорного списку саме в тому, щоб пережити повторну появу того самого номера, і видалення запису на вимогу внесеної до нього особи знищило б цей механізм повністю. Хешування — компроміс: сам номер у відкритому вигляді більше не зберігатиметься і не зможе бути прочитаним, а захисна функція збережеться. Причина внесення (Reason), внесена Користувачем, залишається в записі.

8. Права суб'єкта персональних даних

8.1. Відповідно до статті 8 Закону України «Про захист персональних даних» суб'єкт персональних даних має право:

  • знати про джерела збирання, місцезнаходження своїх персональних даних, мету їх обробки, місцезнаходження володільця чи розпорядника;
  • отримувати інформацію про умови надання доступу до персональних даних, зокрема про третіх осіб, яким вони передаються;
  • на доступ до своїх персональних даних;
  • отримувати не пізніше ніж за 30 календарних днів з дня надходження запиту відповідь про те, чи обробляються його дані, а також отримувати їх зміст;
  • пред'являти вмотивовану вимогу щодо зміни або знищення своїх персональних даних, якщо вони обробляються незаконно чи є недостовірними;
  • на захист від автоматизованого рішення, яке має для нього правові наслідки;
  • відкликати згоду на обробку персональних даних;
  • знати механізм автоматичної обробки персональних даних;
  • на захист від незаконної обробки та на звернення зі скаргами (див. розділ 9).

8.2. Додатково, у обсязі, сумісному з Загальним регламентом захисту даних ЄС (GDPR), Сервіс готовий розглянути звернення щодо права на доступ, виправлення, видалення («право бути забутим»), обмеження обробки, заперечення проти обробки та переносимість даних.

8.3. Чесне застереження про межі. Право на видалення та право на заперечення не є абсолютними і не діють там, де обробка необхідна для виконання юридичного обов'язку зі зберігання або для формування, здійснення чи захисту правових вимог. Це рівно ті випадки, що описані вище, і повторити їх треба тут:

  • історія відправлень і первинні документи не видаляються (розділ 6);
  • записи незмінного журналу-доказу не видаляються взагалі — і містять персональні дані у відкритому вигляді (розділ 3);
  • записи чорних списків не видаляються, а звірка продовжує спрацьовувати (пункт 7.3): при знеособленні номер телефону замінюється на ключований хеш.

У решті випадків вимога про видалення виконується.

8.4. Порядок реалізації прав — розділ 7. Оскільки щодо даних отримувачів Виконавець є розпорядником (пункт 1.1), звернення може бути перенаправлене володільцю — Користувачеві, який ці дані вніс, — про що суб'єкта буде повідомлено.

9. Оскарження

9.1. Суб'єкт персональних даних має право звернутися зі скаргою на обробку його даних до Уповноваженого Верховної Ради України з прав людини, який здійснює контроль за додержанням законодавства про захист персональних даних:

  • вебсайт: https://www.ombudsman.gov.ua
  • поштова адреса: 01008, м. Київ, вул. Інститутська, 21/8

9.2. Суб'єкт також має право на судовий захист своїх прав та на відшкодування шкоди, завданої незаконною обробкою його персональних даних.

9.3. Звернення до Уповноваженого або до суду не потребує попереднього звернення до Виконавця, однак ми будемо вдячні за можливість вирішити питання безпосередньо — support.ukrposhta@main.fish.

10. Захист даних

10.1. Ключі API Користувачів зберігаються в базі даних у зашифрованому вигляді. Паролі зберігаються у вигляді хешів. Токени доступу вирізаються з усіх журналів перед записом.

10.2. Персональні дані отримувачів у базі даних НЕ шифруються — вони зберігаються у відкритому вигляді (пункти 2.1–2.4). Захист забезпечується на рівні доступу до інфраструктури, розмежування доступу за підключеннями й ролями та передачі даних захищеним каналом (HTTPS).

10.3. Доступ до даних підключення мають лише Користувач-власник і запрошені ним учасники — у межах наданих їм ролей. Кожна значуща дія фіксується в аудиті (пункт 2.8).

11. Зміни Політики

11.1. Виконавець має право змінювати цю Політику. Кожна редакція має номер версії та дату набрання чинності, зазначені на початку документа.

11.2. Чинна редакція завжди доступна за адресою https://ukrposhta.main.fish/pryvatnist/.

11.3. Про зміни, що суттєво розширюють обсяг оброблюваних даних, змінюють мету обробки або коло третіх осіб, Користувачі повідомляються на адресу електронної пошти облікового запису не пізніше ніж за 14 днів до набрання ними чинності.

11.4. Продовження користування Сервісом після набрання чинності новою редакцією означає ознайомлення з нею. Незгода з новою редакцією реалізується припиненням користування Сервісом — з урахуванням розділу 6 (дані, що підлягають зберіганню за вимогою закону, зберігаються й після припинення договору).

Сервіс «Кабінет B2B відправника Укрпошти (неофіційний)» не є АТ «Укрпошта», не афілійований з нею, не є її представником чи агентом.