Русский
Русский
English
Статистика
Реклама

Куки

Перевод Нет Cookies, нет проблем использование ETag для отслеживания пользователей

03.07.2020 22:11:07 | Автор: admin
Работая старшим консультантом по дижитал-аналитике в ведущем международном аналитическом агентстве, с огромным интересом наблюдаю за нынешним крестовым походом современных веб-браузеров против технологии cookie.

Оказывается, есть способ отслеживать отдельных не вошедших в систему пользователей без использования файлов cookie. Я тоже реализовал это. Сейчас покажу как.


Для наглядности я создал демо-сайт. Вот он.

Нажмите на каждую из трёх кнопок Page На всех трёх один и тот же идентификатор.
Закройте окно браузера и снова откройте сайт Идентификатор не поменялся.
Выключите компьютер и зайдите на эту веб-страницу завтра Идентификатор всё тот же.
Проверьте ваши куки Демо-сайт не записывает куки и не считывает их.
Проверьте URL Сомнительные строки запроса отсутствуют.

Итак, как именно я могу хранить идентификатор и узнавать, что вы с определённого устройства возвращаетесь на сайт, при этом без входа в систему и без использования куки?
EDISON Software - web-development
Мы в EDISON со всеми этими нюансами приватности сталкиваемся постоянно.


Наш новый выполненный проект Резидент Такси в котором мы связали в единое целое сайт агрегатора-такси, CRM-систему, блок контроля водителей и автомобилей, мобильные приложения для iOS и Android.

Однако, всегда учитываем: безопасность каждого пользователя это святое ;-)

Cookies используются всё меньше


Если вы достаточно активный пользователь интернета, вы наверняка так или иначе сталкивались с бесконечными дискуссиями относительно файлов cookie и о том, как они используются. В настоящее время браузерные технологии всё чаще отказываются от куки тем паче что сейчас всё строго зарегламентировано правилами конфиденциальности, такими как GDPR или CCPA. Хотя это, безусловно, прогресс, так как является важным шагом на пути к более ориентированному на конфиденциальность интернету, однако с другой стороны также наносит огромный урон основной функциональности большинства веб-сайтов, их UX, экономической структуре интернета и индустрии дижитал-аналитики. Хотя в техническом аспекте использование cookie-файла браузером в качестве идентификатора для возвращающегося пользователя весьма надёжно, есть и другие веб-технологии, основанные на хранении информации на локальном компьютере.

Роль кэша


Вот кэш. По сути, веб-кэширование означает хранение данных из интернета на вашем устройстве, поэтому браузер может повторно использовать эти данные позже, когда тот же ресурс запрашивается снова. Например, когда пользователь загружает веб-страницу впервые, сервер страницу полностью отправляет браузеру. Когда страница закэшируется, и пользователь запрашивает ту же страницу снова на следующий день, браузер запоминает её, и серверу не нужно отправлять ее снова, страница в браузере может быть сразу отображена из кэша. Это гораздо быстрее, да и обеспечивает высокую пропускную способность. В целом, технология кэширования значительно увеличивает скорость доставки веб-контента, а также значительно сокращает объём работы, выполняемой на стороне сервера.

Кэширование может быть выполнено с использованием ETag. Это такие идентификаторы, которые прикрепляются к каждому ресурсу, предоставляемому сервером (например, веб-странице или изображению). Таким образом сервер выясняет, кэшировал ли пользователь самую новую версию ресурса. Когда ресурс на сервере изменяется, для этого ресурса создается новый идентификатор ETag.

  • Понедельник.
    Пользователь заходит на веб-сайт впервые. В запросе отсутствует ETag. Страница сайта отправляется в браузер с ETag 123. Сайт сохраняется (кэшируется) на локальном устройстве.
  • Вторник
    Пользователь снова заходит на тот же сайт ETag 123 включён в исходящий запрос Сервер проверяет, изменился ли ресурс (Идентификатор ETag остается прежним?) Если ETag не изменился, сервер инструктирует браузер: просто используйте сайт, который был уже доставлен и кэширован в понедельник. Нет необходимости веб-ресурс пересылать повторно, время и трафик экономятся. Profit.


Использование технологии кэширования для отслеживания и идентификации пользователей


Хотя ETag предназначен именно для кэширования, эта функция также может быть взломана и преднамеренно использована для отслеживания пользователей.

Вот как это сделал я в моём примере:

  • Создаётся простой сайт с тремя страницами.
  • Вставляется один и тот же iFrame на каждую страницу. Этот iFrame просто белый пиксель 1x1, который невидим для пользователя.
  • Когда запрашивается этот веб-ресурс iFrame, с помощью PHP генерируется случайный идентификатор на стороне сервера. Я использую этот идентификатор, чтобы переопределить идентификатор ETag для iFrame, который обычно сервером выдаётся автоматически.
  • Каждый раз, когда пользователь запрашивает одну из трёх страниц (и, следовательно, запрашивает iFrame), мой идентификатор ETag включается в запрос. Затем проверяется на стороне сервера, существует ли этот идентификатор или это первый запрос без ETag.
  • Если ETag существует: значит, это вернувшийся посетитель. Можно зафиксировать как удостоверение его личности.
  • Если ETag не существует: это новый посетитель. Новый ID. С этого момента этот идентификатор будет включен во все заголовки запросов устройства этого пользователя на сайте.
  • В качестве последнего шага вот как этот ETag ID попадает в аналитику:
    я беру ID из заголовков запроса/ответа в iFrame на стороне сервера. Невидимый для пользователя, этот iFrame теперь содержит идентификатор пользователя. Затем я использую JavaScript на стороне клиента и просто включаю этот идентификатор в свой запрос отслеживания аналитики вместо идентификатора файла cookie.



Поиск ETag ID iFrame с помощью Chrome DevTools.

Как предотвратить отслеживание с помощью ETag


Это может быть достаточно непросто. Здесь не используются куки или локальное хранилище браузера. Работает без участия JavaScript. И не используется User-Agent.

Однако у пользователей есть несколько вариантов защиты от отслеживания ETag:

  • Отключите в настройках браузера кеширование.
    Тут следует соблюдать осторожность как пояснялось выше, кеширование может быть очень полезным и имеет много преимуществ.
  • Модифицируйте заголовки headers с помощью надстройки браузера.
    Хотя большинство браузеров изначально не предоставляют возможность изменять headers, для этой задачи существует множество доступных расширений браузера, таких как ModHeader. Почему это работает? Функциональность ETag опирается на заголовки запроса и ответа для обмена идентификатором. Например, если пользователь перезаписывает заголовок If-None-Match, чтобы он был пустым при каждом запросе, новое значение ETag будет генерироваться при каждом запросе страницы. Это предотвращает идентификацию устройства пользователя.




Почему это важно


Почему я проверяю эти вещи? Почему я написал эту статью? Я, разумеется, не намерен использовать это в широких масштабах. Но хотя ETag может использоваться и нехорошими людьми, этот пример демонстрирует важную мысль: как и большинство других технологий, по умолчанию ETag не обязательно вреден. В зависимости от того, для каких целей это используется.

Я считаю, что для всех важно знать, про существование подобных методов. И что они могут быть использованы. Было довольно много случаев, когда сайты использовали ETag незаконно. Некоторые из этих инцидентов были даже урегулированы в суде. И вполне вероятно, что подобные методы будут всё чаще использоваться перепуганной рекламной индустрией, которая наблюдает за тем, как рушится один из её столпов: coockie.

Один из многих (безопасных) примеров ETag в интернете можно найти, к примеру, в политике конфиденциальности сети быстрого питания Wendy в отношении файлов cookie и технологий отслеживания:


С помощью ETag можно генерировать уникальные значения отслеживания, даже если пользователь блокирует файлы cookie HTTP, Flash и/или HTML5.

Подобное объявление, похоже, является примером того, как многие сайты используют ETag в своей политике конфиденциальности. Чтобы было ясно: это само по себе не является ни плохим, ни незаконным. Конечно, значения ETag должны быть уникальными. В этом весь смысл их работы в целях кэширования. Однако этот раздел сформулирован очень расплывчато и неоднозначно, особенно когда речь идет о том, используются ли эти значения ETag для отслеживания или нет. И лично я считаю это проблемой. При запросе в отдел конфиденциальности Wendy, они ответили стандартным электронным copy-paste письмом, подтверждающим, что ETag не используются для отслеживания. Политика конфиденциальности, однако, оставляет эту дверь широко открытой. И это то, что меня беспокоит.

Я верю в открытую и прозрачную передачу знаний в отрасли среди поставщиков аналитики, издателей, рекламщиков и пользователей Интернета. ИМХО, отсутствие открытости является одной из основных причин, по которой мы все оказались втянуты в эту грязную войну с cookie-файлами: интернет-экосистема всегда страдала от недостатка прозрачности, технологии развивается слишком быстро, чтобы законодательство успевало за ними, и люди не понимают многочисленные тонкости веб-технологий, наподобие файлов cookie. И когда технологии используются ненадлежащим образом, пользователь по понятным причинам чувствует себя уязвлённым. Но запрет технологии оказывается классическим случаем борьбы с симптомами, а не с причиной. Тот факт, что многие технологические компании злоупотребляют такими технологиями, как файлы cookie, формирует несправедливое отношение к технологии со стороны общественности. Что, в свою очередь, приводит к несоразмерным мерам со стороны разработчиков браузеров и законодательства. Хотя эти меры нацелены на обеспечение приватности, они в то же время наносят вред хорошим и значимым инновациям.

Всегда есть нюансы. Я твёрдо верю в законность и важность серьёзной дижитал-аналитики до тех пор, пока она выполняется с должным уровнем соблюдения конфиденциальности. Что происходит после, когда магазин законно идентифицировал посетителя? ETag, безусловно, можно использовать в разных целях. Но одно можно сказать наверняка: эта тема никогда не станет скучной.
Подробнее..

Перевод Zoom так и не понял GDPR

28.08.2020 14:05:29 | Автор: admin


Cookies куки


Практически каждый веб сайт знает, когда вы посещали его в последний раз. Веб-сайты держат вас авторизованными и напоминают вам про корзину с товарами и большинство пользователей воспринимает такое поведение как данность.
Магия кастомизации и персонализации возможна благодаря Cookies. Cookies это небольшая по объему информация которая хранится на вашем девайсе и отправляется с каждым запросом веб-сайту и помогает ему с вашей идентификацией.


Несмотря на то, что функционал cookies может быть полезен в повышении безопасности и доступности веб сайтов, долгое время ведутся дебаты на тему слежения за пользователями. Большая часть вопросов касается преследования пользователей по всему интернету через cookies которые используются для рекламы, а так же то как такая информация может быть использована сторонними компаниями для манипуляций.
С тех пор как появилась ePrivacy директива и GDPR, тему cookies стали камнем преткновения онлайн приватности.


В течении прошлого месяца, удаляя Zoom (компания Threatspike EDR), мы обнаружили неоднократный доступ к Google Chrome cookie в процессе удаления:



Это было крайне подозрительно. Мы решили провести небольшое исследование и проверить является ли это поведение зловредным.


Мы проделали следующие шаги:


  • Почистили куки файл
  • Скачали Zoom
  • Поклацали сайт zoom.us
  • Походили по разным веб-сайтам, включая малоизвестные
  • Сохранили куки
  • Удалили Zoom
  • Сохранили куки еще раз для сравнения и что бы понять какие конкретно затрагивает Zoom.

Часть куков была добавлена при посещении сайта zoom.us, часть при авторизации на сайте.



Это поведение ожидаемо. Но когда мы попытались удалить Zoom клиент с компьютера под управлением Windows мы заметили интересное поведение. Файл install.exe обращается к Chrome Cookies и читает, в том числе куки не относящиеся к Zoom.



Изучив операции чтения, мы задались вопросом читает ли Zoom только определенные куки с определенных веб-сайтов?


Мы повторили шаги описанные выше с различным количеством куков и с различными веб сайтами. Причина по которой Zoom читает куки веб сайта фанатов какой-то поп звезды или Итальянского супермаркета, навряд ли кража информации. Исходя из наших тестов, паттерн чтения похож на бинарный поиск собственных кук.


Однако, мы все-таки нашли аномальное и интересное поведения в процессе удаления сравнив куки до и после. Процесс installer.exe записывает новые куки:



Куки без срока (так же известные как сессионные куки) будут удалены при закрытии браузера. Но куки NPS_0487a3ac_throttle, NPS_0487a3ac_last_seen, _zm_kms and _zm_everlogin_type имеют срок годности. Последняя запись имеет срок 10 лет:



Судя по имени "everlogin" это запись определяет использовать ли пользователь Zoom. И тот, факт, что эта запись будет храниться 10 лет после того как приложение было удалено, нарушает ePrivacy директиву:


У всех постоянных файлов cookie должен быть срок годности, записанный в их код, но их продолжительность может варьироваться. Согласно Директиве о конфиденциальности, они не должны хранится дольше 12 месяцев, но на практике они могут оставаться на вашем устройстве намного дольше, если вы не примете меры.

Слежение за пользовательской активность в интернете не самая ужасная вещь сама по себе. Однако, как правило пользователи не будут вдаваться в подробности "Принять все куки" кнопки. Зачастую, только на совести компании уважать ePrivacy, GDPR или нет.


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

Подробнее..

На что соглашается человек, когда разрешает все куки

25.02.2021 00:07:45 | Автор: admin
Люди не читают инструкций. Вы почти наверняка не читали лицензионное соглашение Windows, не читали лицензионное соглашение iTunes, не читали условия Linux GPL или любого другого программного обеспечения.

Это нормально. Такова наша природа.

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



Большинство нажимает Согласиться и продолжает жить как ни в чём ни бывало. Никто ведь не читает политику конфиденциальности, верно?

Разработчик Конрад Акунга (Conrad Akunga) решил разобраться, какие конкретно условия предусмотрены соглашением об использовании. Для примера он взял новостной сайт Reuters. Это абсолютно произвольный пример, у большинства других сайтов тоже есть свои правила.

Вот эти правила:


Обратите внимание на полосу прокрутки. Дальше идёт продолжение.

Ещё шесть экранов с текстом











Если вкратце, документ информирует пользователя о нескольких вещах:

  • Что веб-сайт собирает и обрабатывает данные
  • Что для этого он работает с различными партнёрами
  • Что сайт хранит некоторые данные на вашем устройстве с помощью файлов cookie
  • Что некоторые файлы cookie строго необходимы (определяется сайтом). Их нельзя отключить.
  • Некоторые персональные данные могут быть проданы партнёрам для предоставления соответствующего контента
  • Вы можете персонализировать рекламу, но не удалить её

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

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

И ещё один пункт о партнёрах, которым продаются ваши персональные данные. Список партнёров общий для всех сайтов, которые сотрудничают с IAB.

Кто же эти партнёры?

Если нажать на соответствующую кнопку, то появится следующее окно:


Обратите внимание, насколько маленький ползунок на полосе прокрутки. Наверное, там их сотни. Под названием каждой компании ссылка на политику конфиденциальности.


Это не одна и та же ссылка, а разные! Каждая из них ведёт на уникальную политику конфиденциальности каждого партнёра. Сколько человек на самом деле пойдёт по этим ссылкам вручную, чтобы прочитать условия? Это просто нереально.

Конрад Акунга воспользовался инструментами разработчика Chrome, чтобы извлечь реальный список партнёров со ссылками на условия конфиденциальности каждого из них.



Скопированный список он вставил в VSCode и получил огромный файл на 3835 строк, который после форматирования (Alt + Shift + F) разбился в чудовище на 54 399 строк.



Конрад написал программку, которая с помощью регулярных выражений извлекает нужные фрагменты данных названия компаний с URL и генерирует результат в формате Markdown по шаблону.

Log.Logger = new LoggerConfiguration().WriteTo.Console().CreateLogger();// Define the regex to extact vendor and urlvar reg = new Regex("\"vendor-title\">(?<company>.*?)<.*?vendor-privacy-notice\".*?href=\"(?<url>.*?)\"",RegexOptions.Compiled);// Load the vendors into a string, and replace all newlines with spaces to mitigate// formatting issues from irregular use of the newlinevar vendors = File.ReadAllText("vendors.html").Replace(Environment.NewLine, " ");// Match against the vendors html filevar matches = reg.Matches(vendors);Log.Information("There were {num} matches", matches.Count);// extract the vendor number, name and their url, ordering by the name first.var vendorInfo = matches.OrderBy(match => match.Groups["company"].Value).Select((match, index) =>new{Index = index + 1,Name = match.Groups["company"].Value,URL = match.Groups["url"].Value});// Create a string builder to progressively build the markdownvar sb = new StringBuilder();// Append headerssb.AppendLine($"Listing As At 30 December 2020 08:10 GMT");sb.AppendLine();sb.AppendLine("|-|Vendor| URL |");sb.AppendLine("|---|---|---|");// Append the vendor detailsforeach (var vendor in vendorInfo)sb.AppendLine($"|{vendor.Index}|{vendor.Name}|[{vendor.URL}]({vendor.URL})|");// Delete existing markdown file, if presentif (File.Exists("vendors.md"))File.Delete("vendors.md");//Write markdown to fileFile.WriteAllText("vendors.md", sb.ToString());

В результате получился список всех партнёров, и у каждой свой уникальный документ c условиями конфиденциальности. Вот этот список: vendors.md.

В нём 647 компаний.

Очевидно, что никто не сможет ознакомиться со всеми этими условиями прежде, чем нажать кнопку Согласиться, делает вывод автор.

Помните, что эти рекламные провайдеры предоставляют одни и те же услуги разным сайтам. Они однозначно идентифицируют браузер и устройство, поэтому могут анализировать и отслеживать ваши действия на разных сайтах для создания максимально точного профиля. На каждого якобы анонимного пользователя собираются большие объёмы данных.

Код для парсинга из этой статьи опубликован на Github.
Подробнее..

Перевод Как мы устранили редкую ошибку, из-за которой пришлось разлогинить всех пользователей Github

24.03.2021 10:15:26 | Автор: admin

8 марта мы рассказали о том, что из соображений безопасности разлогинили всех пользователей GitHub.com из-за редкой уязвимости защиты. Мы считаем, что прозрачность ключевой фактор сохранения доверия со стороны пользователей, поэтому решили рассказать об этом баге подробнее. В этом посте мы изложим технические детали данной уязвимости и объясним, как она возникла, как мы на неё отреагировали и какие мы предприняли шаги для того, чтобы подобное не повторилось.

Отчёты пользователей


2 марта 2021 через службу технической поддержки мы получили отчёт пользователя, который войдя на GitHub.com под собственными идентификационными данными, внезапно авторизировался как другой пользователь. Он немедленно вышел из аккаунта, но сообщил о проблеме нам, поскольку она обеспокоила его, и на то были все основания.

Мы привели в действие свои процедуры реагирования на инциденты с безопасностью и немедленно изучили этот отчёт, призвав на помощь специалистов компании из отделов безопасности, разработки и поддержки пользователей. Спустя несколько часов после первого отчёта мы получили второй отчёт от другого пользователя с очень похожей ситуацией. После анализа логов запросов и аудита мы смогли подтвердить истинность полученных внешних отчётов сессия пользователя действительно внезапно оказалась общей для двух IP-адресов примерно во время отправления отчётов.

Исследование недавних изменений в инфраструктуре


Учитывая то, что этот баг был новым поведением, мы сразу же заподозрили, что он связан с недавним изменением в нашей инфраструктуре, и начали поиск решения с анализа изменений. Недавно мы обновили компоненты на уровне системы, занимающемся балансировкой нагрузки и маршрутизацией. Мы выяснили, что устранили проблему с keepalive-сообщениями HTTP, которая, по нашему мнению, могла быть связана с указанной в отчётах проблемой.

После исследования этих изменений мы выяснили, что первопричиной были не они. Запросы пользователей, которые отправили нам отчёты, на уровне балансировки нагрузки следовали по совершенно другому пути, задействуя другие машины. Мы исключили возможность того, что ответы заменялись на этом уровне. Исключив из возможных первопричин недавние инфраструктурные изменения и будучи уверенными, что проблема присутствует не в слоях связи и протоколов, мы перешли к другим потенциальным причинам.

Исследование недавних изменений в коде


Благодаря тому, что мы начали расследование с недавних изменений в инфраструктуре, нам удалось выяснить, что запросы, приводившие к возврату неправильной сессии, обрабатывались на одной и той же машине и в одном процессе. Мы используем многопроцессную схему с веб-сервером Unicorn Rack, выполняющим наше основное Rails-приложение. обрабатывающее такие задачи, как отображение issues и пул-реквестов.

После изучения логов мы выяснили, что тело HTTP-объекта в передаваемом нами ответе клиенту было правильным, ошибочным были только куки в ответе пользователю. Отправившие отчёты об ошибке пользователи получили куки сессии пользователя, запрос которого совсем незадолго до них обрабатывался внутри того же процесса. В одном из случаев два запроса обрабатывались последовательно, один за другим. Во втором случае между ними было ещё два запроса.

У нас появилась рабочая теория о том, что нечто каким-то образом приводило к утечке состояния между запросами, которые обрабатывались в одном процессе Ruby. Нам нужно было выяснить, как такое может происходить.

Исследовав недавно внедрённые функции, мы выявили потенциальную проблему с безопасностью потоков, которая могла возникать из-за функциональности с недавно изменённой ради повышения производительности архитектурой. Одно из таких улучшений производительности заключалось в переносе логики включенных для пользователя функций в фоновый поток, который обновлялся с определённым интервалом вместо проверки их состояния во время обработки запроса. Нам показалось, что это изменение затронуло изучаемые нами области и теперь основной целью нашего исследования стало неопределённое поведение этой проблемы с безопасностью потоков.

Безопасность потоков и отчёты об ошибках


Для понимания проблемы с безопасностью потоков необходим контекст. Основное приложение, обрабатывающее большинство браузерных взаимодействий на GitHub.com это приложение Ruby on Rails, известное тем, что оно имело компоненты, написанные без учёта возможности в нескольких потоках (т.е. они были непотокобезопасны). Обычно в прошлом непотокобезопасное поведение могло приводить к неправильному значению во внутренних отчётах об исключениях системы, но при этом пользователи не сталкивались с изменением поведения системы.

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

Изначально мы думали, что это только внутренняя проблема отчётности, и что мы будем наблюдать в логах данные, зафиксированные от не относящегося к делу запроса в фоновом потоке. Несмотря на противоречивость, мы посчитали такое поведение безопасным, поскольку каждый запрос имел собственные данные запроса, а Rails-приложение создавало новый экземпляр объекта-контроллера для каждого запроса. Нам по-прежнему было непонятно, как это могло вызывать проблемы, с которыми мы столкнулись.

Многократно используемый объект


Наша команда совершила прорыв, обнаружив, что HTTP-сервер Unicorn Rack, используемый в нашем Rails-приложении, не создаёт новый и отдельный объект env для каждого запроса. Вместо этого он выделяет единственный Ruby Hash, который очищается (с помощью Hash#clear) между запросами, которые он обрабатывает. Благодаря этому мы поняли, что проблема с потокобезопасностью в логгинге исключений может привести не только к неправильности фиксируемых в исключениях данных, но и к передаче данных запросов на GitHub.com.

Первоначальный анализ привёл к созданию гипотезы о том, что для возникновения условия гонки необходимо два запроса, происходящих за короткий промежуток времени. Получив эту информацию, мы попытались воспроизвести проблему в среде разработки. Когда мы попробовали выполнить последовательность определённых запросов, то обнаружили, что требуется ещё одно дополнительное условие, а именно анонимный запрос, с которого начинается вся последовательность. Вот полный список необходимых шагов:


  1. В потоке обработки запросов запускается анонимный запрос (назовём его Request #1). Он регистрирует обратный вызов в текущем контексте для внутренней библиотеки отчётности об исключениях. Обратные вызовы содержат ссылки на текущий объект контроллера Rails, имеющий доступ к единому объекту среды запроса Rack, предоставляемого сервером Unicorn.
  2. В фоновом потоке возникает исключение. Сообщение об исключении копирует текущий контекст, чтобы включить его в отчёт. Этот контекст содержит обратные вызовы, зарегистрированные запросом Request #1, в том числе и ссылку на единую среду Rack.
  3. В основном потоке запускается новый запрос залогиненного пользователя (Request #2).
  4. В фоновом потоке система отчётности об исключениях обрабатывает обратные вызовы контекста. Один из обратных вызовов считывает идентификатор сессии пользователя, но поскольку запрос на момент контекста не имеет авторизации, эти данные ещё не считываются, и, следовательно, запускают новый вызов к системе авторизации через контроллер Rails из запроса Request #1. Этот контроллер пытается выполнить авторизацию и получает куки сессии из общей среды Rack. Так как среда Rack это общий объект для всех запросов, контроллер находит куки сессии запроса Request #2.
  5. В основном потоке запрос Request #2 завершается.
  6. Запускается ещё один запрос залогиненного пользователя (Request #3). В этот момент Request #3 завершает свой этап авторизации.
  7. В фоновом потоке контроллер завершает этап авторизации, записывая куки сессии в cookie jar, находящийся в среде Rack. На данном этапе это cookie jar для Request #3!
  8. Пользователь получает ответ на запрос Request #3. Но cookie jar был обновлён данными куки сессии Request #2, то есть пользователь теперь авторизован как пользователь из Request #2.

Подведём итог: если исключение возникло именно в нужный момент и если параллельная обработка запросов происходит именно в нужном порядке среди серии запросов, то в результате сессия одного запроса заменяется сессией более раннего запроса. Возврат неправильного куки происходит только для заголовка куки сессии, и, как говорилось выше, остальная часть тела ответа, например HTML, по-прежнему была связана с ранее авторизованным пользователем. Это поведение соответствовало с тем, что мы видели в логах запросов и мы смогли чётко идентифицировать все элементы, составлявшие первопричину состояния гонки.

Для возникновения этого бага требовались очень конкретные условия: фоновый поток, общий контекст исключения между основным потоком и фоновым потоком, обратные вызовы в контексте исключения, многократное использование объекта env между запросами и наша система авторизации. Подобная сложность является напоминанием о многих из пунктов, представленных в статье How Complex Systems Fail, и демонстрирует, что для возникновения подобного бага требуется множество различных сбоев.

Предпринимаем действия


Выявив первопричину, мы немедленно сделали основным приоритетом устранение двух условий, критически важных для появления этого бага. Во-первых, мы избавились от нового фонового потока, появившегося после вышеупомянутой модернизации архитектуры, призванной повысить производительность. Благодаря тому, что мы точно знали, что было добавлено в процессе этой работы, изменения легко можно было откатить. Изменение, в котором был удалён этот поток, вывели в продакшен 5 марта. После этого изменения мы знали, что условия, требуемые для возникновения условия гонки, больше не будут удовлетворяться, и что наша непосредственный риск возврата неверных сессий снижен.

После выпуска изменения с удалением фонового потока, мы создали патч для Unicorn, удаляющий возможность создания общей среды. Этот патч был выпущен 8 марта и ещё больше усилил изоляцию между запросами, даже на случай возникновения проблем с потокобезопасностью.

Кроме устранения бага мы предприняли действия для определения пользовательских сессий, на которые он повлиял. Мы изучили данные логгинга на предмет паттернов, соответствующих неправильно возвращаемых сессий. Затем мы вручную просмотрели соответствующие паттерну логи, чтобы определить, на самом ли деле сессия была неверно возвращена от одного пользователя другому.

В конце мы решили сделать ещё одно превентивное действие, чтобы гарантировать безопасность данных наших пользователей, и аннулировали все активные сессии пользователей на GitHub.com. Учитывая редкость условий, необходимых для возникновения этого условия гонки, мы знали, что вероятность возникновения бага очень мала. Хотя наш анализ логов, проведённый с 5 по 8 марта, подтвердил, что это была редкая проблема, мы не могли исключить вероятность того, что сессия была неверно возвращена, но никогда не использовалась. Мы не хотели идти на такой риск, учитывая потенциальный ущерб использования даже одной из таких неверно возвращённых сессий.

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

Продолжаем работу


Несмотря на устранение непосредственной угрозы, мы объединили усилия с мейнтейнером Unicorn, чтобы поднять изменения вверх по потоку и чтобы новые запросы выделяли собственные хэши среды. Если Unicorn будет использовать новые хэши для каждой среды, то это устранить возможность того, что один запрос ошибочно завладеет объектом, который может повлиять на следующий запрос. Это дополнительная защита, позволяющая предотвратить превращение подобных багов потокобезопасности в уязвимости защиты для других пользователей Unicorn. Хотим искренне поблагодарить мейнтейнеров Unicorn за сотрудничество и обсуждение данной проблемы.

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

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

Подведём итог


Многопоточный код бывает очень сложен в анализе и отладке, особенно в тех кодовых базах, где потоки в прошлом использовались редко. Пока мы решили перестать использовать долгоживущие потоки в наших процессах Rails. Мы воспользуемся этой возможностью, чтобы сделать наш код более надёжным для различных многопотоковых контекстов, а также для обеспечения дополнительной защиты и создания потокобезопасной архитектуры для использования в будущем.

Если взглянуть со стороны, то данный баг не только оказался сложным с технической точки зрения (ведь для его возникновения требуются сложные взаимодействия между несколькими потоками, отложенными обратными вызовами и совместным использованием объектов), но и стал проверкой способности нашей организации реагировать на проблему с неизвестной причиной и уровнем угрозы. Отлаженная работа команды реагирования на инциденты с безопасностью совместно со специалистами из отделов поддержки, безопасности и разработки позволила нам быстро исследовать, оценить и квалифицировать потенциальную опасность этой проблемы, а также повысить приоритет её решения во всей компании. Это повышение приоритета ускорило работу над анализом логов, изучением последних изменений в коде и архитектуре, а в конечном итоге позволило выявить глубинные проблемы, которые привели к возникновению этого бага.

Благодаря чёткому пониманию проблемы мы смогли сосредоточиться на принятии нужных мер для ограничения её воздействия на пользователей. Полученные нами в процессе этой работы знания позволили нам обсудить ситуацию с ответственными лицами из разных отделов компании и принять конфиденциальное решение о необходимости выхода из системы всех пользователей GitHub.com. Мы лучше разобрались в сложных системах компании и воспользуемся этой возможностью для создания мер предосторожности, предотвращающих возникновение подобных проблем в будущем.
Подробнее..

Recovery mode Federated Learning of Cohorts убийца cookie или всего лишь еще один способ трекинга пользователей

14.04.2021 12:16:12 | Автор: admin

В последнее время активно освещается проблема приватности пользовательских данных. Скандал с Cambridge Analytica и Facebook, внедрение GDPR, многомиллионные штрафы для Google за установку файлов cookie без ведома пользователей, обновление iOS 14 (с ограничениями трекинга) все это оказывает давление на рекламодателей, рекламные платформы и заставляет всерьез озаботиться обеспечением приватности данных.

Компания Google разработала и активно тестирует новую технологию, которая может заменить традиционный таргетинг рекламы на основе cookie-файлов Federated Learning of Cohorts (FLoC). В статье рассказываем, что это за технология и чего ждать рекламодателям.

Чем не угодили cookie и почему нельзя просто так взять и отказаться от них

Основная претензия к cookie-файлам отсутствие гарантии конфиденциальности пользовательских данных. Сторонние cookie, установленные на сайтах, собирают слишком много информации о пользователях. С помощью этих данных (история поисковых запросов, просмотров страниц, заполнение полей в формах ввода данных и т. д.) можно идентифицировать конкретного человека, что является серьезной угрозой приватности.

Вместе с тем просто убрать cookie не получится слишком многое держится на них:

  • рекламные системы используют cookie для ретаргетинга и поиска релевантной аудитории для показа определенных рекламных объявлений. Чем релевантнее (и эффективнее) реклама, тем больше денег получают рекламные системы от рекламодателей;

  • рекламодатели с помощью рекламных систем получают возможность запускать более результативные рекламные кампании (и получать больше прибыли);

  • сайты-издатели и вебмастеры зарабатывают на размещении рекламы. Они напрямую заинтересованы в том, чтобы реклама была выгодна рекламодателям и размещений было много.

И, наконец, сами пользователи привыкли к многим удобствам, которые обеспечивают cookie:

  • сохранение настроек авторизации и параметров;

  • юзабилити, основанное на поведении пользователя;

  • персонализация интерфейса, контента, рекламы.

Как использовать данные с сохранением конфиденциальности

Есть хороший пример, в котором сочетаются те же задачи, что и в вопросе с cookie, медицина. Например, для повышения эффективности тестов на определение заболевания нужно собрать обучаемую модель. При этом:

  • нужно получить как можно больше данных об обследованиях пациентов;

  • данные должны быть обезличенные (медицинские учреждения не делятся данными конкретных пациентов из соображений конфиденциальности).

Решение этой задачи обрабатывать данные на стороне каждого медицинского учреждения и передавать общей модели обобщенные данные (без раскрытия персональных данных отдельных пациентов).

Именно такая концепция лежит в основе Federated Learning.

Что такое Federated Learning

Google разработала и активно тестирует новую технологию Federated Learning of Cohorts (FLoC).

Federated Learning распределенная модель, которая использует алгоритмы машинного обучения для анализа пользовательских данных и формирования когорт. Когорта группа обезличенных данных пользователей (браузеров) с похожими свойствами. Данные пользователей (которые могут содержать чувствительную и конфиденциальную информацию) не поступают напрямую ни в один централизованный обработчик или сервер: вычисление и назначение когорты происходит на стороне браузера.

Остальным сервисам (рекламным платформам, сайтам и т. д.) передается только идентификатор когорты, без данных, по которым можно идентифицировать отдельных пользователей.

Для справки. Еще в 2017 году Google тестировал технологию Federated Learning в приложении Gboard для Android. Когда Gboard показывает предлагаемый запрос, смартфон пользователя локально сохраняет информацию о текущем контексте и клике на предложение (или отсутствии клика). Federated Learning обрабатывает эту историю на стороне устройства и предлагает улучшения для следующей итерации модели предложений Gboard.

Для чего может применяться FLoC

  • Показ рекламных объявлений людям, чьи браузеры принадлежат к когорте, которой характерно определенное поведение (например, посещение сайта рекламодателя) или интерес к определенным продуктам.

  • Применение моделей машинного обучения для прогнозирования вероятности конверсии на основе когорты пользователя (и корректировки ставки на рекламном аукционе с использованием полученной вероятности).

  • Рекомендация релевантного контента пользователям.

Как работает FLoC

Разберем на примере, как работает FLoC на практике. Для понимания процесса определим трех основных участников:

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

  • издатель новостной сайт, который продает рекламные места (размещает у себя рекламные объявления и получает вознаграждение от рекламной системы);

  • рекламная система платформа, предоставляющая инструменты для размещения рекламы.

Рассмотрим этот процесс подробнее, для примера возьмем двух пользователей, которых зовут Сергей и Антон (имена выбраны рандомно). Изначально их браузеры принадлежат к одной и той же когорте, допустим, 1354.

1. FLoC-сервис

FLoC-сервис, используемый браузером, создает математическую модель с тысячами когорт. Каждая из когорт соответствует тысячам браузеров с похожей недавней историей активности и имеет свой уникальный номер, по которому ее можно идентифицировать.

2. Браузер

Из FLoC-сервиса браузер Сергея получает данные, описывающие FLoC-модель. Браузер пользователя определяет свою когорту: для вычисления подходящей когорты используется специальный алгоритм, который соотносит браузерную историю с наиболее подходящей когортой. В нашем примере это будет когорта под номером 1354. Обратите внимание, браузер Сергея не передает никаких данных FLoC-сервису.

Точно так же браузер Антона вычисляет идентификатор своей когорты. История браузера этого пользователя отличается от истории браузера Сергея. Однако они достаточно похожи, поэтому им присваивается одинаковая когорта 1354.

3. Взаимодействие с рекламодателем

  • Сергей посещает сайт рекламодателя (shoe.com).

  • Сайт запрашивает ID когорты браузера пользователя и получает значение 1354.

  • Сергей ищет кроссовки для бега.

  • Сайт сохраняет информацию о том, что браузер из когорты 1354 выявил интерес к беговым кроссовкам.

  • Позже на сайте зафиксирован дополнительный интерес к товарам со стороны когорты 1354, а также со стороны других когорт.

  • Время от времени сайт собирает информацию о когортах и проявленному интересу к товарам и передает ее рекламной системе.

4. Издатель новостной ресурс news.com

  • Антон посещает новостной сайт news.com.

  • Сайт издателя запрашивает у браузера пользователя его когорту.

  • Затем сайт отсылает запрос рекламной системе и включает в этот запрос ID когорты браузера Антона 1354.

5. Рекламная система

Рекламная система может подобрать подходящее для Антона рекламное объявление, основываясь на данных от издателя и рекламодателя:

  • когорта браузера Антона (1354) эти данные рекламной системе передает издатель;

  • интересы, которые соответствуют данной когорте, передаются от рекламодателя (Браузеры из когорты под номером 1354 могут быть заинтересованы в беговых кроссовках).

Рекламная система подбирает подходящее объявление беговые кроссовки от shoe.com.

На сайте отображается объявление кроссовок.

Ключевая особенность такого подхода

Сейчас показ релевантных рекламных объявлений базируется на технологиях отслеживания файлов cookie и цифровых отпечатков устройств. Эти технологии используются рекламодателями для отслеживания поведения в сети отдельных пользователей.

FLoC позволяет сохранить релевантность, но без ущерба для приватности данных: браузер не делится браузерной историей ни с FLoC-сервисом, ни со сторонними службами. Браузер вычисляет подходящую когорту на стороне устройства пользователя. История браузера при этом никогда не покидает пределы устройства.

Браузерная когорта может меняться

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

Характеристики активности каждой когорты в основном постоянны. Поэтому когорты хорошо подходят для подбора рекламных объявлений, так как объединяют схожие поведенческие характеристики. Условно, когорта 1354 будет объединять людей, заинтересованных в беговых кроссовках, сегодня, через месяц и через полгода. Только сегодня это может быть одна группа людей, а через месяц совершенно другая.

Браузеры отдельно взятых пользователей могут переходить от когорты к когорте по мере того, как их история браузинга меняется. Ожидается, что браузер будет пересчитывать свою когорту каждые 7 дней.

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

На какой стадии сейчас находится технология и что ждать в ближайшее время

30 марта Google запустил тестирование технологии в браузере Chrome. Первичные тесты проводятся на небольшой группе пользователей в таких странах:

  • Австралия;

  • Бразилия;

  • Канада;

  • Индия;

  • Индонезия;

  • Япония;

  • Мексика;

  • Новая Зеландия;

  • Филиппины;

  • США.

Со временем тестирование будет расширяться и на другие регионы.

Главные вопросы к Federated Learning

Что с релевантностью рекламы?

Вопрос, который больше всего интересует рекламодателей. Они опасаются ухудшения эффективности рекламы при отказе от привычных cookie.

По заявлениям Google, беспокоиться не стоит: при тестировании FLoC Google определил, что использование новой технологии обеспечивает как минимум 95% конверсий по сравнению с использованием традиционного показа рекламы на основе cookie.

Решит ли FLoC проблему приватности пользовательских данных?

Размер когорты должен быть достаточным, чтобы сохранялась анонимность

В каждой когорте могут быть тысячи браузеров. Чем меньше размер когорты, тем более персонализированной будет реклама, но при этом уменьшится степень приватности (и наоборот).Для обеспечения анонимности пользователей в когорте Google использует обобщение данных k-анонимность. Под термином k-анонимность понимается метод, который позволяет скрыть персональную информацию нескольких лиц в наборе данных, если эти лица похожи друг на друга. Если упрощенно, k количество пользователей в группе с похожими свойствами. Чем больше это число, тем более анонимна группа и сложнее отследить отдельно взятого пользователя. Подробнее о k-анонимности можно почитать тут.

k-анонимность не гарантия

Несмотря на заявления Google об обезличивании данных пользователей в когортах (с помощью вычисления ID когорты на стороне браузера и размера когорт), многие игроки в отрасли высказывают опасения по поводу того, что новая технология не решает проблему сохранения анонимности:

  • при авторизации на сайте через аккаунт Google сайт может сопоставить пользовательские данные с ID когорты FLoC в этом случае уже нет полной обезличенности данных;

  • деперсонализация может быть возможной благодаря пересечению нескольких характеристик, например идентификатора когорты и IP-адреса пользователя;

  • также есть мнение о том, что данные все равно хранятся у Google (пусть и частично обезличенные), а это дает частной компании неоправданно широкие возможности и власть над информацией.

Чего ожидать рекламодателям и чем закончится борьба за приватность пользовательских данных

Пока FLoC все еще находится на стадии тестирования и не является окончательным вариантом выводы делать рано. Возможно, будут рассмотрены другие альтернативы трекингу с помощью файлов cookie. Но ясно одно все основные участники рынка (рекламодатели, рекламные платформы и издатели) заинтересованы в нахождении баланса:

  • между приватностью пользователей, за которую активно борются регуляторы, общественные организации и отдельные компании (привет, Apple);

  • и трекингом, который позволял бы сохранить возможность показывать пользователям релевантную рекламу и извлекать из этого прибыль.

Если говорить про Google, рекламный бизнес занимает львиную долю в структуре доходов корпорации и снижать его эффективность явно не входит в планы IT-гиганта. Поэтому с большой долей уверенности можно сказать, что Google приложит все усилия для поиска решения, которое удовлетворит всех (и позволит компании продолжать получать миллиарды выручки с рекламы).

Подробнее..

Прощай Google! 15 Альтернативных поисковиков, которые не шпионят, а сажают деревья и раздают воду

21.06.2020 12:22:54 | Автор: admin
Аве Кодер!

В этой статье речь пойдет о крутых инди поисковиках, которые могут составить конкуренцию поисковым гигантам, а также удовлетворить вкусы как утонченного мусье, так и идейного борца за личную жизнь.


CC Search


ccsearch.creativecommons.org

CC Search заточен под то, чтобы искать материал не обремененный авторскими правами. Так что если ты контент мейкер, особенно начинающий и денег на платные подписки пока нет, а годноты таки хочется, то этот поисковик то, что надо.

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

Работает CC Search довольно прямолинейно: он извлекает результаты с таких платформ, как Soundcloud, Wikimedia и Flickr и отображает результаты, помеченные как материал Creative Commons.

В панели слева можно выбрать тип лицензии по которой будет фильтроваться контент, ну и прочие стандартные фильтры тип файла, размер, также можно фильтровать по источникам добычи.

SwissCows


swisscows.ch

Швейцарские коровы это уникальный поисковик с милым швейцарским дизайном и запахом сыра. Oн позиционирует себя как семантическую поисковую систему для семейного пользования и использует искусственный интеллект для определения контекста пользовательского запроса.

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

DuckDuckGo


duckduckgo.com

Поисковик УткаУткаИди не собирает и не хранит твои личные данные, по крайней мере так они говорят (кря).
Это означает, что ты можешь спокойно выполнять поиск, не беспокоясь о том, что твой личный ФСБшник узнает, что ты все еще ищешь адрес того деда мороза, которому рассказывал стишок когда тебе было 9 и почему поиск продолжает выдавать адрес мордовской колонии номер 17.

В любом случае, DuckDuckGo идеальный выбор для тех, кто хочет сохранить свои привычки просмотра и личную информацию конфиденциальной, если ты понимаешь о чем я.

StartPage


www.startpage.com

StartPage предоставляет ответы от Google, что делает его идеальным выбором для тех, кто предпочитает результаты поиска Google, но не хочет, чтобы их история поиска отслеживалась и сохранялась.

Он также включает в себя генератор URL, прокси-сервис и поддержку HTTPS.
Генератор URL особенно полезен, потому что он устраняет необходимость собирать куки.
Вместо этого он запоминает настройки таким образом, чтобы обеспечить конфиденциальность.

SearchEncrypt


www.searchencrypt.com/home

SearchEncrypt это поисковая система, которая использует локальное шифрование для обеспечения конфиденциальности запросов.

Информация для реальных ценителей поисковик использует комбинацию методов шифрования, которые включают шифрование Secure Sockets Layer и шифрование AES-256.

Когда ты вводишь запрос, Search Encrypt извлекает результаты из своей сети партнеров по поиску и передает запрашиваемую информацию.

Интересная особенность Search Encrypt заключается в том, что после 30 минут бездействия, твои поисковые запросы и настройки обнуляются, поэтому никто не узнает что ты там искал, печатая одной рукой.

Search Encrypt Выбор настоящего параноика.

Gibiru


gibiru.com

Календарь Мая предсказывал столкновение Земли с планетой Нибиру, но в итоге Земля столкнулась с Gibiru.

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

Все их доходы генерируются через сбор комиссии, когда пользователи покупают или продают через их поисковик. Также имеется мобильный аналог приложение Wormhole и ExpressVPN, видимо, от их друганов.

OneSearch


www.onesearch.com

В январе 2020 года Verizon Media, так называется подразделение Verizon Communications, то есть Bell Corporation, после того, как ее раскололи и перекрасили запустила поисковую систему OneSearch, ориентированную на конфиденциальность.

Они заявляют что в их поисковике:
Нет отслеживания файлов cookie, ретаргетинга или личного профилирования.
Нет обмена персональными данными с рекламодателями.
Нет хранения истории поиска пользователей.

Но есть:
Беспристрастные, нефильтрованные и зашифрованные результаты поиска.

По сути, это еще один поисковик, пытающийся позиционировать себя не похожим на Google, тот в свою очередь не скрывает что проводит сбор данных, однако, что твориться в OneSearch на самом деле неизвестно.

Wiki.com


wiki.com

Это поисковой агрегатор, выуживающий информацию с википедии и с тысяч различных wiki по всему интернету.

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

Boardreader


boardreader.com

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

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

giveWater


www.givewater.com

Пока Джеф Безос наслаждается званием человека, собравшего больше всех нулей на своем банковском счету, два хипана из Нью Йорка сделали дайВоду поисковик, который они сами описывают как социально значимый.

Итак, как он работает:
Ты используешь giveWater, для поиска, к примеру, материала для своего диплома.
Платные поисковые объявления генерируют доход для giveWater.
giveWater распределяет прибыль от этих объявлений между своими партнерами благотворительными фондами
Фонды используют пожертвованные средства для обеспечения чистой водой.

Ecosia


www.ecosia.org

Поисковик из Германии, который отдает 80% своих доходов на посадку деревьев и работающий по схожему с giveWater принципу, ставя социально значимые проекты на первое место перед прибылью для акционеров и инвесторов.

Когда в 2019 PornHub пообещал начать сажать деревья за просмотры видео, пользователи незамедлительно предложили открывать PornHub в Ecosia, дабы озеленить планету с еще большей скоростью. Как говорится: ствол за ствол.

Ekoru


www.ekoru.org

Еще один озеленительный проект, который утверждает, что их сервера также работают на зеленой энергии.

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

Slideshare


www.slideshare.net

Не совсем отдельный поисковик, скорее фича платформы LinkedIn, с помощью которого можно искать, внезапно слайды и презентации. Так что, бери бизнес ланч и врубай яппи-диафильм про то, как менялись предпочтения населения Среднего Запада относительно сухих завтраков.

Wayback Machine


archive.org

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

Тогда тебе сюда. Этот поисковик делает снимки интернет ресурсов в определенный момент времени, в которое ты и можешь отправиться.

У Ясеня


уясеня.рф

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

К сожалению Ясень в основном качает головой и не выдает реальные результаты, дерево все-таки.

Здесь также можно найти некий яснослов, который позволяет яснословить. А именно складывать новые великолепные слова на основе существующих.

Например, можно спросить у Ясеня имя своего будущего чада и сказочный пилматериал съяснословит что-то вроде Енотия.

Судя по дизайну, пилили его пока у авторов не выветрилась брага.

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



Пиши в комментариях свои личные предпочтения или если я упустил кого-то достойного внимания. Аве!
Подробнее..

Перевод Сторонние куки хранить нельзя блокировать? Браузер Brave подходит к снаряду

23.03.2021 18:09:53 | Автор: admin

Сторонним вход воспрещён

С давних времён и до наших дней отслеживание сайтами действий пользователя, по большому счёту, основано на эксплуатации одного из самых старых пороков интернета сторонних (по-иностранному, third-party) данных: кук, записей в localStorage и т. д. Разумеется, в древние времена мало кто мог предположить, что браузерными куками будет вскормлен бессердечный спрут индустрии слежки и рекламных сетей, а конфиденциальность абонентов сети будет пожертвована во славу Больших Данных, принадлежащих Большим Корпорациям.

Как уже было сказано, простая блокировка сторонних кук спорное решение, поскольку мешает нормальной работе множества обычных сайтов. Причём нередко ломаются важные сценарии: вход на сайт или процесс оплаты. Дело в том, что до недавних пор основные браузеры позволяли этим хранилищам работать без каких-то ограничений соответственно и сайты не ждут подвоха или недоступности сторонних данных. Такое отсутствие ограничений позволяет всем разновидностям аналитических скриптов, следящих пикселей и рекламных сетей выдавать вашему браузеру уникальную куку и вести журнал её жизнедеятельности (в хромоподобных браузерах куки можно увидеть на странице chrome://settings/siteData)

Пример

Cайты shop.com, school.edu и bank.ru добавляют на свои страницы следящий пиксель <img src=https://trackingcorp.com/track.gif>. При первом запросе за этим пикселем, сайт trackingcorp.com сохранит в браузере куку с уникальным номером. При последующих запросах с сайтов магазина, школы и банка, сервер trackingcorp будет записывать историю визитов для этого номера и продавать её всем желающим за пригоршню долларов.

До недавнего времени мы балансировали между сохранением приватности и обеспечением корректности работы сайтов путём всевозможного колдунства, монтажа костылей и инжекта скриптов. Некоторые сайты приходилось просто добавлять в список исключений, иначе они отказывались работать. Это более или менее помогало оборонять наших пользователей, но стратегически это глубоко ущербный подход, который не решает проблему в целом.

Усилиями наших лучших умов (и с помощью наблюдений за другими браузерами на рынке) было придумано эфемерное хранилище сторонних данных новая конструкция, которая не кормит трекеры, рекламные сети и Корпорации Добра данными пользователей, и при этом сильно реже ломает посещаемые сайты. На момент публикации мы включили эфемерное хранилище в бете и раскатываем на пользователей релизного канала.

В чем сила

Эфемерное веб-хранилище по сути представляет собой комбинацию решений по хранению данных, каждое из которых мы опишем подробнее, с оговоркой, что по результатам работы некоторые пункты могут быть пересмотрены.

  1. Никаких кук по запросам за ресурсами (картинки, скрипты и т. д.) на сторонних доменах. Brave шлет куки по запросам на поддомены текущего сайта (например, sub.habr.com), но если это cross-origin запрос (например, за evilcorp.com/tracking_pixel.gif), ни одна кука не будет выдана.

  2. Секционированное (то есть, раздельное) хранилище для сторонних фреймов. Скрипты, которые исполняются в таких фреймах, могут обращаться к кукам документа, localStorage или sessionStorage API (остальные API пока что, как и раньше, полностью отключены для сторонних запросов), однако фактически им будут предоставлены разные хранилища. Например, если фрейм trackingcorp.com встроен в сайты example.org и other.org, то будут созданы два хранилища: одно для trackingcorp.com + example.org, другое для trackingcorp.com + other.org. Таким образом, исключается возможность сохранения в браузере уникальной куки (или записи в localStorage) имени trackingcorp.com.

  3. На одном и том же сайте все сущности используют одно хранилище. Например, у вас открыты две вкладки сайта first.example.org и second.example.org, на каждой вкладке есть фрейм с видео с YouTube. Оба фрейма будут обращаться к одному хранилищу. А вот если тот же YouTube-фрейм встроен в other.org или на одной из вкладок открыто то же самое видео на сайте YouTube хранилище example.org ни тот, ни другой фрейм не увидят, ибо не положено.

  4. Все сторонние хранилища для first-party сайта очищаются, как только закрывается последняя вкладка с этим сайтом. Соответственно, сторонние фреймы, о которых мы говорили в примерах выше, теряют данные в этих хранилищах. Пока открыта хоть одна страница для данного сайта, сторонние хранилища для фреймов существуют. Если закрыть последнюю и открыть заново появятся новые, пустые хранилища.

  5. После закрытия браузера очищаются все сегменты всех сторонних хранилищ. Даже при включенном восстановлении вкладок, после рестарта, хранилища будут новыми. Этот подход совпадает с алгоритмом рандомизации браузерных отпечатков в Brave, о которым мы расскажем в следующих сериях.

Пока что мы умеем только секционировать куки и localStorage, на подходе indexedDB и другие API например, предстоит интегрироваться с Storage Access API (которое в Chromium внедряла команда Edge).

Что у других браузеров?

Пионеры секционирования сторонних хранилищ это Safari и Tor Browser, примером которых мы и вдохновились. В отличие от Safari, Brave очищает сторонние хранилища при закрытии сайта, а не всего браузера, что существенно усиливает защиту многие пользователи крайне редко перезапускают браузер.

Секционированное хранилище (в отличие от нас не эфемерное, а персистентное) для обороны от суперкук сделали в Firefox. Chromium же в этой области догоняющий на сегодня в нём секционируется только кэш, и ведётся работа по другим компонентам. C 2019 года Firefox блокирует сторонние куки, принадлежащие доменам известных трекеров. А совсем недавно авторы Chromium объявили о курсе на полный запрет сторонних кук этот процесс растянется надолго, но одной исторической ошибкой в интернете станет меньше.

Подробнее..

Мини-туториал отключение third-party cookies

17.11.2020 18:17:45 | Автор: admin

Меня долго печалила ситуация с рекламой в Интернете. Стоит всего однажды зайти на продающий какие-либо товары сайт, как тут же начинаешь видеть соответствующую рекламу в соцсетях, в почте, даже в чёртовом музыкальном плеере на телефоне (да, в Xiaomi докатились и до этого). Причем неважно с какой именно целью ты зашел на сайт быть может просто решил уточнить характеристику устройства, или уточнить модель девайса, о котором рассказал другу. Это совершенно не важно, итог один: несколько недель тебе будут показывать злополучные стиральные машинки, мониторы и так далее. Знакомая ситуация? Я уверен, что да!


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


О сторонних cookie

Если вкратце, то на заре интернета сайты были "неперсональными". При каждом обращении пользователю показывался один и тот же статичный макет страницы. С целью хранения состояния (например, для создания корзины товаров) были придуманы т.н. cookies. Это маленькие файлы, которые сайт отдает вместе со страничкой браузере, и которые ожидает получить обратно при следующем обращении. Так стало возможным понять, новый ли это пользователь, или он уже ранее появлялся на сайте. Браузер бережно хранит Ваши cookies в разрезе сайтов: сайту A недоступны "куки" сайта B. Однако со временем в HTML (основной язык веба) появилась возможность встраивать в сайт "кусочки" другого сайта. Такому встроенному сайту, несмотря на "ущербность", доступны его cookies. Например, в магазин встраивается "кусочек" соцсети, якобы для возможности поставить лайк. Таким образом получается, что магазин знает Ваш ID в социальной сети, даже если Вы явно для этого ничего не делали. Такие cookie называюся third-party. Они, как правило, не требуется для нормальной работы сайта, однако открывают большие возможности по межсайтовой слежке. Статьи по теме: раз, два.


Для отключения подобной слежки (строго говоря отключения сторонних cookies) нужно поставить всего одну галочку в Chrome. Вот ссылка на настройки браузера (вашего, локального): chrome://settings/cookies?search=Privacy+and+security. Нужно включить опцию Block third-party cookies:



И вуаля, на скриншоте ниже ситуация cookie до и после. Раньше была целая куча "левых" сайтов (это еще не попали yandex, mail и т.д.), а теперь только сам сайт магазина. Можете попрактиковаться в проверке такого подхода.



Теперь Вы можете спокойно искать в сети любые товары, не боясь бессмысленной и бсепощадной рекламы. Как бы ни старались рекламщики, пока "воз и ныне там":


Вы купили диван? Давайте мы подберем Вам еще 50 диванов

Я уже несколько дней тестирую полет нормальный, работоспособность нужных мне сайтов не нарушена!

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru