Чтобы попасть в список Labs, нужно зайти в Google Maps и нажать на шестеренку в правом верхнем углу. В выпадающем меню выбрать «Maps Labs».

Откроется окно со списком, где можно включить/отключить ту или иную фичу.

Полезными я бы назвал только две первых: измерение расстояний и быстрый зум. Причем, расстояния — это то, чего мне больше всего не хватало в гуглокартах. В принципе, я считаю наличие измерителя расстояний в стандартной морде Яндекс.Карт самым весомым их преимуществом.

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

Полностью защитить протокол общения пользователя с сервером можно только одним способом — шифрование трафика. Экзотические способы шифрования, а также создание различного вида тоннелей мы не рассматриваем. Только обычное SSL-шифрование протокола HTTP, которое поддерживает любой современный браузер — HTTPS.

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

И вот, учитывая это, возникает вопрос: если полностью защитить трафик мы не можем, то можем ли мы защитить хотябы самое важное? Например, пароль. В принципе, можем, но тоже не на 100%. Пароль можно хэшировать до передачи на сервер JavaScript-ом. Тогда перехватчик получить хэш. Он сможет по нему авторизоваться, но сам пароль не увидит. Правда, его можно подобрать брутфорсом. С шифрованием самого пароля (вместо хэширования) картина примерно та же, только реализация гораздо сложнее.

Давать возможность пользователю работать с сайтом по HTTPS можно, но заставлять нужно только тогда, когда шифрование реально необходимо: например, в интернет-банкинге. Дело в том, что у некоторых компаний могут быть закрыты исходящие соединения на 443-й порт, либо запрещен бинарный трафик.

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

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

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

Именно так поступили в Яндексе. У них я подсмотрел способ определения доступности HTTPS. Подгружается JS с https://, который устанавливает флаг в DOM-модели страницы. Форма авторизации ведет себя по разному в зависимости от этого флага.

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

А как делают другие?

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

Mail.ru ведет себя как Яндекс, только их способа определения поддержки HTTPS я не нашел (хотя и не глубоко искал).

Google работает по HTTPS нормально. Пароль передает в открытом виде. Авторизацию по умолчанию предлагает защищенную. Способов определения, поддерживает  ли клиент HTTPS, я не нашел.

Facebook, как и Google, прекрассно работает по HTTPS. Авторизация по умолчанию защищенная. Пароль в открытом виде.

Вконтакте, Одноклассники, TUT.BY и Onliner.by по HTTPS не отвечают, защищенную авторизацию не предлагают, пароль идет в открытом виде.

oz.by по HTTPS предлагает принять самоподписанный сертификат, чтобы потом произвести редирект на HTTP. Пароль в открытом виде.

Вот такая статистика. Западные ресурсы и пользователи давно освоили основы безопасности в сети. Ведущие российские ресурсы защищают хотябы авторизацию пользователя. Ведущие белорусские ресурсы безопасность пользователей игнорируют полностью.

Долгое время белорусская версия была доступна по адресу google.com.by из-за того, что домен google.by был занят. Если точнее, то он был выкуплен Денисом Кораблевым из компании activemedia.by (я так и не понял, какую должность он там занимает — руководитель компании?). В это время на сайте крутился поисковый интерфейс Гугла, который вел на сам google.com, продавалась контекстная реклама и ссылки с главной страницы. Правда в сентябре 2008 сайт закрылся.

Вчера новостному проекту electroname.com и сайту netnews.by представитель Гугла Дмитрий Шоломко прокомментировал ситуацию и сообщил, что еще в декабре домен google.by отсужен у activemedia.by в Верховном Суде Республики Беларусь. Так же он сообщил: «Сейчас ведутся подготовительные работы к запуску сервисов Google на этом домене, и через некоторое время он будет функционировать в обычном режиме сайта Google». Эту информацию electroname.com также подтвердила Алла Забровская, директор по связям с общественностью Google Russia.

Кстати, мне не известны случаи до этого, когда домен в зоне .by был кем-то у кого-то отсужен. Не известны даже случаи подачи таких исков. Так что, вероятно, ситуацию с google.by можно считать хорошим прецедентом в BY-нете. Правда есть одно «но». По словам Дмитрия Шоломко, они обратились в суд с иском о нарушении прав на товарный знак и фирменное наименование, т.к. google.by в свое время копировал сайт google.com. Т.е. объектом иска выступал все же не сам домен непосредственно, а факт копирования интерфейса.

Жаль только, что этот процесс достойно не освещался в СМИ, так, как это происходит на западе и даже в России. Все прошло очень тихо.

* РБ — Республика Беларусь

Эта запись третья, и посвящена она GMail — почте от гугла.

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

На любой потовый ящик, существующего более месяца, и засвеченный хотя бы в 2-3 местах, ежедневно сыпятся тонны спама. И при выборе сервера качество спам-фильтра — один из главных показателей. На Gmail у меня 2 ящика, один поновее, ему где-то год. Второму уже 6 лет, он был заведен еще до появления Gmail, а полгода назад его обслуживание было переведено на Gmail. На второй ящик в день валится в среднем 70 писем спама. Из них попадает во входящие не более 2-3 в неделю, а иногда несколько недель ничего не проскакивает. На первый ящик приходит много меньше писем и спама, но там спам не проскакивает вообще (за весь год 2-3 случая). Так что антиспаму Gmail ставим 5 с плюсом!

До того, как я завел ящик на Gmail, я практически не пользовался веб-интерфейсами для почты. Они были неудобны, просто абсолютно неудобно. Свой первый ящик на гмыле я так и не привязал к TheBat! Ни дома, ни на работе. Потому что сразу начал пользоваться веб-мордой и остался доволен. Ящик доступен дома, на работе и в любом другом месте. Легко найти нужные письма, все быстро открывается и не глючит. В последнее время я даже стал пользоваться веб-интерфейсом и для второго ящик, но только дома. В опере у меня постоянно открыты 2 таба на два ящики на гмыле.
Определенные плюс Gmail в том, что нет нужды задумываться о наличии места на диске. Его там столько, что я не представляю, как его вообще можно исчерпать.

POP3, SMTP и IMAP сервисы доступны в безопасном SSL-режиме. Что еще надо то?

Ну и конечно замечательно то, что они дают возможность использоваться их сервер для почты на личных доменах пользователя. Для этого достаточно перевести MX-записи DNS на почтовые серверы Gmail. И все возможности почты от гугла доступны на вашем домене.