Действительно, реально ли избежать таких подстав, с/переформулировав некоторые пункты договора? Скажем, тем же ограничением выплачиваемого Исполнителем ущерба? Если не сложно, не поделитесь вариантами?

Прошу прощения за некропост, если вопрос уже неактуален. Однако он остался без ответа, потому озвучу свои мысли (не юрист, но исполнитель).

Если действительная нужна настолько точная идентификация сайта, можно в договоре прописать полные технические характеристики сайта: язык программирования серверной части, фреймворк/CMS, используемую базу данных; библиотеки/плагины, используемые для работы фронтенда, JS-библиотеки и фреймворки, препроцессоры, автоматизаторы рутины (Grunt|Gulp) и пр. Даже дойти до скриншотов дизайна, которые также можно заверить и приложить к договору.

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

4)Предоставить бессмертную душу

Сейчас этого пункта нет. Он действительно там был, или это шутка?

CSS Colours

Для именования переменных цвета в SASS / LESS приглянулся Name That Color: вводим шестнадцатеричное значение цвета или выбираем пипеткой из палитры, сервис выдаёт нам название (на английском) цвета, ближайшего к нему. Цветов примерно в 10 раз больше.

Таким образом, как возможный вариант — некий ресурс пробивает базу своих пользователей на совпадение паролей к их сайту с паролями к почтовым сервисам

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

Проблему, всё-таки (конечно же) заметили и на западе.

На Mashable приведены выводы, схожим с комментариями выше:

• пароли большей частью очень старые или не принадлежат к ящикам
• плюсы и точки в почтовых адресах могут указать на сайты, которые возможно были взломаны (friendster, filedropper, xtube)

Согласно им же и CNN, Google факт взлома их систем отрицают. И все адреса из списков на всякий случай блокируют и перенаправляют на страницу восстановления пароля.

По дыре в OpenSSL могли вытащить те немногие валидные пароли; насколько я понял в принципе такое возможно. Но скорее всего, вы правы; действительно, с момента моего комментария подобных пересечений всплыло очень много.

Возможно, зарегистрировались до введения этого правила.

Возможно, все эти пароли были выужены, когда работала уязвимость OpenSSL. Такое предположение подтверждают некоторые комментарии; и то, что никакой рассылки от почтовых сервисов пользователям по такому, казалось бы, требующему внимания поводу не было (т.е., шум уже был, но какое-то время назад и несколько в другом ключе).

Ждём слива аккаунтов Gmail с кастомными доменами.