"Яндекс" создал аналог iCloud

[watashiwa_daredeska]

Протоколом он в любом случае быть не перестаёт.

Вебдав - тоже ведь протокол

нет, это надстройка над http·

Что-то путаница какая-то. Так протокол, надстройка над протоколом или не протокол вовсе? :)

Кстати, насдстройка над протоколом — совсем не обязательно является самостоятельным протоколом. Как надстройка на здании совсем не обязательно является самостоятельным зданием.

[Bizdelnick]

насдстройка над протоколом — совсем не обязательно является самостоятельным протоколом

WebDAV, если не ошибаюсь, принято называть HTTP+надстройку.

[sash-kan]

WebDAV, если не ошибаюсь, принято называть HTTP+надстройка.

предлагаю на этом и остановиться·

[drBatty]

Из коробки.

странно, зачем тогда яндекс рекомендует для венды костыль?

Что-то путаница какая-то. Так протокол, надстройка над протоколом или не протокол вовсе? :)

почему один протакол не может являться надстройкой над другим протоколом? ИМХО так всегда и бывает.

[Bizdelnick]

зачем тогда яндекс рекомендует для венды костыль?

А в винде так принято.

[taaroa]

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

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

Адрес сервера: https://webdav.yandex.ru
Логин (Имя Пользователя): ваш логин на Яндексе
Пароль: ваш пароль на Яндексе

Список программ, которые поддерживают протокол WebDAV

* Windows
Встроенный клиент XP и Windows 7 («Проводник»)
Дополнение для Total Commander
CrossFTP Pro
Far-NetBox

http://help.yandex.ru/disk/?id=1124655

[taaroa]

Из коробки.

странно, зачем тогда яндекс рекомендует для венды костыль?

mailto: support@yandex.ru

[drBatty]

Bizdelnick
taaroa
да? ну ладно. Это мне просто для расширения кругозора...

[Ism]

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

[kamre]

Кто там собирался шифрованные файлы на яндексе хранить: http://legal.yandex.ru/rules/

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

[Bluetooth]

Кто там собирался шифрованные файлы на яндексе хранить: http://legal.yandex.ru/rules/

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

дык никто и не ограничивает доступ к шифрованным файлам - читай этот поток байт сколько влезет

[sash-kan]

Кто там собирался шифрованные файлы на яндексе хранить: http://legal.yandex.ru/rules/

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

записал туда файл, зашифрованный моим открытым ключём·
для проверки, нарушает ли он пункт 5.2.12·

[Bizdelnick]

записал туда файл, зашифрованный моим открытым ключём·
для проверки, нарушает ли он пункт 5.2.12·

Теперь напиши об этом тамошним админам. Если забанят - значит нарушает. (-:

[Basileus]

Кто там собирался шифрованные файлы на яндексе хранить: http://legal.yandex.ru/rules/

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

Ой, как тонко...

[drBatty]

Кто там собирался шифрованные файлы на яндексе хранить: http://legal.yandex.ru/rules/

есть такая схема выкладывания вареза:
1. на форуме публикуем ссылку на файлопомойку + пароль. (пароля может и не быть, тогда он очень простой, и подбирается за 5 минут)
2. на файлопомойке публикуем запароленый RAR архив.
Вот что-бы уберечься от таких схем, на яндексе и ввели это правило. Однако, разве там все файлы находятся в свободном доступе? Это правило касается (должно касаться) ТОЛЬКО общедоступных файлов.

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

на самом деле, это правило запрещает хранить ЛЮБОЙ контент. Например этот пост в виде plain-text там хранить нельзя, ибо доступ к содержимому ОГРАНИЧЕН только теми людьми, которые понимают русский язык. Чем это ограничение хуже/лучше ограничения чтения только теми, кто имеет мой секретный ключ? Количеством "посвящённых"? Хорошо, 1 - мало, 100500К - много. Где граница? Over9000 это много?

Теперь напиши об этом тамошним админам.

я попробую сегодня получить разъяснения...

[sash-kan]

Теперь напиши об этом тамошним админам.

это будет грязный эксперимент — меня забанят как шизофреника (сам на себя настучал)·
для чистоты эксперименто надо, чтобы стучал кто-то другой·

[rm_]

А я вот изобрёл способ безопасного бэкапа на облачные сервисы. Берётся gzip-архив, особым скриптом режется на 2 файла.
Штука в том, что режется не просто на середине пополам, а...
первые 4 килобайта в первый файл
вторые 4 килобайта во второй
следующие 4 снова в первый
ещё 4 опять во второй
и т.д.
Вместо четырёх килобайт подставить число по вкусу, хоть 512 байт и меньше. Получаем некоторый аналог RAID0, только на базе файлов.
В силу особенностей работы алгоритмов сжатия, восстановить что-либо имея только одну половинку, решительно невозможно.
Даже без шифрования. Но для пущей надёжности я таким образом шинкую даже не gz, а gz.gpg.
После чего обе эти половинки заливаются на два разных сервиса (к примеру яндекс и гмайл).
В результате имеем непревзойдённую защищённость от доступа сотрудников сервиса, либо злоумышленников взломавших один из эккаунтов, к содержимому архива. Даже если они смогли увести с локальной машины gpg-ключ, не имея обоих половинок архива - им всё равно ничего из одной половины не достать.
Возвращаясь к сабжу - считается ли незашифрованная половинка от файла нарушающей TOS? Доступ к её содержимому не ограничен, ну а то что половины содержимого нет - так уж извините, никто меня и не заставит тут у вас всё целиком хранить, так что нарушения нет

[drBatty]

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

вы таки уж меня извините, но если сотрудники yandex'а увели с вашей машины _секретный_ gpg ключ, да ещё и его расшифровали, то что помешает им стащить оттуда-же расшифрованый и лежащий открыто пароль от гмыла??? Ваш метод - это как деньги в бумажном конверте, который в сейфе - типа "даже если вор вскроет сейф, он не сможет порвать конверт"

Возвращаясь к сабжу - считается ли незашифрованная половинка от файла нарушающей TOS? Доступ к её содержимому не ограничен, ну а то что половины содержимого нет - так уж извините, никто меня и не заставит тут у вас всё целиком хранить, так что нарушения нет

считается. Ибо доступ к данным _ограничен_ кругом лиц, которые имеют вторую половинку. WinRARархив+пароль это тоже две "половинки" в таком случае, и как в вашем случае, эти половинки бесполезны для тех, кто владеет лишь одной. Доступ для них закрыт.
Вы просто порезали информацию пополам, а обычное симметричное шифрование делит файл на две неравные половинки - шифрованную и пароль, так просто удобнее.

[drBatty]

это будет грязный эксперимент — меня забанят как шизофреника (сам на себя настучал)·
для чистоты эксперименто надо, чтобы стучал кто-то другой·

ну стучите...
https://mail.yandex.ru/disk/public/#u95RvRT...xm+0YIkA68VsAY=
этот файл представляет собой зашифрованный plain/text файл.
вот его ЭЦП https://mail.yandex.ru/disk/public/#Se1K5m+...2LEO5NAJsOhFqw=
(подписано моим ключом, ID которого можно найти под аватаркой)

В силу особенностей работы алгоритмов сжатия, восстановить что-либо имея только одну половинку, решительно невозможно.
Даже без шифрования. Но для пущей надёжности я таким образом шинкую даже не gz, а gz.gpg.

два возражения:
1. ну в чётной половинке можно таки без шифрования восстановить первый чётный блок. И я полагаю, что для данных зашифрованных методом Хаффмана тоже можно что-то придумать. С арифметиком сложнее, но тоже не всё потеряно.
2. что касается шифрования, так gpg в любом случае по дефолту сжимает gzip'ом. Т.ч. у вас будет *.gz.gz.gpg

[rm_]

2. что касается шифрования, так gpg в любом случае по дефолту сжимает gzip'ом. Т.ч. у вас будет *.gz.gz.gpg

Я всегда выключаю встроенное сжатие GPG, сжимаю сам явно, и кстати не всегда gz, в зависимости от ситуации иногда lzo и другие.

[drBatty]

Я всегда выключаю встроенное сжатие GPG

зачем?

и кстати не всегда gz, в зависимости от ситуации иногда lzo и другие.

я тоже. но там ведь есть --compress-algo

[rm_]

Я всегда выключаю встроенное сжатие GPG

зачем?

Затем чтобы не греть CPU на gz+gz либо (что-то моё)+gz.

и кстати не всегда gz, в зависимости от ситуации иногда lzo и другие.

я тоже. но там ведь есть --compress-algo

lzma, lzo и xz я там не вижу. Да и вот ещё, морочиться менять его через ключи, и вообще, встроенное сжатие в шифровалке - это неюниксвейно.
Гораздо прямее шифруемые данные принимать через пайп от архиватора (никто ведь не говорит о промежуточном файле на диске и т.д).
К тому же сомневаюсь что gpg сможет шифрование и сжатие раскидать на разные ядра CPU, в случае же с архиватором отдельным процессом - только в путь.

[drBatty]

встроенное сжатие в шифровалке - это неюниксвейно.

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

Шифрование без сжатия - это плохая идея, и плохое шифрование. Да и заюзать libz.so совсем не сложно.

[rm_]

Ну что, пригласили - зарегался и попробовал сабж.

Киллер фича для меня - это то, что (не взирая на протоколосрачик выше по теме) смонтировать диск можно по стандартному, открытому протоколу WebDAV, таким образом получив доступ к хранилищу без установки какого-либо проприетарного софта в систему.
Дропбокс (с которым следовало бы сравнивать ЯД, а не с iCloud!) так не умеет, верно?

Ещё б davfs2 работал чуть менее по-дебильному, не кидаясь кэшировать на диск каждый открытый файл полностью, прежде чем разрешать какие-либо операции над ним.

Из глюков - скопировал 2 файла с narod'а (воспользовавшись предложением в "Опубликованных файлах"), после чего удалил их, но место так и не освободилось, хотя прошло уже несколько часов.

Также вызвало недоумение, что ссылки на расшаренные файлы ведут на "http://mail.yandex.ru/....."

3. эту файло помойку можно смонтировать к каталогу в Linux. Вот что навоял небезызвестный Поттеринг: http://www.0pointer.de/lennart/projects/fusedav/
Уж не знаю, как оно работает, попробую... Не получится костылём Ленарта, попробую этим: http://savannah.nongnu.org/projects/davfs2

Костыль от поттеринга заброшен в 2006-м году, и работает на редкость хреново.
В половине попыток открыть файл приложения просто обламываются с какой-то ошибкой ввода-вывода.
Вторая попытка вроде даже проходит, иногда.
Я в общем ничуть не удивился такому горькому катаклизму, в итоге снёс данный костыль, вернувшись к davfs2.
Который вполне даже юзабелен, по крайней мере если не хранить на ЯДе файлы размером более мегабайта-двух.

вообще-то есть www.wuala.com
и там есть шифрование. Причём довольно стойкое. Причём сотрудники этой вуаля в принципе не могут расшифровать ваши файлы - ваш локальный клиент сам создаёт ключ шифрования, при этом доверие к нему обеспечивают случайно выбранные (вашим клиентом) узлы сети. Сами данные хранятся тоже у клиентов, а не на серверах вуали (ну по большей части). Естественно, код клиента открыт. Вуаля...

Но зачем, зачем же вы обманываете?
http://www.wuala.com/en/support/faq/c/21
Do you plan to open the source code? "Currently not. Opening the source code of Wuala would consume quite some time and effort, and commitment to maintain it. If you are a software engineer and would like to see how Wuala works, feel free to apply for a job at Wuala."

[rm_]

Лучше запросите клиент под линукс, а не помидорами закидывайте.

+1. Можно конечно через WebDAV работать, но синхронизация локального каталога а-ля Dropbox порой сильно удобнее.

1) значит кривой и косенький, и главное проприетарный (а другого вам не сделают) "Клиент Под Линукс" для вас лучше возможности просто примонтировать хранилище стандартными инструментами ОС?
2) натравить unison на смонтированный WebDAV-каталог для какой угодно синхронизации чего угодно с чем угодно - религия не позволяет?

[drBatty]

Киллер фича для меня - это то, что (не взирая на протоколосрачик выше по теме) смонтировать диск можно по стандартному, открытому протоколу WebDAV, таким образом получив доступ к хранилищу без установки какого-либо проприетарного софта в систему.

я пока только в Dolphin'е пробовал.
Нареканий нет, но ещё недостаточно протестировал.

Но зачем, зачем же вы обманываете?
http://www.wuala.com/en/support/faq/c/21
Do you plan to open the source code? "Currently not.

странно... раньше код клиента был открыт. теперь вот так пишут:

We love open source technology and Wuala is based on a number of open source projects. We did open source Wuala Webstart and Wuala Persistent Map.

обновили, *ля... :(
Прошу прощения, за то, что ввёл вас в заблуждение...

[Aectann]

1) значит кривой и косенький, и главное проприетарный (а другого вам не сделают) "Клиент Под Линукс" для вас лучше возможности просто примонтировать хранилище стандартными инструментами ОС?

Тогда, когда это было мне действительно нужно, оно у меня работало, выполняло свои функции на ура, не глючило, есть не просило. Остальное не интересно.
И да, это проще, нежели примонтировать хранилище, потому что синхронизация выполняется тогда, когда есть доступ к сети, а локальные копии файлов нужно было порой редактировать при отсутствии доступа. Собственно, это и является одной из "фишек" клиентов Dropbox/аналогичных серсисов перед обычными каталогами, смонтированными по WebDAV/NFS/sshfs/SMB.

2) натравить unison на смонтированный WebDAV-каталог для какой угодно синхронизации чего угодно с чем угодно - религия не позволяет?

Посмотрю, что это такое, спасибо. Впрочем, линуксовый клиент для Диска уже пилится, возможно, через какое-то время будет работающая версия.

[vbif]

Кто там собирался шифрованные файлы на яндексе хранить: http://legal.yandex.ru/rules/

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

Так вроде исключили уже этот пункт