У порівнянні з клієнтським відстеженням або маркуванням, записи щодо користувачів відбуваються на стороні сервера непрямо. Від браузера користувача відбувається відправлення трекінгового події до власного сервера та далі до справжнього призначення. З цього випливають цікаві питання захисту даних.
Вступ
Серверне відслідковування або server side tracking іноді називається також серверним тегуванням. Цей синонім, ймовірно, виник тому, що Google підтримує серверний підхід до відслідковування за допомогою спеціального інструменту Tagging Tool. Тегування означає так само як і «заповнити інформацією». Відслідковування ж означає слідувати за користувачами, щоб вивчити їхнє поведінку.
Що таке серверне відслідковування?
У протилежність цьому знаходиться класичне відстежування, яке також називається клієнтським відстежуванням. Клієнтом, наприклад, є браузер відвідувача вебсторінки. Також може бути мова про застосунок.
При Server Side Tracking звичайно відбувається відправлення трекінгового події з власної вебсторінки на власний сервер і далі майже без змін до справжнього кінцевого пункту призначення. При Tagging ж інформація із трекінгового події на власному сервері спочатку збагачується, перш ніж подія буде передана одному або декільком кінцевим пунктам призначення.
Клієнтська і серверна трекінг
Трекінг на стороні сервера вже завжди був можливим, але раніше не особливо підкреслювався і тому не був популярним. Росту ж загрози через санкції для порушників даних, як Google (і всі ті, хто безвідповідально використовує послуги інших), спричинився перехід до нового парадигми.
Нижче наведені діаграми показують відмінності між звичайним та новітнім трекінгом та різні можливості. Як приклад використовується Google Tag Manager (GTM), який використовується для завантаження Google Analytics (GA). Це досить поширений випадок на вебсторінках. Замість Google Analytics часто також інші інструменти завантажуються з допомогою Tag Manager.
Навігований Стандартний відстеження засновується на завантаженні GTM та GA кожен з яких від спеціального сервера Google. Цей підхід називається clientseitiges Tracking.
Гриний колір позначає сервер, який відносно не критичний за законодавством про захист даних, тобто сервер, на якому працює саме ця відвідувана вебсторінка. Жовтий колір вказує на Треті сторони-сервери (Third-Party), наприклад, сервери Google. Уявляється, що це можуть бути сервери будь-якого іншого надання.
Рожеві стрілки вказують на Datentransfers. Завантаження GTM потребує двох Datentransfers. Перший це запит, тобто запитання. Другий передавач є відповіддю на запит. При Google Analytics це аналогічно. Отже, для завантаження GTM і GA разом відбувається чотири Datentransfers. П'ятий показаний Datentransfer є реєстрацією дії користувача за допомогою Google Analytics.
Клієнтське відстеження відомо вміло встановлювати. Для цього досить лише переглянути, до яких серверів (адрес) вебсторінка підключається. Кожен миттєво бачить, що виклик адреси google-analytics.com має щось спільне з Google Analytics.
Нині можна використовувати так званий Тунель або Прокси, щоб Google Analytics завантажувати індиректно та/або відправляти події слідкування в Google Analytics. Перевагою цього є те, що кінцеве слідкування може бути однаковим для всіх пристроїв і платформ (аплікацій, вебсторінок). Технічно все виглядає так:
Закон про захист даних майже нічого не змінив, оскільки тунель, яким здійснюється доступ до Google Analytics, знаходиться на третьому сервері. Google пропонує такі сервери безкоштовно у своїй Google Cloud. Практичний користь від Google Cloud Platform (GCP) для більшості людей відсутній, оскільки імплементація досить складна. Tag Manager завантажується в цій варіанті звичайним шляхом, що без згоди майже не дозволено не.
З допомогою Транспортного тунелю можна буде приховати виклик Google Analytics до певної міри затуманити його. Але треба бути обережним, щоб не потрапити під підозру. Ризик розкриття досить великий. Також через цей тунель можна завантажити Tag Manager. У прикладі я цього не розглянув. Нижче буде розглянуто цей випадок.
Наступає варіант для згаданого вище моделю. Тут усе ідентично, лише Транспортний тунель є окремим сервером. Ідеальним чином транспортний тунель повинен мати ту ж адресу, що й відвідувана раніше вебсторінка.
Google Analytics тут цілком здійснюється через власний тунель-сервер.
У цьому моделі скрипт Google Analytics може бути завантажений з сервера Google або сервера іншого постачальника, або власного сервера. Показана перша варіант. Зовні це не має ніякого значення. Правове регулювання захисту даних було б гірше в першому випадку, але друга чи третя варіанти для зовнішнього спостерігача будуть нерозбірливі та таким чином не можна буде їх безпосередньо підтвердити.
Виконання цього сценарію складне, оскільки необхідно встановити власний транспортний тунель. Потрібно враховувати можливі зміни на інтерфейсі та збільшувати вартісний навантаження.
Довідкова інформація щодо захисту даних щодо діяльності у цьому сценарії вже не так добре здійснюється, як раніше. Процес завантаження справжнього Google Analytics Scripts не можна відслідковувати ззовні. Коли скрипт передається на вебсторінку, щонайменше підтверджується те, що скрипт був завантажений, але ні звідки. Також можна використовувати власну логіку для керування транспортним тунелем Google Analytics. Це вимагає деяких зусиль та періодичної перевірки функціональності, оскільки Аналітична платформа може змінюватися. Таким чином, можна досягти найбільш можливої прихованості, але вона все ще частково відкривається.
У останньому сценарії всі дані передаються через власний проксі-сервер.
В кількості переданих даних вже помітна висока технічна складність цього сценарію. Усі дані передаються через власний сервер. Безумовно, також можливі декілька власних серверів. Якщо сервер тунелю має ту ж саму доменну зону, що й відвідувана раніше сторінка, трекінгові події не будуть відбуватися так швидко, як раніше.
У цьому сценарії можливо зробити спробу приховати всі дані, що передаються. У кінцевому підсумку (щоб щастя) це може бути лише спроба, оскільки кожна клієнтська приховаюча можливість відкривається. Далі нижче більше інформації щодо цього.
Нижче наведено таблиця, яка знову показує різні варіанти в огляді:
| Сценарій | Характеристика |
|---|---|
| Клієнтське відстеження | Звичайний підхід, легко імплементувати, легко відкрити, багато передач даних до третіх осіб. |
| Серверне відстеження з використанням тунелю третіх сторін для відстеження | Новачок, не дуже складний, легко відкривається, але більше можливостей для користувачів з великою потужністю. |
| Серверне відстеження з власним тунелем для відстеження | Новаторський, складний, легка маскування, багато можливостей для досвідчених користувачів. |
| Серверне відслідковування власним тунелем для всього | Новаторський, дуже складний, багато можливостей для приховування інформації, дуже багато можливостей для досвідчених користувачів. |
Конфігурація тунелю для менеджера меток Google
Гугл пропонує не зовсім безкорисну можливість з використанням Google Tag Manager, щоб виконувати серверне відслідковування. Поки що Google Tag Manager є видатним прикладом цього підходу, часто також використовується термін серверне маркування.
ГТМ_ використовується як проміжна шарка для відправлення даних як до Google Analytics, так і до інших Google-служб або навіть до послуг третіх осіб. Таким чином, Google отримує дані з більшої кількості послуг, ніж раніше, і може таким чином компенсувати втрати даних через законодавство про захист даних.
Конкретно, конфігурація Менеджера сторінок така:
З цим можна вказати GTM, щоб він міг повідомляти Google Analytics про події не на google-analytics.com, а на спеціальну адресу analytics.example.com.
Гугл обіцяє цим полегшення при слідуванні за користувачами через декілька кінцевих пристроїв.
Аби сервер міг передавати дані, які він отримує від відвідуваної вебсторінки, цей сервер повинен бути підготовлений відповідно. Основним чином необхідно забезпечити нову функціональність, щоб сервер міг виконувати роль посередника між клієнтом та постачальником даних про відвідування. Tagging Server може бути власний, що є більш відповідальним щодо захисту даних. Альтернативно такий сервер можна замовити у постачальника, наприклад Google в Google Cloud, що вже з початку піднімає питання захисту даних.
Режими роботи
Загалом існує дві види відображення серверного тегування. Технічним чином вони порівняні, але щодо захисту даних виникають інші питання.
Перший модус – це використання сервера третього рівня. На практиці цей сервер може належати самому собі. Адреса сервера тут відрізняється від власної вебсторінки та вказує на адресу, яка вказує на третю особу. Як приклад можна назвати сервер-інстанс, який надається Google Cloud і створює URLs таких як: https://sturdy-pier-xyz.ab.r.appspot.com
Така адреса виглядає підозріло з точки зору захисту даних. З початку можна вважати, що це є обов'язковим процесом отримання згоди. Детальніше потрібно дослідити кожен окремий випадок.
Другий спосіб називаю Proxy-спосіб. Прокси – це заступник, який передає дані. А також третій сервер, який виконує роль тунелю, технічно є проксі-сервером. Однак третій сервер не є справжнім проксі за законодавством про захист даних. У цьому контексті проксі згідно моїй визначення є самостійний сервер.
Діючий модус використовує адресу сервера, яка знаходиться в одній домені з відвідуваною вебсторінкою. Якщо користувач відкриває сторінку eine-webseite-081516.de, тоді адреса для сервера тегування може бути eine-webseite-081516.de/tagging. Поки на сайті часто відбуваються самі собі запити, запит до серверного тегування або слідкування втрачає своє значення серед інших безпечних запитів.
У режимі проксі можуть бути майже добре приховані обов'язкові згоди виклики. Коли сторінка відкривається, справжній трекінг-відрядження на власну домену не дуже помітне. Але якщо користувач переміщується по вже завантаженій сторінці, наприклад, шляхом прокрутки вікна і знаходиться тут сервер-відрядження, вже досить добре можна зробити висновок про те, що це трекінг.
Tracking – це не дуже точно визначений термін, який у кожному окремому випадку повинен бути заповнений життям. При використанні модулу проксі головним чином залежить від двох питань:
- Знайдіть місце технічного виклику, який не потрібен і не має підстав згідно з законним інтересом?
- При виклику створюються чи передавляються файли cookie?
Якщо одна з двох питань відповідається «так», існує обов'язок згоди, тобто майже слідування за цим, якщо хочеш щось скоротити у виразі.
Кукі не можна приховати. Хто хоче без куків відслідковувати відвідування, втрачає певні переваги від використання куків. Одним з цих переваг є можливість легко розпізнавати користувача всередині одного пристрою та браузера, коли він відкриває ту ж саму сторінку через кілька днів. Це можна зробити без куків лише за допомогою цифрового відбитка пальця. Теоретично існує також можливість використання так званих ідентифікаторів сесії (Session IDs), які кодуються в адресі відвідуваної сторінки. Але це не рекомендується з огляду на питання безпеки та оптимізації для пошуку.
Виклик на власний сервер можна трохи приховати, що користувача слідкували. Наприклад, таке сценарій із різними варіантами можливий:
- Користувач А відкриває вебсайт вперше
- Для користувача А робиться відбиток пальця, який зберігається до його адреси IP
- Найбільше декілька днів минуть
- Користувач А знову відкриває вебсторінку з тієї ж самої програми для перегляду браузера
- Паводка: Адрес IP такий самий і може бути поєднаний із відбитком пальця
- Паводка: Адрес IP трохи інший і може бути поєднаний з відбитком пальця
- Паводка: Адрес IP зовсім інший і не може бути поєднаний із відбитком пальця
У перших двох випадках за пунктом 4 користувач може бути знову розпізнаний. Це те, що називається класично обов'язковим відслідковуванням. І чим довше триває період часу після якого можливе відновлене розпізнавання, а також активно намагаються здійснити його, тим більше існує зобов’язання щодо згоди. Моя особиста думка полягає в тому, що 24 години є прийнятним значенням для правомірного інтересу. Всі речі, які перевищують чотири тижні, згідно з моїм поглядом, обов'язково повинні бути згоджені. Всі між одним днем і чотирма тижнями залежать від окремого випадку. Чотири тижні мені розповів раніше про державний захист даних щодо слідкування за файлами cookie, але я вважаю їх занадто високими. Як межу для відносно прийнятної тривалості в рамках ризик-користьової оцінки я бачу лише кілька днів, хоча я вірю, що це буде порушенням законодавства.
Питання також щодо того, які дані відправляються на власний сервер для спостереження за користувачем. Теоретично досить порожня запит, оскільки на сервері з кожним запитом згідно Інтернет-протоколу серед іншого потрапляють такі дані:
- Адреса (URL) поточної сторінки
- Часовий момент
- Ідентифікатор браузера (User Agent)
- Адрес IP користувача
Інші дані, які цікаві для ідентифікації користувача, можуть і повинні бути відправлені разом із запитом і будуть помітні ззовні. Ці дані головним чином:
- Різолінійність екрану та розмір вікна
- Налаштування мови
- Встановлені плагіни та шрифти
- Інші особливості, наприклад, чи є наявний екран дотик
Наступний виклик до власного сервера відстеження був би вельми помітним:
https://meine-webseite-471112.de/tracking?resolution=1920-1080&spras=de&plugins=plugin_tc1&fonts=arial,verdana&touch=yes
Якщо кодувати дані трекінгу, то вже досить складно розпізнати трекінг. Наприклад, такий виклик міг би відправляти ті ж дані, але зашифровані (фактивний приклад):
https://meine-webseite-471112.de/t?i=dhfkjjh7828763kjkHKJHJhkjjhkjbmnvghfzgjhgkjhkgjhg
Незважаючи на це, тут теж можна буде довести наявність цілей трекінгу. По-перше, Вартість наприкінці URL виділяється своєю довжиною. У цьому випадку вже досить важко уявити собі якусь виправдання чому саме така довга послідовність символів повинна бути передана на власний сервер.
Завданням другого є кодування значення в браузері користувача за допомогою справжніх даних. Ця кодифікація знову може бути підтверджена. Також тут злочинець може зробити для слідчого роботу важчою, наприклад, шляхом знищення джерел коду. Це називається обфускацією. Як завжди, кожен процес шифрування можна виконати у зворотньому порядку, а саме зміну джерельного коду. Якщо людина розповість про свій попередній довгий рядок і зможе підтвердити його шляхом розшифровки джерельного коду щось протилежне, ситуація швидко стане дуже ніяково.
Переваги та недоліки серверного відстеження
Які переваги та недоліки існують, залежать від перспективи. З погляду на Google відкривається нова можливість заміняти дані даних, що є підозрілими щодо захисту даних, подібними, але важче доказовими, практиками. Крім того, Google отримує потенційно більше даних з інших інструментів, які тепер інтегровані в сервери Google замість прямого завантаження.
Переваги
З погляду захисту даних тепер можливо менше особистих даних, які стосуються відвідувача вебсторінки, відправляти Google та іншим постачальникам.
Серверне відслідковування базується на собі не на cookie's, що спочатку здається вигідним у сенсі захисту даних.
Для власників вебсайтів та застосунків тепер краще можливе tracking користувача через межі пристрою та програми.
Для Google подібний підхід до компенсації втрачених даних через зміну законодавства схожий на ситуацію, яка відбувається зараз.
Недоліки
Є можливість використовувати файли cookie і приховати слідування користувачів, а також записувати IP-адреси, оскільки цей процес відбувається у тлі. Це недоліки з погляду захисту даних.
Якщо вебсайт використовує Google Tag Manager для серверного відстеження, тоді Google автоматично отримує ті ж дані від користувача під час завантаження Tag Managers. До цих даних належить особиста IP-адреса. Google Tag Manager є обов'язковим заявленням, що робить його нецікавим для мене. Ніякі зміни навіть після запровадження режиму Google Consent Mode нічого не змінюють. Відповідальні особи повинні підкорятися складності захисту даних Google та їхньої Tagging-Lösung. Популярна рішення в принципі більш доступне для атак, ніж менш відомі провайдери.
Якщо Google Tag Manager використовується для взаємодії з Google Analytics, знову Google стає третім, який сміється. Користувач все ще слідкує за собою і власник вебсторінки повинен прийняти потенційно гіршу якість даних, якщо ніхто не використовує файли cookie або подібні конструкції. Однак навіть Google пропонує можливість призначити користувачеві ідентифікацію, яка зберігається у файлі cookie. У прикладі Google цей файл cookie має термін дії два роки. Це було б обов'язковим для згоди. Для більшості власників вебсторінок та користувачів не буде ніякої вигоди, але зросте навантаження і збільшиться залежність від Google.
Імплементація стає складнішою для власника вебсайту. Лише коли власник досягне певної величини або значущості, імплементація мені здається вартісною, бо тоді користь для власника стає суттєвою, оскільки він зможе зібрати дані від більшої кількості кінцевих точок (аплікації, вебсайт тощо).
Контингент
Велика кількість окремих кінцевих точок користувачів — це їхні браузери. Кожен браузер працює через власну мережеву адресу. Ці кінцеві точки користувача заміняються однією кінцевою точкою, а саме проксі. Прокси має лише одну мережеву адресу.
Звідси часто виникає проблема з контингентами. Нехай витрати на послугу залежать від кількості звернень. Звернення можна рахувати за мережевою адресою звернувшого. Так не завжди, але такий випадок існує. Якщо тепер одна мережева адреса звернеся до служби, виникнуть швидко дуже багато звернень. Довго вже було так, що кожному окремому користувачеві та його мережевій адресі належало лише кілька звернень.
Навіть більше міг виникнути блокування при зверненні до цілей, оскільки багато запитів від проксі можуть бути ідентифіковані як єдиний виконавець. Також це не було б проблемою для кожного окремого користувача.
Висновок
Серверне відслідковування мені здається для більшості несуттєвим. Воно залишиться функціонально непотрібним для багатьох. Я підозрюю, що Google просуває цей підхід, щоб компенсувати майбутні втрати даних через відсутність згоди користувачів тощо.
Виявлення обов'язкових дій на стороні сервера складніше, ніж раніше. Коли використовуються Кукі, майже нічого змінюється при виявленні. Кукі не можуть бути приховані. Тут немає значення, чи використовуються так звані First Party або Third Party Cookies, адже фахівцями вважаються завжди Third Party дані, коли увімкнено Google.
Якщо дані не кодуються, доведення того, що трекінг відбувається, дуже ймовірно буде досить простим. Якщо дані кодуються, власник вебсторінки спочатку має більше зусиль. Він тоді рідше потрапляє під підозру, але все ще може бути викритий.
Сховане порівняння IP-адрес із даними трекінгу, яке відбувається на власному сервері у тлі, мені здається більш ймовірним. Це вже сьогодні можливо і, певно, деякі вже роблять це.
Нижче наведено таблиця, яка дуже грубо показує, які дані можуть бути приховані шляхом серверного відстеження. Я згодом присвятюватиму окремий матеріал цьому і тут не буду детальніше зупинятися на дрібницях.
| Аспект | Видалення можливе? |
|---|---|
| Кукі | Ні |
| Палець відбиток | Так, але тільки приблизно |
| Розширений відбиток пальця | Мало |
| Інший ідентифікатор користувача | Так, але тільки приблизно |
| Tracking IP-Adresse | Yes |
| Передача даних до США | Yes |
| Перевірка IP-адреси з іншими даними | Yes |
Гугл намагається уникнути використання cookie за допомогою спроб, як-от FloC (Federated learning of Cohorts), незалежно від серверного моніторингу. Тут Ви знайдете мої статті щодо Google FloC:
Я бачу, що server side Tracking досить спокійний. Хто хоче інтенсивно шпигувати своїх користувачів, не лише використовує Google Analytics, а й багато інших інструментів та механізмів. Зусилля, щоб приховати всі ці дії, вимагають чималої праці і навіть злочинної енергії. Приховування доказів, звичайно, не буде позитивно оцінено у суді.
My name is Klaus Meffert. I have a doctorate in computer science and have been working professionally and practically with information technology for over 30 years. I also work as an expert in IT & data protection. I achieve my results by looking at technology and law. This seems absolutely essential to me when it comes to digital data protection. My company, IT Logic GmbH, also offers consulting and development of optimized and secure AI solutions.
