Google убрал www из браузерной строки в версии Chrome 79. Полный адрес будет виден только при двойном клике в поле адресной строки для редактирования URL или установления расширения Google Chrome.
С выпуском Chrome 69 Google решила больше не показывать «тривиальный поддомен» в адресной строке при посещении веб-сайта. Однако это вызвало протест пользователей, заявивших о том, что между www-сайтами и m-сайтами есть серьезная разница. В итоге Google отменила автоматическое сокрытие поддоменов.
Однако в версии Google Chrome 76 для упрощения чтения и понимания URL-адресов функцию вновь ввели. Пользователи же, которые хотят видеть www поддомены или https://, могут отключить флаг chrome: //flags/#omnibox-ui-hide-steady-state-url-scheme-and-subdomains. Для этого необходимо открыть браузер Chrome, ввести chrome://flags/#omnibox-ui-hide-steady-state-url-scheme-and-subdomains в адресную строку и нажать Enter. На новой странице в опции «Omnibox UI Hide Steay-State URL Scheme and Trivial Subdomains» можно изменить настройки на «Отключено», а затем перезапустить браузер. Кроме того, есть возможность установить расширение Suspicious Site Reporter, позволяющее сообщать о вредоносных, мошеннических и фишинговых сайтах, и Chrome перестанет скрывать www поддомены и .
См. также: ««Прячь www»: почему разработчики мейнстрим-браузера снова отказались от отображения поддомена»В версии же Chrome 79 опцию флага исключат.
Начиная с версии Chrome 77 Google ввела еще одно изменение, которое касается сертификатов EV (Extended Validation). EV-сертификаты лишили дополнительного места в адресной строке браузера для отображения информации о компании. Теперь такая информация выводится по нажатию на пиктограмму с замочком.
См. также: «Заметки верстальщика: Полезные расширения Google Chrome в 2019 году»Специалисты по дизайну интерфейсов и безопасности (группа Chrome Security UX) пришли к выводу, что «EV UI не обеспечивает защиту пользователей должным образом». Другими словами, пользователи не обращают внимания на информацию из EV-сертификатов.
Комментарии (30)
konchok
13.12.2019 15:03По факту это фишинг в виде подмены домена на неоригинальный. Пока только в адресной строке но толи ещё будет. Окончательно избавился от Хрома уже давно, что и всем желаю.
Vilgelm
15.12.2019 06:47Сейчас такое время, что Chrome по сути можно сменить только на другую шкурку над тем же движком.
Crandel
15.12.2019 14:38Нет, пользуюсь фаерфоксом уже 3 года, после квантума, на хромого не собираюсь возвращаться. На мобильном уже есть фаєрфокс превью, который тоже быстрее хромого, можно полностью отказаться от гуглозонда
Xobotun
13.12.2019 16:09+1Лучше бы сделали, что если в адресной строке написано
10.17.185.1:8080/тест, и это выделяется и копируется, то в буфере обмена не оказывалось быhttp://10.17.185.1:8080/%D1%82%D0%B5%D1%81%D1%82. Простая операция копирования, но добавляет протокол и преобразует не-ASCII символы в urlencoded. :/
dartraiden
13.12.2019 17:19добавляет протокол
Логично, потому что в адресной строке у вас, на самом деле, написаноhttp://10.17.185.1:8080, а не 10.17.185.1:8080. Т.е. никто ничего не добавляет, протокол там есть изначально, вам визуально его не показывают.
Chamie
13.12.2019 17:28Это в урле (адресе страницы) он есть, а я текст из текстового поля копирую. Если бы я хотел урл, я бы из контекстного меню выбирал «копировать адрес», а если я в текстовом поле выделяю текст, то не нужно за меня всякую дрянь туда писать. В Хроме же, емнип, даже если руками в адресе выделить только хостнейм, всё равно при копировании протокол допишется и слэш в конце.
Fahrain
13.12.2019 23:25+1Чтобы обойти эту фигню — надо перед копированием перейти в начало/конец поля ввода и добавить пробел. А потом уже выделять и копировать в буфер. Тогда скопирует с русскими символами.
Не удобно — но хотя бы так…Xobotun
14.12.2019 20:29Подключился к рабочему компу, проверил. Хром 78.0.3904.70, если что.
Ctrl+A+Ctrl+C– ковёркает буфер обмена. Ожидаемо.End+?+Ctrl+A+Ctrl+C– тоже ковёркает буфер обмена. Странно.Home+?+Ctrl+A+Ctrl+C– ковёркает буфер обмена. Хм.End+?+Shift+Home+Ctrl+C– всё ещё ковёркает буфер обмена. Неужели совет не из той версии хрома?..Home+?+Shift+End+Ctrl+C– копирует так, как надо! Фух.
Спасибо. Это было сложно, но вы упростили мне жизнь. :)
Xobotun
14.12.2019 20:17Да, это логично и в 98% случаев востребованно. Но всё равно неудобно.
Кмк, лучшее решение – не убирать отображение протокола. От того, что там будет написано
http://на широких экранах места не убавится, а копировать нужное будет проще. Оставшиеся два процента приходятся на какие-нибудь интранет-сайты иftp://, скажем. :)
vitaliy2
13.12.2019 19:27Если так сделать, посыпется много жалоб на кучу ссылок в Интернете, которые не работают. Потому что юзер не знал, что для копирования нужно нажать на адресную строку 2 раза либо 1 раз, но начать перемещать курсор.
Но было бы круто, чтобы появлялась кнопка «скопировать как текст» которая копирует отображаемый адрес без всяких преобразований. После первого копирования объяснить, как это работает, и что ссылка не обязана быть рабочей.
Также рядом можно добавить кнопку «скопировать адрес страницы». Если юзер хочет скопировать адрес для себя, он нажмёт первую кнопку. Если для постинга где-то, то вторую.
JTG
13.12.2019 18:36+1Надеюсь, убрав http(s), они не запилят через десяток версий в результатах поиска новые модные ссылки аля amp://habr.com, которые будут отображаться как habr.com.
toxi_roman
13.12.2019 18:53У меня версия 78 и там нет вообще настройки «Omnibox UI Hide Steay-State URL Scheme and Trivial Subdomains». Другие есть, а именно этой нет.
alexantr
13.12.2019 20:02Нужно включить опцию Temporarily unexpire M76 flags chrome://flags/#temporary-unexpire-flags-m76
Akuma
15.12.2019 08:32А в 79 версии вообще теперь нельзя вернуть полный url что-ли?
Хром скоро страницы начнет обрезать, т.к. «ну а че, нах оно нужно».
kAIST
Ну так www.site в большинстве случаев это просто алиас к site. Никогда не понимал, зачем он сейчас нужен, это архаизм. А m.site вроде как не собираются скрывать.
amarao
Он остался с тех времён, когда сервера называли по именам, и у компании могло быть, например, три сервера: один отвечал за www, второй за почту (smtp/pop3) и третий мог обслуживать ftp. Поскольку никаких динамических средств разделения трафика (балансеров, port-based routing и т.д.) не было, использование разных доменных имён позволяло разделить типы трафика по разным серверам.
Archon
Это одна из причин, но не главная. Гораздо важнее то, что HTTP в те древние времена не был главным протоколом для общения пользователя с сервисом, и предлагать его «по умолчанию» никто и не думал. Кто-то мог работать, допустим, исключительно с юзнет-группами, и даже слова «браузер» не знать. Кто-то соединялся по FTP и качал файлики, и так далее. Масса пользователей работала исключительно с почтой. В итоге, написав на двери магазина «walmart.com», вы не привлекали посетителей на сайт, т.к. не каждый мог понять, что это именно сайт и туда надо ходить браузером.
Сейчас, говоря о каком-то ресурсе с каким-то доменом, мы по умолчанию подразумеваем, что его надо открыть в браузере, поэтому www не нужен и даже вреден.
green_tree
Да, но вот с новыми TLD порой без www непонятно. Вот недавно в вагоне метро видел www.metro.taipei. Из-за www понятно что это URL, а если написать просто metro.taipei, то уже надо какие-то иконки добавлять, чтобы было понятно что это URL. Не всё так однозначно тут
MilesSeventh
Можно https:// дописать, как вариант
vitaliy2
https://metro.taipei
Думаю, это даже больше походит на ссылку, чем
www.metro.taipei
Да и выглядит стильнее.
green_tree
Ну я вообще за, но на рекламе редко видно https://. Наверное это не так понятно для, кхм, обычных людей :)
vitaliy2
Вообще к кукам на www.site.com нет доступа ни одного другого поддомена, кроме *.www.site.com. А к кукам на site.com есть доступ вообще на всех поддоменах.
Т.?е. если на сайте есть авторизация пользователя, то www.site.com безопаснее, т.?к. к этим кукам больше ни у кого нет доступа, а на site.com доступ есть у всех.
В особо важных случаях вместо www можно также юзать специальный поддомен. Например, Вы видели такой у любого из хостингов, когда заходите в админку. Это сделано не для красоты.
Но в 99% случаев сайт разрабатывается одной командой или человеком, и на поддоменах всё-равно не будет левого кода. И использовать www нет никакого смысла, это только мозолит глаза. Причём нужно понимать, что если вдруг реально понадобится, Вы итак сможете перейти на www в любой момент без каких-либо последствий. Но с 99% вероятностью Вам это так никогда и не понадобится.
Если же сайт большой, и разные разделы сайта разрабатываются разными командами, то да, тут уже всегда использование поддоменов логичнее (для разделения кук, чтобы взлом одного поддомена не влиял на другие). Но даже в этом случае вместо разделения по поддоменам я бы поюзал разделение по разделам, например, site.com/раздел1, site.com/раздел2 и т.?д. (это возможно, но надо аккуратно, если Вы не профи, не делайте так, т.?к. нужно настроить права в CORS, в фреймах на «on messsage», запретить флеш, запретить прямой доступ к фреймам переопределив стандартное API, убрать window.opener, поставить на всякий случай всем ссылкам
rel="noopener noreferrer"и т.?д.).andreymal
Это только при некорректной настройке сервера или в забагованном IE11 (в Edge уже пофиксили). Зайдите на тот же www.habr.com — по сравнению с habr.com половина кук (например habrsession_id) будет отсутствовать (другая половина, вроде PHPSESSID, останется, но это уже у Хабра надо спрашивать почему)
vitaliy2
Вообще Вы правы. Вот цитата из MDN:
Если мы указываем конкретный домен, то кука будет доступна также и на всех поддоменах. Но когда мы вообще ничего не указываем, кука будет доступна только на текущем домене и больше никаких.
Тогда в использовании www вообще нет никакого смысла.
Кстати, появилась также новая опция SameSite=Strict|Lax|None, которая позволяет запретить посылку куки, когда запрос к сайту посылается с другого домена (например, через fetch, ajax, img