Search
Write a publication
Pull to refresh

Comments 17

Что помешает рекламодателям абъюзить RWS? Можно взять и объеденить все сайты на которых размещена твоя реклама под свой primary сайт. Для сайтов которые хотят зарабатывать с рекламы это будет обязательное условие.

Процесс добавления нового сета прописан тут.

Он включает в себя набор автоматических и ручных проверок. Просто так прийти и законтрибьютить туда любые списки любых сайтов не получится. Сами сайты тоже валидируются через механизм .well-known, который (как я понимаю) не позволит переиспользовать один сайт в двух разных сетах

Также "концептуально" подразумевается что все сайты в RWS должны быть аффилированы между собой, и эта связь должна быть прозрачна и понятна для пользователей сайта и прописана в исходном JSON файле

Вопрос в тему. Есть плагины для Файрфокса или Хрома, позволяющие в разных табах иметь отдельные, гарантированно непересекающиеся по кукиз браузеры?

Кажется, вы только что описали режим "инкогнито", но там разделение идет по окнам, а не по вкладкам (в том числе потому, что нужно исключить отслеживание браузерными плагинами)

В хроме для этого есть профили, но они в разных окнах, не табах.

Обвязывать работа браузера, да и вообще работа WWW с конкретным бизнесом (github), это так прекрасно!

Справедливости ради, RWS внедряют только в Chrome, который является продуктом гугла.

Полагаю, это делается для "открытости"/"прозрачности" - мол, если сомневаетесь в нашей честности, то вот же ж, смотрите на Гитхабе, всего-то пару гигабайт полистать.

Заодно и системные требования Хрома можно обосновать - "мы же обязаны выполнять требования стандарта"

Access requests are automatically denied if the browser detects that the user hasn't interacted with the embedded content in a first-party context recently (in Firefox, "recently" means within 30 days).

Я правильно понял, что сайт запрашивающий API сможет узнать, посещал ли пользователь тот другой сайт в течении 30 дней?

Получается так. Хотя вряд ли это будет очень полезно.

Пока доступ к кукам есть (30 дней с момента одобрения), у тебя есть безлимит на получение любой информации о пользователе, включая посещения сайта. Последнее, что что можно узнать - что 30 дней прошло и доступ аннулирован.

Какой сейчас консенсус - домен и поддомен это все ещё First-Party?

Тут главное не перепутать теплое с мягким

1) First и third party - это про то, откуда запрос идет (с того же домена, где куки и так доступны через JS, или с другого)
2) Partitioned и Unpartitioned - про то, делятся ли куки (и другие стораджи) по top-frame сайту (как раз про это писал недавно заметку)
3) Разделение по доменам (и поддоменам) и для Partitioned и для Unpartitioned и для first-party и для third-party кук работает одинаково, через атрибут Domain (который работает очень неочевидным не очень очевидным образом), или через префикс __Host.

Я во всех своих браузерах выключил third-party cookies ещё несколько лет назад, и не заметил существенных проблем. Кажется, что полезных для пользователя применений для сторонних кук просто не существует. И кажется, что если их просто убрать, не предоставив никакой замены, мир станет лучше. Если очень хочется передать данные между разными сайтами, например, для авторизации на всяких порталах с кучей доменов, это можно сделать через редиректы и гет-параметры.

Боюсь, где-то тут закралась ошибка. Скорее всего в том, что вы путаете отключение third-party и включение partitionned. Рекомендую мой коммент выше.

На данный момент авторизация через гугл работает в вашем браузере даже если вы выключили third-party куки только потому что куки продолжают быть Unpartitioned и отправляться, например, в айфреймах самого гугла (с чужого сайта мы твои куки, конечно, не отправим, но если ты вставишь айфрейм first-party сайта - то оттуда без проблем).

Вся "заварушка" как раз для того и планируется, чтобы "через редиректы и гет-параметры" нельзя было передавать данные пользователя "для авторизации на всяких порталах с кучей доменов"

Ох, с каким же предвкушением гемороя я читаю новости о том как порежут сторонние куки. Вроде перечитал 2 раза, но как же это запарно в случае iframe всё равно, не понятно, придется уже по факту воевать.

Вот есть у нас на работе некоторая CRM которая расширяется средствами встраивания iframe, куда CRM проталкивает всякие параметры типа временного токена юзера, чтобы его аутентифицировать и т.п. Вот только токены эти живут 5 минут, а пользователи держат вкладки открытыми днями. Естественно приходится футентифицировать юзера, повесить ему свои куки и не дергать CRM лишний раз вопросами "а хто это?".

Ну и само собой юзеры могут юзать расширения как в режиме встраивания в iframe, так и отдельно как обычный сайт. В общем поглядим, надеюсь лечение проблем будет не сильно замороченым.

Похоже расходимся, куки решили не депрекейтить

https://privacysandbox.com/news/privacy-sandbox-update/

Sign up to leave a comment.

Articles