Спасибо за статью. Интересная мысль высказана, но мне кажется, что всё несколько иначе.
Есть замечательный анекдот на эту тему
Приходит сын к папе программисту.
Папа, как всегда, трое суток не вылазя из-за компьютера что-то хачит…
– Папа, почему Солнце всходит на востоке, а заходит на Западе?
Папа — ноль эмоций…
– Папа, ну почему Солнце каждый день всходит на востоке,
а заходит на Западе?
Папа — опять ноль эмоций…
Сын, нетрпеливо дергая папу за рукав:
– Папа, папа, ну почему Солнце
каждый день всходит на востоке, а заходит на Западе?
Папа, оторвавшись от Клавы и глядя мутным взором на сына:
– Солнце…
– Да
– Всходит на востоке…
– Да
– Заходит на западе…
– Да, папа
– Каждый день?!
– Да…
– И давно так?
– Ну, я не знаю… Всегда…
– Тогда сынок, ради бога, ничего не трогай и ничего не меняй!
Людей из компании просто так не увольняют и особенно ключевых сотрудников. Я вижу только 3 причины увольнения ключевого сотрудника.
А) Попытка сэкономить. Как было уже сказано, проект вышел на плато и есть возможность/необходимость сэкономить средства на рабочей силе.
Зарплаты сотрудников это одна из самых больших статей расходов компании и когда встаёт вопрос финансов, первыми летят головы сотрудников. А кого увольнять, дешёвых джунов или дорогостоящих ключевиков, уже на усмотрение бизнеса.
Если на вас решили сэкономить, то лучше за эту компанию не держаться. Ни к чему хорошему это не приведет. А если в компании реально финансовые трудности, то и обижаться тут не на что. (Я бывал в такой ситуации)
Б) Мешает развитию бизнеса. Не прислушивается к авторитетным мнениям, отказывается реализовывать нужные бизнесу фичи, пилит свои, никому не нужные, фичи, требует долю в бизнесе, диктует как вести бизнес и т.д.
Не важно как, но если ключевой сотрудник мешает развитию компании, то от него нужно избавляться и это нормально.
Если от вас решили избавиться, то может стоит поработать над собой?
С) Возможно вы не такой уж и ценный сотрудник. Бывают случаи когда бизнес списывает какие-то свои провалы на не особо ценных сотрудников и просто избавиться от них.
Тут нет четких критериев выбора козла отпущения. Это просто бизнес.
В любом случае, я бы рекомендовал становиться ценным сотрудником для бизнеса, а не ключевым сотрудником и морально готовится перейти на руководящие роли отдав программирование другим.
Каждый раз когда заходит разговор о фингерпринте, все тут же вспоминают таргетированную рекламу, но почему-то забывают о том, что для этого используются банальные куки, а не фингерпринт.
На всех сайтах установлен Google Analytics и/или Яндекс.Метрика. Куки ставятся на домены Гугла и Яндекса. И не важно, что вы посещаете разные сайты, Гугл с Яндексом могут точно идентифицировать вас по своим кукам.
Фингерпринт хоть и даёт высокий процент точности идентификации пользователей, но не 100% в отличии от кук.
Значительно чаще я встречаю кейсы в которых фингерпринтинг используют для борьбы с теми, кто злоупотребляет анонимностью. Цитата с сайта из комментария выше:
я играю в браузерную онлайн стратегию… при создании второго аккаунта меня система распознаёт как уже зарегистрированного… повторную регистрацию удается повторить при очистке истории (куки) и смене айпи… но если пробовать регать новый ак по реферальной ссылке реферал получается не рабочий ( то-есть ак вроде есть и играет но польза от него хозяину реферальной ссылки ни какой) Эффективно только регистрация на новом не засвеченном компьютере… но где взять столько машин если надо много рефералов?.. МАК-адрес менял не помогает… может криво с руками что… ПОМОГИТЕ обмануть меркантильных хозяев онлайн стратегий и иметь возможность на халявный плюсик.
Делали подобные штуки лет 5 назад, в самописе, и кажется использовали Go!, только аспекты накладывали через аннотации.
Пример в статье не очень удобен, потому, что он моментально сломается если метод переименуется или изменится список аргументов. А отслеживать такие вещи сложно ибо разработчик меняющий метод может быть не в курсе, что на него кто-то налажал аспект. И IDE такую связь не увидит. Особенно весело, если проблема вылезет на этапе слияния с другими фичами.
Аннотации дают более четкую связь метода и аспекта и не такую жёсткую связь как явное использование в методе.
Я вот не понимаю этого шума вокруг знака $. Не припомню чтобы мне когда либо мешал этот символ.
Скажу даже больше. Некоторым не хватает $ в других языках. Довольно часто встречаю случаи когда JavaScript разработчики используют $ в имени переменных (сам так не делаю). Поначалу мне думалось, что это php программисты переносят свои привычки в js, но сейчас так пишут код даже чистые фронтендеры, которые php в глаза не видели. Возможно это просто последствия.
Хотя есть свой смысл в использовании $ в контексте js. Например, в следующем примере без контекста невозможно понять, bar это переменные с некоторым значением или название функции, а foo это название функции или ссылка на функцию.
foo(bar);
Следующие примеры более очевидны
foo($bar);
$foo(bar);
$foo($bar);
И не подумайте. Я не поддерживаю идею использования $ в js.
Сейчас набегут хейтеры и скажут, что это недостатки самого языка и писать надо на питоне)))
Вообще это была шутка. В плане стадий отрицания, с руби и питоном я дальше первой не ушел. Покапал немного, написал несколько простеньких програмулин, но не зашло. А вот php зашёл с самых первых строк. Так зашёл, что до сих пор не отпускает)))
То есть, доступ к данным имеет их владелец или пользователь техподдержки. Получается это тоже бизнес правило, которое также можно закладывать в условия.
Кроме того этот случай решается «супер-пользователем»
На мой взгляд, "супер-пользователь" это серьезный удар по безопасности.
В своей практике я не припомню случаев необходимости в таких пользователях.
Персональный пользователь с правами администратора – Да
Временный пользователь для функциональных тестов – Да
Пользователь с ограниченными правами для ботов – Да
Но не супер-пользователь.
Да, но если эти данные вообще не предназначены для данного пользователя зачем ему вообще иметь возможность их видеть?
Моё предложение в том, что бы использовать базовую спецификацию проверяющую права и расширять её при необходимости. В этом случае вы в явном виде запрашиваете данные конкретного пользователя. То есть, это не спецификация проверчющая права доступа, а спецификация возвращающая пользовательские данные, которая инкапсулирует проверку прав доступа. Это немного другой взгляд.
Конечно можно применять фильтры и на глобальном уровне в неявном виде. Иногда я тоже так делаю, но лично я все равно придерживаюсь мнения, что явное лучше неявного.
Короткий ответ — отлично. Если хотите длинный ответ, то вот он.
Вообще, ограничения доступа которые вы описали в статье, это больше похоже на бизнесовые правила и им место скорее в спецификациях, а не на глобальном уровне. Применяя их на глобальном уровне вы можете столкнутся с ситуацией когда вам нужно получить данные не применяя эти правила.
А что бы не забывать применить спецификации, давайте им понятные названия и объединяйте их в большие. Например, в вашем случае, можно создать спецификации ClientOrganizationsSpec и StaffingAgencyOrganizationsSpec и объединить в общую UserOrganizationsSpec.
Остальные правила которые вы описываете в Where, так же можно описать через спецификации и в результате в контроллере вы будете передавать 1-3 спецификации.
На мой взгляд, проще ориентироваться в наборе спецификаций имеющих четкое название и четкое назначение чем в куче условий в Where. Тем более что со спецификациями вы уже имели дело. Кстати говоря, как ваше впечатление от них спустя год?
Когда пользователь перемещается между страницами его явно интересуют не последние записи
И вернувшись на первую страницу он не увидит новых записей.
на момент запроса тут было сообщение, но к тому моменту как вы до него добрались оно уже было удалено, поэтому мы не можем показать вам его содержимое
Вот вы не видите проблемы в НЛО, но видите проблему в дублях. Другие же разработчики и пользователи не видят проблемы в дублях, а вот НЛО раздражает.
Снепшот создаётся клиентом целенаправленно, чтобы с ним потом работать независимо от изменений в исходных данных.
Из вашей статьи я делаю вывод, что вы запрашиваете с сервера список id записей соответствующих поисковому запросу и кешируете результат на клиенте. Далее, реализуете пагинацию на клиенте по списку закешированных записей.
Вы список закешированных записей называете снепшотом, но механика явно кеширующая.
Так что, нет. В вашем случае кеш и снепшот это синонимы.
А ограничение на число элементов есть всегда
И снова нет. Ограничений почти никогда нет. Вам уже привели 2 примера и можно привести ещё миллион.
Да, некоторые искусственно ограничивают число элементом в силу своих каких-то технических ограничений и Google Search тому яркий пример. Выдавать в поисковой выдаче результаты до которых пользователей не долистает для них скорей всего экономически не выгодно. А вот для каталогов (1, 2, 3) это не корректно. Тоже с архивом новостей. А обрезание комментариев на форуме или сообщений в личке или списка конкурсантов в онлайн конкурсе или ленты в соцсетях это вообще нарушение целостности данных и пользователи вас за это по головке не погладят.
Подитожу. Как я, так и другие комментаторы я полагаю, критикуем не сам ваш метод, давно известный, но не слишком популярный. Мы критикуем ваше отношение к нему. Вы преподносить классическую пагинацию как антипаттерн, а ваш метод как серебряную пулю и универсальное решение хотя это не так.
Но это конечно ваше право иметь собственное мнение и не принимать истину.
При удалении записей которые есть в снепшоте вы получите НЛО или дырки. Если удаленных материалов много, то вы можете получить вообще дырку от бублика пустую страницу.
Вы ограничиваете результат до 1000 записей, но это не всегда корректно. Это корректно для поисковой выдаче, но не корректно для каталогов и архивов. Вспоминаем Бездну.
Реализация без паджинации, но с разделением поиска и выборки решает их все. Было бы не плохо предлагать альтернативы, которые как минимум не хуже.
Serious? Ваше решение решает только проблему дублей на странице, но оно не решает остальные поставленные вами проблемы, о чем вам уже не однократно написали в комментариях.
Относительная паджинация, предложенная maximw, решает как проблему дублей, так и проблему удаленных записей.
Операция – это всего лишь то, что находится во временном интервале: «с» и «по». Если точность наших измерений не позволяет различить «с» и «по», и они сливаются, то мы получаем событие с датой «когда».
Почему операция вдруг превращается в событие? Откуда вообще здесь взялись события если это "продолжительная операция" (с/по) и "одномоментная операция" (когда)?
Трансформатор для эксплуатации и трансформатор для учета материального учета – разные объекты. [...] То есть, один и тот же 4-Д объем может трактоваться как физический трансформатор или как функциональный трансформатор.
Таки разные или одинаковые?
Я бы сказал, что это разные объекты в разных Bounded Context и соответственно с разными 4-Д объемами.
Изменение – это сценарий, а не операция и не событие.
Разве? Мне всегда казалось, что — сценарий выполняет операциюизменения которая триггерит событие.
Но, уточняя модель, мы все равно наткнемся на событие, в котором свет и темнота существуют вместе.
Поясните пожалуйста, что вы имеете в виду под событием в данном случае?
Если это событие которое триггерится на изменение состояния, то я не вижу проблем в сосуществовании света и тени (красный и белый) в одном событии. Хотя в случае если состояний ограниченное количество, как в случае со светом, лучше подойдут типизированные события в духе: в помещении А включили свет.
Так я и не говорю "как взломать соседа". Я говорю, что последствия взлома сосед не проблема архитектуры SSL, а проблема самого взлома соседа.
Уже много раз встречал подобные заявления и каждый раз умиляюсь.
Почему-то все забывают, что если Почтальон взломает Бориса, то Почтальон станет Борисом со всеми вытекающими последствиями. И SSL здесь вообще не при делах.
каким-то образом (социальная инженерия, взлом с проникновением) прописать свой фейковый корневой центр сертификации в реестр Бориса.
В случае взлома, Почтальон уже имеет полный контроль над устройством и ему проще просто установить следящее ПО, майнинг Биткоино и тд, чем развлекаться с сертификатами. Он уже может больше чем просто слушать и изменять трафик.
Та же ситуация с социальной инженерией. Гараздо проще уговорить пользователя два раза кликнуть на exe, чем лезть в сертификационный центр. С этой задачей не каждый продвинутый пользователь справится, что уж говорить о бугалтерушечках.
Я говорю как раз о фактической безопасности сайта. Для пользователей будет все очевидно:
Красный — не безопасно. Не безопасно соединение и как следствие сам сайт.
Нет цвета — возможно безопасно, а может и нет. Соединение безопасно, а вот что с сайтом не известно.
Зелёный — безопасно. Зелёное только для EV сертификатов которые выдаются только юрлиццам и с кучей бумажной волокиты. Сайты под EV достаточно серьезно заботятся о своей безопасности и безопасности своих пользователей. Взломать конечно могут и сайт под EV сертификатом, но вероятность этого ниже. И если не доверять сайтам под EV, то вообще никому доверять нельзя.
Вот мы и получаем, что обозначение будет значительно лучше соответствовать фактической безопасности сайта. И для юзеров это будет нагляднее.
Хотя, пожалуй сайты под EV лучше все же сделать желтыми ибо безопасность не 100%
Я с вами полностью согласен, что "безопасный сайт" и "безопасное соединение с сайтом" это разные понятия. Я вам о другом говорю.
Посмотрите скрин в начале статьи с пометкой "В будущем". Скоро не будут писать ни каких "Защищено". Будут писать только "Не безопасно", что уже намного ближе к правде.
Если соединение с сайтом не защищено, то и сайт не защищен и пользователь не защищен. А если соединение с сайтом защищено, то нет гарантий, что сайт и пользователь защищены и значков говорящих об этом или обратном больше не будет.
Акцент меняется. Раньше было HTTPS это хорошо, а HTTP ну такое, а теперь будет HTTPS ну такое, а HTTP вообще ад. Если раньше Chrome говорил, что сайту с HTTPS можно доверять, то скоро этого не будет. И только избранные, с сертификатом EV, смогут говорить, что им можно доверять.
То есть, по факту, скоро обозначение безопасности сайта в Chrome будет на много ближе фактической безопасности сайта.
Получается как раз наоборот. Если на сайте есть HTTPS, то просто не выводится значек Not secure.
Если раньше Chrome говорил, что сайт с HTTPS безопасный и ему можно полностью доверять, то теперь этого не будет.
Спасибо за статью. Интересная мысль высказана, но мне кажется, что всё несколько иначе.
Приходит сын к папе программисту.
Папа, как всегда, трое суток не вылазя из-за компьютера что-то хачит…
– Папа, почему Солнце всходит на востоке, а заходит на Западе?
Папа — ноль эмоций…
– Папа, ну почему Солнце каждый день всходит на востоке,
а заходит на Западе?
Папа — опять ноль эмоций…
Сын, нетрпеливо дергая папу за рукав:
– Папа, папа, ну почему Солнце
каждый день всходит на востоке, а заходит на Западе?
Папа, оторвавшись от Клавы и глядя мутным взором на сына:
– Солнце…
– Да
– Всходит на востоке…
– Да
– Заходит на западе…
– Да, папа
– Каждый день?!
– Да…
– И давно так?
– Ну, я не знаю… Всегда…
– Тогда сынок, ради бога, ничего не трогай и ничего не меняй!
Людей из компании просто так не увольняют и особенно ключевых сотрудников. Я вижу только 3 причины увольнения ключевого сотрудника.
А) Попытка сэкономить. Как было уже сказано, проект вышел на плато и есть возможность/необходимость сэкономить средства на рабочей силе.
Зарплаты сотрудников это одна из самых больших статей расходов компании и когда встаёт вопрос финансов, первыми летят головы сотрудников. А кого увольнять, дешёвых джунов или дорогостоящих ключевиков, уже на усмотрение бизнеса.
Если на вас решили сэкономить, то лучше за эту компанию не держаться. Ни к чему хорошему это не приведет. А если в компании реально финансовые трудности, то и обижаться тут не на что. (Я бывал в такой ситуации)
Б) Мешает развитию бизнеса. Не прислушивается к авторитетным мнениям, отказывается реализовывать нужные бизнесу фичи, пилит свои, никому не нужные, фичи, требует долю в бизнесе, диктует как вести бизнес и т.д.
Не важно как, но если ключевой сотрудник мешает развитию компании, то от него нужно избавляться и это нормально.
Если от вас решили избавиться, то может стоит поработать над собой?
С) Возможно вы не такой уж и ценный сотрудник. Бывают случаи когда бизнес списывает какие-то свои провалы на не особо ценных сотрудников и просто избавиться от них.
Тут нет четких критериев выбора козла отпущения. Это просто бизнес.
В любом случае, я бы рекомендовал становиться ценным сотрудником для бизнеса, а не ключевым сотрудником и морально готовится перейти на руководящие роли отдав программирование другим.
Каждый раз когда заходит разговор о фингерпринте, все тут же вспоминают таргетированную рекламу, но почему-то забывают о том, что для этого используются банальные куки, а не фингерпринт.
На всех сайтах установлен Google Analytics и/или Яндекс.Метрика. Куки ставятся на домены Гугла и Яндекса. И не важно, что вы посещаете разные сайты, Гугл с Яндексом могут точно идентифицировать вас по своим кукам.
Фингерпринт хоть и даёт высокий процент точности идентификации пользователей, но не 100% в отличии от кук.
Значительно чаще я встречаю кейсы в которых фингерпринтинг используют для борьбы с теми, кто злоупотребляет анонимностью. Цитата с сайта из комментария выше:
Делали подобные штуки лет 5 назад, в самописе, и кажется использовали Go!, только аспекты накладывали через аннотации.
Пример в статье не очень удобен, потому, что он моментально сломается если метод переименуется или изменится список аргументов. А отслеживать такие вещи сложно ибо разработчик меняющий метод может быть не в курсе, что на него кто-то налажал аспект. И IDE такую связь не увидит. Особенно весело, если проблема вылезет на этапе слияния с другими фичами.
Аннотации дают более четкую связь метода и аспекта и не такую жёсткую связь как явное использование в методе.
Сейчас, в Symfony, подобные задачи можно решить через Doctrine Annotation.
Я вот не понимаю этого шума вокруг знака $. Не припомню чтобы мне когда либо мешал этот символ.
Скажу даже больше. Некоторым не хватает $ в других языках. Довольно часто встречаю случаи когда JavaScript разработчики используют $ в имени переменных (сам так не делаю). Поначалу мне думалось, что это php программисты переносят свои привычки в js, но сейчас так пишут код даже чистые фронтендеры, которые php в глаза не видели. Возможно это просто последствия.
Хотя есть свой смысл в использовании $ в контексте js. Например, в следующем примере без контекста невозможно понять,
barэто переменные с некоторым значением или название функции, аfooэто название функции или ссылка на функцию.Следующие примеры более очевидны
И не подумайте. Я не поддерживаю идею использования $ в js.
Сейчас набегут хейтеры и скажут, что это недостатки самого языка и писать надо на питоне)))
А с autoconfigure и конфиг писать не надо. Просто говорим в конструкторе какие зависимости нам нужны.
Вообще это была шутка. В плане стадий отрицания, с руби и питоном я дальше первой не ушел. Покапал немного, написал несколько простеньких програмулин, но не зашло. А вот php зашёл с самых первых строк. Так зашёл, что до сих пор не отпускает)))
14 лет пишу на php. Пробовал питон и руби – и меня никто, ни за какие деньги не заставит писать на них)))
То есть, доступ к данным имеет их владелец или пользователь техподдержки. Получается это тоже бизнес правило, которое также можно закладывать в условия.
На мой взгляд, "супер-пользователь" это серьезный удар по безопасности.
В своей практике я не припомню случаев необходимости в таких пользователях.
Но не супер-пользователь.
Моё предложение в том, что бы использовать базовую спецификацию проверяющую права и расширять её при необходимости. В этом случае вы в явном виде запрашиваете данные конкретного пользователя. То есть, это не спецификация проверчющая права доступа, а спецификация возвращающая пользовательские данные, которая инкапсулирует проверку прав доступа. Это немного другой взгляд.
Конечно можно применять фильтры и на глобальном уровне в неявном виде. Иногда я тоже так делаю, но лично я все равно придерживаюсь мнения, что явное лучше неявного.
Спасибо за доклад. Было интересно послушать.
Вообще, ограничения доступа которые вы описали в статье, это больше похоже на бизнесовые правила и им место скорее в спецификациях, а не на глобальном уровне. Применяя их на глобальном уровне вы можете столкнутся с ситуацией когда вам нужно получить данные не применяя эти правила.
А что бы не забывать применить спецификации, давайте им понятные названия и объединяйте их в большие. Например, в вашем случае, можно создать спецификации
ClientOrganizationsSpecиStaffingAgencyOrganizationsSpecи объединить в общуюUserOrganizationsSpec.Остальные правила которые вы описываете в
Where, так же можно описать через спецификации и в результате в контроллере вы будете передавать 1-3 спецификации.На мой взгляд, проще ориентироваться в наборе спецификаций имеющих четкое название и четкое назначение чем в куче условий в
Where. Тем более что со спецификациями вы уже имели дело. Кстати говоря, как ваше впечатление от них спустя год?Я в подобных случаях использую спецификации
И вернувшись на первую страницу он не увидит новых записей.
Вот вы не видите проблемы в НЛО, но видите проблему в дублях. Другие же разработчики и пользователи не видят проблемы в дублях, а вот НЛО раздражает.
Из вашей статьи я делаю вывод, что вы запрашиваете с сервера список id записей соответствующих поисковому запросу и кешируете результат на клиенте. Далее, реализуете пагинацию на клиенте по списку закешированных записей.
Вы список закешированных записей называете снепшотом, но механика явно кеширующая.
Так что, нет. В вашем случае кеш и снепшот это синонимы.
И снова нет. Ограничений почти никогда нет. Вам уже привели 2 примера и можно привести ещё миллион.
Да, некоторые искусственно ограничивают число элементом в силу своих каких-то технических ограничений и Google Search тому яркий пример. Выдавать в поисковой выдаче результаты до которых пользователей не долистает для них скорей всего экономически не выгодно. А вот для каталогов (1, 2, 3) это не корректно. Тоже с архивом новостей. А обрезание комментариев на форуме или сообщений в личке или списка конкурсантов в онлайн конкурсе или ленты в соцсетях это вообще нарушение целостности данных и пользователи вас за это по головке не погладят.
Подитожу. Как я, так и другие комментаторы я полагаю, критикуем не сам ваш метод, давно известный, но не слишком популярный. Мы критикуем ваше отношение к нему. Вы преподносить классическую пагинацию как антипаттерн, а ваш метод как серебряную пулю и универсальное решение хотя это не так.
Но это конечно ваше право иметь собственное мнение и не принимать истину.
Это такой тонкий троллинг?
Вам же уже написали:
дырку от бубликапустую страницу.Serious? Ваше решение решает только проблему дублей на странице, но оно не решает остальные поставленные вами проблемы, о чем вам уже не однократно написали в комментариях.
Относительная паджинация, предложенная maximw, решает как проблему дублей, так и проблему удаленных записей.
Почему операция вдруг превращается в событие? Откуда вообще здесь взялись события если это "продолжительная операция" (с/по) и "одномоментная операция" (когда)?
Таки разные или одинаковые?
Я бы сказал, что это разные объекты в разных Bounded Context и соответственно с разными 4-Д объемами.
Разве? Мне всегда казалось, что — сценарий выполняет операцию изменения которая триггерит событие.
Поясните пожалуйста, что вы имеете в виду под событием в данном случае?
Если это событие которое триггерится на изменение состояния, то я не вижу проблем в сосуществовании света и тени (красный и белый) в одном событии. Хотя в случае если состояний ограниченное количество, как в случае со светом, лучше подойдут типизированные события в духе: в помещении А включили свет.
Так я и не говорю "как взломать соседа". Я говорю, что последствия взлома сосед не проблема архитектуры SSL, а проблема самого взлома соседа.
Уже много раз встречал подобные заявления и каждый раз умиляюсь.
Почему-то все забывают, что если Почтальон взломает Бориса, то Почтальон станет Борисом со всеми вытекающими последствиями. И SSL здесь вообще не при делах.
Как я люблю такие заявления:
В случае взлома, Почтальон уже имеет полный контроль над устройством и ему проще просто установить следящее ПО, майнинг Биткоино и тд, чем развлекаться с сертификатами. Он уже может больше чем просто слушать и изменять трафик.
Та же ситуация с социальной инженерией. Гараздо проще уговорить пользователя два раза кликнуть на exe, чем лезть в сертификационный центр. С этой задачей не каждый продвинутый пользователь справится, что уж говорить о бугалтерушечках.
Я говорю как раз о фактической безопасности сайта. Для пользователей будет все очевидно:
Вот мы и получаем, что обозначение будет значительно лучше соответствовать фактической безопасности сайта. И для юзеров это будет нагляднее.
Хотя, пожалуй сайты под EV лучше все же сделать желтыми ибо безопасность не 100%
Я с вами полностью согласен, что "безопасный сайт" и "безопасное соединение с сайтом" это разные понятия. Я вам о другом говорю.
Посмотрите скрин в начале статьи с пометкой "В будущем". Скоро не будут писать ни каких "Защищено". Будут писать только "Не безопасно", что уже намного ближе к правде.
Если соединение с сайтом не защищено, то и сайт не защищен и пользователь не защищен. А если соединение с сайтом защищено, то нет гарантий, что сайт и пользователь защищены и значков говорящих об этом или обратном больше не будет.
Акцент меняется. Раньше было HTTPS это хорошо, а HTTP ну такое, а теперь будет HTTPS ну такое, а HTTP вообще ад. Если раньше Chrome говорил, что сайту с HTTPS можно доверять, то скоро этого не будет. И только избранные, с сертификатом EV, смогут говорить, что им можно доверять.
То есть, по факту, скоро обозначение безопасности сайта в Chrome будет на много ближе фактической безопасности сайта.
Получается как раз наоборот. Если на сайте есть HTTPS, то просто не выводится значек Not secure.
Если раньше Chrome говорил, что сайт с HTTPS безопасный и ему можно полностью доверять, то теперь этого не будет.