• Забудьте про div, семантика спасёт интернет
    +1

    Всерьёз так ни кто не делает, потому, что из всех браузеров отличились разработчики Safari, отказавшись реализовывать расширение нативных элементов. В Safari в целом наследование не от HTMLElement просто не работает.


    Семантика пользовательским элементам задаётся двумя способами:


    1. ARIA атрибуты: role, aria-label и т.д. т.п. (Устанавливается либо через сеттеры role, ariaLabel и т.д. Либо через установку атрибута);
    2. Через готовящийся ElementInternals.

    По семантике ещё делается "виртуальное дерево" для использования с canvas и д.р.

  • Нет серверным веб-приложениям
    0

    Это правда. Просто получилось, что те кто понимают суть JAM хотя бы частично, горят что пример только часть JAM'а, а те кто не в теме получили либо не полное, либо ложное понимание. Автор оригинальной статьи тоже "молодец" с его "Нет" серверам, и в середине "Да" серверам.

  • Нет серверным веб-приложениям
    0

    Автор сам запутался во всех "новых" словах которые он узнал за последние пару лет.


    1. В начале он говорит нет серверам и на середине статьи говорит, а вот JAMstack (у которого на минуточку API это сервера). Т.е. он сам себе противоречит.
    2. SPA/MPA/PWA/CRA/etc, React/Vue/etc. и т.д. и т.п. Если они используют статичные HTML страницы (даже если она одна), используют JavaScript (а всё перечисленное использует его), используют API (а многие всё же делают запросы к API) — всё это JAMstack.

    Сам JAMstack далеко не новый, название и реклама да, подход нет. И он не умирал и не умирает, а живёт и процветает, подстраиваясь под 5 лет эволюции веба (на самом деле 10 лет, а если честнее ещё больше). Ключевые JAM: JavaScript API Markup никуда не пропадали.

  • Нет серверным веб-приложениям
    0

    SPA тоже JAMstack, т.к. есть JavaScript, есть API и есть Markup (пусть и в виде одной страницы).


    С сайта JAMstack.wtf:


    JavaScript
    Dynamic functionalities are handled by JavaScript. There is no restriction on which framework or library you must use.

    APIs
    Server side operations are abstracted into reusable APIs and accessed over HTTPS with JavaScript. These can be third party services or your custom function.

    Markup
    Websites are served as static HTML files. These can be generated from source files, such as Markdown, using a Static Site Generator.
  • Нет серверным веб-приложениям
    +1

    JAMstack не противоречит SPA, а даже наоборот. Главный манифест JAM — JavaScript API Markup, а это всё есть почти в любом SPA (есть SPA не использующие API серверов).

  • Нет серверным веб-приложениям
    +1

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


    Вообще стоит сказать, что JAMstack может быть и без генераторов на самом деле. Если у вас собранная руками html страничка и есть как клиентский JavaScript, так и запросы к API — вы уже используете JAMstack. Даже если страница фактически будет тупо скелетоном это всё ещё JAMstack, хотя больше продвигается "прогрессивный" подход. Тут важно ещё не забывать про клиентскую сторону — мегабайты кода. Всё это всё ещё нужно оптимизировать.


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

    А вот это в рамочку. В зависимости от подхода к JAMstack вы будете платить временем и объёмом хранилища.

  • Нет серверным веб-приложениям
    0

    Но ведь у вас всё равно в итоге получился не JAMstack. Вы всё ещё используете чисто второй подход скатываясь к первому, только рендер перенесли с on-prem на этап сборки. В итоге на выходе у вас только статическая разметка (пусть и сгенерированная). Это путь всевозможных статических генераторов и только часть JAMstack, даже не половина, а скорее треть.


    Чтобы получился действительно настоящий JAMstack нужно скрестить все 3 варианта. Причём даже в статье расшифровка приведена JavaScript API Markup. Т.е. к вашему варианту нужно ещё добавить сервер с API (и вот оно расхождение в статье) и клиентский JavaScript код, тогда у вас будет действительно JAMstack.


    Фактически сайты на React/Vue/etc, если используют API, гидрацию и будут собирать страницы в статику именно на этапе сборки — настоящий JAMstack.


    Чтобы понять что такое JAMstack, оставлю ссылку на JAMstack.wtf. А вообще всё это довольно олдскульно, даже JAMstack существует далеко не 4 года и не 8.

  • Демистификация JWT
    0
    Я говорю данных чувствительных к изменениям.

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


    То что использование любого средства может быть правильным, неправильным и дико неправильным — мне представляется довольно естественным. Тема с JWT выделяется тем, что примеров дико неправильного использования настолько много, что явно выше 50х50

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


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

  • Демистификация JWT
    0

    Опять таки если мы рассматриваем алгоритмы подписи JWT, среди которых есть hash-only HS* (SHA*) и специальный "none" у которых просто нет пар ключей, аргумент про длину подписи зависящую от длины ключа точно так же опровергается. Подчёркиваю я настаиваю именно на утверждении, что подпись JWT зависит от выбранного алгоритма подписи JWT, если это "none" — длина подписи будет равна 0, если это HS* — будет равна размеру хэш-блока, если это RS*, ES*, PS* будет зависеть от длины ключа т.к. длина результата алгоритмов RSA, ECDSA будет зависеть от длины ключа. Но последнее утверждение не применимо к алгоритмам HS* и "none", именно по этому я настаиваю на связи именно от алгоритма подписи JWT. Не стоит откидывать алгоритмы HS* и "none" для них найдутся применения.

  • Демистификация JWT
    0

    И даже при использовании любой пары RS* (RSA) — RS256 и RS512? Это же именно алгоритмы генерации подписи JWT, различия между ними в алгоритмах генерации хешей SHA256 и SHA512, но одинаковый алгоритм RSA. Ладно длина будет одна, но ключи можно использовать одинаковые как для RS256, так и для RS512. И опять таки это не противоречит тому, что я пишу — длина подписи JWT зависит именно от алгоритма подписи JWT, алгоритм подписи JWT может работать как с ключами RS*, ES*, PS*, так и без ключей HS* и "none". Если использовать разные ключи одинаковой длинны в разных алгоритмах с одинаковой хеш-функцией (например SHA256) длина подписи будет разная и зависеть от самого алгоритма будь то RSA или ECDSA.

  • Демистификация JWT
    0

    И всё-таки не зависит от ключа на прямую, но зависит от алгоритма подписи напрямую.


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


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


    Мы же ведём речь о стандарте JWT в целом, а он поддерживает множество алгоритмов подписей в т.ч. и не на ключах. Если выбрать указанный алгоритм "none", то подпись будет равна длине 0 (т.е. вовсе отсутствовать).

  • Демистификация JWT
    +1

    Дело в том, что неправильных тоже нет.


    В конце своего сообщения я указал пример выбора решения использования JWT не смотря на то, что он увеличивает объём трафика и может показаться более жирным чем тупо id + подпись. Главный аргумент — стандартизованный контейнер, об этом даже в самом стандарте написано. JWT это платформо-независимый контейнер токенов, со статусом стандарта. В base64 все вполне умеют в криптографические подписи тоже и в JSON тоже. Его сделали, специально таким гибким и универсальным ведь в большинстве случаев разработка своего формата токенов является задачей сложной, мало сформулировать формат, нужно его внедрить и поддерживать.


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


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


    Чувствтельные данные в JWT хранить не только можно но и нужно.

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


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

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


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


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

  • Демистификация JWT
    0
    так как размер подписи не зависит от объема данных а зависит от величины ключа

    Скорее зависит от применяемого алгоритма подписи. Подпись ведь является по своей сути хешем.

  • Демистификация JWT
    +3

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


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


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


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


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


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


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


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


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


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

  • Почему 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
    Вы серьезно?
    Это было бы так, если бы любой, кому вы скармливаете свой емейл, мог бы запросить остальные данные у почтового провайдера. А это не так. Значит считается, что у вас только почта, более ничего нет.

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


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


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


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

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