У перла много недостатков, банальный парсинг json в POST превращается в 3 экрана кода.
Откуда там 3 экрана? JSON это две строки:
use JSON::XS;
$perl_hash_or_arrayref = decode_json $utf8_encoded_json_text;
Если речь про ngx_http_perl, то обработка собственно POST займёт ещё несколько строк, на этом всё. Другой вопрос, насколько это стабильно, с учётом того что Perl в nginx до сих пор «experimental»…
Perl не умеет нормально обрабатывать ошибки и при любом удобном случае просто завершает весь процесс
Это неправда — Perl отлично умеет обрабатывать ошибки, просто некоторые привыкли писать как модули так и приложения где предпочитают завершать процесс в случае ошибок (djb style). Сделать приложение/модуль который будет вести себя корректно — вообще не проблема, достаточно эти самые ошибки обрабатывать.
Когда интерпретатор Perl-а не может выделить себе память, он убивает весь nginx...
Да, это одна из немногих ситуаций которую невозможно предотвратить простыми средствами в Perl (сюда также входят SIGSEGV/SIGFPE/SIGILL).
Но если уж дошло до нехватки памяти, то вполне логично убить весь процесс — ибо ситуация уже нестабильна, и скорее всего любое другое действие тоже приведет к проблемам (или будет периодически приводить пока система балансирует на границе голодания). Убийство процесса может либо стабилизировать ситуацию (он сошёл с ума и потёк, упершись в лимит, соответственно будет «чистым» после рестарта), либо дать системе время среагировать корректно.
Для embedded систем ситуация может быть иной, но в типичный сценариях frontend proxy или static file serving суицид — это единственно верное решение. Можно попытаться освободить буфера, уменьшить количество workers, etc — но это вряд-ли спасёт ситуацию (если нехватка глобальная, а не обусловленная лимитом на процесс). Опять-таки, при недостаче памяти можен начаться проблема с открытием файлов/сокетов, буферов для сокетов внутри ядра, etc — дело однозначно швах.
Наличие либ для Lua поможет только тем кому нужны специфические задачи, ими решаемые. В большинстве случаев это простая логика под конкретные требования конкретного прокси, значит — сравнительно небольшой и уникальный (для каждого случая) код, который может состоять всего из двух-трёх десятков строк.
При таком раскладе человек вряд-ли захочет изучать новый язык (синтаксис это часть проблемы, структуры данных и среда — более неприятная часть) — проще тот который более похож на один из ему известных. Каким бы простым он не был — на изучение нужно время, которого обычно очень мало.
JS это как-бы не совсем с нуля, если уж говорить честно и откровенно, а Lua — таки нишевый (на TIOBE он на 22 позиции ниже JS и уступает даже Fortran). Его единственный плюс — это JIT компиляция (которая нерелевантна для nginx), и на этом всё.
Мне почему-то думается, что любому кто имел дело только с C/C++/C#/Java/Perl/PHP (а это > 45% из наиболее популярных) JS будет намного понятней и проще чем Lua.
Единственный существенный минус JS — отсутствие эффективной работы с целыми числами (32/64 bit), но это тоже не очень релевантно в случае nginx. Хотя, если это + эффективная работа с целочисленными Array ((u)int 8/16/32/64) будет в njs добавлены, это будет просто супер для прокси-скриптинга.
Получается, чем быстрее продадите, тем меньшую разницу надо будет компенсировать, что бы купить авто того же класса и в том же состоянии.
Ну давайте посчитаем… Только вот «того же класса и в том же состоянии» слегка удивляет — зачем нам покупать «в том же состоянии» если оно и так у нас есть? Нам нужно новое, иначе смысла нет (гарантия и всё такое). Если каждый раз покупать не новое авто, то это лишает смысла всю процедуру и увеличивает риск — любая б/у машина это кот в мешке, а известное зло по всякому лучше неизвестного, гарантии обычно тоже нет или она всего год (и то если не у частника).
Поехали: покупаем авто, стоит изначально 30K. Если мы будем менять его каждые два года, то (в зависимости от пробега) можем продавать за примерно 2/3 от оригинальной цены (будем оптимистами). Итак, за 10 лет мы купим 5 новых автомобилей и доплатим аж 50K (!) за это удовольствие — это явно больше чем потенциальное обслуживание одного на протяжении 10 лет, не говоря уже о том что в сумме это 30K + 50K = 80K за удовольствие ездить на новом автомобиле. Т.е. можно было бы легко купить сразу два и отложить 20K на обслуживание на это время.
Ладно, посмотрим на «раз в три года». С улучшенным оптимизмом мы получаем 2/3 обратно при продаже (через три года, ага), за 10 лет мы доплачиваем ещё 30K — итого общие затраты уже 60K (+ обслуживание, если было). Не многовато-то ли за 10 лет? Опять-таки, можно было бы изначально купить два и ездить попеременно, таким образом увеличив срок службы, плюс бэкап.
Зачем вообще продавать хорошее авто, если ещё можно ездить и ездить? Моему старому VW уже 20 лет, пробег ~330 ткм, на обслуживание за все эти годы было потрачено порядка 10K евро (всего-то, но это в Германии по хорошим дорогам) + стоимость покупки около 30K — итого, 40K евро за 20 лет (бензин не в счёт поскольку расходы на него будут при любом автомобиле, а в городском цикле в постоянных пробках выигрыш даст только гибрид).
Когда ему было около 10 лет, я послушал «доброго совета» («Скоро умрёт, думай о новой машине») и купил Audi классом чуть повыше (+35K), на коем и езжу до сих пор. Но вот удивительное дело — VW до сих пор жив и не чахнет (сестра ездит), только расходники менять надо. Audi тоже уже почти 10 лет, пробег ~110 ткм, затраты на обслуживание за это время порядка 7K (потому как у официалов).
Итого — имеется два авто с общими затратами за 20 лет (минус бензин) 82K евро, в то время как меняя одну машинку каждые три года (см. расчеты выше) я бы потратил как минимум 100K и имел бы всего один автомобиль. Стоит оно того?
PS: Да, тесла обошлась бы в эти же деньги и была бы экономичней — но она была бы одна, и увы ещё не продавалась 20 лет назад :)
Это необязательно троллинг — я встречаю немало людей которые совершенно искренне думают точно также, и не видят криминала в том чтобы персональные данные были публично доступны. Именно такие обычно говорят: «Мне не нужен антивирус, я не представляю интереса для хакеров».
Большинство компаний (и предпринимателей) думают в основном о пользе для себя, просто так получается что без пользы для клиентов они не получат пользы для себя, вот и вынуждены крутится. Если бы это была «польза для нас» — то не было бы кривых китайских телефонов, которые разваливаются через три месяца (это просто иллюстрация «пользы» — спектр гораздо шире и Китаем или телефонами не ограничивается, некачественных товаров или услуг очень много).
Поэтому у меня вопрос — какие ещё опасности подстерегают человека, у которого утекли все персональные данные в паблик?
Начнём с того что эти данные могут быть использованы злоумышленниками, например, путём фишинга. Одно дело обычный фишинг («Уважаемый клиент банка...»), другое дело персонализированный («Уважаемый Вася Пупкин, вы получили это письмо так как являетесь клиентом банка...») — во втором случае доверия письмам гораздо больше. Знание дополнительной информации (адреса, телефона, года рождения etc) даёт ещё больше возможностей по профилированию и злоупотреблению — пусть и не прямой «кражей личности». Можно устроить проблемы кому-то конкретно, позвонив от его имени и притворившись им (ведь все данные известны, и часто адрес или дата рождения используется для «идентификации»). Это также даёт более широкие возможности тем кто хочет кого-то найти. Хватит для начала?
Я лично считаю что компания (любая) должна получать абсолютный минимум данных, который необходим для выполнения контракта — т.е. онлайн-магазину достаточно знать имя и адрес (год рождения только для товаров/услуг 18+) + способ контакта (email/телефон исключительно на выбор пользователя, без обязаловки), всё остальное лишнее (оплата осуществляется через процессинговую компанию). При регистрации на сервисе типа VK/Facebook/Twitter достаточно года рождения (требования закона) и страны резиденции (ограничения по содержания) — всё остальное им не необходимо для предоставления сервиса и должно быть строго добровольно, требование реальных имен и телефонов должно быть запрещено. Мобильные операторы, банки и финтехи — все данные необходимые для однозначной идентификации человека (имя + дата/место рождения + номер паспорта + средство контакта типа email/телефон) и его последующего поиска (если не платит или накосячил), а вот всем остальным «бизнесам» не нужен даже телефон (email достаточен, если нет (такое бывает) — тогда телефон но строго добровольно).
А бесконтрольная передача данных по цепочке рано или поздно приведет к их утечке без шанса найти ответственного — каждый будет говорить «это не мы», и доказать ничего нельзя.
Простой пример пусть хоть и не особой проблемы, но всё же — в своё время я ради эксперимента зарегистрировался на одном ICO, указав реальное имя. Они клялись (в T&C) никому не передавать данные, но вот что интересно — через некоторое время мне стали приходить приглашения от других ICO, на тот уникальный email что был создан для первого, и меня называли полным именем. Переписка ни к чему не привела — они утверждали что в соответствии с T&C никому ничего не передавали и кражи данных не было, заявили что-то типа «это у вас троян данные украл» (что, разумеется, не так). В данном случае это не привело ни к чему кроме спама, но хз к кому это попадёт дальше и как это применят (хорошо хоть адрес и прочие данные не оставил). Подобные проблемы были и раньше с другими компаниями — онлайн-магазинами в частности.
И вот как с такими нарушителями бороться, если дать им право отдавать данные кому угодно без моего согласия? Да и не каждый может отследить откуда ноги растут — к примеру, уникальные email для каждой конторы не все могут себе позволить, а без этого и концов не найти.
Идеальное решение — это вообще запрет требования персональных данных, и переход на уникальные для каждой транзакции (покупка, регистрация, оплата etc) токены для идентификации, которые будут обрабатываться соответствующими операторами. Таким образом, продавец (бизнес) имеет что-то что может предъявить в случае чего, чтобы найти заказчика в случае неоплаты или других нехороших действий, оператор имеет полные данные (паспортные) для выдачи органам в случае чего, и жестко контролируется регуляторами с логом всех использований данных, в то же время клиент (пользователь) уверен что ничто не уйдёт на сторону без его согласия (токены генерируются исключительно по его явному согласию на каждый конкретный случай, причём явно декларируется какая информации будет разглашена). Этот же токен может использоваться для отчетов налоговой (в случае оплат). Такой метод также позволит избежать профилирования в рамках одной компании, ибо связать два разных заказа от одного человека будет невозможно (разумеется, если это не физические товары, требующие имени и адреса для доставки).
Жаль только, что подобного рода реализация идентификации вряд-ли когда-то будет реализована — бизнесам это очень невыгодно.
PS: Ну и самое главное — персональные данные — это моя собственность (пока что), и если кто-то хочет получать от этого выгоду, я хочу долю. Отдали данные сотне компаний — заплатите минимум 50% от того что получили (и далее по цепочке) :)
Как именно шифруется? end-to-end или просто до сервера (TLS etc)?
Если второе — то каковы гарантии что кто-то у вас (нечестный, подкупленный или просто скучающий) админ не подключится к потоку? Про взлом инфраструктуры я уже молчу.
Из предыдущих сообщений о вашем месснджере сложилось впечатление что end-to-end вообще не используется — так о какой приватности идёт речь?
Если вы всё же используете end-to-end — то какой протокол? Есть ли независимый аудит (если протокол свой)?
...Ubuntu 16.04 (который аж 2016 года), в то время как в 18.04 (тоже LTS, да) есть штатный squid 3.5.27 — ставится «одним кликом» и можно напрямую конфигурировать. Бонус — новый openssl + простые обновления + поддержка несколько лет (как минимум security patches).
Вот правда интересно, что вас сподвигло компилировать вручную да ещё и на устаревшем убунту? Неужели только отключение ipv6?
Если же причины более глубокие — то лучше было бы из озвучить.
Для новых клиентов новых банков или финтехов это может быть включено в контракт (хотя скорее всего такой банк останется без клиентов), но вот уже существующие контракты не могут быть изменены таким образом.
Банковская тайна никуда не делась, в конце концов — просто раньше банки невозможно было заставить сотрудничать с кем-то, а теперь их обязывают, но всё же не в ущерб этой самой тайне.
Так что, принципиально ничего не поменялось, пока что.
Чтобы купить товар в онлайн-магазине (или получить какой-то сервис, типа мобильного контракта), ему таки придётся дать доступ. Пусть небольшой (номер счёта/кредитки, персональные данные) и временный (для совершения транзакции на определенную сумму), но всё же.
Впрочем, возможен и другой вариант развития событий — компании (как ритейлеры, так и и процессинговые) могут начать отказывать в обслуживании если им не давать доступа к такой информации (как в случае кредитов), но это всё же маловероятно.
Согласно инициативе, банки должны предоставить 3-им лицам (т.н. финансово-техническим компаниям) данные о балансе клиентов и доступ к их расчетным счетам.
Только в случае если клиент не против.
В странах Европейского Союза с января 2018 года действует стандарт PSD 2 (Европейская платежная директива), которая обязывает банки предоставлять клиентские базы данных и программные интерфейсы (API) для 3-их лиц, собирающихся работать в финансовом секторе.
Не процитируете статью где есть обязательство предоставлять клиентские базы данных?
Ни в одной из имеющихся инициатив и директив в ЕС нет обязательства делать это против воли клиента. Да, если клиент сам решил поделиться своей информацией с чьим-то приложением — нет проблем. Но только в этом случае. Ни один финтех не получит данных о клиенте без его явного согласия.
Мы должны поддерживать компании, которые выбирают людей вместо машин, даже если это менее эффективно и более затратно.
Почему это должны? Я, как потребитель, возьму то что дешевле — при прочих равных, и мне совершенно всё равно кто произвел то что мне нужно. Более того, я буду более уверен в качестве сборки автомобиля (к примеру) если человек будет исключен из сборочного процесса.
Формально, они не обязаны это делать, это проблема въезжающего на автобан. Если втиснуться не получается, въезжающий должен ждать адекватного просвета, ибо у траффика на автобане есть преимущество.
(сорри за дубль, сообщения выше ещё не было когда начал ответ)
Если через уязвимость в системе или пользовательской программе злобный хацкер получил доступ к учетке пользователя, то наличие такого замечательного sudo позволит ему без напряга получить рута со всеми вытекающими.
Говоря честно и откровенно, в большинстве случаев рут злоумышленнику и не нужен — чтобы сделать из компа зомби, хватит обычных прав, чтобы (кей)логгить всё что он делает — тоже (ptrace и LD_PRELOAD наше всё). Только очень зубодробительная конфигурация с selinux/apparmor спасёт от этого, но это редчайший случай и явно не дефолт.
если написано под винду (а это так в ~100% случаев)
Это давно уже не так — руткитов и прочего под Linux вагон и маленькая тележка. Чем популярнее становится система, чем больше она распостраняется и используется — тем больше шансов что под неё начнут копать. Пока Linux был уделом гиков, им мало кто интересовался, но как только он пошел в массы (как сервер в частности), всё изменилось (и не забудьте про Android — это тоже Linux, и там уязвимостей чуть меньше чем много). Windows же изначально был сильно распостранен, соответственно, под него намного больше накопано за всё это время.
Линукс практически невосприимчив к заразе, обитающей в Интернете. Можно спокойно шляться по самым злачным и сомнительным местам Сети, не опасаясь за свои данные.
Правильно настроенный линукс — да. Без дырявого софта — да. Но баги находят и в Chrome с Firefox, и в других приложениях с помощью которых «шляются» — соответственно 0day-дыра в Firefox даст чему-то доступ как минимум на уровне пользователя независимо от того, какой OS он пользуется.
Если же говорить про всё остальное (сервера) — то тут Linux впереди планеты всей — с кучей похаченных серверов по всему миру. Точки входа — разумеется, дырявые приложения (Wordpress etc), другие непропатченные или баговые серверные приложения (почта, веб etc — тысячи их) и всё такое — так что не надо про «невосприимчив к заразе».
Пусть это прозвучит банально и уже в трилионный раз, но безопасность — это процесс, а не продукт, и правильно настроенная (и используемая) ОС с приложениями будет довольно безопасна, вне зависимости от того что это — Linux, Windows или даже DOS.
Просто как пример — за последние лет 20 я ни разу не поймал ни вируса, ни трояна, постоянно используя Windows для практически всего десктопного (Linux использую исключительно как серверную ОС) — что я делаю не так и почему «дырявость» Windows на меня не влияет? Да, падений тоже практически не бывает (бывали BSOD несколько раз за всю историю, но проблема была либо в железе либо экспериментах, т.е. не просто так во время обычной работы).
На самом деле это не только RFC, это полиси, т.е. имеет силу закона для всех LIR.
Но если сама компания просто арендует сервера у кого-то, не являясь LIR, то да — они могли получить свои честные /64 у провайдера и теперь их продают поштучно (хотя могли бы хотя бы /96 или даже /112).
Откуда там 3 экрана? JSON это две строки:
Если речь про ngx_http_perl, то обработка собственно POST займёт ещё несколько строк, на этом всё. Другой вопрос, насколько это стабильно, с учётом того что Perl в nginx до сих пор «experimental»…
Это неправда — Perl отлично умеет обрабатывать ошибки, просто некоторые привыкли писать как модули так и приложения где предпочитают завершать процесс в случае ошибок (djb style). Сделать приложение/модуль который будет вести себя корректно — вообще не проблема, достаточно эти самые ошибки обрабатывать.
Да, это одна из немногих ситуаций которую невозможно предотвратить простыми средствами в Perl (сюда также входят SIGSEGV/SIGFPE/SIGILL).
Но если уж дошло до нехватки памяти, то вполне логично убить весь процесс — ибо ситуация уже нестабильна, и скорее всего любое другое действие тоже приведет к проблемам (или будет периодически приводить пока система балансирует на границе голодания). Убийство процесса может либо стабилизировать ситуацию (он сошёл с ума и потёк, упершись в лимит, соответственно будет «чистым» после рестарта), либо дать системе время среагировать корректно.
Для embedded систем ситуация может быть иной, но в типичный сценариях frontend proxy или static file serving суицид — это единственно верное решение. Можно попытаться освободить буфера, уменьшить количество workers, etc — но это вряд-ли спасёт ситуацию (если нехватка глобальная, а не обусловленная лимитом на процесс). Опять-таки, при недостаче памяти можен начаться проблема с открытием файлов/сокетов, буферов для сокетов внутри ядра, etc — дело однозначно швах.
При таком раскладе человек вряд-ли захочет изучать новый язык (синтаксис это часть проблемы, структуры данных и среда — более неприятная часть) — проще тот который более похож на один из ему известных. Каким бы простым он не был — на изучение нужно время, которого обычно очень мало.
Мне почему-то думается, что любому кто имел дело только с C/C++/C#/Java/Perl/PHP (а это > 45% из наиболее популярных) JS будет намного понятней и проще чем Lua.
Единственный существенный минус JS — отсутствие эффективной работы с целыми числами (32/64 bit), но это тоже не очень релевантно в случае nginx. Хотя, если это + эффективная работа с целочисленными Array ((u)int 8/16/32/64) будет в njs добавлены, это будет просто супер для прокси-скриптинга.
Ну давайте посчитаем… Только вот «того же класса и в том же состоянии» слегка удивляет — зачем нам покупать «в том же состоянии» если оно и так у нас есть? Нам нужно новое, иначе смысла нет (гарантия и всё такое). Если каждый раз покупать не новое авто, то это лишает смысла всю процедуру и увеличивает риск — любая б/у машина это кот в мешке, а известное зло по всякому лучше неизвестного, гарантии обычно тоже нет или она всего год (и то если не у частника).
Поехали: покупаем авто, стоит изначально 30K. Если мы будем менять его каждые два года, то (в зависимости от пробега) можем продавать за примерно 2/3 от оригинальной цены (будем оптимистами). Итак, за 10 лет мы купим 5 новых автомобилей и доплатим аж 50K (!) за это удовольствие — это явно больше чем потенциальное обслуживание одного на протяжении 10 лет, не говоря уже о том что в сумме это 30K + 50K = 80K за удовольствие ездить на новом автомобиле. Т.е. можно было бы легко купить сразу два и отложить 20K на обслуживание на это время.
Ладно, посмотрим на «раз в три года». С улучшенным оптимизмом мы получаем 2/3 обратно при продаже (через три года, ага), за 10 лет мы доплачиваем ещё 30K — итого общие затраты уже 60K (+ обслуживание, если было). Не многовато-то ли за 10 лет? Опять-таки, можно было бы изначально купить два и ездить попеременно, таким образом увеличив срок службы, плюс бэкап.
Зачем вообще продавать хорошее авто, если ещё можно ездить и ездить? Моему старому VW уже 20 лет, пробег ~330 ткм, на обслуживание за все эти годы было потрачено порядка 10K евро (всего-то, но это в Германии по хорошим дорогам) + стоимость покупки около 30K — итого, 40K евро за 20 лет (бензин не в счёт поскольку расходы на него будут при любом автомобиле, а в городском цикле в постоянных пробках выигрыш даст только гибрид).
Когда ему было около 10 лет, я послушал «доброго совета» («Скоро умрёт, думай о новой машине») и купил Audi классом чуть повыше (+35K), на коем и езжу до сих пор. Но вот удивительное дело — VW до сих пор жив и не чахнет (сестра ездит), только расходники менять надо. Audi тоже уже почти 10 лет, пробег ~110 ткм, затраты на обслуживание за это время порядка 7K (потому как у официалов).
Итого — имеется два авто с общими затратами за 20 лет (минус бензин) 82K евро, в то время как меняя одну машинку каждые три года (см. расчеты выше) я бы потратил как минимум 100K и имел бы всего один автомобиль. Стоит оно того?
PS: Да, тесла обошлась бы в эти же деньги и была бы экономичней — но она была бы одна, и увы ещё не продавалась 20 лет назад :)
Большинство компаний (и предпринимателей) думают в основном о пользе для себя, просто так получается что без пользы для клиентов они не получат пользы для себя, вот и вынуждены крутится. Если бы это была «польза для нас» — то не было бы кривых китайских телефонов, которые разваливаются через три месяца (это просто иллюстрация «пользы» — спектр гораздо шире и Китаем или телефонами не ограничивается, некачественных товаров или услуг очень много).
Начнём с того что эти данные могут быть использованы злоумышленниками, например, путём фишинга. Одно дело обычный фишинг («Уважаемый клиент банка...»), другое дело персонализированный («Уважаемый Вася Пупкин, вы получили это письмо так как являетесь клиентом банка...») — во втором случае доверия письмам гораздо больше. Знание дополнительной информации (адреса, телефона, года рождения etc) даёт ещё больше возможностей по профилированию и злоупотреблению — пусть и не прямой «кражей личности». Можно устроить проблемы кому-то конкретно, позвонив от его имени и притворившись им (ведь все данные известны, и часто адрес или дата рождения используется для «идентификации»). Это также даёт более широкие возможности тем кто хочет кого-то найти. Хватит для начала?
Я лично считаю что компания (любая) должна получать абсолютный минимум данных, который необходим для выполнения контракта — т.е. онлайн-магазину достаточно знать имя и адрес (год рождения только для товаров/услуг 18+) + способ контакта (email/телефон исключительно на выбор пользователя, без обязаловки), всё остальное лишнее (оплата осуществляется через процессинговую компанию). При регистрации на сервисе типа VK/Facebook/Twitter достаточно года рождения (требования закона) и страны резиденции (ограничения по содержания) — всё остальное им не необходимо для предоставления сервиса и должно быть строго добровольно, требование реальных имен и телефонов должно быть запрещено. Мобильные операторы, банки и финтехи — все данные необходимые для однозначной идентификации человека (имя + дата/место рождения + номер паспорта + средство контакта типа email/телефон) и его последующего поиска (если не платит или накосячил), а вот всем остальным «бизнесам» не нужен даже телефон (email достаточен, если нет (такое бывает) — тогда телефон но строго добровольно).
А бесконтрольная передача данных по цепочке рано или поздно приведет к их утечке без шанса найти ответственного — каждый будет говорить «это не мы», и доказать ничего нельзя.
Простой пример пусть хоть и не особой проблемы, но всё же — в своё время я ради эксперимента зарегистрировался на одном ICO, указав реальное имя. Они клялись (в T&C) никому не передавать данные, но вот что интересно — через некоторое время мне стали приходить приглашения от других ICO, на тот уникальный email что был создан для первого, и меня называли полным именем. Переписка ни к чему не привела — они утверждали что в соответствии с T&C никому ничего не передавали и кражи данных не было, заявили что-то типа «это у вас троян данные украл» (что, разумеется, не так). В данном случае это не привело ни к чему кроме спама, но хз к кому это попадёт дальше и как это применят (хорошо хоть адрес и прочие данные не оставил). Подобные проблемы были и раньше с другими компаниями — онлайн-магазинами в частности.
И вот как с такими нарушителями бороться, если дать им право отдавать данные кому угодно без моего согласия? Да и не каждый может отследить откуда ноги растут — к примеру, уникальные email для каждой конторы не все могут себе позволить, а без этого и концов не найти.
Идеальное решение — это вообще запрет требования персональных данных, и переход на уникальные для каждой транзакции (покупка, регистрация, оплата etc) токены для идентификации, которые будут обрабатываться соответствующими операторами. Таким образом, продавец (бизнес) имеет что-то что может предъявить в случае чего, чтобы найти заказчика в случае неоплаты или других нехороших действий, оператор имеет полные данные (паспортные) для выдачи органам в случае чего, и жестко контролируется регуляторами с логом всех использований данных, в то же время клиент (пользователь) уверен что ничто не уйдёт на сторону без его согласия (токены генерируются исключительно по его явному согласию на каждый конкретный случай, причём явно декларируется какая информации будет разглашена). Этот же токен может использоваться для отчетов налоговой (в случае оплат). Такой метод также позволит избежать профилирования в рамках одной компании, ибо связать два разных заказа от одного человека будет невозможно (разумеется, если это не физические товары, требующие имени и адреса для доставки).
Жаль только, что подобного рода реализация идентификации вряд-ли когда-то будет реализована — бизнесам это очень невыгодно.
PS: Ну и самое главное — персональные данные — это моя собственность (пока что), и если кто-то хочет получать от этого выгоду, я хочу долю. Отдали данные сотне компаний — заплатите минимум 50% от того что получили (и далее по цепочке) :)
Как именно шифруется? end-to-end или просто до сервера (TLS etc)?
Если второе — то каковы гарантии что кто-то у вас (нечестный, подкупленный или просто скучающий) админ не подключится к потоку? Про взлом инфраструктуры я уже молчу.
Из предыдущих сообщений о вашем месснджере сложилось впечатление что end-to-end вообще не используется — так о какой приватности идёт речь?
Если вы всё же используете end-to-end — то какой протокол? Есть ли независимый аудит (если протокол свой)?
...Ubuntu 16.04 (который аж 2016 года), в то время как в 18.04 (тоже LTS, да) есть штатный squid 3.5.27 — ставится «одним кликом» и можно напрямую конфигурировать. Бонус — новый openssl + простые обновления + поддержка несколько лет (как минимум security patches).
Вот правда интересно, что вас сподвигло компилировать вручную да ещё и на устаревшем убунту? Неужели только отключение ipv6?
Если же причины более глубокие — то лучше было бы из озвучить.
Банковская тайна никуда не делась, в конце концов — просто раньше банки невозможно было заставить сотрудничать с кем-то, а теперь их обязывают, но всё же не в ущерб этой самой тайне.
Так что, принципиально ничего не поменялось, пока что.
Впрочем, возможен и другой вариант развития событий — компании (как ритейлеры, так и и процессинговые) могут начать отказывать в обслуживании если им не давать доступа к такой информации (как в случае кредитов), но это всё же маловероятно.
Только в случае если клиент не против.
Не процитируете статью где есть обязательство предоставлять клиентские базы данных?
Ни в одной из имеющихся инициатив и директив в ЕС нет обязательства делать это против воли клиента. Да, если клиент сам решил поделиться своей информацией с чьим-то приложением — нет проблем. Но только в этом случае. Ни один финтех не получит данных о клиенте без его явного согласия.
Почему это должны? Я, как потребитель, возьму то что дешевле — при прочих равных, и мне совершенно всё равно кто произвел то что мне нужно. Более того, я буду более уверен в качестве сборки автомобиля (к примеру) если человек будет исключен из сборочного процесса.
Формально, они не обязаны это делать, это проблема въезжающего на автобан. Если втиснуться не получается, въезжающий должен ждать адекватного просвета, ибо у траффика на автобане есть преимущество.
(сорри за дубль, сообщения выше ещё не было когда начал ответ)
Говоря честно и откровенно, в большинстве случаев рут злоумышленнику и не нужен — чтобы сделать из компа зомби, хватит обычных прав, чтобы (кей)логгить всё что он делает — тоже (ptrace и LD_PRELOAD наше всё). Только очень зубодробительная конфигурация с selinux/apparmor спасёт от этого, но это редчайший случай и явно не дефолт.
Если бы: A remote user can create content that, when loaded by the target user, will execute arbitrary code on the target user's system. (да, и на Linux тоже) — и это не то чтобы совсем уж «древний» баг, начала этого года.
Или возьмем популярный MTA Exim (стандарт в Debian), майский баг этого года: By sending a handcrafted message, a buffer overflow may happen. This can be used to execute code remotely.
— тут совсем действий пользователя не требуется (не считая того что у него должен быть почтовый сервер на Exim, разумеется).
Это давно уже не так — руткитов и прочего под Linux вагон и маленькая тележка. Чем популярнее становится система, чем больше она распостраняется и используется — тем больше шансов что под неё начнут копать. Пока Linux был уделом гиков, им мало кто интересовался, но как только он пошел в массы (как сервер в частности), всё изменилось (и не забудьте про Android — это тоже Linux, и там уязвимостей чуть меньше чем много). Windows же изначально был сильно распостранен, соответственно, под него намного больше накопано за всё это время.
Правильно настроенный линукс — да. Без дырявого софта — да. Но баги находят и в Chrome с Firefox, и в других приложениях с помощью которых «шляются» — соответственно 0day-дыра в Firefox даст чему-то доступ как минимум на уровне пользователя независимо от того, какой OS он пользуется.
Если же говорить про всё остальное (сервера) — то тут Linux впереди планеты всей — с кучей похаченных серверов по всему миру. Точки входа — разумеется, дырявые приложения (Wordpress etc), другие непропатченные или баговые серверные приложения (почта, веб etc — тысячи их) и всё такое — так что не надо про «невосприимчив к заразе».
Пусть это прозвучит банально и уже в трилионный раз, но безопасность — это процесс, а не продукт, и правильно настроенная (и используемая) ОС с приложениями будет довольно безопасна, вне зависимости от того что это — Linux, Windows или даже DOS.
Просто как пример — за последние лет 20 я ни разу не поймал ни вируса, ни трояна, постоянно используя Windows для практически всего десктопного (Linux использую исключительно как серверную ОС) — что я делаю не так и почему «дырявость» Windows на меня не влияет? Да, падений тоже практически не бывает (бывали BSOD несколько раз за всю историю, но проблема была либо в железе либо экспериментах, т.е. не просто так во время обычной работы).
Но если сама компания просто арендует сервера у кого-то, не являясь LIR, то да — они могли получить свои честные /64 у провайдера и теперь их продают поштучно (хотя могли бы хотя бы /96 или даже /112).