Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 90
интересно как
«технология поиска дубликатов файлов, загружаемых пользователями»
сочетается с
«Шифровка файлов происходит на клиентской стороне, так что администрация также ничем помочь правообладателям не сможет, если те и обратятся с просьбой помочь выявить правонарушения».
«технология поиска дубликатов файлов, загружаемых пользователями»
сочетается с
«Шифровка файлов происходит на клиентской стороне, так что администрация также ничем помочь правообладателям не сможет, если те и обратятся с просьбой помочь выявить правонарушения».
По хэшам?
Если файл шифруется на клиентской стороне, то как его отдать другому пользователю даже если мы знаем, что файлы этих пользователей одинаковы?
Допустим, мы знаем, что алгоритм шифрования AES с ключом 256 бит. Что дальше?
Действительно, если даже есть возможность узнать, что файлы дублируются, то ключи на клиентской стороне должны быть разными, как и шифрованные файлы. А если они одинаковые — то заявление о том, что «администрация ничем не поможет правообладателям» —чушь маркетинг.
Действительно, если даже есть возможность узнать, что файлы дублируются, то ключи на клиентской стороне должны быть разными, как и шифрованные файлы. А если они одинаковые — то заявление о том, что «администрация ничем не поможет правообладателям» —
Хэш можно считать и для незашифрованного файла на клиентской стороне.
Ну допустим посчитали мы хэш незашифрованного файла у клиента, нашли такой же в облаке.
И какие дальнейшие действия?
Можно сказать клиенту что файл загружен — тогда получается что он будет лежать в облаке зашифрованный чужим ключем и ключ этот надо передать пользователю, который скачивает этот файл, чтобы он смог его расшифровать.
Вобщем чувствуется какой-то подвох в их словах.
И какие дальнейшие действия?
Можно сказать клиенту что файл загружен — тогда получается что он будет лежать в облаке зашифрованный чужим ключем и ключ этот надо передать пользователю, который скачивает этот файл, чтобы он смог его расшифровать.
Вобщем чувствуется какой-то подвох в их словах.
Есть такое. К тому же, как расшаривать файлы, если они все зашифрованы уникально.
ну это то как раз решается просто — шаринга у них не предусмотрено :)
Во-первых, файлы, которые здесь хранятся могут быть доступны только для пользователей сервиса, их нельзя расшарить для всех желающих.
Не совсем ясно возможно ли расшарить для пользователей сервиса. Поэтому я опять таки посмел предположить :)
Ну как раз пользователю сервиса проблем передать ключь для расшифровки по идее нет. Другой вопрос что тогда все заявления про правообладателей являются чистейшей воды маркетингом и действительности соответствуют весьма слабо.
Да и собственно сейчас гадать то бессмысленно — в ролике на сайте и пресс-релизе на CNET только чистой воды реклама, без какой-либо конкретики.
Да и собственно сейчас гадать то бессмысленно — в ролике на сайте и пресс-релизе на CNET только чистой воды реклама, без какой-либо конкретики.
Хм, возможно, ключ генерируется на основе хеша файла. Таким образом, для одинаковых файлов будут одинаковые ключи. По сути сам файл и будет как бы ключом к самому себе при первичной шифровке. А это означает, что одинаковые оригиналы будут в зашифрованном виде тоже одинаковы.
Это, правда, позволит правообладателю проверить (при определенном уровне доступа), что такой-то файл принадлежит такому-то юзеру, но при одном условии: список хешей юзера будет хранится на сервере в не зашифрованном виде. А вот здесь уже можно применить личный ключ для шифрования этого списка. И чтобы сервису выявлять удаленные файлы (для очистки места), достаточно лишь хранить количество владельцев (без уточнений, кто именно закачивал). Хотя, если вдуматься в идеологию, то удаления файлов вообще не должно быть предусмотрено (с бесконечным хранилищем в удалении не будет необходимости ни одному юзеру).
При такой схеме правообладатель ничего не сможет проверить, кроме наличия файла на сервисе. Чтобы проверить файл у юзера, правообладателю нужно будет встроить в сервис свой код и отслеживать обращения к этому файлу. Хотя я сомневаюсь, что сервис позволит даже просто покопаться кому-либо в своих серверах. Строго говоря, при такой схеме сервис не нарушает закон, даже в случае, если спецслужбы конфискуют носители, разберутся в системе хранения и алгоритме вычисления хешей, и найдут запрещенный хеш. Это смешно. Ну, максимум — парализуют работу сервиса на некоторое время и удалят запрещенные файлы. До выхода соответствующих законов ничего не будет ни сервису, ни юзерам. И я даже не представляю, какие здесь могут быть законы, т.к. сервис не распространяет ничего (именно это не нравится правообладателям больше всего).
Но как там на самом деле будет устроен сервис — пока не ясно. Я просто описал, что двух зайцев убить все-таки можно (теоретически).
Это, правда, позволит правообладателю проверить (при определенном уровне доступа), что такой-то файл принадлежит такому-то юзеру, но при одном условии: список хешей юзера будет хранится на сервере в не зашифрованном виде. А вот здесь уже можно применить личный ключ для шифрования этого списка. И чтобы сервису выявлять удаленные файлы (для очистки места), достаточно лишь хранить количество владельцев (без уточнений, кто именно закачивал). Хотя, если вдуматься в идеологию, то удаления файлов вообще не должно быть предусмотрено (с бесконечным хранилищем в удалении не будет необходимости ни одному юзеру).
При такой схеме правообладатель ничего не сможет проверить, кроме наличия файла на сервисе. Чтобы проверить файл у юзера, правообладателю нужно будет встроить в сервис свой код и отслеживать обращения к этому файлу. Хотя я сомневаюсь, что сервис позволит даже просто покопаться кому-либо в своих серверах. Строго говоря, при такой схеме сервис не нарушает закон, даже в случае, если спецслужбы конфискуют носители, разберутся в системе хранения и алгоритме вычисления хешей, и найдут запрещенный хеш. Это смешно. Ну, максимум — парализуют работу сервиса на некоторое время и удалят запрещенные файлы. До выхода соответствующих законов ничего не будет ни сервису, ни юзерам. И я даже не представляю, какие здесь могут быть законы, т.к. сервис не распространяет ничего (именно это не нравится правообладателям больше всего).
Но как там на самом деле будет устроен сервис — пока не ясно. Я просто описал, что двух зайцев убить все-таки можно (теоретически).
Интересно. Но в ситуации когда
По сути сам файл и будет как бы ключом к самому себе при первичной шифровке.Не понятно, зачем тогда вообще шифровать файлы. И это не совпадает с заявлением
Во-вторых, все файлы шифруются, и никакой правообладатель, даже при большом желании, не сможет обнаружить защищенные авторским правом данные.
Очевидно, чтобы их нельзя было прочитать. Потому что файлы могут быть личными, а не только фильмами и музыкой. Если к кому-то попадет Ваш личный файл, то он сможет узнать от него ключ, но здесь нет вины сервиса. По описанной мною схеме сервис хранит только шифры, а ключей у него нет.
Можно, например, каждый файл шифровать уникальным ключем и при совпадении хешей передавать ключ от файла.
Передавать ключ не комильфо.
Можно шифровать не весь файл, а только какой-то его кусок (особенно актуально с большими файлами). т.е.:
1) упаковали с одинаковыми параметрами сжатия (для обычных алгоритмов типа lz* должен получится одинаковый файл)
2) получаем хеш упакованного файла, ищем в базе
3) шифруем рандомное кол-во байт в шапке(шапка должна быть всегда фиксированного размера) упакованного файла, сохраняем кол-во шифрованных байт
4) записываем шифрованную шапку
5) если в 2* нашли файл — то уже все есть на сервисе, если нет — загрузили.
Другое дело, что такой алгоритм для
точно не подходит.
Можно шифровать не весь файл, а только какой-то его кусок (особенно актуально с большими файлами). т.е.:
1) упаковали с одинаковыми параметрами сжатия (для обычных алгоритмов типа lz* должен получится одинаковый файл)
2) получаем хеш упакованного файла, ищем в базе
3) шифруем рандомное кол-во байт в шапке(шапка должна быть всегда фиксированного размера) упакованного файла, сохраняем кол-во шифрованных байт
4) записываем шифрованную шапку
5) если в 2* нашли файл — то уже все есть на сервисе, если нет — загрузили.
Другое дело, что такой алгоритм для
Загруженную музыку или фильм можно послушать или посмотреть прямо из Сети, без новой загрузки на локальный диск.
точно не подходит.
Ну вариантов как это сделать по большому счету тьма.
Просто все они слабо сочетаются с невозможностью правообладателю выяснить есть ли файл на сервисе или нет и всех прижать по результатам.
Просто все они слабо сочетаются с невозможностью правообладателю выяснить есть ли файл на сервисе или нет и всех прижать по результатам.
Если можно передавать ключи в принципе (а еще веселе, если это будет вшито в ПО) то эти ключи замечательно могут попасть и к администрации, и к кому угодно.
Ну, чисто теоретически, алгоритмы шифрования имеют коллизии. Т.е. можно так зашифровать файл, что он будет открываться несколькими паролями (и для ассиметричного шифрования можно на один закрытый ключ найти пару открытых и наоборот).
Возможно, нужно будет доработать какой-то алгоритм шифрования, но деньги на это у ребят есть.
Возможно, нужно будет доработать какой-то алгоритм шифрования, но деньги на это у ребят есть.
Господи, не городите проблем. У них наверное отдельно хранилище файлов. Каждый файл шифруется своим ключом (не пользовательским, а файловским). Если файл, который пользователь загружает, по хешу совпадает с файлом, который уже есть в облаке — ему просто выдается ключ от этого файла. Ключи хранятся в хранилище ключей клиента, которые уже шифруются ключом пользователя.
Я бы так сделал.
Я бы так сделал.
А как расшифровать на стороне другого клиента?
когда файл шифруется на стороне пользователя, его можно хэшировать. НО!!! Если на сервисе ведется борьба с дублированием файлом, и файлы с одинаковым хэшем удаляются, то как несколько пользователей могут пользоваться зашифрованым файлом?
Да чушь полная… одно исключает другое.
Тут или ошибка в пресс-релизе или в переводе…
Ну или банальный развод =) и ничего они не будут шифровать — ведь проверить то юзер не сможет.
Тут или ошибка в пресс-релизе или в переводе…
Ну или банальный развод =) и ничего они не будут шифровать — ведь проверить то юзер не сможет.
Ошибка перевода, afaik
«Gauda says he can make this business work at $10 a month with unlimited storage. The company is aggressive about data de-duplication, and furthermore, most users have less than 25GB of data. With cheap bandwidth and cheap storage, it works.»
Тут сказано, что компания пристально смотрит на дублирование данных, но не факт, что речь идет о дублировании _разными_ пользователями.
А на их сайте есть такое: «Bitcasa encrypts your data before it is sent to the cloud. It is actually impossible for Bitcasa to access any of your data for any reason.»
«Биткаса шифрует данные до отправки в облако. Биткаса не может иметь доступ к вашим данным ни в коем случае.»
«Gauda says he can make this business work at $10 a month with unlimited storage. The company is aggressive about data de-duplication, and furthermore, most users have less than 25GB of data. With cheap bandwidth and cheap storage, it works.»
Тут сказано, что компания пристально смотрит на дублирование данных, но не факт, что речь идет о дублировании _разными_ пользователями.
А на их сайте есть такое: «Bitcasa encrypts your data before it is sent to the cloud. It is actually impossible for Bitcasa to access any of your data for any reason.»
«Биткаса шифрует данные до отправки в облако. Биткаса не может иметь доступ к вашим данным ни в коем случае.»
> ведь проверить то юзер не сможет
Почему? Если шифрование производится на стороне клиента, то проверить можно.
Почему? Если шифрование производится на стороне клиента, то проверить можно.
тоже это смутило! имхо несочетаемые вещи вообще!
Вы им пользуетесь? Можно популярно — это что? Бекап, когда удаленное со временм удалится и в облаке или как дополнительное место хранения (закинул файл в единственном экземпляре и забыл)?
Как-то странно это:
«Шифровка файлов происходит на клиентской стороне, так что администрация также ничем помочь правообладателям не сможет, если те и обратятся с просьбой помочь выявить правонарушения.»
и
«Загруженную музыку или фильм можно послушать или посмотреть прямо из Сети, без новой загрузки на локальный диск.»
Мне кажется что это взаимоисключающие параметры
«Шифровка файлов происходит на клиентской стороне, так что администрация также ничем помочь правообладателям не сможет, если те и обратятся с просьбой помочь выявить правонарушения.»
и
«Загруженную музыку или фильм можно послушать или посмотреть прямо из Сети, без новой загрузки на локальный диск.»
Мне кажется что это взаимоисключающие параметры
Пользователь, загрузивший фильм, сможет посмотреть его прямо из «облака». Шифрование происходит на стороне клиента.
Так если шифрование происходит локально на моем компьютере, то как не зная ключ шифрования, его посмотреть в браузере?
А причем тут браузер?
каким-то образом доступ к хранилищу «там» осуществляется через их софт на клиенте. Либо это просто программа которая показывает ваши файлы там, и по щелчку запускает плеер (расшифровав до этого файл на лету), либо это может быть, например, драйвер, который имитирует жесткий диск. При обращении любой программы (браузера, видеоплеера) к файлу, этот файл выкачивается и расшифровывается.
Предположения, но так это вполне может работать.
Предположения, но так это вполне может работать.
Шифрование происходит на стороне клиента.
Вы имеете ввиду, что на клиенте мы шифруем, а отправляем в незашифрованном виде что-ли? Если нет, то где расшифровывать?
Вот и мне этот момент не ясен. Стримить зашифрованный файл и расшифровывать?
Я приветствую появление конкурентов Dropbox-а. Надеюсь, вследствие этого от Dropbox-а стоит ожидать увеличение бесплатного дискового пространства.
А я жду удобного клиента для работы с хранилищем Google Docs. Вот тогда конкуренция резко возрастет!
ZohoCRM?
Не понял связи… Если что я про www.google.com/accounts/PurchaseStorage?hl=ru. Очень уж тарифы приятные
Сервис пока проходит стадию бета-тестирования и недоступен для всех желающих. Есть и система инвайтов, запросить инвайт можно здесь.Вчера коллега дал ссылку аналогичную. Суть «инвайтов» — приведи нам стадо и в зависимости от размера стада ты приблизишься к инвайту.
Понаблюдав ворох косяков с отображением контента, плюнул на них. Если они в морде ошибок наделали, то хз чего от сервиса ждать.
Крупные файлы, которые хранят люди в «облаке», обычно представляют собой фильмы и музыку, и такие данные составляют обычно 60% от файлов, хранимых среднестатистическим пользователям. Технологии, которые позволяют избежать дублирования хранимых на сервисе файлов
Во-вторых, все файлы шифруются, и никакой правообладатель, даже при большом желании, не сможет обнаружить защищенные авторским правом данные.
Логическое противоречие только я здесь вижу? Как они ищут дубликаты, если файлы зашифрованы? Ведь если они ищут дубликаты уже зашифрованных файлов, то вероятность их найти мизерная и не принесёт никакой выгоды.
Сервис, облачный, превосходящий по всем параметрам dropbox давно существует, но, видимо, маркетологи и дизайнеры интерфейса не могут его так же успешно продавать.
Сервис как будто специально разработан для хранения лично выкачанной пиратской музыки, фильмов и софта. Больше ни для чего не годится.
Вот если бы можно было у себя такой поднять вместо ftp.
Когда сорцы откроют?
Вот если бы можно было у себя такой поднять вместо ftp.
Когда сорцы откроют?
ммм, а зачем вам сырцы если есть WebDAV?
Берем первую попавшуюся статью по настройке, настраиваем и радуемся :)
Берем первую попавшуюся статью по настройке, настраиваем и радуемся :)
Кто-нибудь знает WebDAV-клиент, умеющий полностью кэшировать удалённый контент локально, как это делают DropBox и iDisk?
Иначе WebDAV-ом можно пользоваться только для небольших текстовых файлов.
Иначе WebDAV-ом можно пользоваться только для небольших текстовых файлов.
DropBox это вообще модифицированный SVN клиент. iDisk я думаю тоже что-то из этой серии.
Т.е. по большому счету все что они делают — автоматический коммит с пушем в удаленный репозиторий и автоматический чэкаут на других компьютерах. Естественно все это в окружении плюшек, рюшек и красивого интерфейса :)
Поднять такое не проблема совершенно, я полгода назад видел статьи на эту тему.
Т.е. по большому счету все что они делают — автоматический коммит с пушем в удаленный репозиторий и автоматический чэкаут на других компьютерах. Естественно все это в окружении плюшек, рюшек и красивого интерфейса :)
Поднять такое не проблема совершенно, я полгода назад видел статьи на эту тему.
Мне кажется, они сами не поняли, что же они хотят предложить.
«Во-первых, файлы, которые здесь хранятся могут быть доступны только для пользователей сервиса, их нельзя расшарить для всех желающих.»
Нет пути
Нет пути
Мне не понравилось низкое быстродействие сервиса. Уж очень медленно странички у них на сайте прогружаются. Для меня это критично, я люблю скорость и минимализм.
аналогичный функционал, но только для музыки это 10tracks.ru
та же дедубликация файлов
та же дедубликация файлов
Ждём запуска Bitcasa beta.
Странно, что они представляют как новинку тот факт, что одинаковые файлы на их сервисе не хранятся по два раза. На дропбоксе есть то же самое — если заливаемый файл уже загружался другим пользователем, то загрузка как будто бы происходит моментально. Сравнивают по хэшам, очевидно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
«Облачный» сервис Bitcasa может стать серьезным конкурентом Dropbox