owncloud/nextcloud не умеют end-to-end между двумя незарегистрированными пользователями (и не уверен что уже могут хотя бы между двумя разыми пользователями), к тому же очень тяжеловесны.
Суть подобных сервисов — простота и доступность в сочетании с безопасностью — не нужно ничего ставить, регистрироваться etc, можно использовать любой браузер (с js) в любой системе в любой момент.
На первый вопрос ответить легко — это экономит не 10 секунд, а минимум 10 минут времени, потому что (для обычного, не продвинутого пользователя):
— не нужно искать и ставить приложение для шифрования (получателю тоже);
— не нужно его использовать;
— не нужно искать сервис который позволяет надежно обмениваться файлами «без регистрации и смс».
Те, кто этим занят постоянно и круг получателей постоянный, могут конечно использовать заранее согласованные способы и сервисы, но вот так «вдруг» — сервис удобнее, не говоря уже о том что далеко не все достаточно продвинуты чтобы правильно выбрать нужные способы.
Что касается второго вопроса — поскольку шифрование end-to-end, и это легко проверяется на стороне клиента, то «посмотреть файлы» не получится. Компания тратит «много денег» (на самом деле не очень) по как минимум одной простой причине — это формирует положительный образ компании, о ней говорят, она становится более известной.
При любом раскладе всё упирается в вопрос доверия миксеру, к тому же это (в какой-то мере) централизация децентрализованного (сеть уже не может подтвердить платеж конкретному адресату). Все основные достоинства блокчейна фактически нивелируются этой схемой, но зато супер-пупер анонимно.
Если в схеме будут задействованы несколько миксеров (и они принадлежат разным владельцам), то вероятность мошенничества резко возрастает (у мошенников обычно не бывает проблем чуть-чуть заплатить системе чтобы обобрать её клиентов), не говоря уже о том что доверять сразу пачке разных сервисов с разными владельцами сложнее чем одному, не говоря уже о том что они должны будут между собой договориться, а если владелец один — то вероятность утечки от их количества не сильно зависит.
Теперь вопрос — кто, вероятней всего, действительно готов будет пойти на соответствующие риски и дополнительные затраты ради анонимности?
И второй вопрос — что помешает соответствующим службам (или просто чрезмерно любопытным) раскрутить свою «честную» сеть миксеров, но бесшумно пользоваться собранными данными?
Если вы пользуетесь стандартными криптоблиотеками (например, openssl)...
А кто определяет «стандартность» библиотек? OpenSSL — это всего лишь одна их многих библиотек, и пусть она ужасно популярна, но все же далеко не единственная.
Как правило, не может, если действия служб были санкционированы и они действовали в рамках закона. Но бывают и (не)приятные исключения, в зависимости от массы переменных.
Впрочем, гражданину в таком случае стоит беспокоиться вовсе не об иске…
Что вас смущает? Наркокартели обычно имеют под контролем вполне легальные структуры, и хотя де-факто «все всё знают», де-юре там не докопаться, а вот для подрядчиков это вполне себе сравнительно безопасный способ получить с картельного пирога, при этом не прячась в джунглях.
Большинству людей этого можно не опасаться, их больше волнует что бы их личные маленькие тайны (пиво, водка, любовники и любовницы, заначки) не стали достоянием гласности. Ну и для бизнесменов — чтобы инфа не попала к кому не нужно, разумеется — поэтому для спецслужб они вообще не интересны.
Что касается истории переписки — то любой адекватный мессенджер с end-to-end эту проблему решает, прочитать её можно только на устройствах участников.
Справделивости ради, смена винта (или любого другого умершего компонента) усилиями провайдера — тоже не всегда оперативно, по крайней мере за стандартную плату. Если нужно оперативно — то это уже совсем другие деньги, зачастую в разы выше чем стандартная, а за них (в пересчёте на годы работы) можно себе позволить cold standby в том же DC.
У меня был случай на serverloft, умерло одновременно оба винта на железном RAID, они 12 часов мучались пытаясь это восстановить, даже не поверили сначала. Бэкап разумеется был, но сам факт…
С другой стороны, многие colocation предлагают remote hands — и если рядом со стойкой/клеткой есть шкафчик с компонентами (от клиента), то это решается за вполне разумные (а не конские) деньги за очень разумное время.
Ваше предложение — это как раз уже упомянутый мной «идеальный мир» (отчасти). Осталось убедить моих клиентов (и большинство других) перейти с CentOS/Ubuntu на ArchLinux, и проблема будет решена — как всё просто, оказывается. А ведь именно из-за них мне приходится держать у себя весь этот зоопарк систем.
Впрочем нет, это тоже не решит все проблемы — не все пакеты в ArchLinux есть, не все есть нужных версий (последняя — не всегда нужная), и не все собраны с нужными опциями или дефолтами. Плюс приходится «вручную» думать что можно а что нельзя обновить чтобы ничего не разрушить (такова иногда цена за самые свежии версии в репах, однако).
К примеру я знаю, что версия 1.2.3 имеет эксплоит. И я, установив 1.2.4 с исправлением этого эксплоита уверен, что моя система защищена.
Это в лучшем случае. А если нужной либы вообще в системе (дистрибутиве) нет? Искать репо где есть и долго думать, доверять ли тому кто её поддерживает? Собирать самому и иметь головную боль по её поддерживания стопятсот лет?
Но всё же, зачем все эти сложности, если «всё в одном каталоге» решает все проблемы без перехода на что-либо? В конце концов, docker создавался для примерно таких же целей, а «всё в одном» это своего рода «docker для бедных» (конечно, чуть менее докер, минус ряд вещей, но всё же идея такая же).
Даже для серверных приложений это иногда очень удобно, в частности, это фишка DotNet Core — «просто скопируй это» — и всё работает.
Попробуйте этот же номер провернуть с чем-то построенном на ruby (например, Discourse) — придётся ставить докер как минимум, чтобы оно гарантированно работало, потому что попытавшись поставить всё вручную вы либо сломаете систему, либо получите неработающее приложение. А ведь как просто было бы просто скачать и распаковать — без бубна и заклинаний.
Так что пожалуйста, создавая какое-либо приложение для масс, подумайте о той части масс которые не хотят сложностей с системой и менеджерами пакетов — это не так уж и сложно, на самом деле, и такое отношение к вопросу тоже имеет право быть.
Хочу подчеркнуть, я не навязываю никому свою точку зрения — я всего лишь хочу чтобы у пользователей был выбор, в зависимости от их целей, задач и личных предпочтений, а не жёстко установленные кем-то извне (разработчиками, мейнтейнерами систем и пакетов) требования где и что должно находится.
А теперь более подробно.
В идеальном мире, если бы существовал только один менеджер пакетов и один репозиторий для всех существующих в мире программ и библиотек, в котором хранились бы как самые актуальные (стабильные) версии так и все предшествующие, если бы при установке я мог выбирать что куда класть (конфигурации, данные, кэш etc) — да, вероятно, я бы с удовольствием им пользовался.
В реальном же мире мы имеем зоопарк дистрибутивов, менеджеров пакетов, репозиториев, причем те кто всё это поддерживает не могут договориться даже об именовании пакетов (lib*-dev в ubuntu/debian, *-devel в centos/fedora), адекватном именовании и расположении конфигурации (postgres/exim в debian/ubuntu и centos/fedora яркие тому примеры), не говоря уже о том что в ряде случаев «официальные» репозитории сильно отстают от жизни по версиям.
Теперь добавим сюда невозможность использования менеджера пакетов обычным пользователем (без рут-прав), невозможность установки приложения только для конкретного пользователя (чтобы ничего не сломалось в самой системе), невозможность поставить нужную версию без риска поломать что-либо из зависимостей. И да, внезапно, даже в однопользовательской системе это актуально.
Стоит также отметить что некоторым из нас приходится иметь дело с несколькими версиями приложения одновременно, которые никак не поставить «стандартными» менеджерами пакетов.
Так что да, для банальных вещей типа sed/bash/mtr/ping/traceroute/gcc/make/etc я воспользуюсь менеджером, но для чего-то отсутствующего в репозиториях (вообще или нужной версии) — уж извините, лучше я всё буду держать в $HOME (в конце концов, это моё личное пространство — поэтому позвольте уж мне решать что туда «пихать»).
Мне также удобно сделать rsync с одной машины на другую (даже если одна debian, другая centos) и быть уверенным что всё осталось на своих местах и работает (в $HOME), чем плясать с бубном для синхронизации пакетов на обеих.
Не менее удобно сделать бэкап $HOME (или его части), и тоже быть уверенным в том что этот бэкап содержит всё что нужно чтобы начать работу после его восстановления, не заботясь об операционной системе (в разумных пределах), сюда входит также возможность полной переустановки системы (или её апгрейда) без особого риска что-то сломать в рабочей среде.
Когда-то очень давно, когда дисковое пространство было сильно ограничено, а сами накопители были медленными, всё было несколько иначе, но сейчас можно себе позволить не думать о shared libs и прочих анахронизмах, по крайней мере в случаях когда это не цельный проект, зависящий от них.
Надеюсь, я достаточно аргументировал свою позицию?
Было бы интересно узнать, почему вы считаете что выбор — это плохо (при наличии адекватных дефолтов), и особенно почему мой «идеал» может кого-то не устраивать (для них ведь ничего не меняется, если они не делают лишних телодвижений).
Пользователь, как владелец ресурсов, вправе самостоятельно определять где (каталоги), что (данные, код, кэш) и как (файловая система) должно храниться, в то время как для разработчика это всего несколько лишних строк кода.
Это вопрос задач и личных предпочтений, как мне кажется. К примеру, я предпочитаю переносимые приложения (и на Linux и на Windows), где код, библиотеки и все данные (кроме временных и кэшей, которые можно смело сносить, и соответственно, можно использовать $TEMP) находятся в каталоге самого приложения, чтобы простым копирование можно было сохранить или перенести всё, не рыская по куче разных мест с данными, библиотеками и всем остальным, и не зависеть от неожиданных рантаймов.
Вообще любые (не входящие в систему стандартно) приложения которые требуют установки вызывают зубную боль — потому что установка должна быть эквивалентна распаковке архива, со всем чем нужно внутри, не зависящее от системных библиотек (кроме настолько стандартных, что они с гарантий 101% везде есть и совместимы, разумеется). Такой способ установки удобен ещё и тем что достаточно просто удалить каталог — и вуаля, приложение снесено, без бубна для поиска его остатков в системе (/usr/lib/*, /usr/share/*, /var/lib/* etc, причем не факт что использованные каталоги называются как само приложение).
Что касается yarn/npm etc (о которых говорится в статье) — мне кажется как раз логично что всё что имеет отношение к проекту хранится в его директории, а не хз где по другим «стандартным» местам (опять-таки, кроме временных данных и кэша) — мне не нравится наличие $HOME/.npm, к примеру, я не хочу его общий для всех проектов (да, у меня резиновый диск, могу себе позволить).
Разумеется, у других могут быть другие предпочтения или требования, так что в идеале, каждое приложение должно давать пользователю выбор — использовать установочный каталог как относительный корень для всего (это важно — без абсолютных путей) или «стандартные места», определенные в переменных среды.
Логично всё же иметь какие-то разумные ограничения по длине вводимых полей, а то найдётся шутник который скриптом туда несколько мегабайт загонит при регистрации или авторизации.
Это зависит от того, что собой представляет устройство мгновенной связи. Если это, к примеру, куб размером 1x1x1 м, который весит одну тонну и требует ИП мощностью 10 кВт для работы, то как бы более практично поставить по одному кубу на много систем с обычной связью, и вот нам снова нужны таблицы маршрутизации. Поскольку вряд-ли одно устройство имеет неограниченную полосу пропускания, и нам ещё нужно резервирование — вот и появляется несколько кубов в одной системе, со всеми вытекающими.
Кто ему запрещает брать заказы через другие службы? Не говоря уже о более простом случае, если он собирается закончить работу в 11, или у него другое мероприятие в 11.
Это не такой простой вопрос. Если водитель не знает куда ехать, это не позволяет ему планировать. К примеру, он уже имеет заказ на 11, поступает вызов в 10 на короткую поездку, минут 30 со всеми пробками в обе стороны — всё ок, можно взять. А иначе — он подъезжает и узнает что ехать час в одну сторону, итог — зря потраченное время и отказ от заказа, недовольны и клиент и водитель.
Неудобность же заказа компенсируется ценой (если он настолько неудобен), но как правило, пока стоимость поездки выше затрат, то всегда найдётся исполнитель которому выгоднее взять заказ чем ждать золотого клиента, клиент разве что дольше подождёт (или же предложит больше).
Верховный суд штата Нью-Йорк вынес постановление, согласно которому мерчанты в праве взимать с покупателей комиссии на транзакции.
Говоря честно и откровенно, мерчанты всегда имели такую возможность, закладывая комиссии в цену товара — никакие запреты им не мешали (и не могли помешать) это делать.
Суть подобных сервисов — простота и доступность в сочетании с безопасностью — не нужно ничего ставить, регистрироваться etc, можно использовать любой браузер (с js) в любой системе в любой момент.
— не нужно искать и ставить приложение для шифрования (получателю тоже);
— не нужно его использовать;
— не нужно искать сервис который позволяет надежно обмениваться файлами «без регистрации и смс».
Те, кто этим занят постоянно и круг получателей постоянный, могут конечно использовать заранее согласованные способы и сервисы, но вот так «вдруг» — сервис удобнее, не говоря уже о том что далеко не все достаточно продвинуты чтобы правильно выбрать нужные способы.
Что касается второго вопроса — поскольку шифрование end-to-end, и это легко проверяется на стороне клиента, то «посмотреть файлы» не получится. Компания тратит «много денег» (на самом деле не очень) по как минимум одной простой причине — это формирует положительный образ компании, о ней говорят, она становится более известной.
Если в схеме будут задействованы несколько миксеров (и они принадлежат разным владельцам), то вероятность мошенничества резко возрастает (у мошенников обычно не бывает проблем чуть-чуть заплатить системе чтобы обобрать её клиентов), не говоря уже о том что доверять сразу пачке разных сервисов с разными владельцами сложнее чем одному, не говоря уже о том что они должны будут между собой договориться, а если владелец один — то вероятность утечки от их количества не сильно зависит.
Теперь вопрос — кто, вероятней всего, действительно готов будет пойти на соответствующие риски и дополнительные затраты ради анонимности?
И второй вопрос — что помешает соответствующим службам (или просто чрезмерно любопытным) раскрутить свою «честную» сеть миксеров, но бесшумно пользоваться собранными данными?
А кто определяет «стандартность» библиотек? OpenSSL — это всего лишь одна их многих библиотек, и пусть она ужасно популярна, но все же далеко не единственная.
Впрочем, гражданину в таком случае стоит беспокоиться вовсе не об иске…
Что касается истории переписки — то любой адекватный мессенджер с end-to-end эту проблему решает, прочитать её можно только на устройствах участников.
Тогда уж и от телефона стоит отказаться, чего уж там…
У меня был случай на serverloft, умерло одновременно оба винта на железном RAID, они 12 часов мучались пытаясь это восстановить, даже не поверили сначала. Бэкап разумеется был, но сам факт…
С другой стороны, многие colocation предлагают remote hands — и если рядом со стойкой/клеткой есть шкафчик с компонентами (от клиента), то это решается за вполне разумные (а не конские) деньги за очень разумное время.
К сожалению, не все домены столько стоят. Некоторые (другие tld) стоят и несколько сотен в год (причем совсем даже не премиум).
Впрочем нет, это тоже не решит все проблемы — не все пакеты в ArchLinux есть, не все есть нужных версий (последняя — не всегда нужная), и не все собраны с нужными опциями или дефолтами. Плюс приходится «вручную» думать что можно а что нельзя обновить чтобы ничего не разрушить (такова иногда цена за самые свежии версии в репах, однако).
Это в лучшем случае. А если нужной либы вообще в системе (дистрибутиве) нет? Искать репо где есть и долго думать, доверять ли тому кто её поддерживает? Собирать самому и иметь головную боль по её поддерживания стопятсот лет?
Но всё же, зачем все эти сложности, если «всё в одном каталоге» решает все проблемы без перехода на что-либо? В конце концов, docker создавался для примерно таких же целей, а «всё в одном» это своего рода «docker для бедных» (конечно, чуть менее докер, минус ряд вещей, но всё же идея такая же).
Даже для серверных приложений это иногда очень удобно, в частности, это фишка DotNet Core — «просто скопируй это» — и всё работает.
Попробуйте этот же номер провернуть с чем-то построенном на ruby (например, Discourse) — придётся ставить докер как минимум, чтобы оно гарантированно работало, потому что попытавшись поставить всё вручную вы либо сломаете систему, либо получите неработающее приложение. А ведь как просто было бы просто скачать и распаковать — без бубна и заклинаний.
Так что пожалуйста, создавая какое-либо приложение для масс, подумайте о той части масс которые не хотят сложностей с системой и менеджерами пакетов — это не так уж и сложно, на самом деле, и такое отношение к вопросу тоже имеет право быть.
А теперь более подробно.
В идеальном мире, если бы существовал только один менеджер пакетов и один репозиторий для всех существующих в мире программ и библиотек, в котором хранились бы как самые актуальные (стабильные) версии так и все предшествующие, если бы при установке я мог выбирать что куда класть (конфигурации, данные, кэш etc) — да, вероятно, я бы с удовольствием им пользовался.
В реальном же мире мы имеем зоопарк дистрибутивов, менеджеров пакетов, репозиториев, причем те кто всё это поддерживает не могут договориться даже об именовании пакетов (lib*-dev в ubuntu/debian, *-devel в centos/fedora), адекватном именовании и расположении конфигурации (postgres/exim в debian/ubuntu и centos/fedora яркие тому примеры), не говоря уже о том что в ряде случаев «официальные» репозитории сильно отстают от жизни по версиям.
Теперь добавим сюда невозможность использования менеджера пакетов обычным пользователем (без рут-прав), невозможность установки приложения только для конкретного пользователя (чтобы ничего не сломалось в самой системе), невозможность поставить нужную версию без риска поломать что-либо из зависимостей. И да, внезапно, даже в однопользовательской системе это актуально.
Стоит также отметить что некоторым из нас приходится иметь дело с несколькими версиями приложения одновременно, которые никак не поставить «стандартными» менеджерами пакетов.
Так что да, для банальных вещей типа sed/bash/mtr/ping/traceroute/gcc/make/etc я воспользуюсь менеджером, но для чего-то отсутствующего в репозиториях (вообще или нужной версии) — уж извините, лучше я всё буду держать в $HOME (в конце концов, это моё личное пространство — поэтому позвольте уж мне решать что туда «пихать»).
Мне также удобно сделать rsync с одной машины на другую (даже если одна debian, другая centos) и быть уверенным что всё осталось на своих местах и работает (в $HOME), чем плясать с бубном для синхронизации пакетов на обеих.
Не менее удобно сделать бэкап $HOME (или его части), и тоже быть уверенным в том что этот бэкап содержит всё что нужно чтобы начать работу после его восстановления, не заботясь об операционной системе (в разумных пределах), сюда входит также возможность полной переустановки системы (или её апгрейда) без особого риска что-то сломать в рабочей среде.
Когда-то очень давно, когда дисковое пространство было сильно ограничено, а сами накопители были медленными, всё было несколько иначе, но сейчас можно себе позволить не думать о shared libs и прочих анахронизмах, по крайней мере в случаях когда это не цельный проект, зависящий от них.
Надеюсь, я достаточно аргументировал свою позицию?
Пользователь, как владелец ресурсов, вправе самостоятельно определять где (каталоги), что (данные, код, кэш) и как (файловая система) должно храниться, в то время как для разработчика это всего несколько лишних строк кода.
Вообще любые (не входящие в систему стандартно) приложения которые требуют установки вызывают зубную боль — потому что установка должна быть эквивалентна распаковке архива, со всем чем нужно внутри, не зависящее от системных библиотек (кроме настолько стандартных, что они с гарантий 101% везде есть и совместимы, разумеется). Такой способ установки удобен ещё и тем что достаточно просто удалить каталог — и вуаля, приложение снесено, без бубна для поиска его остатков в системе (/usr/lib/*, /usr/share/*, /var/lib/* etc, причем не факт что использованные каталоги называются как само приложение).
Что касается yarn/npm etc (о которых говорится в статье) — мне кажется как раз логично что всё что имеет отношение к проекту хранится в его директории, а не хз где по другим «стандартным» местам (опять-таки, кроме временных данных и кэша) — мне не нравится наличие $HOME/.npm, к примеру, я не хочу его общий для всех проектов (да, у меня резиновый диск, могу себе позволить).
Разумеется, у других могут быть другие предпочтения или требования, так что в идеале, каждое приложение должно давать пользователю выбор — использовать установочный каталог как относительный корень для всего (это важно — без абсолютных путей) или «стандартные места», определенные в переменных среды.
Неудобность же заказа компенсируется ценой (если он настолько неудобен), но как правило, пока стоимость поездки выше затрат, то всегда найдётся исполнитель которому выгоднее взять заказ чем ждать золотого клиента, клиент разве что дольше подождёт (или же предложит больше).
Говоря честно и откровенно, мерчанты всегда имели такую возможность, закладывая комиссии в цену товара — никакие запреты им не мешали (и не могли помешать) это делать.