Новшества JavaScript: итоги Google I/O 2019. Часть 1

Совершенно верно, только конкретно про название Hard Private это даже не я, а сам комитет так называет.

Новшества JavaScript: итоги Google I/O 2019. Часть 1

Раз уж вы стали цепляться за всё и вся начнём.

Нету никакой "реализации инкапсуляции через weakmap", это вообще НЕ инкапсуляция (т.к. переменная не скрыта)

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

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

Далее не забывайте про главное отличие от других ООП языков — прототипное наследование он сильно отличает ES от многих имеющихся ООП-языков и требует своих подходов в реализации.

Потом что же это такое «стандартная» реализация инкапсуляции и какой это стандарт и действует ли он во всех языках без исключений и не изменен ли он со временем?

ES это отдельный язык, у которого свой путь и принимаемые решения зависят на уже принятых ранее. Причём при всём при этом ES сохраняет обратную совместимость, чего не сказать про тот же Python (переход со 2 версии на 3 был довольно долгим и болезненным)

Никаких викмапов и прочей чуши для этого не надо

Уверены? И вы прям знаете точно во что превращает компилятор синтаксис приватных полей? И это прям точно не похоже на те же WeakMap? Вот серьёзно.

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

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

Вы просто проигнорировали все отличия ES от того же C# или C++ и сказали, что должно быть 1 в 1. Более того ваши представления отличаются от действительности и выше вам на это уже казали.

С тем чтобы закрыть нет никаких трудностей

Приведите пример на ES, в котором будет очень легко реализовать закрытую переменную класса (причём переменная не static, а для каждого инстанса своя), но на синтаксисе ES6-ES10 с использованием синтаксического сахара классов. Главное эта переменная не должна быть доступна кому угодно кроме инстанса/инстансов класса.

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

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

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

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

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

Новшества JavaScript: итоги Google I/O 2019. Часть 1

Причин этому синтаксису несколько:

1. Это всё-таки синтаксис Hard Private соответственно задача закрыть доступ из вне всем и именно в рантайме.
2. Обеспечение обратной совместимости с точки зрения комитета — не сломать имеющийся код изменением синтаксиса.
3. Обеспечение обратной совместимости с точки зрения разработчиков — действительно закрыть доступ к полям, используемым для внутренней реализации классов и не предназначенных для внешнего использования.
4. Упрощение реализации синтаксиса в движках в т.ч. в целях избежать ухудшение производительности.

Почему не использовать зарезервированное в ES ключевое слово private, которое уже применено в TypeScript:

• Относительно TypeScript ключевое слово private предназначено непосредственно для разработчиков, которые читают и/или пишут конкретный код. Разработчики, которые используют библиотеку в своих проектах с огромной вероятностью не полезут в исходники библиотеки.
• Так же это ключевое слово относительно TypeScript не влияет на рантайм т.к. при компиляции просто напросто вырезается. Соответственно как бы вы не именовали переменную она будет доступна окружению в рантайме. Следовательно ни чего не мешает использовать "приватную" по "соглашению" переменную игнорируя "соглашение", что в свою очередь довольно часто встречается в ES сообществе/экосистеме.
• Пример такого использования: изменение поведения кода от наличия переменной или случай использования приватного метода, когда публичный метод и приватный метод выполняют на первый взгляд одно и тоже (однако публичный может так же иметь сайд эффекты).

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

• Если бы мы вводили именно зарезервированное ключевое слово private для Hard Private, в реализациях движков пришлось бы любое обращение к любой переменной проверять на тип т.е. является ли данная переменная в данном объекте приватной или же публичной.
• Как движки должны воспринимать случай, когда в родительском классе переменная является приватной, а в производном публичной — как воспринимать эту переменную при её использовании в каком скоупе и т.д.
• Так же не забываем, что наименование переменной может быть откровенно говоря любого примитивного типа.
• Опять таки относительно Hard Private (полного сокрытия) любая переменная объекта может быть получена подбором через синтаксис object[key], что в случае Hard Private не допустимо.

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

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

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

И так какой это должен быть символ-префикс, чтобы при этом не нарушить работу имеющегося кода и не забываем нам нужно избежать доступа через object[key]? (в object.field часть после точки заведомо интерпретируется движками как примитив string и эквивалентно object["field"])

И вот тут появляется символ #, который по стандарту dot notation является не верным и считается ошибкой (invalid) т.е. движки не будут считать часть после точки строкой это обеспечение обратной совместимости со стороны комитета. Таким образом object.#field это не object['#field'] и не object['field'] и не object[#field] т.к. #field не примитив. В реализации движков в данном случае заменяется выброс ошибки на обработку специфичного синтаксиса без проверок примитивного типа ключа (наименования переменной) т.к. это не требуется.

Разработчики библиотек могут получить пользу от Hard Private т.к. в случае если они решат изменить внутреннюю реализацию класса, изменив/заменив/убрав переменные внутренней реализации при этом оставив не изменной публичную часть (API), это будит действительно патч или минорное изменение.

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

И всё из-за нарочного публичного использования заведомо не рассчитанных на это переменных.

Таким образом object.#field это во первых полностью скрытая в рантайме приватная переменная + соглашение по именованию, что позволяет судить о природе переменной в любой точке кода, где это используется, а так же должно восприниматься как совершенно отдельная/скрытая область.

К слову в том же TypeScript при компиляции приватных полей могли бы их помещать в WeakMap по принципу того, как babel компилирует синтаксис #field тем самым делая их на самом деле приватными. Однако в данном случае вызвалась бы коллизия с определением видимости переменной (что использовать и в каком месте — прямое обращение к object.field или к WeakMap).

И ещё замечу, что да # считается синтаксисом common comment в разных языка, НО не в ES (Здесь это именно //) так, что относительно данного языка это не нарушение.

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

Неожиданный порядок инициализации наследованных классов в JavaScript

Все методы попадают в прототип т.е. все методы уже определены ещё до инициализации любого инстанса. А вот поля в инстансе устанавливаются именно в момент инициализации и именно в порядке из глубины (от самого первого предка).

Но мой основной вопрос всё равно не про это — почему инстанс класса предка сразу бы не инициализировать со значениями полей, переопределёнными в классе-потомке?

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

Пример ниже по своей сути ведёт себя совершенно так же как и ваш случай с классом.

function greet() {
  console.log(`Hello, ${name}!`)
}

function constructorA() {
  Object() // В случае с классами на данном месте неявно вызывается конструктор объекта (super()).
  name = 'ninja cat' // Установка условного поля `name` в родительском классе.
  greet()
}

function constructorB() {
  constructorA() // Это место явного вызова super()
  name = 'world' // Установка условного поля `name` в дочернем классе.
}

constructorB()
// Hello, ninja cat!

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

А это упрощенный пример, показывающий, что любая функция/метод использует значение переменной скоупа на момент вызова. Обращаю внимание, что на момент объявления функции greet() в скоупе о переменной name вообще ничего не известно.

function greet() {
  console.log(`Hello, ${name}!`)
}

let name = 'ninja cat'
greet()
// Hello, ninja cat!

name = 'world'
greet()
// Hello, world!

Неожиданный порядок инициализации наследованных классов в JavaScript

Поэтапное создание класса выглядит не совсем так. B.constructor() будет вызван первым.

Совершенно верно, но я указал именно данный порядок, чтобы было яснее, какое значение поля name будет во время вызова метода log(). Если проще я просто обратную цепочку (из вложения) описал.

Правильнее (подробнее) ваш вариант тогда написать так:

class A {
  name = 'A'

  constructor() {
    console.log('A constructor start')
    this.log()
    console.log('A constructor finish')
  }

  log() {
    console.log(this.name)
  }
}

class B extends A {
  name = 'B'

  constructor() {
    console.log('B constructor start')
    super()
    console.log('B constructor finish')
  }
}

new B()

B constructor start
A constructor start
A
A constructor finish
B constructor finish

И я согласен с автором, что это далеко не очевидно, что инициализация name в B происходит после вызова super().

И всё же на это указывает как спецификация ECMAScript, так и рантайм, если вы попробуете любым образом обратиться к любому полю/методу или установить поле наследующего класса до вызова super().

class B extends A {
  constructor() {
    this.name = 'B'
    super()
  }
}

new B()

Uncaught ReferenceError: Must call super constructor in derived class before accessing 'this' or returning from derived constructor
    at new B (<anonymous>:15:5)
    at <anonymous>:20:1

Т.е. следующие три варианта эквивалентны за исключением того, что в первом и втором случаях поле устанавливается по семантике [[define]], а в третьем по семантике [[set]].

// Первый
class B extends A {
  name = 'B'
}

// Второй (эквивалент первого с точностью до принципа установки поля)
class B extends A {
  constructor() {
    super()
    Object.defineProperty(this, 'name', { value: 'B' })
  }
}

// Третий
class B extends A {
  constructor() {
    super()
    this.name = 'B'
  }
}

К тому же, если переписать код и вместо переменной name использовать метод getName тогда работает так, как автор и ожидал:

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

К слову в моем описании поэтапной инициализации инстанса метод log() появился уже на этапе присвоения значения полю name.

Т.е. поля и методы класса при объявлении ведут себя как function, var, let, const в любой области видимости.

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

И ответ на ваш комментарий в соседней ветке: https://github.com/tc39/proposal-class-fields.

Опять таки я указал способы достижения ожидаемого результата, используя микротаск — всё, что нам нужно это вызвать условную функцию log() в следующем такте исполнения.

Неожиданный порядок инициализации наследованных классов в JavaScript

На самом деле поведение очень даже логичное и понятное. Разберу пример:

class A {
  name = 'A'

  constructor() {
    this.log()
  }

  log() {
    console.log(this.name)
  }
}

class B extends A {
  name = 'B'
}

new B
// A

Почему так происходит?
Всё на самом деле очень просто — в классе A не указан конструктор, соответственно используется конструктор "по умолчанию" т.е. класс выглядит так:

class B extends A {
  name = 'B'

  constructor() {
    super()
  }
}

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

Соответственно поле name указанное в классе B будет установлено только после выполнения конструктора класса A.

Поэтапное создание инстанса класса B будет выглядить так:

1. Object.constructor()  -> Object {}
2. A.name = 'A'          -> A { name: 'A', log() {...} }
3. A.constructor()       -> A { name: 'A', log() {...} }
4. A.log()               -> A { name: 'A', log() {...} }
5. B.name = 'B'          -> B { name: 'B', log() {...} }
6. B.constructor()       -> B { name: 'B', log() {...} }

Т.е. на момент вызова метода log() инстанс класса B содержит в поле name значение A, .

Как добиться ожидаемого в данном примере поведения?

• Есть к примеру способ, который указал vvadzim, но он требует переноса инициализации в отдельный метод.
• Но есть и более простой способ, не требующий переноса инициализации в отдельный метод.

Что это за способ? Ответ: Вызов метода log() в микротаске, но как? Есть опять таки два равносильных варианта:

// 1 вариант -  Микротаск через Promise
class A {
  name = 'A'

  constructor() {
    Promise.resolve().then(() => this.log())
  }

  log() {
    console.log(this.name)
  }
}

// 2 вариант -  Микротаск по запросу
class A {
  name = 'A'

  constructor() {
    queueMicrotask(() => this.log())
  }

  log() {
    console.log(this.name)
  }
}

Команда Polymer Project в проекте lit-element по сути так же использует микротаски (через метод _enqueueUpdate).

Как Сбербанк собирает согласие на обработку биометрии

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

Сбербанк ни как не афилирован с Ростелекомом в плане биометрии, более того Сбербанк изначально делает свою отдельную систему, конкурентную Ростелекомовской.

И нет Оператор БС не только Ростелекомом.

Почему ['1', '7', '11'].map(parseInt) возвращает [1, NaN, 3] в Javascript?

Из-за «babel» это уже не про ECMAScript5. В ES5 по спецификации нет стрелочных функций. А кейс «старая нода и babel» это уже синтаксис ES6+ с трансляцией в синтаксис ES5 посредством babel.

Законопроект об устойчивой работе Рунета принят в первом чтении

Ну такие сети уже давно имеются

Как мы сделали оплату через Google Pay в Яндекс.Кассе [обновлено]

И смысл тогда в Марткеплейсе?

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

Как мы сделали оплату через Google Pay в Яндекс.Кассе [обновлено]

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

хотя бы галочка

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

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

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

и без которой его точно так же обслужат

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

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

передавать его в рекламные сети

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

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

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

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

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

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

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

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

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

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

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

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

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

И любые из этих целей могут быть указаны в Соглашении на обработку ПД как в онлайне, так и в оффлайне и будут законны.

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

Нет. Если вы говорите «либо вы разрешаете продавать ваши данные, либо не ездите на нашем такси»

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

Более того об этом и говорит закон, обязывающий предоставление услуг юр. лицами только по оферте и только после согласия клиента с условиями оферты — «либо вы согласны со всеми условиями предоставления услуги (в том числе как вы постоянно акцентируете „продавать ваши данные“, если это указано в условиях), либо не получаете услугу».

Пользователь хотел Ютубом воспользоваться

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

Именно в оферте указаны эти «подводные камни», на которые пользователь может наткнуться, если руководствуется исключительно ожиданиями и тем как должен работать сервис по его личному мнению и восприятию.

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

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

Вот вам пример условий Apple в Германии (т.е. непосредственно на территории ЕС и по законам ЕС):

Оригинал:
Diese Nutzungsbedingungen (die «Nutzungsbedingungen») gelten für die Apple Website unter www.apple.com und alle zugehörigen Websites, die von Apple mit www.apple.com verlinkt sind, sowie Unter- und Partnerseiten, einschließlich aller Apple Websites weltweit (gemeinsam «die Website»). Die Website ist Eigentum von Apple Inc. («Apple») und seinen Lizenzgebern. INDEM SIE DIE WEBSITE VERWENDEN, ERKLÄREN SIE IHR EINVERSTÄNDNIS MIT DIESEN NUTZUNGSBEDINGUNGEN. VERWENDEN SIE DIE WEBSITE NICHT, WENN SIE MIT DIESEN BEDINGUNGEN NICHT EINVERSTANDEN SIND.

Перевод:
Настоящие условия использования («Условия использования») распространяются на веб-сайт Apple по адресу www.apple.com и на все связанные с ним сайты, а также на партнерские сайты, включая все веб-сайты Apple во всем мире (в совокупности «веб-сайт»). Сайт является собственностью Apple Inc. («Apple») и его лицензиаров. ИСПОЛЬЗУЯ САЙТ ВЫ СОГЛАШАЕТЕСЬ СОБЛЮДАТЬ ЭТИ УСЛОВИЯ ИСПОЛЬЗОВАНИЯ. НЕ ИСПОЛЬЗУЙТЕ САЙТ, ЕСЛИ ВЫ НЕ СОГЛАСНЫ С ЭТИМИ УСЛОВИЯМИ.

Это те же пункты об отказе в обслуживании в случае несогласия. Почитайте полностью условия на сайте, многое узнаете. По поводу такси, так же почитайте условия того же Uber. Ещё можете глянуть условия Spotify.

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

скорее всего сопоставляются с введенными им при регистрации в Яндексе данными

Опять таки ваша догадка, но это не значит, что она верна. Лучше вместо догадок почитайте условия предоставления Яндекс.Аудиторий, там всё будет сказано и указано т.к. фактически оферта Яндекс.Аудиторий является договором между компаниями условно Магазином, который воспользовался услугами Яндекс.Аудиторий и Яндексом.

Я не знаю, как там это выглядит с юридической стороны, но с человеческой стороны это некрасиво.

Всё регулируется законами, а не предположениями/ощущениями/эмоциями. И если с юридической стороны всё в порядке, то значит всё в порядке.

Как мы сделали оплату через Google Pay в Яндекс.Кассе [обновлено]

Вот вам пример Маркетплейсов: Apple Store и Google Play, в одном из них Администрация полностью мониторит качество продуктов и продавцов, что не исключает косяков проверенных продавцов. В другом же случае в том числе и ввиду ограниченных ресурсных возможностей не полностью мониторят всё, что представлено на платформе и частично обязанности перекладывают на продавцов. Соответственно в первом случае полностью проверенный Маркетплейсом, но так же не избавленный от возможных проблем список продуктов и продавцов, но этот список сильно ограничен. В другом же список товаров/продавцов более обширный, но менее проверенный.

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

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

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

И ровно так же всё работает относительно прочих площадок, размещения Продавцов.

Как мы сделали оплату через Google Pay в Яндекс.Кассе [обновлено]

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

Давайте я упрощу пример. Вы проголодались, идете в магазин купить хлеба. А вам на кассе говорят: по условиям Соглашения вы должны надеть вот этот ошейник с GPS-датчиком и микрофоном. Это нужно для защиты от ботов и мошенничества (вдруг у вас карточка краденная). Ну и для таргетинга рекламы по вашим интересам. Не нравится — сидите голодным или идите в любой другой магазин (там то же самое).

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

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

Хорошая история, зато все электронные договора подписываются в едином доверенном центре.

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

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

Что касается ПД. Закон, если не путаю, предусматривает добровольное согласие на использование данных в каких-то целях, отличных от нужных для выполнения услуги. Если вы **требуете** дать согласие, иначе отказываетесь предоставлять услугу — это не добровольное согласие. Это навязывание.

Это добровольное согласие т.к. вы даёте добровольное согласие с условиями оферты и разрешение на обработку ПД является часть этой оферты.

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

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

А именно Юр. Лицо не имеет право предоставлять услуги без оферты и если пользователь не согласен с условиями оферты Юр. Лицо так же не имеет права предоставлять услуги, а имеет право только если пользователь дал согласие с условиям.

Вот и получается если вы Пользователь не дали своё согласие с офертой, то Юр. Лицо не имеет право предоставить вам услуги, а если Юр. Лицо не имеет право предоставить вам услуги, то Пользователь не имеет право воспользоваться услугами (даже если такая возможность имеется) т.к. закон запретил Юр. Лицу в таком случае оказывать услуги.

Навязывание вы взяли из закона о правах потребителя, однако он действует только в том случае, если вы платите за предоставление услуги. А понять когда вы платите за предоставление услуги вы можете прочитав оферту, в которой будет явно указано что-то вроде «предоставить услугу за денежное вознаграждение».

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

Зато он может быть неизвестен Гуглу. Или Гуглу может быть неизвестно то, что я разорвал договор с оператором или сменил номер — а благодаря обмену данными он об этом узнает.

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

Как мы сделали оплату через Google Pay в Яндекс.Кассе [обновлено]

IP адреса бывают индивидуальные, выделенные конкретному пользователю.

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

Если затрагивать обычных пользователей, с обычными провайдерами, которые явно не выдают именные IP адреса — однозначно IP адрес не ПД.

То, что в квартире за одним IP может быть несколько человек — это не аргумент. Адрес с номером квартиры ведь тоже не указывает на одного человека, но РКН или европейские органы вам его публиковать не позволят.

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

Даже было судебное решение, где суд явно укал, что должно быть несколько факторов и чтобы они вместе указывали на вас.

Так например номер паспорта явно указывает на вас т.к. он уникальный, принадлежит только вам и указывает на однозначную связку ПД вида ФИО и адрес прописки/регистрации и дата прописки/регистрации. Номер телефона так же указывает на ПД вида номер паспорта. А вот только адрес не является ПД т.к. вас в квартире может проживать хоть 33 человека. Email принято считать такими же ПД т.к. обычно указывает на номер телефона или любые другие ПД, однако так же как и с IP не каждый email будет признан ПД.

Я пользуюсь интернетом и сотовой связью — за деньги.

Услуги интернета и сотовой связи предоставляют совершенно другие компании и вы платите именно этим совершенно другим компаниям.

Я пользуюсь интернетом и сотовой связью — за деньги. Я покупаю что-то в ИМ — за деньги. Я покупаю смартфон с Андроид или с Яндекс-оболочкой — за деньги. Я пользуюсь Яндекс-кошельком — за деньги. Если я еду на такси, то тоже за деньги.

Только всё это совершенно разные компании, предоставляющие разные услуги.

Да даже если бесплатно (по факту — за просмотр рекламы).

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

пользователя, который поленится

Вот именно, что поленился

Первый раз слышу про бесплатное такси.

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

А кто разрешил рекламной сети отслеживать мои перемещения по разным сайтам? Я такого разрешения не давал. Сайт от меня потребовать под угрозой отказа в обслуживании его не может (это не будет добровольным согласием, а навязыванием услуг).

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

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

Это какое-то программистское мышление: я в приложении могу получить IP, местоположение, IMEI, значит я могу их сохранять и связывать с другими данными.

Интересный вы человек, эти данные не указывают однозначно на вас и не содержат ничего такого. Эти данные нужны не для того, чтобы сказать что вы были в том то месте с таким то IP и под таким то IMEI, а чтобы улучшить оказываемые услуги, например точнее определить ваше местоположение, чтобы автомобиль, который вы заказали подъехал именно к вам в пределах 2-3х метров, а не в другой квартал.

Простая аналогия:

1) пользователь установил карты на телефон, чтобы узнать, как куда-то проехать
2) пользователь пригласил сантехника для починки трубы

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

Эта же аналогия только в более верном ключе:

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

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

Смотря кому, силовым структурам например даёт право закон, особенно в случае если вы попали в розыск.

И для продажи рекламодателям для более точного таргетинга рекламы, да?

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

Как мы сделали оплату через Google Pay в Яндекс.Кассе [обновлено]

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

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

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

равно как и для судебных споров.

По этому он может встать на вашу сторону в вашем суде с конкретным Продавцом, но не обязан.

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

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

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

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

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

Как мы сделали оплату через Google Pay в Яндекс.Кассе [обновлено]

На странице упомянута возможность хешировать только в md5.

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

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

Во первых теперь спасибо законодательству, все ПД граждан РФ обязаны храниться на территории РФ в программных комплексах, прошедших сертификацию ФСТЕК и ФСБ. Так что о сертификации я очень даже поспорю.

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

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

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

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

Так взять этот же пример, в акцептах явно указано «прохождение процедуры регистрации» т.е. если вы завершаете процедуру регистрации, что равно отправке формы, а отправить вы форму не сможете без установки галочки (этапа процедуры регистрации), то вы явно согласно оферте дали своё согласие.

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

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

А вот это уже действительно то самое предложение о котором идёт речь в законе:

1.1. ООО «ЯНДЕКС» (далее — «Яндекс») предлагает пользователю сети Интернет (далее – Пользователь) — использовать свои сервисы на условиях, изложенных в настоящем Пользовательском соглашении (далее — «Соглашение», «ПС»). Соглашение вступает в силу с момента выражения Пользователем согласия с его условиями в порядке, предусмотренном п. 1.4 Соглашения.

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

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

Нет не можете т.к. это не является офертой и ни как не подпадает под закон урегулирующий эти самые оферты. А вот под закон о рекламе это ещё как подпадает.

Наконец, смотрите, какую я интересную штуку нашел в законе о защите прав потребителей:

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

Этот закон не действует на ваши отношения с Яндексом т.к. Яндекс предоставляет вам услуги на Бесплатно основании, если вы пользуетесь платными услугами Яндекса, то закон имеет силу только в отношении этих самых платных услуг и не затрагивает остальные, предоставляемые Бесплатно.

> Запрещается обусловливать приобретение одних товаров (работ, услуг) обязательным приобретением иных товаров (работ, услуг).

Вы даже не обратили внимание на указание приобретение т.е. денежные отношения.

Смешно. Давайте не будем переводить разговор на политику, а про развитое самоуправление вы можете почитать в Яндексе, набрав в поиске «мунфильтр». Там же можете почитать про простоту регистрации политических партий.

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

Только это вы постоянно переводите разговор из одной темы в другую. И это вы начали про становление депутатом.

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

Ну знаете, наличие таргетинга указывается в соглашении и если вы используете услугу, то вы согласны с офертой иначе как я сказал пользуйтесь услугами. Лично вас никто не заставляет пользоваться почтой ООО Сетевая связь

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

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

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

Все остальное без явного, добровольного согласия пользователя

Для суда, согласно тем пунктам в оферте, которые я уже приводил и в оферте портала правительства Москвы, явным согласием будет считаться факт использования функционала сайта. (Напомню посещение ещё не является фактом использования сервиса или части его функционала, однако если вы воспользуетесь функционалом, например в поле поиска начнёте что-то вводить, то вы воспользуетесь часть функционала — поисковая подсказка)

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

За вами следят в оффлайне, но вам на это всё-равно, а вот когда следят в онлайне вы сразу в рядах диванных войск поднимаете бучу. Не вся «слежка» ставит перед собой именно слежку за конкретным человеком и так же любая слежка может поставить такую цель, пример: камеры в тц, транспорте, частных и закрытых территориях, просто общественных местах, а ещё факты перевода денежных средств (для налоговой), учёт имущества, система городского видео наблюдения. Это всё тоже можно назвать слежкой если очень сильно впадать в паранойю.

Как мы сделали оплату через Google Pay в Яндекс.Кассе [обновлено]

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

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

Хотя вы не просили об этом и можете даже не знать о таких возможностях.

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

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

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

То есть я в интернет-магазины хожу ради попадания в систему таргетинга, а не чтобы что-то купить? Вот так новость. А почему ИМ не рекламируют такую услугу? Только в нашем магазине — добавление в 20 рекламных систем и ведущие базы директ-маркетинга (в простонародье, спама)!

Таргетинг ни что иное как рекомендации чего-либо (рекламного объявления/услуги/товара) основываясь на интересах т.е. специально для вас подбирают именно то, что вас может заинтересовать, а не рандомные предложения.

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

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

И с какой стати Яндекс имеет право знать, какой фитнесс-центр я посещаю?

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

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

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

— аккаунты в Гугле или Яндексы, в которых логинится пользователь
— неизменяемые идентификаторы вроде IMEI или MAC-адреса

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

Наличие аккаунтов говорит о соглашении с офертами данных компаний, где рекламные цели указаны.

IMEI и MAC-адреса получают только если вы используете приложение на устройстве (а на приложение так же действует оферта, акцептом которой является факт установки приложения из маркетплейса приложений).

Следовательно вы уже на это дали право.

Вот, например, посмотрите, что пишет Гугл при регистрации Гугл-аккаунта: imgur.com/a/cjIEgtf

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

То есть Гугл собирает какие-то данные об устройстве (номер или IMEI) и за спиной свободно обменивается ими с сотовым оператором, причем без моего согласия.

А вы знали, что ваш IMEI итак известен сотовому оператору т.к. телефон представляется вышкам этим IMEI.

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

А нужны все эти пункты для привязки устройства в аккаунте Google.

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

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

А главное вы не хотите обвинять Гугл, но пытаетесь в этом обвинить Яндекс.

Серьёзно, перестаньте, законодательно всё честно. Вы сами натыкаетесь на факт о согласии с офертой (факт наличия аккаунта к примеру) и при этом игнорируете этот факт.

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

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

Как мы сделали оплату через Google Pay в Яндекс.Кассе [обновлено]

А не надо приводить маразматичные законы РФ как основание для того, что оборот ПД не должен регулироваться.

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

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

Действующий закон о ПД именно это и ругулирует и именно на это и указывает (цели оказания услуг).

Остальные указанные вами вещи работают не на ПД.

Что касается маркетплейсов или сервисов-агрегаторов такси — конечно, отвечать за косяки партнеров должны они. Пользователь не должен бегать и искать, какое именно ООО Вектор с капиталом в 10000 р продало некачественный товар или отвезло его не в тот район города. Это не с юридической, а с человеческой точки зрения.

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

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

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

Как удобно. Я открыл магазин, но это не я продаю некачественные арбузы, а мой партнер из солнечной южной страны, удачи вам в его поисках, уважаемый Потребнадзор. Хотя здание, прилавки и кассы — мои.

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

Как мы сделали оплату через Google Pay в Яндекс.Кассе [обновлено]

Я могу ошибаться, но здесь Яндекс предлагает настроить таргетинг рекламы по списку email и телефонов («Сегмент на основе загружаемых данных»).

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

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

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

То есть пользователь купил что-то в компании X или записался в фитнесс-зал компании Y, и эти компании в сговоре с Яндексом вместе следят за действиями конкретного пользователя в Интернете.

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

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

Вы уверены? Есть различные методы хеширования помимо md5, sha1.

По поводу подбора в кластере Яндекса, теперь я точно уверен, что у вас паранойя и что вы считаете, что вы такой особенный, что ваши ПД прям так сильно нужны компаниям и им прям так сильно хочется что-то впарить именно вам, что компаниям не жалко любых вычислительных процессов/денежной волокиты и миллионов только ради вас.

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

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

И если вы удалите этот cookie на домене DMP, то при следующем посещении страницы с ресурсом на домене DMP вам выдадут новый cookie и будут заново собирать информацию и строить приблизительные догадки о ваших интересах не более.

Или становитесь депутатом и улучшайте законодательство для регулирования оборота ПД.

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

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

Как мы сделали оплату через Google Pay в Яндекс.Кассе [обновлено]

Я и не должен ее искать. В Законе написано:

> Офертой признается адресованное одному или нескольким конкретным лицам предложение

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

То, что вы не удосужились посмотреть в конце страницы и среди ссылок найти явно ссылку с текстом «Пользовательское соглашение» или «Юридическая информация» не означает, что на странице с формой оферта нигде не представлена или не указана.

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

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

Таким образом, в моем неюридическом понимании, требования ГК к оферте вы не выполнили.

Ключевое, то, что именно в вашем не юридическом понимании, однако именно в юридическом понимании всё выполнено.

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

Ну раз пользователь не обязан принимать оферту, чтобы пользоваться сервисом, то он и не обязан пользоваться именно этим сервисом.

Нет, не подтверждаю. Я вижу адресованное мне предложение оплатить покупку картой с простыми понятными условиями: я ввожу данные карты и получаю товар. С этим я согласен. С написанным где-то на задворках интернета договором, который я должен искать — я не соглашался. Передавать свои ПД для чего-то, кроме осуществления продажи товара, я также не соглашаюсь.

Раз не поддерживаете, не пользуйтесь. А по поводу адресованного вам предложения, раз вы так прицепились к серым буква, то вот вам вопрос, это где текстом написано было предложение оплатить покупку картой с расписанием условий ровно так же как и в офертах? Вы и так не передаёте никакие ПД кроме как для осуществления оплаты.

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

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

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

Т.е. вы хотите, чтобы от вас требовали регистрации абсолютно на каждом сайте, с указанием ПД (как минимум номера телефона). Чтобы факт регистрации представлял из себя вашу личную подпись. И это даже ради одной страницы просто с текстом, а не с услугами. Вы действительно согласитесь на это? Вам и так предоставляют большинство сервисов Бесплатно, согласно закону они опубликовали оферту со своими условиями, всегда находящуюся по одному и тому же адресу. И эта оферта согласно законодательству действительна (те пункты про использование 100% действительные и подтверждённые судебной практикой). Вы лезете в крайности, осторожнее ведь рано или поздно загоните себя в них и вернуться уже не сможете.

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

Нет не значит, а по поводу юридической волокиты я так понимаю, что вы считаете, что составление оферты юр. лица происходит без юридической волокиты, проверок юридической значимости и применимости пунктов?

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

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

Что касается обязаны вам платить 100 рублей, вопрос за какие услуги? Т.е. в оферте вы должны явно указать перечень услуг и как у юр. лица у вас должно быть разрешение на предоставление услуг данных категорий, если они требуются законодательно. А ещё в таком случае вам необходимо будет соблюсти права потребителей, т.к. раз речь пошла о денежных отношениях, то и законодательство регулирующее денежные отношения начинает действовать на вас. И вот теперь ваш готовый иск может обернуться против вас.

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

1) явно прописать, что договоры вроде EULA могут приниматься только добровольно, и использование сайта или программы не считается принятием

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

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

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

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

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

3) нельзя было отказывать в обслуживании пользователям, отказавшимся предоставлять ПД для целей таргетинга рекламы

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

В общем, нам бы не помешал аналог GDPR для защиты от интернет-трестов и торговцев ПД.

И вот вам тоже по «секрету» GDPR никак не влияет на таргетинг. А торговцы ПД найдутся и в оффлайне, например сотрудники вашего интернет-провайдера (а по мимо провайдера может быть и сотрудник мфц и больницы, да вообще чего угодно хоть паспортный стол), которых увольняют со дня на день, они чувствуют несправедливость и решают выгрузить базу клиентов, чтобы потом её где-нибудь толкнуть. Только вот этими случаями и их предотвращением занимаются службы безопасности компаний, что впрочем не может гарантировать 100% невозможность этих ситуаций.