• Почему App Store против разработчиков и при чем тут суд Epic Games с Apple
    +2

    Хорошая "забота" о разработчиках и о пользователях, но с намеренным умалчиванием множества фактов.


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


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


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


    И вот тут привет всем судебным делам в отношении Google по факту продвижения собственных сервисов на первых позициях и аналогичным прецедентам в отношении Яндекса. Чем данная политика Apple отличается от политик Google и Яндекса? Ответ ни чем.


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


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


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


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


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


    Другой бы разговор был, если всё-таки по мимо App Store имелись другие магазины, пусть даже доступные только через App Store. В таком варианте Apple может до определённого времени сохранять приоритетную роль дистрибутора софта на iOS, организуя достаточную безопасность с защитой от "дурака" пользователей, хотя бы предупреждая при установке других магазинов о возможных последствиях и дополнительных отказах от ответственности и гарантиях со стороны Apple (формат не согласился — не установил).


    В отношении конкурентной платформы Android были дела и по серьёзней, так почему практики и прецеденты с их конкурентом должны обойти Apple стороной?


    Сразу про другие аргументы типа "Apple вложилась в платформу iOS", "А почему они кому-то что-то должны" и "Apple продвигала платформу" — мало создать платформу, надо её наполнить. И вот тут, если бы не сторонние разработчики, которые пока делают под их платформу софт, не было бы ни macOS, ни iOS как бы их не продвигала Apple — они бы просто не набрали пользовательскую базу ввиду малого функционала.


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


    В общем всё очень многогранно и не так очевидно.

  • Четверть выходных нод TOR под контролем злоумышленников
    0
    Осталось чуть-чуть. Объяснить это всё массам пользователей и убедить их строго следовать этому подходу.

    Нет, ну если хочется ещё проще, поскорее и без объяснений всем массам, можно принудительно зашить в браузерах https-only или https с фолбеком на http.


    А вообще эта проблема должна будет решиться с внедрением выше упомянутого HTTPSSVC DNS resource record. Если у домена есть данная запись, браузер строго следует правилам в ней и использует https соединения. Если такой записи нет, работает точно так же как сейчас (http-first).

  • Четверть выходных нод TOR под контролем злоумышленников
    +2
    Вы, наверное, не в курсе, но без HSTS preloaded list запрос сначала пойдет на 80-ый порт.

    Если не указывать протокол браузер вероятнее всего будет использовать http и тогда да в начале пойдёт на 80-ый порт. А если ручками указать протокол https, будет использоваться только 443 порт (если вы и порт ручками не указали). Причём это весьма не сложно (всего дополнительно 8 символов и то если вспомнить, что слеши не обязательны — 6 символов, https:example.com).


    Но вот это "вероятнее всего" зависит от множества факторов:


    Для начала в "большой тройке" браузеров (Chromium, Firefox, Safari), HSTS preload list поставляется изначально далеко не пустой. Более того этот список с обновлениями браузеров подкачивается/синхронизируется. Кстати производитель вполне может в этот список на этапе поставки браузера добавить дополнительные записи.


    Так же этот список локально обновляется сайтами с HSTS header и не значащимися в HSTS preload list — тут действительно первый заход будет на 80-ый порт, однако последующие уже на 443-ий.


    Стоит отметить, что в выше указанный HSTS preload list жестко вшиты некоторые домены первого уровня (.dev, .app), а значит на сайты в этих gTLD браузеры заходят только на 443-ий порт, игнорируя вообще существование 80-го порта.


    А вообще HSTS header де-факто уже признан устаревшим и ему на смену готовят HTTPSSVC DNS resource record. Это по сути замена сразу двух HTTP заголовков HSTS header и AltSvc header с интеграцией сюда ESNI.


    В данной схеме устраняется та самая уязвимость первого захода с HSTS header. Главная идея в том, что браузер будет ходить на порты, указанные в DNS записи и по протоколам так же указанным в этой записи. Например, на ещё не посещённый сайт сразу на 443 порт так ещё по протоколу Quic или HTTP/3 и с применением ESNI.


    Также рассматривается будущая (через 2-5+ лет) возможность признания протокола http устаревшим с дальнейшим выпиливанием из браузеров, по аналогии с протоколом ftp в этом году.

  • Правообладатели постарались: с YouTube могут исчезнуть музыкальные видеоуроки с разборами чужих композиций
    0

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


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


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

  • Что Microsoft представила разработчикам на Build: winget, GUI-программы в WSL2 и прочее
    0

    Это должно будет придти с версией Windows 10 Pro 2004 (Пока Insider Preview), а сейчас доступно как сетевая папка \\wsl$.

  • Почему WSL 2 в 13 раз быстрее, чем WSL: впечатления от Insider Preview
    +2
    Если бы… Не операционОК, а операционКИ. 1 шт.

    Почему же, вот открыл Microsoft Store и что я вижу:



    Раньше ешё были Fedora официальные, но сейчас их нет.


    Остальные/Кастомы:



    А ещё можно и самому создавать из tar с командой wsl:


    --import <Distro> <InstallLocation> <FileName> [Options]
            Импорт указанного TAR-файла в качестве нового дистрибутива.
            В качестве имени стандартного выходного файла можно указать "-".
    
            Параметры:
                --version <Version>
                    Указание версии, которую нужно использовать для нового дистрибутива.
  • Почему WSL 2 в 13 раз быстрее, чем WSL: впечатления от Insider Preview
    0

    Я бы сказал от части криворукость и легаси. Windows 10 это ядро Windows 7 с навешенными брокерами функционала Windows 8 (только того, который решили оставить).

  • Почему WSL 2 в 13 раз быстрее, чем WSL: впечатления от Insider Preview
    +1

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


    В WSL2 это виртуалка, в которую ставится дополнительно связующий софт (именно слой совместимости между Windows и Linux). Стоит ещё отметить что дистрибутивы операционок в Microsoft Store распространяются и поддерживаются разработчиками этих операционок. Так например Ubuntu это облачный образ с настройками для лучшей работы именно в Hyper-V.


    P.S. Я этим уже пользуюсь пол года и мне нравится реализация именно WSL2. Microsoft так же оставили возможность выбора режима WSL1 или WSL2 как по умолчанию для новых дистрибутивов, так и выбор конкретному дистрибутиву. И ещё пока есть проблема в WSL2, на уровне организации виртуальной сети (пока не умеет в IPv6, с января имеется тикет на решение, но появится это решение скорее всего через несколько релизов после Майского).

  • Почему WSL 2 в 13 раз быстрее, чем WSL: впечатления от Insider Preview
    +1
    … и не очень хорошо с собственно Linux'ом.
    Ключевое — «упрощенной» и «Ядро Linux в WSL 2 создано собственными силами на основе».

    Опять таки вы путаете подход использованный при создании WSL1 и WSL2.


    То что вы пишете это именно про WSL1, где действительно кастомное ядро Linux, в котором системные вызовы Linux пробрасываются/транслируются в системные вызовы Windows. Из-за чего в WSL1 получилось много проблем с совместимостью и целый список не работающих фич и софта.


    PS. чисто по-женски интересно — какая религия запрещает эффективным манагерам Microsoft сделать нормальный транслятор вызовов абсолютно открытой OS?

    Но в Microsoft поняли, что так не пойдёт (трансляцией) и решили переделать всё с нуля используя свою технологию виртуализации Hyper-V (поддерживает аппаратную виртуализацию на базе Intel VT либо AMD SVM). Т.е. WSL2 это уже полноценный образ Linux. Назвали всё это WSL2.


    Чисто технически у WSL1 и WSL2 задача одна, а реализация разная. Новая реализация очевидно сильно лучше. Складывается вопрос почему раньше так не сделали, а пошли более жёстким, больным путём.


    Чисто теоретически если бы это был не Microsoft вместо Hyper-V мог бы быть и KVM и XEN.

  • Почему WSL 2 в 13 раз быстрее, чем WSL: впечатления от Insider Preview
    +1
    WSL2 — это не виртуалка.
    Это слой совместимости.

    Это вы путаете как раз с WSL1, который по сути и был слоем совместимости (подмена системных вызовов Linux системными вызовами Windows).


    А вот WSL2 это именно виртуалка в Hyper-V. С рядом настроек для проброса и шаринга.

  • Хабр, я не буду сообщать тебе об ошибках на твоем сайте
    0

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


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


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

    Третье несмотря на схожесть идеи и ряда пунктов GDPR и 152-ФЗ, ещё не значит, что пояснения и практики по данным законам будут одинаковыми.


    Даже если учитывать пункты GDPR, то GDPR 4.1. вполне считают электронный адрес персональными данными.


    В пояснении к данному пункту, есть важный момент:


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

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


    В итоге, форма обратной связи вполне регулируется GDPR и скорее является случаем единоразового/одноразового (здесь и сейчас, только на данные, указанные в форме) соглашения на предоставление ПД.


    Да в случае не согласия с обработкой данных вы не можете отправить своё обращение (что казалось бы противоречит GDPR 7.4.), однако у вас есть возможность/право добровольно указывать или не указывать какие либо дополнительные ПД (что вполне соответствует GDPR 7.4.), кроме адреса электронной почты (который вполне удовлетворяет GDPR 4.1. и GDPR 6.1.f.).


    Ключевое, что GDPR 7.4. не столько про возможность добровольно согласиться/отказаться, сколько про возможность добровольно выбрать какие данные, каким образом обрабатывать, а так же возможности отзыва соглашения.

  • Хабр, я не буду сообщать тебе об ошибках на твоем сайте
    0

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


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


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


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


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


    Или же как защита от дурака, когда вы сами предоставили свои ПД, там где это не требовалось.


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


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


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


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

  • Хабр, я не буду сообщать тебе об ошибках на твоем сайте
    0

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

  • Хабр, я не буду сообщать тебе об ошибках на твоем сайте
    0

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


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

  • Хабр, я не буду сообщать тебе об ошибках на твоем сайте
    0

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


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

  • Хабр, я не буду сообщать тебе об ошибках на твоем сайте
    0

    И всё таки я напишу про


    удаление, уничтожение персональных данных

    Это возможно только в случае


    накопление, хранение

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


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

  • Хабр, я не буду сообщать тебе об ошибках на твоем сайте
    0

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

  • Хабр, я не буду сообщать тебе об ошибках на твоем сайте
    +2

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


    Ну и честности ради:


    Я не сказал, что вы — тролль.

    Вы же пишите выше комментарием:


    Я не хочу кормить тролля.

    Вы всё же назвали своего собеседника троллем и пытаетесь красиво съехать.

  • Хабр, я не буду сообщать тебе об ошибках на твоем сайте
    0

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

  • Хабр, я не буду сообщать тебе об ошибках на твоем сайте
    0

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

  • Хабр, я не буду сообщать тебе об ошибках на твоем сайте
    0

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

  • Хабр, я не буду сообщать тебе об ошибках на твоем сайте
    +3

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

  • Хабр, я не буду сообщать тебе об ошибках на твоем сайте
    0

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

  • Хабр, я не буду сообщать тебе об ошибках на твоем сайте
    +1

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


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

  • Хабр, я не буду сообщать тебе об ошибках на твоем сайте
    0

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

  • Хабр, я не буду сообщать тебе об ошибках на твоем сайте
    +1
    Вы серьезно?
    Это было бы так, если бы любой, кому вы скармливаете свой емейл, мог бы запросить остальные данные у почтового провайдера. А это не так. Значит считается, что у вас только почта, более ничего нет.

    Серьёзно, например вдруг оператор службы поддержки узнаёт у вас, как к вам обращаться. Про запрос данных у почтового провайдера тоже вполне работает, когда вы отправляете письмо, например в ответ. По мимо адреса почты в поле "От кого" могут прилететь ваши ФИО, а так же с письмом и аватар вашего ящика, более так и происходит в обычном случае.


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


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


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

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

  • Хабр, я не буду сообщать тебе об ошибках на твоем сайте
    +1

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


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


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


    Естественно будут и исключения, когда номер телефона зарегистрирован на левого человека или использованы сервисы "анонимной" электронной почты. Однако и связка указанная Жаровым как достаточная для идентификации (Фото + ФИО + Номер телефона) фактически не более чем просто Номер телефона и подвержена тем же проблемам.


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


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


    Т.е. это как ответ на ваш посыл поста:


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

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


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


    Ну и лучше обратите на ответ сотрудника Хабра. Главная причина этого всего — повышение контроля телекоммуникаций со стороны государства. Просто банальная бюррократия.

  • Contact Picker API, или как поделиться своими контактами с браузером
    +2

    Этот API даже не учитывается в списке прав (соответственно ни как не относится к воркфлоу запроса прав). Как выше указали данный API использует по сути внешний интерфейс (на уровне браузера).


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


    К слову это не единственный API с подобной реализацией (единоразовый доступ):


    • Contact Picker API (доступ к контактам — пользователь сам выбирает каким)
    • File API (доступ к содержимому файлов — пользователь сам выбирает каким, одно из первых API с подобным воркфлоу)
    • Native File System API (доступ на изменение файлов/директорий — пользователь сам выбирает каких)
    • Web Authentication API (доступ к ключу — опять таки пользователь выбирает к какому)
    • Payment Request API (доступ к платёжной информации в т.ч. Google/Apple/Samsung/etc. Pay — аналогично)
    • Web Share API (вызов/доступ к внешним приложениям — снова пользователь выбирает)

    В этот же список можем добавить ещё:


    • Install Banner API (запрос на добавление PWA, отличается от выше перечисленных автоматическим вызовом)
    • User Activation API (как пример влияет на воспроизведение аудио/видео на мобильных — только после взаимодействия пользователя со страницей)

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


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


    Есть ещё API с альтернативной выдачей разрешения:


    • SMS Receiver API (доступ к содержимому следующего входящего SMS — вызов = запросу, разрешение = содержимое SMS содержит ссылку на страницу, запрет не предусмотрен = бесконечный Promise пока не придёт SMS подходящее под критерий разрешения. Я видел вариант с дополнительным запросом разрешения по типу как у Install Banner API)

    По поводу User Activation API к сожалению пока это API только Chromium-based браузеров и доступен как navigator.userActivation, однако технически в других реализациях (только internal use only) имеется в Safari и Firefox для тех же изначально нужд по авто воспроизведению медиа контента.

  • Contact Picker API, или как поделиться своими контактами с браузером
    0
    С флагами фичу на живых пользователях сложно проверить, обычные пользователи ни в какие флаги не полезут.

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


    Для примера YouTube ещё в процессе перехода на Custom Elements v1 и как минимум с середины 2019 года у них на страницах имеется Origin Trials токен на Custom Elements v0, которые в свою очередь в флагах по умолчанию выключены.


    Но зачем они добавляют свои "идеи" в стандартный объект navigator – непонятно.

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


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

  • Yarn 2 — с Prolog'ом и плагнплеями
    0

    С unpkg.org всё вполне в порядке, хотя и не всегда ES Modules работают как надо. Я просто вкинул довольно новый проект, у которого слегка иной подход. И если я не ошибаюсь как раз у pika.dev есть поддержка import maps и их генерация. pika.dev пытаются стать именно универсальным регистром пакетов, который будет работать как в браузерах так и на серверах в Deno.

  • Yarn 2 — с Prolog'ом и плагнплеями
    0

    Для веба могу обратить внимание на pika.dev, позиционируют себя как условно браузерный npm (cdn с пакетами из npm), ES Modules-first. У них есть ещё утилита, которая под веб собирает и бандлит по пакетам все зависимости в отдельную папку.

  • Let vs const — что использовать?
    0

    Я немного обобщу, в общем и целом проблемы в выборе let и const нет, минус названный вами в сторону const вами же отображен и на let. Описанный подход prefer-const и вами prefer-let по своей сути идентичны +- (просто инверсия). 99.9% замена const на let ничего не ломает и эти же проценты переиспользование let тоже, однако всегда есть 0.1% когда это приводит к багам.


    Соответственно стреляет не let и не const (шансы у них примерно равны), а непосредственно разработчики, которые либо невнимательны, либо безответственны, а иногда и то и другое.


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

  • Let vs const — что использовать?
    0

    Случайный дубль комента по двойному клику. Хабр стоит переводить кнопку в disabled по первому клику.

  • Let vs const — что использовать?
    0
    Сравните с вариантом, когда у вас одно объявление и — внезапно — нужен let. Вроде же по-русски писал, одно с другим связать не можете?

    Вы лучше сразу пример приведите, как я просил с самого начала. Если у вас одно объявление и внезапно понадобился let, сделайте новое в чём проблема?


    Речь не о можно, а том, что в случае const нельзя иначе. Вы вообще обдумываете свои решения или идёте на поводу толпы?

    Речь именно о можно и нужно. В случае с const можно иначе и это let. Вот серьёзно в каком месте не понятно моё краткое объяснение правила prefer-const? "Если вы не меняете ссылку на значение — const иначе let". Где явно случай с вашим тернарным const лучше реализовать через let и с нормальными if. Это правило обращаю внимание не противоречит тому, что вы "пытаетесь донести" не вникнув в то, что я вам писал изначально. Вот для начала сами по обдумывайте то о чём говорит собеседник.


    В первую очередь вы не обдумываете свои решения и ответы, особенно когда пишите про "идёте на поводу толпы". Какой нафиг толпы? Я опробовал prefer-const подход, он показал свои плюсы, я использую его.


    И уж тем более я не "иду на поводу толпы" т.к. эта самая толпа категорически против приватных полей у классов в JS с текущим синтаксисом #fieldName. Я же в этом синтаксисе вижу плюсы: 1. хард приватность, а не "соглашение о приватности", нарушается постоянно; 2. сразу синтаксис показывает, что это приватное поле и не нужно вносить опять таки "соглашение по именованию приватных полей". Тут всё принёс язык и это хорошо.


    Просто? Разговор с того и начался, что prefer-const не даст вам просто поменять, потому что при деструктуризации останутся незименные переменные.

    Просто и про останутся неизменные переменные, ну и пускай останутся. Чем это мешает вам? Вот серьёзно это такая придирка ну серьёзно с натяжкой. Я просто вынесу из const необходимую/мые переменные в let и всё, если это одна, то можно вообще даже в let не пихать если задуматься.


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

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


    Впрочем, вы даже на русском неаккуратно пишите.

    Ну и как обычно, что в прочем не удивительно по "идёте на поводу у толпы" это попытка съехать на личности. Вероятно вы сами не менее плохо пишите код, с уверенностью в своей правоте.


    P.S. Вдобавок, ниже уже привели ссылки на статьи, почему const не работает. Как верно подмечено, prefer-const заставляет использовать const, когда так совпало, что переменная не изменяется, а не только когда она реально должна быть константой.

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


    Ну и теперь я пишу, что вы идёте на поводу у толпы, которая категорически не приемлет использование const в тех ситуациях, для которых и разрабатывалось это ключевое слово. Даже в proposal на эту фичу были примеры из ряда prefer-const, однако опять таки никто не читает документацию, и следует правилу "в других же языках так, значит и тут так и по другому не может быть".


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

  • Let vs const — что использовать?
    +1

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


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

  • Let vs const — что использовать?
    –1

    Возможно вы немного промахнулись и писали Aingis. Я же совершенно как и вы использую prefer-const.

  • Let vs const — что использовать?
    0
    А теперь сделайте имена реально длины и вложенности (settings.product.someParams) и добавьте ещё пару переменных, и вместо искусственного примера сразу увидите раздутие.

    Хорошо, вот тот же отрывок с "реальной длинной":


    const { width, title } = settings.product.someParams
    let { height, aspect } = settings.product.someParams

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


    А нужен let затем, зачем и в топике написано. Чтобы, например, не делать плохо читаемые вложенные тернарники, а нормально читаемые последовательные if'ы.

    Это уже аргумент с натяжкой т.к. эти же тернарки можно писать и в let и в var. Это уже зависит от разработчика и его желаний сократить код. А вообще это вопрос умения применять тернарки, если правильно оформлять, то и вложенные не будет особых трудностей читать. И да конечно же везде, где можно обойтись без тернарок или сложность условий велика лучше и нужно использовать if.


    Вообще исходный код должен быть читаемым, а то, что пойдёт в продукт уже будет обработано каким-нибудь Terser'ом.


    Что значит «нежелательных»?

    То и значит. Иногда сломать весь код можно и банальным случайным или намеренным изменением значения переменной. К примеру, вот ожидаете объект и выполняете запрос к полю foo.bar, а выше какой-нибудь "Вася" в каком-нибудь if'е на каком-нибудь условии без церемоний записал в ваш let foo значение null. По логике "Васи" всё верно т.к. foo в конечном итоге возвращается из функции.


    Вы либо меняете, либо нет. Не знаете что пишете?

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


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

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


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

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

  • Let vs const — что использовать?
    +1

    Почему?


    const options = {
        width: 100,
        height: 200
    }
    
    const { width } = options
    let { height } = options
    height += width / 16 * 9
    options.height = height

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


    const options = {
        width: 100,
        height: 200
    }
    
    const { width } = options
    let { height } = options
    height += width / 16 * 9
    options = { ...options, height }

    Но не проще ли в подобном случае сразу делать так:


    const options = {
        width: 100,
        height: 200
    }
    
    options.height += options.width / 16 * 9

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


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


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


    Относительно последнего абзаца я кстати пробовал и TypeScript и Flow, а в итоге вернулся к чистому ECMAScript с документацией в комментариях по типу JSDoc/ESDoc. VSCode совершенно спокойно распознаёт эти комментарии и выдаёт всё те же подсказки по типам, что и с TypeScript. И в данной ситуации не требуется компилировать в JS/ES и нет проблем с идеологией как у TypeScript (в частности по приватным полям).

  • Let vs const — что использовать?
    +2

    Сравниваете не сравниваемое, если в const из ECMAScript хранить примитивы (которые по своей природе immutable), так же как вы это делаете в других языках с приведёнными величинами (G, PI, e, etc.), то отличий никаких эти константы полностью иммутабельны т.к. ссылка на них иммутабельна и значения-примитивы тоже иммутабельны.


    Если же вы храните в const объект (мутабельный по умолчанию), то и получаете иммутабельную ссылку на мутабельный объект. Чтобы объект был иммутабельным нужно его залочить Object.freeze() (блокирует конкретный объект).


    const immutableObject = Object.freeze({
        name: 'Alice',
        age: 25,
    })

    Данный пример полностью иммутабельный т.к. мы используем иммутабельную ссылку, на иммутабельный объект с иммутабельными значениями переменных.


    Главное понимать, что var, let, const это всё переменные, которые в сущности являются просто ссылками на значения, соответственно ключевое слово влияет только на область видимости и мутабельность этой самой ссылки, но никак не значения.

  • Let vs const — что использовать?
    +2

    Самое правильное с моей точки зрения это правило prefer-const из eslint. Кратко и просто: Если переменную не перезаписываем, то const. Иначе let. Больше никаких рассуждений не нужно.


    function processItems(id) {
       const items = fetchItems(id);
       for(const item of items) {
            doSomething(item)
       }
    }

    В данном случае обе переменные const т.к. мы их не меняем (изменение атрибута переменной item не относится к изменению переменной).


    Если мы меняем хранимое значение, то let:


    let counter = 0
    counter++
    
    const object = {
        name: 'Bob'
    }
    object.name = 'Alice'