Вряд ли.

Интересно, никто не пробовал написать аналог *cloud, но чтобы серверная часть была написана на Си или хотя бы крестах? (Ну чтобы жрало мало, зависимостей минимум и работало на бюджетной VPSке?) Да-да, я понимаю, это существенно увеличивает трудоёмкость по сравнению с PHP — но вдруг нашлись джедаи?

У PHP не так и много зависимостей. Мне когда-то удавалось запустить php-сайты на роутере даже через thttpd с помощью chmod +x и вписывания #!/usr/bin/php-cgi в первую строку .php файла.

Киллер-фича nextcloud на PHP в данном случае — подключение внешних модулей. Сделать https://apps.nextcloud.com/ на сях нереально.

Интересно. А вы как запускали? Через preview:generate-all?

Вообще говоря судя по описанию сие чудо приводится в движение по crone или

systemctl enable nextcloud-preview.timer

и работает только во время простоя системы. При этом предварительно предлагают запустить 1 раз

occ preview:generate-all -vvv

Зачем на серваке WebAsm?

И я не знаю зачем. Вы это зачем придумали?

Приложение пишется на Rust, например, и то что может исполняется у клиента в виде WebAsm, а на сервере native.

Внезапно, в современных браузерах есть встроенные средства синхронизации закладок. Вот я и пытаюсь узнать чем они не устраивают? Зачем тут owncloud/nextcloud?

Вы правда совсем не понимаете что говорите?

Для справки То что Вы говорите работает исключительно через сторонний сервис. Он например крутится на Mozilla или еще где. Ваши данные уходят туда. И оттда синхронизируются на другой браузер.

NC выступает в роли «того» сервера. Что тут может быть непонятного???

Вы либо прекращайте троллить или пить. Или и то и другое.

То что Вы говорите работает исключительно через сторонний сервис. Он например крутится на Mozilla или еще где. Ваши данные уходят туда. И оттда синхронизируются на другой браузер.

NC выступает в роли «того» сервера. Что тут может быть непонятного???

Блин. Я уже не знаю как иначе это сформулировать...

Зачем нужен NC/OC для синхронизации закладок, если в браузере уже есть встроенные средства синхронизации, пусть через тот же сервер мозиллы? Чем NC лучше «того сервера»?

Зачем тратить время на прикручивание и настройку NC? Почему не взять встроенный в браузере механизм? Чем он не устраивает?

У PHP не так и много зависимостей.

А какая разница сколько у него зависимостей? У PHP много тормозов. По мимо того организация NC подразумевает дублирование функции файловой системы с помощью SQL.

А все потому что Linux до сих пор не удосужился созданием нормальной виртульной базы пользователей и виртуальным домашним каталогом для одного конкретного сервиса. Заставлять людей ставить LDAP это убить пользовательскую базу. Оно по хорошему должно работать автоматически ровно как с процессами. Но нет.

Ведь по сути NC это управление пользователями и их данными и предоставление сервиса через интернет.

Чем NC лучше «того сервера»?

Именно тем, что он под «моим» контролем. Или Вы вчера родились и не в курсе как сливаются данные пользователей направо и налево?

На свете как ни странно не все строчат в твиттер и не все без ума о социальных сетей и не все хотят сливать инфо первому попавшемуся дяде. В противном случае Dropbox или другой Cloud решает все задачи.

Т.е. если Вы хотите быть последовательным Вы должны ставить под сомнение само существование NC. Есть же Dropbox и его хватит всем...

Как только появляется смысл в NC тут же появляется смысл в его приложениях.

> Чем NC лучше «того сервера»?

Именно тем, что он под «моим» контролем. Или Вы вчера родились и не в курсе как сливаются данные пользователей направо и налево?

Эх... Ещё раз.

Мы говорим о конкретной задаче — синхронизация закладок. Чтобы с «моего» сервера не слили все данные, его надо грамотно настроить, регулярно следить за безопасностью, обновлять и всё такое. Это сложно и отнимает много времени.

А в том же firefox sync всё зашифровано так, что даже взломав сервер, скачав базу и перехвав весь траффик, не достать ни закладки, ни пароли. И это работает из коробки, без посторонних приложений.

Вот и вопрос: зачем тратить силы и время на настройку и поддержку NC? Почему не использовать тот же встроенный firefox sync, тем более что там закладки в большей безопасности?

А все потому что Linux до сих пор не удосужился созданием нормальной виртульной базы пользователей и виртуальным домашним каталогом для одного конкретного сервиса.

Базу пользователей можно хранить хоть в текстовом файле, хоть в PAM, хоть в LDAP/AD. Все зависит от приложения. Если софт linux-only, то PAM логичное решение. Если нужна кроссплатформенность, то либо своя бд с пользователями либо LDAP/AD

Заставлять людей ставить LDAP это убить пользовательскую базу.

Зачем, сабж хорошо работает и без LDAP.

По мимо того организация NC подразумевает дублирование функции файловой системы с помощью SQL.

NC это кросплатформенное решение, и теоретически может работать на win системах, где PAM и функции файловой системы несколько ограничены.

Вот и вопрос: зачем тратить силы и время на настройку и поддержку NC

«Эх... Ещё раз.»

Когда Вы делаете что-то сам, то ответственность тоже лежит только на Вас. Когда кто-то это делает «дядя», то у вас нет никакого влияния и постоянно появляющиеся новости, что внешние сервисы взламывают не дает никакой уверенности.

Включите голову! Вы говорите, что у «них» все зашифровано и вообще супер. Скажите в Facebook кто работает? Там что люди специально пишут кривой софт? Наверно нет. Только что взломали Quora - там что?

Если бы Вы у них спросили ДО взлома они бы тоже сказали, что все надежно сделано. Факты говорят о другом.

А теперь не выключая головы ответьте на вопрос - что будут ломать сайт с миллиардом пользователей и сайт с 10тью?

Я согласен только, что настройка веб сервера это очень непростое дело. Но часто мотивация перевешивает сложности. Тем более, что решение комплексное и адресует не только задачу синхронизации закладок. Очень часто данные стоят дороже, чем доверие сторонним организациям.

Причем я ни слова не сказал про юридическую составляющую вопроса! Я уверен, что 99% даже местных читателей не знает элементарного факта, что данные, которые храняться на сервере в США более 6 месяцев попадают под юрисдикцию штатов и их владелец где бы он не был может быть привлечен к ответственности по законам США, даже если он никогда не был в США и не имеет там никакого бизнеса. Это же касается почтовых серверов... Догадываетесь на что я намекаю...

Базу пользователей можно хранить хоть в текстовом файле, хоть в PAM

Это в корне не верно! На сегодня единственным и очень кривым по реализации решением является протокол LDAP. Других решений просто нет!

Хранить действительно можно хоть в кружке, как только у нее есть интерфейс LDAP.

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

Если Вы посмотрите на огромное кол-во программ типа клиент-сервер, то только LDAP имеет поддержку почти везде. NC имеет такую поддержку на ряду с SQL базой.

Представьте себе картину. У меня всего 10 пользователей! И у меня работает порядка 10 сервисов. Мы получаем 100 учетных записей, каждая из которых имеет разные пароли для одного пользователя. С этим работать невозможно! Это мрак как для пользователей так и для админов.

В реальной жизни пользователей существенно больше. Сервисов тоже.

Теперь смотрите в NC при поддержке LDAP каждый пользователь может иметь свои данные на сервере под своим именем. Пользователи могут быть включены в группы и все это работает на базе операционной системы - SQL не нужен совершенно. Но....

я уже писал - заставлять пользователей настраивать LDAP это самоубийство.

Зачем, сабж хорошо работает и без LDAP.

Он работает криво и дико медленно, а мог бы летать. Вы просто не представляете как оно устроено внутри. За такое руки надо ломать, но... пользователь не только дурак, но и всегда прав. - «сабж хорошо работает и без LDAP» - вот так он думает...

NC это кросплатформенное решение, и теоретически может работать на win системах, где PAM и функции файловой системы несколько ограничены

Да и на КАМАЗе можно ездить в отпуск. Почему нет. Люди и не такое делают...

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

Есть мнение

Не говори так. Это искуственное усиление значимости слов. Если бы не это, то ты был бы на 95% прав (на все 100% нельзя быть правым, ИМХО).

Ставил недавно ради фана на Keenetic Giga (который уже не zyxel) c 256 RAM, с ngnix удалось запустить, но ползал ОЧЕНЬ медленно.

Это искуственное усиление значимости слов.

Я думал, наоборот. :) Что ты собственно и подтвердил:

Если бы не это, то ты был бы на 95% прав

Кроме того, это открытое ёрничание: «есть мнение» имеется в виду у меня. Что впрочем не отменяет того факта, что я говорил серьёзно.

Разрешите просуммировать вышесказанное.

LDAP страх и ужас, но ничего другого нет. NC быстро работает только с LDAP. SQL не нужен, для всего есть LDAP и ФС. Так?

Не знаю через какие костыли сделана работа с пользователями в NC через SQL, но мое мнение LDAP в целом медленнее работает с данными, чем SQL. Те же интернет магазины вполне себе держат пользователей в SQL и хорошо себя чувствуют. А для централизации бесспорно LDAP удобнее. Не все функции NC для работы с файлами можно реализовать через ФС. Версионирование, например не все ФС поддерживают, а привязываться к одной фс, так себе идея.

LDAP страх и ужас, но ничего другого нет. NC быстро работает только с LDAP. SQL не нужен, для всего есть LDAP и ФС. Так?

Правильная версия: LDAP это единственное на сегодня работающее решение. Оно очень далеко от идеальности особенно в плане настройки. Это похоже на квест как в свое время была настройка FIDO mailer. Но при этом LDAP и системы достаточно, чтобы работать с файлами быстро.

NC использует LDAP исключительно для авторизации и не использует его для доступа к файлам! Вместо этого в любом случае используется SQL - отсюда и дикие тормоза, так как база читается при каждом чихе.

Делать чистое LDAP решение Nextcloud не хочет - очевидно потому как отваляться все пользователи. Автоматической универсальной настройки LDAP для всех нет!

Т.е. «NC быстро работает только с LDAP» - это фантазии. Не существует в природе такого NC, который бы действительно работал с LDAP.

но мое мнение LDAP в целом медленнее работает с данными, чем SQL

Это не соответствует действительности! Сама фраза не имеет смысла от слова вообще. Я специально писал, что LDAP это протокол = язык общения. В роли backend у LDAP может выступать база SQL. В стандартном варианте в роли backend выступает LMDB, но можно хоть текстовые файлы использовать.

В случае с NC база SQL работает поверх файловой системы, от которой никуда не уйти. Т.е. она все равно есть и все равно используется. Только вместо адекватного режима она работает в однопользовательском режиме, а кому какой файл принадлежит уже берет на себя SQL. Это называется дублирование функциональности. Оно всегда принципиально медленней, чем вариант без дубляжа.

LDAP же тесно интегирован с системой авторизации в Linux. И самодостаточен для работы с FS напрямую. Т.е. пользователь авторизуясь через веб интерфейс может получать свои файлы напрямую и все коллизии разрешает сама файловая система.

Те же интернет магазины вполне себе держат пользователей в SQL и хорошо себя чувствуют

Провайдеры мобильной связи с миллионами абонентов держат своих пользователей в базе LDAP. Погуглите доклад автора ReOpenLDAP! В интернет магазинах кроме 2-4 наиболее известных редко бывает много клиентов и каждый клиент редко постоянно там сидит.

Клиенты операторов мобильной связи очевидно постоянно сидят на связи... Подумайте над этим. У China Mobile если я правильно помню порядка 800млн клиентов...

Версионирование, например не все ФС поддерживают, а привязываться к одной фс, так себе идея.

Если включать голову и выбирать ФС с умом, то особенно выбора не остается. Учитывая доступность данных через инет и заведомо меньшую пропускную способность по сравнению с локальным доступом требование к сохранности данных выходит на первый план. Собственно друго требования и нет. И в таком случае выбор ФС невелик. Для меня он сузился до одной единственной системы.

С другой стороны я спокойно могу жить без версионирования. Т.е. любая система подойдет. А вот с базой будет проблема.

Вместо одной точки отказа мы имеем 2! Казалось бы ФС в порядке данные целы, а вот SQL упала и унесла все данные с собой. В итоге мы получаем такой геморой на восстановление, что хуже и придумать сложно.

Наверно чистое LDAP решение это по сути SAMBA или Active Directory как это называется у MS. Другое дело оно без Web interface и без плюшек которые последний предлагает.

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

Предоставить это - все равно что разрешить мобильным телефонам общаться на прямую минуя оператора. Бабло утекает мимо.

Справедливости ради, при синхронизации закладок в Chromium вам не нужно полагаться на «стороннюю организацию» (Google). Закладки шифруются на стороне клиента, то есть в браузере, с помощью специального облачного пароля. На сервера гугла закладки приходят уже зашифрованными. Облачный пароль и пароль на гугл-аккаунт это два разных пароля. И гугловцы его не знают.

Думаю, примерно то же самое и в Firefox Sync.

Это совершенно не технический вопрос. Это вопрос юридический и моральный.

Я лично не проверял и скорее всего не буду проверять исходный код продукта. Это и физически невозможно. Новые версии выходят регулярно. Если просто читать исходные коды всего, чем я пользуюсь - жить некогда будет. У меня остается всего одна возможность это верить или нет. С определенных пор доверия ни к G ни к Moz у меня нет. И я не пользуюсь ни тем ни другим. Как ни странно это не мешает жить.

G очень жестко подставляет пользователей с почтой и вообще творит разные очень плохие вещи. Можно прочесть кучу информации на эту тему. Я испытал это сам на своем примере. Лучшего урока на свете не бывает.

Тоже самое касается и Moz. Это зонд, который прикрывается маской приличия. Люди могут врать до тех пор пока их на этом 1 раз не поймают. После этого к ним доверия нет.

Да, кого-то это устраивает. Да большинству плевать на то как к ним относятся. Но каждый имеет право на свое мнение.

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

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

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

Сама фраза не имеет смысла от слова вообще.

Имел в виду стандартную поставку для линукса openldap и lmbd как бэк.

LDAP же тесно интегирован с системой авторизации в Linux.

LDAP же протокол, а реализаций куча, тот же AD сейчас является наиболее пиареным решением. Так что это утверждение равносильно - LDAP тесно интегрирован с авторизацией винды, да и не только с авторизацией. Но настроить авторизацию винды через openldap то ещё удовольствие. Хотя не спорю что авторизацию линукса можно настроить через AD и по поводу тесноты их интеграции у меня есть вопросы.

ReOpenLDAP это если мне не изменяет память дополненный форк под нужды Мегафона, а что у остальных я если честно хз, всегда думал что какой-нибудь oracle.

Вместо одной точки отказа мы имеем 2!

В случае с LDAP точно так же, ФС и сам LDAP.

NC достаточно сильно абстрагирован от железа, ему не важна какая SQL бд и какая файловая система используется, в этом его огромный плюс и одновременно недостаток, компенсируемый мощностью железа. Для ФС сами разработчики советуют использовать nfs которая к железу не привязана, и может располагаться на нескольких серверах. Точно так же может быть настроена работа и с бд, наиболее затратные процедуры могут обслуживаться например redis.

Я ваши рассуждения понял. Но есть пара вопросов.

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

Законы что, не распространяются на хостинг, где крутится ваш Nextcloud? Если лично вами заинтересуются, то почему вы считаете, что Google выдаст ваши данные, а хостер не выдаст?

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

Свою модель монетизации Google и не скрывают. Но торговля закладками и историей браузера пользователей туда не входит. Если вы полагаете, что они могут втихую банчить облачными данными, то опять же, почему этими же данными не может банчить хостер вашего VPS? Только потому, что вы ему платите за обслуживание? Но и у гуглу вы «платите» своими куками, своим просмотром рекламы.

Ясно

​

при синхронизации закладок в Chromium вам не нужно полагаться на «стороннюю организацию» (Google). Закладки шифруются на стороне клиента, то есть в браузере, с помощью специального облачного пароля. На сервера гугла закладки приходят уже зашифрованными. Облачный пароль и пароль на гугл-аккаунт это два разных пароля. И гугловцы его не знают.

Не совсем так.

Во-первых, по-умолчанию хром шифрует только пароли. Закладки и всё остальное хранится в открытом виде. Да и пароли шифруются гуглопаролем. Но в настройках можно включить «Encrypt all synced data» и задать отдельный пароль, тогда закладки тоже шифруются.

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

Наконец, в хроме используется вариация протокола Nigori. В его спецификации есть слабые места, и в реализации в хроме есть мелкие ошибки. Но если их исправить — это сломает совместимость, так что вряд ли кто-то это будет делать.

Думаю, примерно то же самое и в Firefox Sync.

В протоколе файрфокса шифруется всё, шифрование неотключаемое.

Это совершенно не технический вопрос. Это вопрос юридический и моральный.
[...]
С определенных пор доверия ни к G ни к Moz у меня нет.

Это не вопрос доверия, это вопрос логики. Пусть, например, мы выбираем между: синхронизацией через сервера гугла (шифруется так себе, но более-менее), синхронизацией через мозиллу (шифруется хорошо, даже при взломе или юр.запросе данные не достать), и синхронизацией через NC (при взломе или юр.наезде данные сливаются).

В таких условиях какие логические рассуждения заставят выбрать NC? Какие тут у NC плюсы? Ну хоть один?

данные, которые храняться на сервере в США более 6 месяцев попадают под юрисдикцию штатов и их владелец где бы он не был может быть привлечен к ответственности по законам США

Перед тем, как мы начнём это обсуждать, если не трудно, можно ссылку на подтверждающий это закон или разъяснение?

Одноразовые ссылки на скачивание файла умеет создавать?

Первый запуск:

time sudo -u http ./occ preview:generate-all -vvv

real	460m26.331s
user	396m46.560s
sys	22m14.923s

Второй:

time sudo -u http ./occ preview:generate-all -vvv

real	103m39.266s
user	13m27.031s
sys	16m14.679s

В таких условиях какие логические рассуждения заставят выбрать NC? Какие тут у NC плюсы? Ну хоть один?

Вы мне кажется меня совершенно не поняли! NC - это софт. это программный комплекс для решения некой задачи. Сам по себе он не имеет никаких преимуществ с точки зрения безопасности или других качеств. Например тот же G может предоставлять доступ к своему NC серверу. Это ничего не изменит.

Ключевой пункт в чьих руках находится контроль и управление сервером. Програмная реализация не столь важна. Хотя тоже имеет некоторое влияние с точки зрения ошибок и дыр.

Таким образом плюс не один, а их много! Бесконечно много. Мои данные под моим контролем. Можете измерять в байтах.

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

Перед тем, как мы начнём это обсуждать, если не трудно, можно ссылку на подтверждающий это закон или разъяснение?

https://en.wikipedia.org/wiki/Stored_Communications_Act

Можем начинать?

Законы что, не распространяются на хостинг, где крутится ваш Nextcloud? Если лично вами заинтересуются, то почему вы считаете, что Google выдаст ваши данные, а хостер не выдаст?

Поверьте - я сам себя не выдам... :-)

Думаю мы понимаем, что в использовании NC появляется смысл, когда пользователей больше одного. Use case - это небольшая компания. Сотрудники могут находится как в оффисе так и за его пределами. Скорее всего сервер будет находится в оффисе.

Использование некого провайдера мало отличается от хранения данных на Amazon, Google или еще где-то. Я же говорил про полный контроль над сервером.

Свою модель монетизации Google и не скрывают. Но торговля закладками и историей браузера пользователей туда не входит.

Это исключительно наивно. Google знает о Вас все. И человеческая жадность безгранична. Лет 10-15 назад Google был совсем другой компанией. И в его торговлю много чего не входило.

Если вы полагаете, что они могут втихую банчить облачными данными, то опять же, почему этими же данными не может банчить хостер вашего VPS?

Совершенно верно! Вы правильно полагаете. Рад, что Вы все понимаете. Какой отсюда вывод?

Имел в виду стандартную поставку для линукса openldap и lmbd как бэк.

Вы не могли сравнить эти 2 варианта. SQL используется для записи и чтения. LDAP в основном для чтения. Добавление записей через LDAP дороже, чем в SQL. Оптимизация была сделана именно для чтения.

Но настроить авторизацию винды через openldap то ещё удовольствие.

Там и без винды полно гемороя. Об этом я и говорю, что решение кривое. И почему-то никто не делает прямое решение.

ReOpenLDAP это если мне не изменяет память дополненный форк под нужды Мегафона

Согласно автору его улучшения носят универсальный характер. По крайней мере то что выложено в открытый доступ. Опять же понимая, что LDAP это лишь протокол и другая реализация обязана быть совместима, то разница может быть только в schema файлах. А это просто конфигурация под нужды провайдера.

В случае с LDAP точно так же, ФС и сам LDAP.

Нет. У каждого файла в файловой системе есть владелец и группа. Они закодированы UID и GID соответственно. Это обычные числа. LDAP сопостовляет пользовательский login и UID, а также обеспечиавает аутентификацию. При уничтожении или выключении базы информация на сервере остается intact. Базу можно создать с нуля и лишь по одному файлу восстановить информацию о доступе ко всем файлам. Вы читаете UID и делаете пользователя с логином.

В случае SQL через NC владельцем ВСЕХ файлов является один пользователь! Все файлы продублированы в базе! Если файл на диске есть, а записи о нем в базе нет, то его не видно.

Элементарно скопируйте через «cp» любой файл в папку где хранятся файлы NC. Вы его не увидите. Но это безопасно, потом можно удалить. Хуже если Вы его измените содержание и размер.

Т.е. вся! функциональность файловой системы на 100% дублируется через базу.

Одноразовые ссылки на скачивание файла умеет создавать?

Умеет ссылки, которые живут некоторое время. Не уверен, что одноразовость это осмысленное желание. Например связь пропала и файл недокачался. И все привет семье. В общем глупо это.

О да, Nextcloud — хорошая штука. Альтернатив для личного облака даже на горизонте пока нет.

Seafile тоже ничего.

Вы не могли сравнить эти 2 варианта. SQL используется для записи и чтения. LDAP в основном для чтения.

Почему же, вполне можно сравнить. На позапрошлом проекте добавление нескольких устройств в LDAP с записью mac адресов и ip происходило не мгновенно. Сопоставимое действие в sql происходит мгновенно. Но справедливости ради, на том проекте ldap настраивал не я.

При уничтожении или выключении базы информация на сервере остается intact. Базу можно создать с нуля и лишь по одному файлу восстановить информацию о доступе ко всем файлам.

При уничтожении базы доступ к своим (это ещё вопрос, если uid другой, то файлы не ваши) файлам вы получаете, но теряете доступ к файлам расширенным персонально, а не через группы, нет доступа по ссылке, о федерализации можно забыть. Т.е. решение с ldap не приносит никаких ощутимых плюсов, а минусы те же что и с sql. Это необходимость хранить доп свойства файлов в LDAP т.к. в ФС для них нет места. Бекап БД решение на LDAP не отменяет.

Элементарно скопируйте через «cp» любой файл в папку где хранятся файлы NC. Вы его не увидите.

Есть какой то плагин с inotify для обновления информации о файле. Но я его не тестил.

Т.е. вся! функциональность файловой системы на 100% дублируется через базу.

Не вся, информациия о физическом расположении файла в базу не попадает. Ну это так придирки.

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

Сейчас, храня файлы на сервере, я вынужден доверять:

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

А с end-to-end encryprion риск взлома остаётся только на конечном устройстве, на нём он всегда есть. Остальное убирается.

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

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

В таком случае NC это не то решение. Иначе каким образом Вы собираетесь хранить фотографии или другие документы с просмотром в Web?

В вашем случае единственный вариант это что-то типа VPN доступ к серверу SAMBA и использование FS с шифрованием данных. Я имею ввиду аналогичное решение - не обязательно точно такое.

Мне лично кажется, что Ваш подход сломан на уровне идеи.

Если Вам нужная такая защита куда проще вообще не хранить данные на сервере. Запишите их на флешку и носите с собой. Если же флешки не хватает, то и сервера Вам не хватит, если говорить о чужом сервере. Сервер с доступом в инет и диском 2+Tb будет Вам стоить так дорого, что дешевле снова этот диск носить в кармане.

NC это решение, которое подразумевает именно предоставление доступа к данным многим людям - sharing. Т.е. заведомо не Вы один являетесь владельцем и пользователем, а например группа из 10+ человек. В таком случае хранение диска в кармане не работает. Будет постоянный волейбол диском. Но в таком случае и end-to-end encryprion тоже не работает!

Работает только шифрование типа PGP. Открытый-закрытый ключи. Значит у того парня будет ваш открытый ключ. Значит к нему можно приехать и заставить его предоставить. И соотвественно получить доступ к данным всех чьи ключи у него есть.

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

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

комментарий профессионала... правда зачем так жестко и все сразу? в обычной жизни хватит предоставить соответствующий документ.

Вы мне кажется меня совершенно не поняли!

Да, я вижу, что мы друг друга не понимаем, просто уже не знаю, как иначе объяснить.

Ключевой пункт в чьих руках находится контроль и управление сервером. Програмная реализация не столь важна. Мои данные под моим контролем.

Но в данной-то задаче это не важно! Упоминались два случая — юр.наезд и взлом. Попробую с подробностями...

1. Юр.наезд. Вас арестовали на улице. Ваши сервера конфискованы. С сервера гугла/мозиллы данные бы фиг достали — нужно решение суда и согласие компании, и данные всё равно зашифрованы. Как помог NC? Никак, наоборот, отдал все ваши данные вместе с вашим сервером.

2. Взлом. Все данные и пароли ушли на сторону, вы этого даже не узнали. Кто опытнее и лучше защитит сервер от взломов — вы, или админы мозиллы/гугла? А если взлом таки состоится, что лучше — чтобы данные были надёжно зашифрованы, или хранились в открытом виде? Как помог NC? Опять никак, наоборот, отдал все ваши данные, и вместо штата опытных админов защищаете его только вы.

Данные под вашим контролем, но что вам это дало? Без NC — никто не получает ваши данные, с NC — ваши данные уходят. Вопрос: зачем тогда NC?

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

данные, которые храняться на сервере в США более 6 месяцев попадают под юрисдикцию штатов и их владелец где бы он не был может быть привлечен к ответственности по законам США

можно ссылку на подтверждающий это закон или разъяснение?

https://en.wikipedia.org/wiki/Stored_Communications_Act

Всё ещё не вижу там подтверждения указанных слов. Можно цитату?

PS: Мне интересно, как определяют «владельца» данных. Кто владелец емейла — отправитель или получатель? А если это было коллективное письмо? Или ответ почтового бота? А если это письмо сантаклаусу? Или, может, владелец — почтовая служба? Или админ виртуальной машины, где оно хранится? Или владелец сервера? Или владелец серверной?

На позапрошлом проекте добавление нескольких устройств в LDAP с записью mac адресов и ip происходило не мгновенно. Сопоставимое действие в sql происходит мгновенно.

Сэр, Вы опять ошибаетесь. LDAP оптимизирован на ЧТЕНИЕ данных, а не постоянное добавление. Из-за специфики и назначения работы LDAP запись и тем более изменение данных происходит редко, а чтение постоянно. Считайте это как read-only database. Не совсем так, но близко.

Если Вам в течении жизни проекта нужно часто и много добавлять данные, то Вы выбрали неверное решение. Если же это происходит только во время наполнения базы, то беспокоиться не о чем.

Для справки: Lightning Memory-Mapped Database Manager (LMDB) is a key-value database, it's memory mapped so it's fast, and also uses filesystem storage so we've persistence. This database has transactions so it's safe to read/write from different threads or process.

Это значит данные первоначально хранятся в памяти! Представить себе, что IP и МАС нельзя туда записать ОЧЕНЬ быстро просто не верится. Вы элементарно чего-то не договариваете. Есть подозрение на bulk-write, когда данных ооочень много и они не помещаются в cache. Если это работает первые 5 мин жизни проекта, то это неважно. Если Вы постоянно так туда что-то пишите, то выбрали неверный инструмент.

При уничтожении базы доступ к своим (это ещё вопрос, если uid другой, то файлы не ваши) файлам вы получаете

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

База по своей природе статична в отлчие от SQL решения. Т.е. backup сделанный условно год назад будет работать. SQL устареет за 5 мин и не будет отображать текущее состояние.

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

С какой стати? Что мешает создать группу DLYA_KOLI и создать link на оригинальный файл с добавлением его в эту группу? Понятно, что Колю надо добавить в эту группу.

Что мешает сделать тоже самое разрешив чтение файла для всех и предоставив ссылку на такой файл?

«федерализация» - это нечто другое. речь была наверно о federation.

Мне сложно представить зачем это нужно, но 100% это решаемо.

Так что - нет. Никаких проблем в таком подходе нет. Одни плюсы.

Т.е. решение с ldap не приносит никаких ощутимых плюсов, а минусы те же что и с sql. Это необходимость хранить доп свойства

Я Вам постоянно только о плюсах пишу, а Вы их не видите... Минусов как раз и нет. «Чукча не читатель - чукча писатель?»

Я бы понял вашу позицию, если бы Вы нашли что-то возразить хотя бы по одному пункту! Но похоже минусы SQL вы так и не поняли, раз говорите это одно и тоже...

Причем прикол в том, что под SQL понимается именно то как ее используют в NC, а не вообще SQL сама по себе! Уже было сказано, что LDAP может работать через SQL. И для SQL можно сделать authentication, которую будет понимать FS, правда смысла большого в этом нет. Структура данных для хранения пользователей не ложиться хорошо на таблицы SQL.

P.S. Разумеется минус есть, но о нем я говорил в самом начале. Это настройка LDAP и «слегка» дебильная организация schema файлов на базе которых эта настройка делается. Было бы там все просто и логично, уже давно никто бы не использовал древний shadow с его примитивной и давно недостаточной реализацией.

И проблема в том, что на коленке это не исправить! Это не технический вопрос. Это должно быть принято всей community или силой внедряться как каленым железом внедряли systemd.

Т.е. надо заново создать адекватные schema файлы и сделать набор стандартных конфигураций для локальной машины, сервера итд, чтобы пользователю нужно было выбрать вариант, который больше всего подходит и все. Можно оставить и ручную настройку, но она может быть не совместима с внешним софтом.

Сейчас же мы имеем заплатку на заплатке и хитрые пути как решить проблемы, которые сами авторы и создали.

И подумайте какое могло быть будущее!

LDAP работает как сервер, со всеми вытекающими! Т.е. это может быть отдельный сервер, который предоставляет исключительно функции authentication и хранения некоторых данных пользователей.

Значит другой сервер может например доверять данному LDAP серверу и предоставлять свои ресурсы по его отмашке. Т.е. пользователь имеет универсальный login/password в примитиве, а на самом деле куда больше данных, для захода в любые службы. Хоть facebook, хоть оплата комунальных платежей.

При этом тот же facebook физически не сможет слить данные пользователей кому-то еще. У него их просто нет.

Да, Вам нужно доверять данному конкретному серверу LDAP, но там вы можете это делать на бизнес основе с подписанием договора и абонентской плате! Это будет по сути электронный паспорт.

И это отличная бизнес модель! Если тут есть заинтересованные программисты, то думаю вполне можно реализовать. Пишите в личку.

Это необходимость хранить доп свойства файлов в LDAP т.к. в ФС для них нет места. Бекап БД решение на LDAP не отменяет.

Не буду комментировать, но Вы совершенно точно не понимаете того, что сами пишите. Есть подозрение, что Вы так и не поняли как именно это все работает! Я учебник не заменю.

Всё ещё не вижу там подтверждения указанных слов. Можно цитату?

Electronic communication service. If an unopened email has been in storage for 180 days or less, the government must obtain a search warrant. There has been debate over the status of opened emails in storage for 180 days or less, which may fall in this category or the «remote computing service» category.[3]

180 дней это ~ 6 месяцев. Я привел упрощенный вариант - страницу wiki. На самом деле нужно читать законы, там более полно, но более сложно для понимания. Нас этому тренировали по легальным вопросам импорта и экспорта. Как любой товар информация попадая за границу управляется целым перечнем законов. Нахождение информации на определенной территории означает, что на нее распространяются законы данной страны. Это очевидно и справедливо для всех стран. Поскольку информация может транзитом пересекать территорию страны, то есть законы, которые регулируют доступ к такой информации. Но он тоже есть! Речь о том, что после 6 месяцев наступает безусловный доступ и владелец может быть привлечен, где бы он географически не находился и гражданином каких стран бы не был.

Но на самом деле все хуже. Законодательство после случая со Сноуденом было ужесточено. Почитайте сами - полно информации. США вышли из договора с EU по разграничению доступа к данным. Теперь, например если данные лежат на серверах в других странах, но серверы принадлежат американским компаниям - государство точно так же имеет доступ к этим данным, хотя они даже не пересекали территорию США.

Доступ как я уже писал это право арестовать владельца, если данные нарушают законы США! Это все очень серьезно, но об этом очень мало кто пишет или говорит!

В свете последнего ареста CFO Huawei многие до сих пор задают себе вопрос - а на каком основании гражданин третьей страны работающий на компанию из третьей страны может отвечать за что-то перед США. На самом деле все очень четко по законам. Но если раньше для этого нужно было иметь бизнес на территории США, то теперь достаточно работать с одной из американских компаний причем даже на своей территории!!!

Теперь подумайте почему Google и Co - запрещены на территории Китая?

Сравните это с Россией или другими странами, где невольно граждане становятся объектом американского права...

PS: Мне интересно, как определяют «владельца» данных. Кто владелец емейла — отправитель или получатель? А если это было коллективное письмо? Или ответ почтового бота? А если это письмо сантаклаусу? Или, может, владелец — почтовая служба? Или админ виртуальной машины, где оно хранится? Или владелец сервера? Или владелец серверной?

А на этот вопрос у Вас будет время ответить, когда Вас экстрадируют в какую-нибудь Небраску. Много времени...

Разбил ответ на 2.

1. Юр.наезд. Вас арестовали на улице. Ваши сервера конфискованы. С сервера гугла/мозиллы данные бы фиг достали — нужно решение суда и согласие компании, и данные всё равно зашифрованы. Как помог NC? Никак, наоборот, отдал все ваши данные вместе с вашим сервером.

Зачем так сложно? Давайте фантазировать до конца. - Вас убили. Дальше даже продолжать не нужно. Хотя кто-то может похороны организует... если повезет... ;-)

В реальной жизни все так быстро не происходит. Если Вам есть чего опасаться перед гос органами - мы же не про бандитов говорим, так? - то Вы можете шифровать все свои данные. Можете запустить программу на уничтожение последних. Можете попросить сотрудника уничтожить серевер ломом. Есть миллион способов.

Но так же есть одна проблема! Я писал выше другому оратору. Вы используете NC для предоставления данных многим людям изначально!!! Если это криминальные данные или они так близки вашему сердцу, то зачем Вы это делаете вообще???

Я приводил аналогую с фото с пьянки на facebook. И да люди настолько тупы, что так поступают! Но зачем они при этом критикуют facebook мне непонятно? Или Вы критикуете NC...

Носите с собой флешку! Проглотите ее как профессор Плейшнер, если поймают. Закопайте ее в огороде! В чем проблема? Вам явно не нужен NC! Он Вам противопоказан.

Когда же Вы делитесь данными с людьми Вы автоматически создаете их утечку! Какое бы решение Вы не использовали, но «Коля» выдаст Вас с потрохами несмотря на любую защиту!

2. Взлом. Все данные и пароли ушли на сторону, вы этого даже не узнали.

Мда.. Это Россия... Это Российское мышление... У меня нет средства от психических травм.

Кто опытнее и лучше защитит сервер от взломов — вы, или админы мозиллы/гугла?

Разумеется я. Просто потому, что у меня может быть такая цель. А у них такой цели нет! Вы для них товар. Товар берегут, чтобы не протух, но всегда предлагают к продаже. Новости это подтверждают чуть ли не каждый день! Или Вы считаете, что программисты в facebook в 100 раз хуже гугловских?

Но как же так? Если facebook переманил людей именно из гугла???

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

Вы себе представьте картинку, где полицейский будет определять кто преступник на основании паспорта. Мол нет паспорта - преступник. Или у преступников другие паспорта с отметкой?

Если я действительно преступник, у меня будет отличный паспорт и даже телефон.

У гугла другая задача! Он знает, что клиенты идиоты, что им можно навешать лапшу на уши, НО!!! он понимает, что это не клиенты, а товар! Клиенты же платят ему деньги за рекламу и слив данных. Вот те действительно клиенты.

А если взлом таки состоится, что лучше — чтобы данные были надёжно зашифрованы, или хранились в открытом виде? Как помог NC? Опять никак, наоборот, отдал все ваши данные, и вместо штата опытных админов защищаете его только вы.

А что мне мешает надежно шифровать мои данные? По моему сегодня это может сделать каждый. Или Вы считаете, что опытный админ будет методом пристального взгляда лучше шифровать? - Нет. Опытный админ это канал утечки информации!!! Ему на данные плевать и под нажимом или на финансовой основе он сам сольет все и еще предложит доп помощь за доп вознаграждение!

Если Вы такой умный - взломайте мой сервер! А то языком молоть мы все горазды.

Данные под вашим контролем, но что вам это дало? Без NC — никто не получает ваши данные, с NC — ваши данные уходят. Вопрос: зачем тогда NC?

Именно! До Вас дошло, что если данные настолько секретны, то и показывать их всем довольно глупая затея. И дело не в софте или услугах других людей.

Вот сначала надо это осознать, понять область применения NC и потом доказывать, что он не работает.

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

Опять 25. Нет и еще раз нет. Я писал Выше, что если вопрос секретности стоит остро, то предоставление данных еще 1 персоне не решает, а создает проблему. Вам выше писали, что оказывается на моззиле линки храняться вообще в открытом виде! За алгоритм работы Вы не отвечаете. И его по некому закону, например, легко поменять так, что все будет в открытом доступе, и Вы об этом узнаете последним! Из новостей...

Вы как будто точно на облаке живете в прямом и переносном смыслах...

Лучше Мюллера об этом никто не сказал - Сейчас никому доверять нельзя, даже себе! И потом добавил - мне можно!

Вы поступаете ровно по этой шутке. И на той стороне именно Мюллер.

Чтож, мы каждый остаёмся при своем мнении.

Если тут есть заинтересованные программисты, то думаю вполне можно реализовать.

Собственно, чего мы спорим и теоритезируем, делайте свой аналог NC. Пока ldap никто так не использует у вас преимущество.

If an unopened email has been in storage for 180 days or less, the government must obtain a search warrant. [...] If a communication has been in storage for more than 180 days the government can use a search warrant, or a «specific and articulable facts» court order combined with prior notice to compel disclosure. [...] 180 дней это ~ 6 месяцев

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

Этот акт касался только обыска американских компаний, и не регулировал сервера, находящиеся не в Америке. Этим воспользовалась Microsoft (дело Microsoft Corp. v. United States), и отказалась выдавать данные с серверов в Ирладнии. Суды бодались 5 лет, ни к чему не пришли, пришлось собирать конгресс и вносить поправки в закон (CLOUD Act), чтобы таки обязать американские компании выдавать данные со своих серверов, даже если сервера в другой стране.

Доступ как я уже писал это право арестовать владельца, если данные нарушают законы США!

Нет, это условие, при котором американское государство может прочитать содержимое. Это не имеет никакого отношения к «владельцам» данных. Владельца могут арестовать хоть с доступом хоть без. И дальше суд будет решать, был ли арест правомерным.

В свете последнего ареста CFO Huawei многие до сих пор задают себе вопрос - а на каком основании гражданин третьей страны работающий на компанию из третьей страны может отвечать за что-то перед США. На самом деле все очень четко по законам.

В каком смысле «на самом деле»? Разве были публично названы причины ареста? Хотя мне что-то кажется, что дело не в хранении своих данных на чьих-то серверах...

Теперь подумайте почему Google и Co - запрещены на территории Китая?

Тут причина прямо противоположная — не защита граждан от США, а контроль за своими гражданами. Свои компании Китаю легче контролировать, чем зарубежные. Но как заставить китайцев пользоваться только подконтрольными китайскими компаниями? Запретить зарубежные, конечно.

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

https://apps.nextcloud.com/apps/end_to_end_encryption

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

Еще раз. Конкретные законы можно найти используя поиск. Я видел эти законы, но это было давно и параграф с абзацем я не помню. Тратить на это свое время я не намерен.

Акты касаются разумеется американских компаний. Других компаний в США не бывает! Они все 100% американские.

И именно, что теперь действует экстерриториальный принцип. Можно хранить даже за пределами США. Скоро дойдет до того, что достаточно иметь болт в стойке северов сделанный в США, чтобы обеспечить такой доступ.

Владельца могут арестовать хоть с доступом хоть без. И дальше суд будет решать, был ли арест правомерным.

Для оредера на арест и тем более экстрадицию в США требуется обоснование. Даже в США работает закон - просто так никто не может быть арестован. А вот подозрения на хранение нелегальных данных на серверах США это действительно достаточно. Т.е. по сути достаточно просто написать письмо через gmail и уже начать общаться с американским правосудием.

В каком смысле «на самом деле»? Разве были публично названы причины ареста?

В том смысле, что даже из некоторых СМИ или некоторых оффициальных лиц некоторых стран, не будем их называть раздаются вопли, что это беспредел и что на каком основани США арестовывают иностранцев исходя из своих внутренних законов.

Причина ареста в данном конкретном случае известна. Речь именно об основании. А основанием является, например, создание филиала Huawei на территории США и использование компонентов произведенных или только разработанных в американских компаниях и используемых в продуктах Huawei. Каждый такой компонент имеет ограничение на использование в определенных продуктах и определенных странах.

В свое время США издали запрет на продажу немецкой фирмы в Китай. Именно по причине наличия филиала в США. Хотя в филиале в основном занимались продажей. Теперь пришлось филиал продать...

Закон обоюдоострый. Недавно Китай не дал возможности Qualcomm купить NXP. Формально американская компания не смогла купить нидерландскую фирму.

Так что понятно, что кто сильнее, тот и прав может диктовать свои условия всем остальным.

Сделать ничего нельзя, но принимать во внимание стоит.

Тут причина прямо противоположная — не защита граждан от США, а контроль за своими гражданами. Свои компании Китаю легче контролировать, чем зарубежные. Но как заставить китайцев пользоваться только подконтрольными китайскими компаниями? Запретить зарубежные, конечно.

Китайцы достаточно неглупые люди. По крайней мере те, кто ими правит. Например yahoo.com прекрасно работает в Китае.

Дело именно в размере рынка! Я писал тут, что у China Mobile порядка 800 млн клиентов. Это огромный доход! Представьте, если Google получит доступ к такому кол-ву клиентов?! Таких желающих полно!

Но как заставить китайцев пользоваться только подконтрольными китайскими компаниями?

Особенно заставлять не надо. Очень небольшой процент знает английский язык. Внутри страны есть копии всех внешних сервисов.

В России тоже большинство предпочитает VK, хотя это была чистая копия FB.

Они по сути убивают сразу 2х зайцев.

Что-то мы ушли от темы... В общем, не всегда хорошо хранить данные у себя.

Да вроде бы нет. Юридические вопросы в хранении данных одни из самых важных.

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

Собственно, чего мы спорим и теоритезируем, делайте свой аналог NC. Пока ldap никто так не использует у вас преимущество.

Я уже делаю в каком-то смысле. Только моя профессия несколько другого плана. Касательно NC я пользователь. Тут я могу себе лишь позволить выбрать из разных вариантов. Пока это работает.

Когда у меня будет чуть больше ресурсов, то как написано выше мной же самое простое и адекватное решение это VPN и SAMBA в одной упряжке. Т.е. делать по сути ничего не надо. Уже все есть.

И так работает большинство бизнеса. Так что LDAP именно так используют в промышленном варианте.

Почему я так не поступаю? - Это более формальное решение. Компьютер пользователя нужно специальным образом настраивать и иметь возможность управлять/обновлять им/его со стороны.

Потому как при суперзащищенности сервера - пользователь становится слабым местом. И без усиления клиента все старания напрасны.

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

Но когда я буду выдывать сотрудникам настроенный laptop, то именно так и будет.

Сейчас весь сыр-бор по сути из-за бешенных тормозов данного решения. Не security, а именно скорости доступа, которая при том же канале могла быть на порядок выше.

Не вся, информациия о физическом расположении файла в базу не попадает. Ну это так придирки.

Что есть физическое расположение файлов? Пути в базе хранятся.

https://apps.nextcloud.com/apps/end_to_end_encryption

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

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

Ну если дело дошло до паяльника, тут уже никакое шифрование не поможет.


Но пока до этого не дошло - я хочу, чтобы мои данные были защищены от перехвата всеми, кто имел или мог иметь к ним доступ в процессе передачи: хакеры, взломавшие через 0-day мой сервер(неприцельно, просто насканили), хостинг-провайдер, провайдер интернета, производитель моей ОС. Ибо нефиг.