Комментарии 101
Дело в том, что если у двух файлов изменить имена или расширения, то их хэш-сумма будет по-прежнему одинаковой. При изменении содержимого файла автоматически изменится и хэш-сумма.
Т.е. достаточно изменить одну букву в meta info видео/мп3 файла, и всё будет ок?
Т.е. достаточно изменить одну букву в meta info видео/мп3 файла, и всё будет ок?Т.е. вы серьёзно не знаете, что такое хэш? :) (шучу если что)
Да, будет ок, только этим мало кто заморачивается, в основном тупо копируют. Тот жалкий процент, кто этим озадачился, мало кого волнует.
про mp3 была инфа, что хешируют данные, без метаинформации, а скоро будут по слепку проверять, если не уже. Ссылку не найду уже.
Ну ладно, будут в zip архивах при надобности шарить:)
В zip же тоже смотрят ) (стойкая уверенность, что exe не переслать в zip без пароля в том же gmail)
А под пароль в архив оже противоречит пользовательскому соглашению.
А под пароль в архив оже противоречит пользовательскому соглашению.
/del
Гугл: «Вы не даете нам читать ваши письма — мы не даем вам пользоваться нашей почтой»…
Нормально так… Почти как роскомнадзор. И всегда можно отмазаться, кивнув на борьбу с терроризмом, вот это все…
Нормально так… Почти как роскомнадзор. И всегда можно отмазаться, кивнув на борьбу с терроризмом, вот это все…
А чего им отмазываться? Их почта — их правила. Никто же вас насильно не заставлял нажимать галочку с соглашением при регистрации или пользоваться гмейлом впринципе. :)
Правила-то их, но это не значит, что пользователь не имеет права даже возмущаться ими и постить на всех ресурсах, что Google — уроды.
В следующий раз они так возьмут и перестанут принимать письма с посторонних почтовых сервисов. Разумеется, исключительно ради борьбы со спамом. Хотите переписываться с пользователями GMail — тоже заводите там аккаунт.
Имеет ведь Google право так сделать? Поменять, как они обычно делают, соглашение задним числом и разослать всем пользователям новые правила.
В следующий раз они так возьмут и перестанут принимать письма с посторонних почтовых сервисов. Разумеется, исключительно ради борьбы со спамом. Хотите переписываться с пользователями GMail — тоже заводите там аккаунт.
Имеет ведь Google право так сделать? Поменять, как они обычно делают, соглашение задним числом и разослать всем пользователям новые правила.
Конечно имеют право. Такое же право имеет Apple — запретить входящие звонки с аппаратов других брэндов. И магазин у подъезда может брать деньги за вход. Другое дело, что пользователей/клиентов станет меньше и никто в здравом уме этого не станет делать.
А под пароль в архив оже противоречит пользовательскому соглашению.Серьёзно? Надо наконец его почитать :)
Конкретно там написано про шифрованные файлы и криптоконтейнеры.
То же самое и у DropBox, но на нем 5 лет вполне себе жил гигабайтный TrueCrypt образ. Инкрементальная синхронизация годная вешь. В гугл он недавно был загружен как бекап и пока гугл молчит про него.
То же самое и у DropBox, но на нем 5 лет вполне себе жил гигабайтный TrueCrypt образ. Инкрементальная синхронизация годная вешь. В гугл он недавно был загружен как бекап и пока гугл молчит про него.
Ну у меня там лежит KeePass'овский файл, по сути тоже шифрованный контейнер — проблем не было.
А вообще бред — файл он и файл, мой файл, что внутри — не ваше дело. Видимо просто перестраховываются этим пользовательским соглашением.
А вообще бред — файл он и файл, мой файл, что внутри — не ваше дело. Видимо просто перестраховываются этим пользовательским соглашением.
C DropBox это хотя бы частично можно понять — у них архитекутра основана на блочном хранилище и индексации блоков по хэшам.
И любое шифрование данных рушит всю дедупликацию хранимых данных и мешает эффективно их индексировать. Т.е. сильно увеличивает их расходы на хранение пользовательских данных если пользователи вдруг начинают активно пользоваться шифрованием.
В случае же гугла это наглое заявление — не смейте мешать нам копаться в ваших данных, не для того мы их собираем, чтобы просто хранить.
И любое шифрование данных рушит всю дедупликацию хранимых данных и мешает эффективно их индексировать. Т.е. сильно увеличивает их расходы на хранение пользовательских данных если пользователи вдруг начинают активно пользоваться шифрованием.
В случае же гугла это наглое заявление — не смейте мешать нам копаться в ваших данных, не для того мы их собираем, чтобы просто хранить.
С паролем уже тоже не переслать. Не хочет принимать :(
С паролем исполняемый не хочет передать? Или просто любой архив с паролем? Кроме того, есть такая опция, как шифрование названия файлов.
Уже проверяли с шифрованием файлов в т.ч. Большая часть писем возвращается. Хотя некоторые и уходят в таком виде. Статистику как-то не догадались изучить. Перешли на отправку ссылок на файлы (.
А расширение менять если?
По крайней мере, раньше этот метод работал
Тоже не прокатывает. Какие-то файлы несколько раз так передавали, но
это проблемы ведь и для принимающей стороны и никогда не знаешь пройдут файлы или нет. Проще избавиться от этого и гарантировано доставлять почту. Гугл банальный mdb с макросами может не пропустить даже.
это проблемы ведь и для принимающей стороны и никогда не знаешь пройдут файлы или нет. Проще избавиться от этого и гарантировано доставлять почту. Гугл банальный mdb с макросами может не пропустить даже.
Пакуйте архиватором типа ain — он столь экзотичен, что даже следов в инете почти не найти и его не знает ни один антивирь чтобы распаковать (и гугл, наверняка. тоже; lha/ice, не говоря об arj, должны знать). Он, правда, DOS, но если внутрь положить rar с коротким именем, то он просто его перепашет до неузнаваемости сигнатур, чуть увеличив размер. а ещё можно рар превратить в ююки, которые пожать раром — размер вырастет, но попробуй распакуй (не гарантия).
НЛО прилетело и опубликовало эту надпись здесь
Будем тогда в метаинформации кодировать пиратский контент
На самом деле, за этим будущее. Пройдет лет 5-10, все перехешируют.
И тут внезапно появятся программы на дельфи и бейсике, с большими кнопками «скопировать контент с защитой от детекта», которые будут копировать файл, меняя пару байт в метаданных. Или может быть даже точку в каком-нить кадре. И все наработки по хешированию придется переделывать.
Затем появятся программы, которые будут добавлять маленький водяной знак в каждый кадр с краю экрана, и поломается проверка по хешированию разных блоков.
В общем рано переживать.
И тут внезапно появятся программы на дельфи и бейсике, с большими кнопками «скопировать контент с защитой от детекта», которые будут копировать файл, меняя пару байт в метаданных. Или может быть даже точку в каком-нить кадре. И все наработки по хешированию придется переделывать.
Затем появятся программы, которые будут добавлять маленький водяной знак в каждый кадр с краю экрана, и поломается проверка по хешированию разных блоков.
В общем рано переживать.
Согласен. Пока это выглядит как «охота на домохозяек», как примет массовый характер — появится соответствующее ПО.
Переживать никогда не рано, иначе риск оказаться в роли той варёной лягушки становится вовсе не риском, а вполне устоявшейся практикой.
Надеюсь времена дельфёвых кнопок «скопировать» прошли и человечество перешагнуло это как детский лепет. По современным стандартам должен появиться софт, который будет прозрачно и незаметно обфусцировать и деобфусцировать файлы на стороне клиентов, а торрент-клиенты научатся учитывать обфускацию.
Но вы прав и это классическое противостояние брони и пули. Правообладателей меньше, чем пользователей, но они сообща и знают чего хотят, в отличие от народных масс.
И тут я бы сам рад был видеть решение в стиле PGP, SSL, P2P, VPN, а не партизанского колхоза.
Но не переживайте. Как только корпоративные облака станут тесными и душными, появится спрос и возникнут предложения в виде нормальных P2P решений. BTSync был только первым шагом, причем проприетарным. Все впереди. Будет интересно.
Надеюсь времена дельфёвых кнопок «скопировать» прошли и человечество перешагнуло это как детский лепет. По современным стандартам должен появиться софт, который будет прозрачно и незаметно обфусцировать и деобфусцировать файлы на стороне клиентов, а торрент-клиенты научатся учитывать обфускацию.
Но вы прав и это классическое противостояние брони и пули. Правообладателей меньше, чем пользователей, но они сообща и знают чего хотят, в отличие от народных масс.
И тут я бы сам рад был видеть решение в стиле PGP, SSL, P2P, VPN, а не партизанского колхоза.
Но не переживайте. Как только корпоративные облака станут тесными и душными, появится спрос и возникнут предложения в виде нормальных P2P решений. BTSync был только первым шагом, причем проприетарным. Все впереди. Будет интересно.
Tahoe-LAFS. Распределенное избыточное шифрованное хранилище файлов, где storage-ноды хранят кусочки файлов, не зная их содержимое. Клиент сам шифрует файлы перед загрузкой и расшифровывает после скачивания.
Уже существует облачный провайдер, предоставляющий серверы LAFS: https://leastauthority.com/
Подключайтесь к общему пулу хранилища в I2P: http://jf2g5hus6gp2jfgk7zgc2cxtzeedxbstr3ju374amtoaq6p2ax6a.b32.i2p
Уже существует облачный провайдер, предоставляющий серверы LAFS: https://leastauthority.com/
Подключайтесь к общему пулу хранилища в I2P: http://jf2g5hus6gp2jfgk7zgc2cxtzeedxbstr3ju374amtoaq6p2ax6a.b32.i2p
У меня 1 притензия к i2p она слишком много ресурсов CPU использует…
Но на посмотреть обязательно попробую.
Но на посмотреть обязательно попробую.
Неужели и i2pd тоже? :)
У меня флудфил без ограничения трафика примерно 15-20% на VPS.
Кстати сегодня вышел новый релиз 2.12.0
У меня флудфил без ограничения трафика примерно 15-20% на VPS.
Кстати сегодня вышел новый релиз 2.12.0
его не пробовал. нагрузку 20-25 дает стандартный клиент с ограничением до 50кбс
А как на i2pd торренты качать, кроме Vuze? Vuze я прицепил, но не уверен, что у него есть режим без gui(чтобы держать не на основном компе), да и сам он глюковат и тяжеловат. Оригинальный i2p мой роутерный девайс разорвёт.
Корректная ссылка: http://i2pwiki.i2p/index.php?title=Tahoe-LAFS
У меня когда-то была идея создания распределенного архиватора, когда в публичном хранилище лежат готовые блоки данных, и архиватор, в случае наличия подходящего блока в публичном хранилище, просто сохраняет его индекс.
В результате получается «почти» вечный архиватор для отдельного пользователя.
В результате получается «почти» вечный архиватор для отдельного пользователя.
межпланетная файловая система
IPFS сочетает в себе распределенную хэш-таблицу, децентрализованный обмен блоками, а также самосертифицирующееся пространство имён. При этом IPFS не имеет точек отказа, и узлы не обязаны доверять друг другу
Что то похоже он даун — у меня нигде лизсет не находит.
На ютубе уже даже школьники (не все конечно, но многие) методы борьбы освоили — заливают копирайченный контент на свои каналы, прогнав видео через редактор, который добавляет какую-нибудь рамочку вокруг видео (заодно в стиль канала можно оформить или собственную рекламу пихнуть) и звук чуть-чуть ускоренный/замедленный/сдвинутый по тону. И обламываются не только простые проверки по хэшу, но и продвинутые алгоритмы Content-ID (там намного больше чем просто проверка файлов по хэшу, сложный анализ вплоть до нейросетей и зачатков ИИ) и копирайченный контент висит неопознанным.
Из-за этого гугл уже начал даже набор армии людей добровольцев-стукачей, которые должны среди полезных вещей в т.ч. стучать на нарушения авторских прав. Понимают что только на уровне ПО с этим полностью справится невозможно.
Из-за этого гугл уже начал даже набор армии людей добровольцев-стукачей, которые должны среди полезных вещей в т.ч. стучать на нарушения авторских прав. Понимают что только на уровне ПО с этим полностью справится невозможно.
возможно, они не считают хеш для всего файла, а бьют его на куски и считают для них по отдельности. поменяете в 1м месте в других останется. как при поиске плагиата.
Я уверен, что у Гугла используется перцептивный хэш, так что изменение одной буквы (и даже всего видео) не обманет систему Content-ID
https://en.wikipedia.org/wiki/Perceptual_hashing
https://habrahabr.ru/post/120562/
https://en.wikipedia.org/wiki/Perceptual_hashing
https://habrahabr.ru/post/120562/
На ютубе в хвост приклеивают дополнительное видео размером вполовину от цели и диким, какофоническим звуком.
Я так понимаю что этим занимаются несколько груп, там разные хвосты, одиноковые в пределах группы.
> Пиратская музыка
— Я купил альбом на идиотских Tidal Store, Beatport, Junodownload, тысячи их — которые разрешают скачать купленный альбом только один раз. Чтобы забэкапить, закинул на гуглодиск
ИЛИ
— Я скачал этот же альбом на трекере
Естественно, хеши в обоих случаях будут совпадать, если конечно создатель раздачи на трекере не менял метаданные, и если мы не говорим о каком-нибудь iTunes, который в метаданные добавляет информацию о покупателе.
С фильмами такое не прокатит, ведь стриминг, к сожалению, почти победил. А вот с теми же книгами тоже вполне актуально.
— Я купил альбом на идиотских Tidal Store, Beatport, Junodownload, тысячи их — которые разрешают скачать купленный альбом только один раз. Чтобы забэкапить, закинул на гуглодиск
ИЛИ
— Я скачал этот же альбом на трекере
Естественно, хеши в обоих случаях будут совпадать, если конечно создатель раздачи на трекере не менял метаданные, и если мы не говорим о каком-нибудь iTunes, который в метаданные добавляет информацию о покупателе.
С фильмами такое не прокатит, ведь стриминг, к сожалению, почти победил. А вот с теми же книгами тоже вполне актуально.
НЛО прилетело и опубликовало эту надпись здесь
Эх, чую вернутся времена шаринга пираток по почте — зводится почта, туда выкладывается что-то типа some-popular-movie.rar… r00… r01… r99, далее по принципу token-ring пароль с логином от ящика передается всем желающим скачать. Будут теже яйца, только через [any free popular cloud disk service name]
Но при бекапе вы не будете делать общедоступную ссылку
А если мне захочется скинуть один трек другу послушать… Ах да, копирасты же негодуют даже от того, что мы друг другу диски даем и вообще друг у друга слушаем, Fair use надо испепелить, чтобы все сидели на подписках и покупали
Пора искать \ писать софт для перегенерации хэшей своего контента, поскольку ожидаемо, что проблемы как раз не столько с пиратским контентом будут, а с тем что твоя бережно хранимая коллекция нажитая непосильным трудом попадет под раздачу из за совпадений или законных бэкапов, как указано выше.
Зашифрованные архивы, или просто шифрование.
Допустим я хочу не испытывать неудобств с пользованием коллекции. Например мне нужна книга с моей библиотеки. Одно дело — скачать книгу, другое дело — архив. Его еще распаковывать надо. А если мобила без архиватора. В общем лишнее промежуточное звено. Но вариант работоспособный, если надо здесь и сейчас.
В Gmail, например, у вас просто не получится прикрепить архив с паролем к письму.
Давно? Я постоянно так всё отправляю.
Действительно, вы правы. Как-то нелогично у них запреты устроены. В правилах написано «запрещена пересылка исполняемых файлов, ..., архивов с файлами, которые защищены паролем, ...». Прикрепление исполняемых файлов (даже в архиве) реально запрещено, а архивов с паролем — пожалуйста.
Заблокировав передачу зашифрованных архивов можно чуть-чуть выстрелить себе в ногу.
Гуглопочтой пользуются и корпоративные клиенты, либо контрагенты корпоративных клиентов.
Часто по требованиям IT безопасности передача конфиденциальной информации по email допустима только в зашифрованных архивах (пароли от архивов передаются по отдельному независимому каналу). Не можешь передать/получить зашифрованный архив — твои проблемы.
Гуглопочтой пользуются и корпоративные клиенты, либо контрагенты корпоративных клиентов.
Часто по требованиям IT безопасности передача конфиденциальной информации по email допустима только в зашифрованных архивах (пароли от архивов передаются по отдельному независимому каналу). Не можешь передать/получить зашифрованный архив — твои проблемы.
Прикрепил, отправил, получил, проверил. Всё ок. ЧЯДНТ?
Можно прикрепить даже просто кусок рандомного бинарного файла, который на самом деле может быть архивом, в котором запаролен даже список файлов и поломана сигнатура.
Я даже не могу подсказать почтового провайдера, который бы рискнул сделать у себя подобное ограничение.
Я даже не могу подсказать почтового провайдера, который бы рискнул сделать у себя подобное ограничение.
EncFS
Собственный контент скорей всего не пострадает, если он не доступен большому кругу лиц, просто сделают его видимым только для вас, что предотвратит распространение. Пока они ставят такие цели — не поубивать копии у пользователей, а предотвратить широкое распространение. А если не будет распространения то скорей всего не будет и проблем у правообладателей, ибо контролировать и учесть оффлайн-копирование они пока не в состоянии, да и не нужно им — какая там скорость передачи данных флешками между пользователей? Мелочь…
Как вариант можно к файлу дописать один байт и у него будет другой хеш. Можно в случайном месте поменять бит и хеш также поменяется. В случае с mp3 файлами также можно чуть изменить теги и опять же будет другой хеш.
Это только если хэш один единственный на весь файл. Если хэши считаются для каждого куска скажем по 1 Мб длинной (как в торрент-файла или в той же IPFS которую тут упоминали, где дробление идет на 256 КБ блоки), то для опознания файла достаточно совпадения хэша всего одного такого куска.
Случайное совпадение хэшей даже у небольших кусков стремится к нулю, поэтому любое такое совпадение если не признак, того что это замаскированные файл, то как минимум файл с заимствованиями из закопирайченного файла.
Чтобы от такого маскироваться нужно все содержимое файла изменить — например перекодировать другим кодеком или случайного мусора более-менее равномерно по всему файлу накидать, если структура позволяет это сделать не испортив сам контент.
Случайное совпадение хэшей даже у небольших кусков стремится к нулю, поэтому любое такое совпадение если не признак, того что это замаскированные файл, то как минимум файл с заимствованиями из закопирайченного файла.
Чтобы от такого маскироваться нужно все содержимое файла изменить — например перекодировать другим кодеком или случайного мусора более-менее равномерно по всему файлу накидать, если структура позволяет это сделать не испортив сам контент.
Интересно, сколько у них всего файлов на серверах располагается? А то есть подозрение, что на таких громадных объемах стоит ожидать коллизий даже от самых надежных хэш-функций, притом множество
НЛО прилетело и опубликовало эту надпись здесь
Если пойдет тенденция менять содержимое файлов перед заливкой, то скоро не останется ни одного повторяющегося файла на серверах гугла, прощай дедупликация.
С одной стороны, SHA-512 пока вроде не имеет найденых коллизий даже с учетом парадокса дней рождения. С другой стороны — это гугл, количество файлов у них на серверах должно быть заоблачным. Потому и спрашиваю, есть ли какая информация об этом
НЛО прилетело и опубликовало эту надпись здесь
Вы мне напомнили реакцию гиков в одной старенькой статье.
Хэш-функции не идеальны, сотни миллионов пользователей теоретически вполне способны сгенерировать достаточное число файлов, чтобы появились коллизии. Но это не точно :)
Хэш-функции не идеальны, сотни миллионов пользователей теоретически вполне способны сгенерировать достаточное число файлов, чтобы появились коллизии. Но это не точно :)
Checking MD5… pirated!
Checking SHA1… pirated!
Checking SHA256… pirated!
Ur pozt pirated movi! Собственно говоря — одновременная коллизия нескольких хеш-функций, причём одинаковая чуется мне, что вероятность этого будет около 10^(-999)
Checking SHA1… pirated!
Checking SHA256… pirated!
Ur pozt pirated movi! Собственно говоря — одновременная коллизия нескольких хеш-функций, причём одинаковая чуется мне, что вероятность этого будет около 10^(-999)
Грустная тенденция.
Owncloud, Seafile, и.т.д. — ИМХО, лучшее решение.
У таких решений есть проблемы с надежностью. А городить географически разнесенное дублирование — уже дорого для домашнего пользователя.
Я бы предпочел систему типа торрентов. Сдавать свое место, получать за это рейтинг, тратить рейтинг на место на чужих жестких дисках (к примеру, сдавать свои 200 гб в обмен на 2 дублирующихся тома по 100 гб каждый у разных пользователей, или на 4 тома по 50 гб).
Безусловно, у всего есть своя цена. Но я убеждён, что хранение и сохранение информации — задача заинтересованного лица. Если не хотите решать эту задачу сами, тогда, увы, другие её решат за вас на своих условиях.
НЛО прилетело и опубликовало эту надпись здесь
А оно уже в реальности работает?
А то аналогичный проект (FileCoin, базирующийся на IPFS) уже превратился в бесконечный долгострой, уже 3й год, «ждите, скоро будет»
А то аналогичный проект (FileCoin, базирующийся на IPFS) уже превратился в бесконечный долгострой, уже 3й год, «ждите, скоро будет»
НЛО прилетело и опубликовало эту надпись здесь
Эх давно было, надолго с ГТ выпал.
За прошедшее время плотно ознакомился и со Storj и SiaCoin. Как оказалось проекты действительно уже вполне работают и масштабы их использования постепенно растут.
Теперь среди прочего на домашнем сервере и нода Storj постоянно работает (несколько месяцев и Sia была).
Предложение действительно все еще многократно превышает спрос, но за несколько месяцев на моей около 30 Гб чьих-то хранимых данных все-таки набралось.
Деньги с этого совсем небольшие капают (порядка 2$ / месяц сейчас получается, причем основная часть это фиксированная выплата в 1.5$, которая начисляется просто за сам факт поддержания ноды онлайн, а не за хранимые данные), так что специально под это дело сервер поднимать смысла не имеет.
А вот если сервер уже и так в любом случае круглосуточно работает (для других целей), то почему бы и не выделить часть места на диске и оперативки под работу службы.
За прошедшее время плотно ознакомился и со Storj и SiaCoin. Как оказалось проекты действительно уже вполне работают и масштабы их использования постепенно растут.
Теперь среди прочего на домашнем сервере и нода Storj постоянно работает (несколько месяцев и Sia была).
Предложение действительно все еще многократно превышает спрос, но за несколько месяцев на моей около 30 Гб чьих-то хранимых данных все-таки набралось.
Деньги с этого совсем небольшие капают (порядка 2$ / месяц сейчас получается, причем основная часть это фиксированная выплата в 1.5$, которая начисляется просто за сам факт поддержания ноды онлайн, а не за хранимые данные), так что специально под это дело сервер поднимать смысла не имеет.
А вот если сервер уже и так в любом случае круглосуточно работает (для других целей), то почему бы и не выделить часть места на диске и оперативки под работу службы.
NextCloud все же
Own все, продался
Own все, продался
Content-ID на Youtube — отстой десятой воды ржавого источника загрязнённой химикатами реки! Сколько уже раз наше образовательное учреждение размещало видеороликов, в которых звучит гимн России (sic!), столько же раз и получало уведомление, что музыка нарушает права какой-то конторы и ди-джея, впихнувшего гимн в своё "творение". Приходится каждый раз отписываться, что присвоение общественного достояния — уголовное преступление, и каждый раз получать ответ, что жалоба снята.
И нет никаких гарантий, что «антивирусы» и тот же Windows этим не занимаются/будут заниматься, выполняя заказ правительства или кто больше заплатит. Это я под впечатлением системы телеметрии десятого виндовоза.
AVP в своё время тихо грохал кейгены и патчи, от чего был вой в ru.avp и они так же тихо откатили. Давно это было.
Windows Defender у меня пожирал эксплойты для получения root-прав в Android. Хотя казалось бы, какую опасность несёт ELF-бинарник под архитектуру ARM на Windows-системе.
Ну у них же тоже linux в 10 встроен. Да и под ARM могут тоже.
> Обычно хэшем файла или его хэш-суммой называют уникальный идентификатор файла, который генерируется при помощи специального ПО.
Хеш-сумма не является уникальным идентификатором файла.
Хеш-сумма не является уникальным идентификатором файла.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Google Drive добавил сканирование «пиратского» контента по хэшам файлов