Я имел в виду HTTPS по-умолчанию "из коробки".
Для вас это важно. Логично, что вы должны тратить время, чтобы обезопасить себя. Пускай даже, отказываясь от использования HTTP-сайтов или публичных Wi-fi.
Но перехват трафика это не единственный способ слежки. Много вебмастеров добровольно размещают JS-скрипты, от которых такими примитивными способами, как отказ от HTTP, не защитится. Например, на большинстве крупных украинских сайтов установлен geniusnet.pl, на большинстве русских - LI.
Что вебмастера должны сделать еще, чтобы вас защитить? Разработать свои аналитические системы с самоуничтожаемыми базами?
Господин Милонов предлагает запретить iOS 8.4 и выше из-за смайла emoji на котором изображена гей-пара.
По каким законам? Вы сами подключаетесь к публичной условно-бесплатной Wi-fi сети. Может завтра начнут распространять ПО такое как браузер Амиго, которое будет собирать и продавать полученную информацию. А может это уже делает Яндекс браузер? В этом тоже будет виноват вебмастер? Или все-таки пользователь, который установил этот браузер/подключился к публичной Wi-fi сети?
Так или иначе, но без содействия со стороны разработчиков браузеров, уязвимые HTTP сайты будут всегда. И пускай даже 80% вебмастеров поддержит инициативу и настроит HTTPS, проблема все-равно останется актуальной. Ведь чтобы слить персональные данные достаточно и одного корявого сайта.
В корне решить эту проблему могут только влиятельные люди, а не обычные вебмастера. Например, Google достаточно перестать индексировать сайты по HTTP, отключить поддержку HTTP ниже 2 версии в Chrome. Это только один из сценариев. И судя по новостям, Google ему следует. Но он гарантирует на 100%, что открывая сайты в Google через браузер Chrome, описанная уязвимость вас не коснется.
Такие данные невозможно получить с перехвата трафика сайтов, на которые пользователь не передает информацию. То-есть, блоги без комментирования либо с подключенным комментированием через HTTPS (Disqus, Facebook, VK). А речь шла именно об острой надобности шифровать все и вся.
А о надобности шифровать интернет-магазины, интернет-банки никто и не спорил.
Такой страницы не должно быть. Кроме того, поисковые системы не индексируют страницы с ответом отличным от 200. Исключением является ответ 3XX, поисковая система следует правилам, например, переадресации.
Такой тип страниц должен генерироваться исходя из POST-запроса. Поисковый робот запрашивает страницы только методом GET, поэтому, страниц сгенерированные основываясь на POST-запрос, доступны поисковому роботу не будут.
zadarma.com позволяет активировать функцию приема SMS на украинский мобильный номер Интертелекома, сразу после загрузки скана паспорта. Там можно подключить прямой номер Бразилии бесплатно по тарифу на обслуживание 4 доллара в месяц. Однако, я не уверен, есть ли возможность подключить конкретно мобильный номер.
Есть люди, которые готовы платить деньги за исправление ошибок HTML-валидатора. В большинстве случаев, это ошибки самого стандарта языка разметки, а не ошибки реализации на этом языке. HTML5 частично исправил эти проблемы. И появились толпы людей, которые готовы платить за HTML5, даже не понимая, что это такое.
Но с другой стороны, есть люди, которые программируя на языке PHP, используют одинарные кавычки, только потому, что содержимое в них не проверяется, и теоретически, это дает прирост производительности. На практике, где-то пару наносекунд или другими словами, пару сотен тактов. Когда же нужно вывести содержимое переменной, они используют конкатенацию. То-есть, вместо удобной формы записи "This is $var", они пишут 'This is '.$var.
А есть люди, которые используют методы исходя из потребностей. То-есть, не идеологически двойные кавычки и не oldschool одинарные кавычки, а там где не нужна конкатенация - одинарные, нужна - двойные кавычки.
Я думаю, что рассматривать HTTPS-протокол нужно со стороны протокола, а не со стороны какой-то идеологии Google. Безусловно, стратегически Google популяризирует HTTPS-протокол. Но если говорить об обычных пользователях каких-то блогов, им куда приятнее будет увидеть действительно качественный и полный материал по теме, ежели зеленый значок в адресной строке.
Идеология должна интересовать хостеров, разработчиков серверов (Apache), серверных операционных систем. Они и должны определить когда и как лучше реализовать HTTPS из коробки. И именно они, виноваты в случаях, когда перехватывают и редактируют трафик в публичных Wi-fi сетях. От разработчика сайта требуется только выбор решения, а не свои собственные костыли.
DigitalOcean позволяет расширять сервер налету. То-есть, если со временем, на рабочем сервере, вам 512 MB ОЗУ будет недостаточно, вы сможете в Power Off - Resize - 1 GB изменить конфигурацию сервера без его перенастройки.
Сайты, которые доступны и по HTTP-протоколу и по HTTPS-протоколу, в SERP будут отображены по HTTPS-протоколу по умолчанию.
(c) Google
Google не раскрывает алгоритмов ранжирования, а только задает тенденции. В случае с HTTPS, Google не нарушил традиции. Но это отнюдь не означает, что Google не учитывает и не будет учитывать протокол по которому доступен сайт. Особенно, учитывая следующее.
Кроме того, доступен эксперимент в Chrome, который помечает HTTP-сайты, как небезопасные. Начиная с Chrome 46, сайты с самовыпущенными сертификатами, не считаются безопасными, а считаются нейтральными, как и сайты по HTTP.
HTTP/2 обновленная версия протокола HTTP, в которой за основу взят протокол разработанный Google - SPDY 4. Поддержка HTTP/2 начиная с Chrome 41, Firefox 36 и пока только over HTTPS.
Простыми словами, позиционировать ресурсы относительно /, а не относительно https://site.com/. То-есть, /style.css, а не https://site.com/style.css.
Простыми словами, не указывать в URL, к какому протоколу обращаться, а предоставлять выбор браузеру. То-есть, не https://site.com, а //site.com.
Последствия могут быть не только со стороны закона.
Это проблема браузеров, которые отдают в буфер обмена закодированный URL, вместо читабельного. Некоторые сервисы, например, VK, Skype принудительно декодируют URL перед выводом в чате. В поисковых системах, в браузерах, URL также отображается декодированный.
Именно человеко-читабельный. На секунду, представьте себе транслитерированный URL на статью в Википедии "Цинковый палец" или "Лейциновая застежка-молния".
Транслитерированные слова могут иметь другое значение на других языках. Особенно, если транслитерируются собственные имена. Поэтому, небезопасно подсвечивать их в SERP.
Чтобы увидеть, как Google видит страницу и какое именно содержимое ранжирует, воспользуйтесь инструментом посмотреть, как Googlebot.
При ранжировании, согласно алгоритму Google Panda, Google учитывает визуальное оформление страницы. Согласно официальным данным от Google, поисковый робот не сможет получить доступ к файлам стилей, если их просмотр будет запрещен правилами robots.txt.
Учитывая то, что Google задает тенденции для алгоритмов других поисковых систем, возможно, подобное поведение применимо и для Яндекс, Bing, других поисковых систем.
https://support.google.com/webmasters/answer/35769?hl=ru