В статье на этой странице раскрывается очередное подтверждение по поводу того, что Dropbox небезопасен. Возникает резонный вопрос — как защититься? Я в своем комментарии даю готовый рецепт решения этой проблемы — автоматическое шифрование данных на стороне клиента перед их отправкой на сервер. Но (о ужас!) я позволил себе в своем комментарии дать ссылку на статью, в которой даны конкретные инструкции по поводу того, как настроить у себя подобное шифрование и забыть о проблеме. Итог — сообщение полностью удалено, плюс оставлено язвительное замечание по поводу ссылок. sinodov, то есть если сообщение содержит полезную информацию по теме, но при этом содержит ссылку на внешний ресурс (раскрывающий более подробно тему обсуждения), то это сообщение без вариантов подлежит удалению, так? Это паранойя. Успехов.
Поддерживаю мысль по поводу шифрования данных перед отправкой на сервер. Пользователи Windows могут использовать TrueCrypt (создает зашифрованный файл-контейнер). Пользователям Linux и Mac OS больше подойдет EncFS — эта криптографическая система позволяет шифровать каждый файл в отдельности (имена файлов тоже шифруются). Причем достаточно просто можно [URL=http://www.zhart.ru/software/34-safe-use-dropbox-on-ubuntu-linux]настроить автоматическое шифрование и расшифровку файлов[/URL].
Если конечный потребитель не полная блондинка и если при этом ему нужно решить типовую задачу, то ему также вполне может хватить готового функционала из коробки. Да и нестандартные решения чаще всего можно реализовать при помощи соответствующих дополнений, установка которых в современных CMS сводится к паре кликов. И даже если необходимого функционала не найдется среди обилия существующих дополнений, то разработка решения в виде нового дополнения будет гораздо более простой и дешевой, чем создание проекта с нуля. Здравый смысл подсказывает, что создание с нуля имеет смысл только в тех случаях, когда задача ну очень специфическая и ни один из существующих на рынке продуктов не способен ее решить (либо способен, но дешевле сделать с нуля). Но такие случаи — это скорее исключение, большинство потребительских задач являются типовыми. А если следовать логике автора статьи, то выходит, что уникальных случаев — большинство.
Жизнь и конкурентная борьба показывают, что использование CMS-ок все же эффективно. Если бы разработчику-одиночке или целой девелоперской конторе было бы легче каждый раз писать все с нуля — писали бы все с нуля. В конечном итоге ведь концепцию разработки выбирает именно разработчик, а не заказчик. Заказчик в большинстве случаев вообще не знает, что такое CMS. Заказчику в большинстве случаев на это наплевать, нужен результат. Так почему же разработчик выбирает неудобное и неэффективное для себя решение в виде CMS, вместо того, чтобы каждый раз радостно закатывать рукава и писать все с нуля? Да и доводы по поводу девочек, набирающих контент, очень сомнительны. Что может быть для такой девочки более удобным, чем вордоподобный интерфейс WYSIWYG-редактора, который сейчас в состоянии предложить практически любая CMS? Эта теория не выдерживает проверки практикой. Если бы CMS-ки были неэффективны в использовании, они бы загнулись еще в зародыше.
Дискуссии пользователя
В статье на этой странице раскрывается очередное подтверждение по поводу того, что Dropbox небезопасен. Возникает резонный вопрос — как защититься? Я в своем комментарии даю готовый рецепт решения этой проблемы — автоматическое шифрование данных на стороне клиента перед их отправкой на сервер. Но (о ужас!) я позволил себе в своем комментарии дать ссылку на статью, в которой даны конкретные инструкции по поводу того, как настроить у себя подобное шифрование и забыть о проблеме. Итог — сообщение полностью удалено, плюс оставлено язвительное замечание по поводу ссылок. sinodov, то есть если сообщение содержит полезную информацию по теме, но при этом содержит ссылку на внешний ресурс (раскрывающий более подробно тему обсуждения), то это сообщение без вариантов подлежит удалению, так? Это паранойя. Успехов.
Поддерживаю мысль по поводу шифрования данных перед отправкой на сервер. Пользователи Windows могут использовать TrueCrypt (создает зашифрованный файл-контейнер). Пользователям Linux и Mac OS больше подойдет EncFS — эта криптографическая система позволяет шифровать каждый файл в отдельности (имена файлов тоже шифруются). Причем достаточно просто можно [URL=http://www.zhart.ru/software/34-safe-use-dropbox-on-ubuntu-linux]настроить автоматическое шифрование и расшифровку файлов[/URL].
Если конечный потребитель не полная блондинка и если при этом ему нужно решить типовую задачу, то ему также вполне может хватить готового функционала из коробки. Да и нестандартные решения чаще всего можно реализовать при помощи соответствующих дополнений, установка которых в современных CMS сводится к паре кликов. И даже если необходимого функционала не найдется среди обилия существующих дополнений, то разработка решения в виде нового дополнения будет гораздо более простой и дешевой, чем создание проекта с нуля. Здравый смысл подсказывает, что создание с нуля имеет смысл только в тех случаях, когда задача ну очень специфическая и ни один из существующих на рынке продуктов не способен ее решить (либо способен, но дешевле сделать с нуля). Но такие случаи — это скорее исключение, большинство потребительских задач являются типовыми. А если следовать логике автора статьи, то выходит, что уникальных случаев — большинство.
Жизнь и конкурентная борьба показывают, что использование CMS-ок все же эффективно. Если бы разработчику-одиночке или целой девелоперской конторе было бы легче каждый раз писать все с нуля — писали бы все с нуля. В конечном итоге ведь концепцию разработки выбирает именно разработчик, а не заказчик. Заказчик в большинстве случаев вообще не знает, что такое CMS. Заказчику в большинстве случаев на это наплевать, нужен результат. Так почему же разработчик выбирает неудобное и неэффективное для себя решение в виде CMS, вместо того, чтобы каждый раз радостно закатывать рукава и писать все с нуля? Да и доводы по поводу девочек, набирающих контент, очень сомнительны. Что может быть для такой девочки более удобным, чем вордоподобный интерфейс WYSIWYG-редактора, который сейчас в состоянии предложить практически любая CMS? Эта теория не выдерживает проверки практикой. Если бы CMS-ки были неэффективны в использовании, они бы загнулись еще в зародыше.