Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 79
если я все правильно понял, то сперва пострадают всякие счетчики, которые не iframe
думаю, в первую очередь пострадает индустрия таргетинговой рекламы. Хорошо иллюстрирует настроения рекламщиков твит Майка Занеиса (@mikezaneis): «Такая установка [политик в отношении cookie] по-умолчанию будет ядерной атакой против индустрии рекламы».
Почему такие счётчики должны пострадать? В них JavaScript файл подключается в HTML код сайта и JavaScript код исполняется от имени страницы, куда был подключён JavaScript файл (а не от JavaScript файла, который подключается в HTML код).
речь шла про cookies и в топике, и в моем ответе… всякие счетчики, сторонние сайты (как правило собирающие данные для того, чтобы пихать рекламу) любят ставить свою cookie, это как раз 3rd-party sites, которые не загружаются (опять же, если не iframe)…
Вы меня не поняли, я хотел сказать, что подключаемый с другого домена JavaScript код выполняется от имени домена подключающей его HTML страницы и такой JavaScript код может ставить cookie для домена HTML страницы.
Но когда он будет на другом сайте, где нет достаточной инфы для таргетинга, он не будет иметь доступа к кукам, которые он сохранял на другом сайте. Для этого они сохраняли куки в своем домене. Сейчас это становится сложнее.
Мой ответ касался комментария про счётчики («счетчики, которые не iframe»), не про таргетинг. Но, если касаться таргетинга, то какую ситуацию Вы подразумеваете? Мне приходит в голову лишь ситуация, когда на сайте A (поисковая система) и на сайте B (обыкновенный сайт) установлен JavaScript код некой рекламной системы и посетителю, вводившему ранее на сайте A запрос про машины, на сайте B будет показываться реклама про машины (что технически можно реализовать через iframe, когда на сайте A в iframe'е для домена рекламной системы учтанавливается cookie, идентифицирующая пользователя, а на сайте B в iframe'е выводится реклама с использованием этой cookie). Эту ситуацию нововведение, по идее, никак не затронет (т.к., фраза «публичный суффикс +1 уровень» не подразумевает запрет на установку cookie в iframe'е для доменов второго уровня, который вполне можно использовать для рекламной системы).
О, и firefox продался большевикам. На практике это всегда нехорошо для разработчиков, которым нужны ифреймы. Меня смутило лишь одно, что значит «запросить разрешение перед установкой cookie»? Как это должно выглядеть-то?
Никуда он не продавался, там давно уже есть опция «принимать куки со сторонних сайтов», просто она была включена по-умолчанию, а теперь, видимо, выключат.
Давайте я немного поясню. Мы как-то делали приложения для мамбы. Так вот там приложение работает в ифрейме. Все бы хорошо, но о проблемах в сафари и айпадах мы узнали букально в продакшене, когда стали жаловаться, что дальше первой страницы их не пускает (а у нас там сессии, авторизация, все серьезно). Стали разбираться, узнали что сафари по умолчанию куки во фреймах блокирует. И этого никак программно не избежать (как тот же заголовок P3P в IE). Осталось только просить юзеров это включить, то есть редиректить их на спец страничку с пояснениями. На что многие юзеры говорят, ну у меня же другие сайты работают, а ваш не работает, пошли вы нафик. И уходят. И я их понимаю, в принципе они правы, не их это дело. Ясен пень, что можно переделать на передачу сессии в урле, но слишком там дофига было переделывать и мы на это забили.
А про «продался» — это Ильф и Петров.
А про «продался» — это Ильф и Петров.
>В общем, новая политика Firefox — это слегка упрощенная версия политик Safari.
>Контент сторонних сайтов будет иметь разрешение на cookie, только если Вы посещали эти сайты, и они установили хотя бы одно значение в cookie.
Я так понимаю достаточно отслеживать пользователей огнелиса и показывать им плашку, что для корректной игры требуется один раз посетить наш сайт. Думаю сначала стоит подождать выхода 22ой беты, оценить что к чему и насколько все серьезно, а потом обсуждать, а то как бабки на скамейке.
>Контент сторонних сайтов будет иметь разрешение на cookie, только если Вы посещали эти сайты, и они установили хотя бы одно значение в cookie.
Я так понимаю достаточно отслеживать пользователей огнелиса и показывать им плашку, что для корректной игры требуется один раз посетить наш сайт. Думаю сначала стоит подождать выхода 22ой беты, оценить что к чему и насколько все серьезно, а потом обсуждать, а то как бабки на скамейке.
В фейсбуке по этому поводу уже на ФФ вылиты тонны ненависти
Теперь будет меньше случаев когда прочитав статью о автомобиле я буду потом месяц видеть баннеры с автомобилями?
нет
Присоединяюсь к вопросу, я C++ программист, поэтому не совсем понял, кто и как пострадает от этих политик
значит postMessage обработчики в API приложений добавят и всё.
В статье сказано, что на основных сайтах («публичный суффикс +1 уровень», т.е. домены второго уровня) это никак не скажется. Поэтому вопрос остаётся открытым.
Думаю проблема решится достаточно просто, редирект на страницу сервиса, с «вы соглашаетесь что ваши данные будут исспользованы...».
Если вы добавляете новое приложение к twitter/google сервисам по OAuth так уже давно делается и не возникает больших проблем.
Мне политика Огнелиса нравится, показывает что действительно думают о приватности пользователя, а не деньгах медиакорпораций.
Если вы сайт о новозеландских кроликах, то вам нечего отслеживать мою активность, а если медиа сеть, то должны явно задекларивовать свое желание собирать данные.
Если вы добавляете новое приложение к twitter/google сервисам по OAuth так уже давно делается и не возникает больших проблем.
Мне политика Огнелиса нравится, показывает что действительно думают о приватности пользователя, а не деньгах медиакорпораций.
Если вы сайт о новозеландских кроликах, то вам нечего отслеживать мою активность, а если медиа сеть, то должны явно задекларивовать свое желание собирать данные.
Получается, что основной способ заработка почти всех сайтов на некоммерческой основе пропадет? И все это с позволения Mozilla Foundanation?
если реклама не от гугла \ яндекса (которые легко поставят первый куки), то могут быть некоторые проблемы.
Нет. Если реклама идёт по содержимому сайта, то она будет показываться.
Это больше повлияет на сайты, которые скрытно через куки следят за пользователями. То есть, идёт борьба против тех кук, которые обычно удаляет любой anti-spyware пакет.
Это больше повлияет на сайты, которые скрытно через куки следят за пользователями. То есть, идёт борьба против тех кук, которые обычно удаляет любой anti-spyware пакет.
А если сайт грузится в iframe он при этом считается «основным сайтом»?
Да, очень интересно как теперь различные счетчики и баннерки будут считать уникальных пользователей?
Да, очень интересно как теперь различные счетчики и баннерки будут считать уникальных пользователей?
насколько я понял автора, принадлежащими «основному» сайту будут считаться страницы, расположенные в том домене второго уровня, который написан в адресной строке. Либо страницы, расположенные в домене третьего уровня, если домен второго уровня при этом находится в списке public suffix list от Mozilla (co.uk, .wy.us, .org.uk и подобные).
Независимо в iframe они, или нет.
Независимо в iframe они, или нет.
Тема заинтересовала настолько, что не поленился зайти в группу mozilla.dev.privacy и поискать там ответы на свои же вопросы.
Оказалось что ифреймы тоже работать не будут: Things that are different origin than the top level document.
Оказалось что ифреймы тоже работать не будут: Things that are different origin than the top level document.
в дискуссии рождается истина. позвольте с Вами не согласиться. Цитата из groups.google.com/group/mozilla.dev.privacy:
Вопрос: " What is considered «third-party» in this context? e.g. are iframes third-party? "
Перевод: Что считается сторонним контентом в этом контексте? [любые] iframe это сторонний контент?
Ответ: «Same as for our existing cookie stuff. Things that are different origin than the top level document. „
Перевод: Тоже самое, что и для остального. [сторонним контентом считается] всё, что имеет источник не тот, что у родительского документа.
Если было бы написано “Things that are different than the top level document.» тогда да, Ваше утверждение было бы верным.
А так — для iframe нет специальных правил. Контент за пределами домена, по-умолчанию, не имеет прав на cookie, не зависимо от формы представления этих данных: iframe или нет. Поскольку iframe — наиболее популярный способ подгрузки контента со сторонних доменов — то да, многие iframe не смогут по умолчанию поставить cookie. Но это не связано именно с тем, это iframe.
Вопрос: " What is considered «third-party» in this context? e.g. are iframes third-party? "
Перевод: Что считается сторонним контентом в этом контексте? [любые] iframe это сторонний контент?
Ответ: «Same as for our existing cookie stuff. Things that are different origin than the top level document. „
Перевод: Тоже самое, что и для остального. [сторонним контентом считается] всё, что имеет источник не тот, что у родительского документа.
Если было бы написано “Things that are different than the top level document.» тогда да, Ваше утверждение было бы верным.
А так — для iframe нет специальных правил. Контент за пределами домена, по-умолчанию, не имеет прав на cookie, не зависимо от формы представления этих данных: iframe или нет. Поскольку iframe — наиболее популярный способ подгрузки контента со сторонних доменов — то да, многие iframe не смогут по умолчанию поставить cookie. Но это не связано именно с тем, это iframe.
Это понятно, просто первый коммент к этому посту немного смутил:
пришлось разбираться.
А раз уж есть у кого спросить, страница открытая через window.open — это будет новый top level document или тот же?
если я все правильно понял, то сперва пострадают всякие счетчики, которые не iframe
пришлось разбираться.
А раз уж есть у кого спросить, страница открытая через window.open — это будет новый top level document или тот же?
Если домен у открытой страницы будет отличаться от домена открывающей страницы (а точнее, протокол, домен или порт), то к данным такой страницы нельзя будет получить доступ через JavaScript. Всё как и с iframe: доступ к содержимому окна в iframe получается через свойство contentWindow у объекта HTML элемента фрейма, а доступ к содержимому окна, открытого через window.open — через возвращаемое значение этой функции.
За фразой «top level document» по идее должен скрываться самый верхний документ (предок) в иерархии фреймов/окон. У фрейма на родительский фрейм указывает свойство window.parent, а у открытого через window.open() окна на родительский документ (точнее, на открывший его документ) указывает свойство window.opener. Если у открывшегося фрейма/окна домен, протокол или порт отличаются от подобных значений в родительском/открывающем окне, то можно считать, что иерархия прерывается (т.к. уже нельзя будет обратиться к свойствам window.parent и window.opener — их содержимое не будет доступно и обращение к ним будет вызывать ошибку), поэтому «top level document» можно интерпретировать двояко (либо как верхний уровень от новой иерархии, с момента прерывания, либо как верхний уровень в прежней иерархии, к которому уже нельзя обратиться).
За фразой «top level document» по идее должен скрываться самый верхний документ (предок) в иерархии фреймов/окон. У фрейма на родительский фрейм указывает свойство window.parent, а у открытого через window.open() окна на родительский документ (точнее, на открывший его документ) указывает свойство window.opener. Если у открывшегося фрейма/окна домен, протокол или порт отличаются от подобных значений в родительском/открывающем окне, то можно считать, что иерархия прерывается (т.к. уже нельзя будет обратиться к свойствам window.parent и window.opener — их содержимое не будет доступно и обращение к ним будет вызывать ошибку), поэтому «top level document» можно интерпретировать двояко (либо как верхний уровень от новой иерархии, с момента прерывания, либо как верхний уровень в прежней иерархии, к которому уже нельзя обратиться).
вероятно, по уникальности ip адреса
Да, остается только этот вариант. Но результаты могут в итоге отличаться в разы.
Сейчас в счетчиках есть два независимых параметра «посетители» и «хосты» (первые — по куке, вторые по ip), и если взяглянуть на статистику того же top.mail.ru, то по глобальной статистике, в день:
70,776,640 — посетители
30,434,215 — хосты
разница есть.
Хотя для отдельных сайтов цифры посетителей и хостов почти равны, кое где даже хостов больше.
Сейчас в счетчиках есть два независимых параметра «посетители» и «хосты» (первые — по куке, вторые по ip), и если взяглянуть на статистику того же top.mail.ru, то по глобальной статистике, в день:
70,776,640 — посетители
30,434,215 — хосты
разница есть.
Хотя для отдельных сайтов цифры посетителей и хостов почти равны, кое где даже хостов больше.
Да, очень интересно как теперь различные счетчики и баннерки будут считать уникальных пользователей?
Теперь более-менее нормально работать смогут только счётчики Гугла и прочих монстров. «Более-менее нормально» — это в 30-70% случаев в зависимости от региона.
Всем остальным придётся убеждать веб-мастеров перетаскивать счётчики к себе на сервер, видимо. В случае встраивания комментариев и прочих подобных фич, следует ожидать массового перехода на редиректы через пять сайтов при попытке прочитать комментарии. Ну и одним счётчиком пользоваться снова станет немодным.
И всё ради того, чтобы избежать адекватной таргетированной рекламы, прикрывшись борьбой за «privacy».
Бред, в общем.
В чём, вообще, проблема приватности? Кто-то боится, что за ним будут следить?
Ничего не понял из статьи. Может кто-нибудь толком объяснить что за изменения и что они ограничивают? Установку cookie для домена через HTTP заголовки, полученные с сервера (похоже на бред)? Установку cookie через JavaScript? Для встраиваемых фреймов? Для подключаемых JavaScript файлов с других доменов?
Смотрите глубже. От этого проиграют все пользователи интернета.
Рекламщики, лишившись таргетинговых данных о пользователях, не смогут показывать рекламу так эффективно.
Из-за этого пользователи будут видеть среди рекламы больше ерунды, никак к ним не относящейся, меньше кликать, а владельцы сайтов, зарабатывающих в основном на рекламе, соответственно станут меньше зарабатывать.
В результате, многие хорошие сайты перестанут быть рентабельными и в интернете станет меньше сайтов, упор которых делается на контент, а заработок — на рекламе.
Рекламщики, лишившись таргетинговых данных о пользователях, не смогут показывать рекламу так эффективно.
Из-за этого пользователи будут видеть среди рекламы больше ерунды, никак к ним не относящейся, меньше кликать, а владельцы сайтов, зарабатывающих в основном на рекламе, соответственно станут меньше зарабатывать.
В результате, многие хорошие сайты перестанут быть рентабельными и в интернете станет меньше сайтов, упор которых делается на контент, а заработок — на рекламе.
Рекламщики втихую собирая данные о пользователях, сами себе вырыли могилу.
Захотите собирать, покажите новое окно на домене рекламного агенства с лицензионным соглашением и политикой конфиденциальности, что кстати все уважающие себя западные сайты и делают. Тот же код что исспользуют при авторизации нового приложения по OAuth для Google/Facbook/Twitter.
Кислород рекламщикам перекрыют в любом случает, учитывая динамику разработки нового законодательства о идентификационных данных в Штатах и Эвропе. Меньше хороших сайтов не станет, станет меньше сетей трекеров, по крайней мере на первое время. А о контенте очень хорошая статья www.smashingmagazine.com/2012/08/07/content-blessing-bubble-burden/ если контент занимает меньше 10% страницы, в одном месте вы имеете пользователя и его интересы.
Захотите собирать, покажите новое окно на домене рекламного агенства с лицензионным соглашением и политикой конфиденциальности, что кстати все уважающие себя западные сайты и делают. Тот же код что исспользуют при авторизации нового приложения по OAuth для Google/Facbook/Twitter.
Кислород рекламщикам перекрыют в любом случает, учитывая динамику разработки нового законодательства о идентификационных данных в Штатах и Эвропе. Меньше хороших сайтов не станет, станет меньше сетей трекеров, по крайней мере на первое время. А о контенте очень хорошая статья www.smashingmagazine.com/2012/08/07/content-blessing-bubble-burden/ если контент занимает меньше 10% страницы, в одном месте вы имеете пользователя и его интересы.
Из статьи вообще ничего невозможно понять :( В комментариях пишут про ифреймы, в статье ничего про них нет.
Автор статьи говорит общими словами — «контент со сторонних сайтов», так как для применения политики не важно, каким конкретно способом эти данные будут подгружены/подключены к основной странице.
В комментариях пишут про iframe, потому что это наиболее популярный способ собственно подключения стороннего контента к основной странице.
В комментариях пишут про iframe, потому что это наиболее популярный способ собственно подключения стороннего контента к основной странице.
Пока не вижу, что это особо что-то улучшит для пользователей. Трекинг уже давно научились делать без куков.
Request Policy наше все.
Request Policy наше все.
А как можно технически сделать трекинг без cookie? Как ещё к пользователю привязать «межсайтовый» идентификатор?
LocalStorage в iframe, но с ним будет больше геморра.
Я подразумевал вообще без хранения данных на стороне клиента. Ведь в LocalStorage тоже действуют ограничения, не позволяющие обращаться к сохранённым данным скриптам из других доменов. И, логично предположить, что новые правила, применяемые к cookie, вскоре будут применены и к LocalStorage.
Это вряд ли. Куки можно устанавливать средствами сервера. LocalStorage — только JS. Если такое ограничение и появится (что маловероятно, т.к. сейчас на связке HTML5+JS+CSS пишутся приложения под все и вся), то только через десяток лет
В спецификации WebStorage прямо говорится о том, что для предотвращения слежки за пользователями браузеры могут реализовывать подобные меры:
www.w3.org/TR/webstorage/#user-tracking
There are a number of techniques that can be used to mitigate the risk of user tracking:
Blocking third-party storage
User agents may restrict access to the localStorage objects to scripts originating at the domain of the top-level document of the browsing context, for instance denying access to the API for pages from other domains running in iframes.
www.w3.org/TR/webstorage/#user-tracking
Еще есть такой способ, но он конечно не панацея, т.к. ИМХО, мобильные устройства будут часто совпадать
Т.е. по факту выиграют мейджоры вроде Гугла и Яндекса. А мелкие фирмы таргетированной рекламы проиграют.
Хороший ход)
Хороший ход)
Контент сторонних сайтов будет иметь разрешение на cookie, только если Вы посещали эти сайты, и они установили хотя бы одно значение в cookie.
Уже лучше, но не идеально. Например то, что я раз в пятилетку заглядываю в Facebook, отнюдь не означает, что я согласен с тем, чтобы последний отслеживал мои перемещения по Сети посредством его кнопочек, расставленных на многих сайтах.
В то же время, наверно, можно представить себе вполне полезный и честный виджет, для обеспечения функциональности которого может требоваться установка Cookie от имени сайта его автора.
Лучше бы они занимались оптимизацией своего браузера вместо того, чтобы придумывать эти безумные апдейты. У меня по сравнению с тем же chrome или opera их браузер работает намного медленнее. Правда у меня открыто много окон вместо множества вкладок.
Если я все правильно понимаю, то в первую очередь пострадают рекламные площадки и все вебмастера, работающие с ними.
У меня появилась еще одна причина нелюбить firefox. И, думаю, тут я не одинок.
Если я все правильно понимаю, то в первую очередь пострадают рекламные площадки и все вебмастера, работающие с ними.
У меня появилась еще одна причина нелюбить firefox. И, думаю, тут я не одинок.
У меня (пользующегося исключительно Firefox т.к. больше ни к чему нет таких классных экстэншнов) примерно после вынужденного перехода на винду стал оно очень падуч. С десяток табов и всё — вылет, а через некоторое время вылет и без десятка табов. Я грешил на то, что испортился он в ноавых версиях, но оказалось дело не в этом. Оказалось у меня в оперативе завёлся сбойный бит (нашёл MemTest-ом), а Linux, оказывается, автоматически исключает сбойные блоки из используемого пространства памяти (если ей удаётся устоять на ногах, нарвавшись на оный), а Windows попроще в этом плане (в Windows вроде даже нельзя параметрами ядра при загрузке вручную сбойный участок закрыть, только ампутировать вместе со всей памятью, идущей после него). В общем под Linux оставалось всё нормально и так, а под Windows — стало нормально как поменял планку. Но прежде, чем я до этого дошёл, матов в адрес разработчиков падающего по 10 раз на дню Firefox (всё остальное работало более-менее стабильно) я наговорил немало.
Что касается скорости и отзывчивости — к сожалению (а для кого-то к счастью) Firefox устроен так, чтобы жертвовать ими ради экономии ресурсов. Во-первых JavaScript-движок в Firefox прекомпилирует (JIT) только те участки (ветви) кода, которые собирается исполнять (в чём может иногда ошибаться), а Chrome/Safari, не мудрствуя лукаво, компилируют сразу всё. Во-вторых Chrome запускает по самостоятельному процессу на каждый таб, а Firefox — нет. AFAIK.
Я иногда поглядываю в сторону Chrome, но, думаю, основным браузером у меня ещё очень на долго останется Firefox — ни с какими расширениями и настройками из Chrome не получается то, что мне нужно (функционально), а из Firefox — легко. На сколько мне известно, в Chrome просто более скромная (ограниченная) модель плагинов.
Что касается скорости и отзывчивости — к сожалению (а для кого-то к счастью) Firefox устроен так, чтобы жертвовать ими ради экономии ресурсов. Во-первых JavaScript-движок в Firefox прекомпилирует (JIT) только те участки (ветви) кода, которые собирается исполнять (в чём может иногда ошибаться), а Chrome/Safari, не мудрствуя лукаво, компилируют сразу всё. Во-вторых Chrome запускает по самостоятельному процессу на каждый таб, а Firefox — нет. AFAIK.
Я иногда поглядываю в сторону Chrome, но, думаю, основным браузером у меня ещё очень на долго останется Firefox — ни с какими расширениями и настройками из Chrome не получается то, что мне нужно (функционально), а из Firefox — легко. На сколько мне известно, в Chrome просто более скромная (ограниченная) модель плагинов.
Говоря о «плагинах» здесь я имел ввиду «расширения». А проблемма ограниченных возможностей для их работы — вроде даже проблема всего движка WebKit, а не только Chrome. Пример ограниченности: AdBlock+ пропускает рекламу в видеороликах на YouTube и нет полноценного аналога VideoDownloadHelper — на сколько я понял, полноценные аналоги этих расширений там реализовать просто невозможно.
Ещё один важный для меня пример — нет расширений, существенно модифицирующих функционирование панели табов типа TabMixPlus в Firefox, а я хочу, чтоы она росла по вертикали (добавляла этажи) вместо ужатия табов по горизонтали при переполнении и чтобы корзинка закрырых табов как в Опере была (TabMixPlus в Firefox всё это даёт).
Какая шумиха из-за дефолтных настроек… А всё потому, что большинству пользователей лень кастомизировать браузер по своему вкусу… Даже в том же минималистичном Safari есть пункт, принимать куки со сторонних доменов или нет…
А мне, вот, интересно: а можно добиться такого эффекта уже сейчас (в Firefox 20 или 21)? Может в about:config чего переключить или расширение какое есть?
Теперь, чтобы нормально работали сайты, пользователь будет вынужден синхронизировать историю посещений между девайсами. интересно, каким будет следующий шаг фонда мозиллы в заботе о прайваси?
Обычные сайты, вроде хабра или рутрекера, будут работать как и раньше, без изменений.
Проблемы возникнут только у социальных виджетов и различных отслеживателей.
Кнопка «лайк» не сможет опознать юзера, пока он явно не зайдёт на страницу соц. сети.
Скрипт гугл-аналитики, который веб-мастеры часто встраивают в свои сайты в обмен на плюшки от гугла, не сможет запомнить, что юзер был на этой странице, чтобы после в поиске показать ему рекламу от конкурентов этой страницы.
Проблемы возникнут только у социальных виджетов и различных отслеживателей.
Кнопка «лайк» не сможет опознать юзера, пока он явно не зайдёт на страницу соц. сети.
Скрипт гугл-аналитики, который веб-мастеры часто встраивают в свои сайты в обмен на плюшки от гугла, не сможет запомнить, что юзер был на этой странице, чтобы после в поиске показать ему рекламу от конкурентов этой страницы.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Новая политика Firefox в отношении cookie