Однако с 23 апреля эта фраза изменилась на "Dropbox employees are prohibited from viewing the content of files you store in your Dropbox account, and are only permitted to view file metadata". "Не могут" и "запрещено" - несколько разные вещи, несмотря на "strict policy and technical access controls that prohibit employee access except in these rare circumstances".

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

Источник: InfoWorld

теги: dropbox  |  предложить новость  |  обсудить  |  все отзывы (6)

[10050]

назад «  » вперед

аналогичные материалы Dropbox посеял 130 репозиториев // 02.11.22 02:34 Возможная утечка 7 миллионов аккаунтов Dropbox // 14.10.14 11:56 Dropbox признал ошибку, приводящую к потере файлов // 13.10.14 16:28 Dropbox запустил двухфакторную авторизацию // 27.08.12 22:55 Формально несуществующая уязвимость в Facebook для iOS и Android // 06.04.12 03:55 Dropbox устроил день открытых дверей // 21.06.11 10:32

последние новостиBugTraq.Ru: последние новости Зловреды выбирают Lisp и Delphi // 30.03.25 23:26 Уязвимости в Mongoose ставят под удар MongoDB // 20.02.25 18:23 По роутерам Juniper расползается бэкдор, активирующийся "волшебным пакетом" // 27.01.25 17:33 С наступающим // 31.12.24 23:59 Microsoft обещает радикально усилить безопасность Windows в следующем году // 19.11.24 17:09 Ядро Linux избавляется от российских мейнтейнеров // 23.10.24 23:10 20 лет Ubuntu // 20.10.24 19:11

Комментарии: Они там все с ума посходили... )) 16.05.11 22:33   Автор: Den <Денис Т.> Статус: The Elderman <"чистая" ссылка> Все полученные от пользователя и зашифрованные на сервере данные, которые должны быть этим же сервером расшифрованы и переданы обратно пользователю, априори не могут быть приватными. ) Тут и опытов не надо, а поставленый опыт вообще не показателен, т.к. для передачи расшифрованных данных серверу в любом случае необходимо хранить эти данные в каком-то кеше, а алгоритм передачи сервера или алгоритм приема выкачивалки может проверять контрольные суммы файлов и не отправлять/принимать одно и то же несколько раз. Что мешает поставить драйвер, который шифрует не на сервере, а локально, да еще любым алгоритмом, а потом уже зашифрованное кидает серверу! Надежней по-любому. 16.05.11 23:24   Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman Отредактировано 16.05.11 23:25  Количество правок: 1 <"чистая" ссылка> Что мешает... возможность делать общие папки. а так же возможность шарить файлы публично. ну, и как отметили - веб-морда. 17.05.11 18:35   Автор: kstati <Евгений Борисов> Статус: Elderman <"чистая" ссылка> ничто! только кто бы это сделал... )) 17.05.11 01:50   Автор: Den <Денис Т.> Статус: The Elderman Отредактировано 17.05.11 01:54  Количество правок: 1 <"чистая" ссылка> но проще создать архив под сложным паролем и можно выкладывать этот архив в полный свободный доступ. этот архив будет обладать большей приватностью, чем все те ресурсы, которые эту приватность обещают. там есть веб-интерфейс и api, которым пользуется куча сторонних программ на всяких айфонах и андроидах 17.05.11 00:12   Автор: dl <Dmitry Leonov> <"чистая" ссылка> ну да, про веб-интерфейс, через который передается ну никак не в aes, все явно забыли 16.05.11 22:56   Автор: dl <Dmitry Leonov> Отредактировано 16.05.11 22:57  Количество правок: 1 <"чистая" ссылка>

<добавить комментарий>