Как известно, компания Google пока не выпустила официального клиента Google Drive для платформы Linux, но [[https://plus.google.com/u/0/110043970153071176315/posts/SxDN... подтвердила]], что работает над его созданием. Не дожидаясь выхода Linux-клиента от Google энтузиастами было создано несколько независимых открытых проектов для работы с данным сервисом хранения, используя публично доступную [[https://developers.google.com/drive/v1/reference/ спецификацию]] по API для работы с Google Drive.Среди такие проектов:
[[http://match065.github.com/grive/ Grive]] - написанный на С++ клиент для работы с Google Drive. Поддерживает две базовые операции: загрузка всех находящиеся в Google Drive файлов в текущую локальную директорию и сохранение в Google Drive изменённых данных из локальной директории. В настоящий момент (версия 0.0.3) программа поддерживает только обратную синхронизацию изменений, новые файлы в Google Drive она загружать пока не может. Готовые пакеты сформированы для Debian Testing и Fedora Linux. При первом запуске утилиту следует запустить с опцией "-a", затем открыть указанные URL и скопировать код аутентификции в приглашение программы, после этого будет создана директория .grive и начнётся загрузка данных.
[[http://code.google.com/p/google-docs-fs/ google-docs-fs]] - написанная на языке Python реализация FUSE-модуля для монтирования Google Docs (будет работать и для Google Drive) в качестве локальной файловой системы. К сожалению автор прекратил развитие проекта, но успел выпустить кандидат в релизы. Модуль поддерживает все базовые операции, по чтению и записи данных, позволяет создавать директории. Готовые пакеты доступны для [[https://launchpad.net/google-docs-fs Ubuntu]] и [[http://aur.archlinux.org/packages.php?ID=28666 Arch Linux]]. Для монтирования директории после установки следует запустить "gmount локальная_директория адрес@gmail.com", для размонтирования - "gumount локальная_директория".
[[http://code.google.com/p/gdocsfs/ gdocsfs]] - FUSE-модуль для Google Docs, написанный на Java.
[[https://github.com/jcline/fuse-google-drive fuse-google-drive]] - FUSE-модуль для монтирования содержимого Google Drive в качестве локальной файловой системы. Проект написан на языке Си. В настоящее время проект находится на начальной стадии развития и позволяет только просматривать список файлов, размещённых в Google Drive.
[[https://github.com/beloglazov/google-drive-utils google-drive-utils]] - попытка написать на Python набор утилит для работы с Google Drive, создаваемых по аналогии с GNU Coreutils (ls, cat, cp, mv и т.п.). Проект пока находится на стадии формирования начального тестового прототипа и ещё не пригоден к использованию.
URL:
Обсуждается: http://www.opennet.me/tips/info/2687.shtml
Семь раз подумай, прежде чем залить данные на гугл драйв!
Шифровать...
Что конкретно? Все пароли Google известны наперёд, либо смогут быть получены обходным путём через программное обеспечение от гугла, установленное на машинах пользователей. Аудит пользовательского ПО на предмет "закладок" от Google с их вездесущими сервисами довольно проблематичен (конечно, если это не программы собранные из исходных текстов). :)Я считаю бесперспективной борьбу с Google в вопросах шифрования информации в её сфере влияния.
И у многих стоит гугловский софт с закрытым кодом? Единственное, что из гугловского может быть на современной линуксовой (уж не знаю, как у вас в BSB повелось) машине - хромиум. А полагать,что в него засунули адский код, который будет шариться по диску и искать невесть где пароли для невесть какого софта, которым будет шифроваться какой-то каталог, который дальше будет закидываться на гуглодрайв одой из указанных выше софтин - это паранойя в натуральном, незамутнённом виде.Да даже если пользователь поставит будущий нативный гугловский клиент для гуглодрайва (ага, без исходников) - чтобы оно мониторило систему на предмет того, кто и с какими паролями шифровал то,что оно льёт - это больная фантазия. Потому что достаточно кому-то поиграться с strace - и всё это наружу вылезет, гугл в жизни не отмоется. А кто-нибудь поиграется наверняка.
> И у многих стоит гугловский софт с закрытым кодом? Единственное, что из
> гугловского может быть на современной линуксовой (уж не знаю, как у
> вас в BSB повелось) машине - хромиум. А полагать,что в него
> засунули адский код, который будет шариться по диску и искать невесть
> где пароли для невесть какого софта, которым будет шифроваться какой-то каталог,
> который дальше будет закидываться на гуглодрайв одой из указанных выше софтин
> - это паранойя в натуральном, незамутнённом виде.Причём тут "шариться по диску"? Дисковая активность вызовет подозрения. Достаточно иметь рабочий клавиатурный сниффер в одной из гугловских библиотек. Скажем, в ibus. Самое интересное: при её удалении Chromium тоже работает ;)
> А кто-нибудь поиграется наверняка.
И много таких? Я думаю, эти сначала затребуют мзду у Google за молчание или просто побоятся обнародовать информацию, так как Google их самих сольёт с потрохами (или сделает так специально) спецслужбам. Кто кого: честные хакеры против Google? Не, здесь только обоюдный договор решает дело, а война для хакеров ни к чему хорошему не приведёт. Но это, так, "мысли вслух". Можно воспринимать как фантазию.
Понятно. Это таки паранойя.
А кто сказал, что шифрование бывает только паролем?
Что вообще безопасней - гугл драйв или яндекс диск? Кто из них больше внедряется в личное и ведет себя более агрессивно?
> Что вообще безопасней - гугл драйв или яндекс диск? Кто из них
> больше внедряется в личное и ведет себя более агрессивно?А как они могут куда-то внедряться? У яндекса - вообще webdav - монтируй да копируй привычными средствами. К гуглу вон тоже открытых софтин наваяли (хотя ждём сишный вариант fuse, конечно).
> А как они могут куда-то внедряться?А легко. Впарят вам вместо ваших данных что-то еще например. Или сотрут часть. Или добавят чего не было. А что этому помешает то? Ваше нежелание? Так вас можно и не спрашивать :)
Понятно, опять паранойя.
Ну так это не больше и не меньше, чем любая другая сторонняя система хранения данных. В общем-то крайне сонительно, что кто-то из поставщиков систем онлайн-хранения будет такое чудить, хтя если есть желание перестраховаться - делается левой ногой - шифрование, каталоги, подписи... Впрочем если уж так голову морочить то проще на амазоне каком-нибудь хранилище брать или арендовать серверы/vds. Один черт - если запросы обеспечению к безопасности настолько высоки, то придётся много больше денег/усилий тратить, чем на оплату хранилища и настройку работы с ним.
> А легко. Впарят вам вместо ваших данных что-то еще например.Потеря имиджа им в убыток. А прибыль какая, неуловимый Джо?. Или ты собрался там .exe файлы хранить ?
> Или сотрут часть.
Если ты не платишь деньги, и не подписал контракт по которому они оплатят потерю данных, то должен быть готов к этому всегда. Винчестеры ломаются знаешь ли и в софте баги.
> Или добавят чего не было.
уписяться от страха, ужас какой. Может ещё прийдет человек с ружьем и заставит тебя это добавленное скачать ? А твой провод интернета не выдержит этого насилия ?
какой ты бред пишешь. Единственный не совсем бредовый страх может быть что твои данные сольют третьим лицам. От этого шифруй данные перед заливкой.
> Что вообще безопасней - гугл драйв или яндекс диск?Свой дедик в датацентре. Ну или накрайняк VDS, хотя это и менее надежно. И то гарантии не 100%.
> Свой дедик в датацентре. Ну или накрайняк VDS, хотя это и менее
> надежно. И то гарантии не 100%.Да, и самое главное - датацентр ни в коем случае не на территории exUSSR а желательно какой-то страны щепетильной относительно выполнения законов и в частности неправомерного доступа к информации.
Да-да-да. Уж мы-то заметили, как "не на территории exUSSR" поступают с датацентрами и серверами, на которых пользователи хранили данные, на примере megaupload.
>> Свой дедик в датацентре. Ну или накрайняк VDS, хотя это и менее
>> надежно. И то гарантии не 100%.
> Да, и самое главное - датацентр ни в коем случае не на
> территории exUSSR а желательно какой-то страны щепетильной относительно выполнения законов
> и в частности неправомерного доступа к информации.И самое главное - шифровать/подписывать всё на клиенте и иметь больше одного сервера, на который бэкапимся. В разных юрисдикциях. И всё это нормально настроить, администрировать и сихронизировать.
>>> Свой дедик в датацентре. Ну или накрайняк VDS, хотя это и менее
>>> надежно. И то гарантии не 100%.
>> Да, и самое главное - датацентр ни в коем случае не на
>> территории exUSSR а желательно какой-то страны щепетильной относительно выполнения законов
>> и в частности неправомерного доступа к информации.
> И самое главное - шифровать/подписывать всё на клиенте и иметь больше одного
> сервера, на который бэкапимся. В разных юрисдикциях. И всё это нормально
> настроить, администрировать и сихронизировать.RAID-Z3 на предоставленных "носителях" из разных датацентров, находящихся в разных странах под управлением различных компаний.
RAID-Z3 - это вы ZFS рекламируете? Так он здесь не в кассу - солярис ради этого покупать - всё же перебор, а у FreeBSD малая пользовательская база и нет ни одного вендора, на которого можно было бы положиться в плане слежения за безопасностью. Да и чем оно лучше просто тройного дублирования?
До определённой планки инвестиций в безопасность шансы угробить/скомпрометировать данные на своём сервере много выше, вообще-то. Его надо достаточно надёжно настроить, администрировать, обеспечить достаточно надёжный доступ... И при этом защиты от спецслужб будет не больше, чем на гугле, а шансов потерять данные в результате, скажем, проблем в ДЦ - явно больше.Свои мощности становятся интересными только если есть необходимость какой-то серьёзной защиты и готовность тратить на неё приличные деньги. Ну либо объёмы совсем уж большие, в сотни гигабайт хотя бы.
Вниманию параноиков:
Кто (или что) мешает использовать для хранения в облаках данных криптоконтейнеры?