когда карта кредитка то риск того, что при снятии всей суммы позже будет отлуп, ниже
Если человек регулярно оплачивает счета — да. А если он в постоянном минусе — то риск ровно такой же, в то же время блокировка или снятие полной суммы — гарантия резервирования её для продавца, при любом виде карты. Практически все POS (в обычных магазинах) снимают всю сумму сразу, в онлайн — тут всё зависит, но обычно тоже сразу, кроме крупняков вроде амазона.
кредитка предпочтительней для продавца, так как она гарантирована банком.
Это заблуждение. Она гарантирована (до определенных пределов) только если продавец сделал резервирование или снятие онлайн. Во всех остальных случаях — это риск продавца, банк не будет ему платить если на момент проведения транзакции она не вписывается в остаток лимита.
Но даже если снятие было сделано сразу и в полном объеме, но при этом без соблюдения последних защиных мер (типа пин-кода, Verified by VISA/Mastercard etc) — то даже в этом случае у продавца нет гарантий, потому что клиент скажет "это не я" и продавец останется ни с чем в 99% случаев, даже если клиент расплачивался в обычном магазине, но при этом не использовал пин-код с картой без чипа (или терминал не читает чипы) и расписался "за дядю", а продавец не проверил подпись.
Просто потому что вы дали им карт-бланш на платежи и им известен номер кредитки. Но если у них не получится снять деньги к карты — банк им ровно ничего не заплатит, а разбираться они будут с вами.
Если же вы в магазине первый раз — то маловероятно что вам "отвесят" товар без снятия или блокировки.
Единственной гарантией получения денег для продавца является блокировка (в полном объеме) или снятие (тоже в полном объеме) — иначе банк их пошлёт и будет прав, а тот факт что некоторые продавцы идут на риск откладывая оплату — ну риск он и в африке риск, это вовсе не потому что "банк заплатит".
Если у вас на кредитке лимит в 1000 рублей, то вы можете в пяти магазинах параллельно заказать покупки суммарным объёмом 5000 рублей
Если каждый магазин сделает блокировку на всю сумму покупки сразу — не сможете. Обычно магазины именно так и поступают (трудно снять больше чем заблокировано, если без бубна и прочих нюансов), а заблокировать больше оставшегося лимита не получится, хотя может и есть банки которые это позволяют (в чём я сомневаюсь — банку это тоже невыгодно).
Причём, это работает ровно точно также и для дебетовых карт — т.е. если (условно) блокируется доллар/евро/рубль для "проверки" — то всё получится, а если вся сумма — то с точки зрения эмитента (и владельца) это уже снятая сумма (все блокировки накапливаются), разница между снятием и блокировкой исключительно в том что во втором случае блокировку можно отменить без последствий.
Я не исключаю что в РФ банки-эмитенты ведут себя иначе, но судя по моему опыту снятия денег у клиентов (и иногда разборок по поводу невозможности) это вряд-ли так.
Мой личный опыт владельца разных видов карт от разных банков на протяжении последних 20 лет (в ЕС), равно как и разборок как с продавцами так и банками, это тоже подтверждает — любой платёж (кроме "проверочных") — это сразу минус на карту (и дебет и кредит), с дебетовыми минус к тому что на счёте, с кредитовыми — минус к лимиту.
Два варианта когда потратить можно больше чем позволяет лимит/счёт — это когда карту "прокатывают" или платёж идёт оффлайн (она привязана к Google/Apple/Samsung etc Pay и нет связи) — т.е. платёж фактически отложен, но и там есть свои нюансы. У меня такой случай был — сервис аренды авто "прокатил" мою карту и не получил денег, потому что на момент попытки снятия (через пару недель) остаток лимита не позволил, банк их послал, я мог бы тоже (другая страна, к тому же не в ЕС) — но решили вопрос честно.
mktemp, в теории, должен попробовать другое имя если сгенерированное уже занято, но это зависит от конкретной версии, наверное.
Плюс, гарантируется что если он завершился успешно, то файл (или директорий) был создан с этим именем (именно создан — т.е. его там не было раньше) — а если сначала генерить имя, а потом "вручную" пытаться создать его — это race condition, пусть и с очень низкой вероятностью (хотя как знать, что там в random, может он глючной).
Но основная суть в том что mktemp проще чем приведённая в статье конструкция, выполняющая ту же функцию.
Раньше я упирался в производительность сетки и не сильно парился — но после перехода на 10 Gbit стало не совсем всё равно, потому что 100 MiB/s и 200 MiB/s (больше HDD не позволяют) это таки разница в два раза, а данные гоняются часто, причём сотнями гигабайт — разница ощутима, а luks без тюнинга таки приводил к этой разнице.
Что касается NVMe — не сказал бы что это реально заметно, просто потому что он сам по себе (даже со всеми проседаниями) очень шустрый, и мои кейсы более чувствительны к iops, с этим как раз особых проблем нет.
С другой стороны, по мере увеличения количества одновременных писателей и читателей, разница всё же становится заметной, особенно когда он используется как iSCSI target по сетке больше чем одним потребителем.
Я просто расчитывал что поставлю NVMe и забуду про производительность навсегда (или по крайней мере очень надолго) — но эксперименты показывают, что я просто лишь чуть-чуть отодвинул эти проблемы в будущее, а с учётом того что новые (gen4) NVMe имеют скорость даже выше теоретической для AES (4-5 GiB/s) — про luks, наверное, можно забыть, как-то изворачиваться с тем чтобы всегда иметь доступ к железу (для использования нативного шифрования).
luks сразу на железе, поверх него lvm-thin и ext4. При тестах без fs (dd iflag=direct bs=4M) поверх luks скорость была около 1.3 GiB/s, без luks это 2.7 GiB, поверх fs через fio (iodepth=8 4k) — как говорил выше, около 3 GiB без luks и менее 1 GiB/s с luks. В обоих случаях прогон был по 20 GiB случайных данных, т.е. "честно" без компрессий и всего такого, одно ядро было загружено почти полностью (dmcrypt не использует многопоточность для одного устройства, по понятным причинам).
Если вы всё же прочитаете статью — поймёте почему это возможно в 2020. Я тоже был очень удивлён, особенно тем что mdraid1 из обычных дисков тоже просел (но там спас тюнинг и более низкая скорость самих дисков, хотя и на пределе).
Фишка в том что для большинства применений, особенно с сеткой в 1 Gbit это почти незаметно, но у меня другой случай и сетка 10 Gbit — не заметить было сложно.
benchmark не показывает реальную производительность — это совсем не то же самое что рамдиск (и любое другое блочное устройство) с luks поверху — даже с рамдиском вы не получите такого результата. В моём случае там были цифры больше 3 GiB/s, но это как раз и есть теория, которая сильно отличается от практики.
Проблема не в самом шифровании — проблема в том как оно используется dmcrypt (блокировки, буфера, etc), в статье на которую я дал ссылку всё это хорошо описано.
Если вас устраивает скорость шифрования — ок, отлично, я всего лишь хочу сказать что потери есть и в зависимости от use case они могут быть очень ощутимы, при этом теоретическая скорость существенно выше практической.
Зачем вообще нужен bash если его фичами нельзя пользоваться? Не говоря уже о том что сейчас сложно найти систему где его нет (разве что MCU), да и статья не о shell-scripts а конкретно о bash.
Все эти заявления на тему "непортабельно" изрядно устарели — если им следовать, то можно вообще прекратить разработку чего-то нового, ибо "не рекомендуется", но я подозреваю что реально совместимость с 99% систем нужна едва-ли в 1% случаев.
Что касается POSIX… то он тоже не без нареканий, если всё притянуть за уши к соответствию, весь сделанный прогресс можно откатить лет на 20 назад, ибо работать в чём-то что строго следует стандарту (и писать под это код) — примерно как бегать с будкой на голове и обмотав ноги цепью.
Если у вас интенсивный ввод-вывод (с кучей vm/контейнеров внутри) — очень даже заметная разница.
В моём случае разница была в три раза, как я уже сказал выше — 3 GiB/s без, и чуть меньше 1 GiB/s с LUKS (PNY CS3030 1TB, Intel i7-6700, aes-xts 256b). Путём небольшого тюнинга удалось поднять до почти 2 GiB/s (на длинных блоках), но это всё — что меня тоже не устроило, потому что на 4K было всё равно плохо.
Это зависит от размера операции, типа доступа, количества слоёв блочных устройств — т.е. если у вас softraid => luks => lvm и средний размер операции ввода-вывода в десятки килобайт — это будет намного медленней чем чистый luks поверх железа с блоками от 1 MiB или выше, а если это нагруженная система с кучей ввода-вывода — то проседание будет более очевидно, плюс нагрузка процессора ("железная" поддержка AES тоже не бесплатная, он просто быстрее но всё же жрёт процессор).
Просто проведите эксперимент — сделайте luks поверх ramdisk и пропустите по нему fio с блоками по 4K — и скажите, получили вы "паспортную" скорость AES (гигабайты/c) или нет (как сделали Cloudflare). Если уж с памятью не получается (у них не получилось, у меня тоже) — то что уж про все остальные устройства говорить.
Да, у меня действительно настолько рандомный пароль — я пользуюсь генератором, каждый сайт получает свой пароль и почти рандомный логин/email (только домен неизменен), так что успехов тем кто его будет пробовать.
На действительно важные сайты (банки, paypal etc) у меня к тому же 2FA, а с запоминанием всего этого проблем нет благодаря KeePass.
Даже на устройствах 10-летней давности hardware-accelerated AES — несколько гигабайт в секунду.
Это в теории, при шифровании очень длинных блоков в вакууме памяти. На практике, если вы его пропускаете через LUKS, вы получаете намного меньшую производительность (особенно с длиной ключа 256 bit), а если вы вздумаете (вдруг) шифровать NVMe или толстый RAID тем же LUKS, то просядете конкретно ниже его реальной производительности.
Когда я "в лоб" попытался навернуть LUKS на свой домашний сервер после установки NVMe, удивился низкой производительности (< 1 GiB/s, без него около 3 GiB/s), стал копать и обнаружил что с обычными дисками (HDD) тоже не всё так гладко (~30% ниже), в итоге наткнулся на блог Cloudflare, где очень хорошо разобран этот вопрос. Возможно, их патчи вошли в последние ядра, но до них — всё не очень радужно.
Это тем более печально что далеко не всегда можно воспользоваться встроенным шифрованием накопителей — например, если железо не ваше и шарится с кем-то ещё.
Чего именно вы опасаетесь? Вот мой реальный пароль от одного из аккаунтов на одном из сайтов (нет, не хабра) — 58CNTCzzL9Ls5hWZ — что вы с ним сделаете, не зная логина и собственно сайта? И это с учётом того что оставляя его здесь я рискую гораздо больше чем на каком-то сервисе который про меня знает только мой динамический IP, ОС и браузер.
А если отправить им SHA1, то на его реверс уйдут в лучшем годы работы всех устройств планеты (в нём 87 бит энтропии) — никто в здравом уме не будет этого делать не зная деталей, как минимум ценности аккаунта. Если бы это был пароль от кошелька биткоина на котором миллион биткоинов — думаю, в этом случае было бы проще меня найти и допросить альтернативными способами.
Во втором случае не был использован аргумент по поводу несоответствия ЧОП имеющимся определениям, думаю, грамотный адвокат легко бы это доказал (как было в первом случае), а так — рассмотрели ровно те доводы которые были — "не знал, не видел".
Я тоже совсем не сварщик, но мне кажется что вторая часть просто про другие типы объектов — подводные или подземные, и в обоих частях речь про "охраняемые в установленном порядке", которыми (в свою очередь) могут быть только объекты определяемые в 77-ФЗ — и там ни слова про ЧОП, исключительно про ведомственную охрану, ибо нигде больше (по крайней мере я не нашёл) нет определения "установленного порядка".
Так или иначе, только ведомственная и вневедомственная охрана могут применять какие-либо действия к нарушителями с целью недопущения и всего такого, но ни первые ни вторые не являются ЧОП, а ЧОП, соответственно, не может быть первым или вторым — то есть (по букве закона) прав у них нет никаких, кроме вызова полиции.
Osmotic communication немножко о другом — это подсознательное восприятие (и запоминание) информации, в обсуждаемом же случае проблема не восприятия а фильтрации, то есть если несколько человек говорят одновременно, то вы либо отфильтруете одного, максимум двух, либо запомните какие-то ключевые слова которые были произнесены всеми из них, но вряд-ли сможете запомнить (или хотя бы понять) детали того чём говорил каждый в отдельности, хотя бы потому что звуки будут в массе своей накладываться друг на друга.
Вероятно, это возможно в принципе (если бывает визуальная абсолютная память, то возможно бывает и абсолютная звуковая память), но вот собрание таких уникомов в количестве нескольких человек в одной комнате очень маловероятно, да и выделить речь кого-то одного пост-фактум тоже довольно непросто.
Попробуйте одновременно послушать три-четыре новостные программы и сравните то что запомнили с тем что было на самом деле.
MasterCard от N26 (она дебетовая) вполне работает. Может он не любит дебетовые карты других стран? Или не всех банков?
Если человек регулярно оплачивает счета — да. А если он в постоянном минусе — то риск ровно такой же, в то же время блокировка или снятие полной суммы — гарантия резервирования её для продавца, при любом виде карты. Практически все POS (в обычных магазинах) снимают всю сумму сразу, в онлайн — тут всё зависит, но обычно тоже сразу, кроме крупняков вроде амазона.
Это заблуждение. Она гарантирована (до определенных пределов) только если продавец сделал резервирование или снятие онлайн. Во всех остальных случаях — это риск продавца, банк не будет ему платить если на момент проведения транзакции она не вписывается в остаток лимита.
Но даже если снятие было сделано сразу и в полном объеме, но при этом без соблюдения последних защиных мер (типа пин-кода, Verified by VISA/Mastercard etc) — то даже в этом случае у продавца нет гарантий, потому что клиент скажет "это не я" и продавец останется ни с чем в 99% случаев, даже если клиент расплачивался в обычном магазине, но при этом не использовал пин-код с картой без чипа (или терминал не читает чипы) и расписался "за дядю", а продавец не проверил подпись.
Просто потому что вы дали им карт-бланш на платежи и им известен номер кредитки. Но если у них не получится снять деньги к карты — банк им ровно ничего не заплатит, а разбираться они будут с вами.
Если же вы в магазине первый раз — то маловероятно что вам "отвесят" товар без снятия или блокировки.
Единственной гарантией получения денег для продавца является блокировка (в полном объеме) или снятие (тоже в полном объеме) — иначе банк их пошлёт и будет прав, а тот факт что некоторые продавцы идут на риск откладывая оплату — ну риск он и в африке риск, это вовсе не потому что "банк заплатит".
Если каждый магазин сделает блокировку на всю сумму покупки сразу — не сможете. Обычно магазины именно так и поступают (трудно снять больше чем заблокировано, если без бубна и прочих нюансов), а заблокировать больше оставшегося лимита не получится, хотя может и есть банки которые это позволяют (в чём я сомневаюсь — банку это тоже невыгодно).
Причём, это работает ровно точно также и для дебетовых карт — т.е. если (условно) блокируется доллар/евро/рубль для "проверки" — то всё получится, а если вся сумма — то с точки зрения эмитента (и владельца) это уже снятая сумма (все блокировки накапливаются), разница между снятием и блокировкой исключительно в том что во втором случае блокировку можно отменить без последствий.
Я не исключаю что в РФ банки-эмитенты ведут себя иначе, но судя по моему опыту снятия денег у клиентов (и иногда разборок по поводу невозможности) это вряд-ли так.
Мой личный опыт владельца разных видов карт от разных банков на протяжении последних 20 лет (в ЕС), равно как и разборок как с продавцами так и банками, это тоже подтверждает — любой платёж (кроме "проверочных") — это сразу минус на карту (и дебет и кредит), с дебетовыми минус к тому что на счёте, с кредитовыми — минус к лимиту.
Два варианта когда потратить можно больше чем позволяет лимит/счёт — это когда карту "прокатывают" или платёж идёт оффлайн (она привязана к Google/Apple/Samsung etc Pay и нет связи) — т.е. платёж фактически отложен, но и там есть свои нюансы. У меня такой случай был — сервис аренды авто "прокатил" мою карту и не получил денег, потому что на момент попытки снятия (через пару недель) остаток лимита не позволил, банк их послал, я мог бы тоже (другая страна, к тому же не в ЕС) — но решили вопрос честно.
mktemp, в теории, должен попробовать другое имя если сгенерированное уже занято, но это зависит от конкретной версии, наверное.
Плюс, гарантируется что если он завершился успешно, то файл (или директорий) был создан с этим именем (именно создан — т.е. его там не было раньше) — а если сначала генерить имя, а потом "вручную" пытаться создать его — это race condition, пусть и с очень низкой вероятностью (хотя как знать, что там в random, может он глючной).
Но основная суть в том что mktemp проще чем приведённая в статье конструкция, выполняющая ту же функцию.
О да… Расскажите про это автору osync — 6503 строчки на bash, даже если убрать комментарии и пустые (их там мало), то всё равно наберется около 6000.
Модно, но иногда люди делают
sudo make installи аналогичные вещи. Был уже один такой баг, не помню в каком, но популярном пакете.Впрочем, случайно удалить свой домашний каталог тоже то ещё удовольствие.
Раньше я упирался в производительность сетки и не сильно парился — но после перехода на 10 Gbit стало не совсем всё равно, потому что 100 MiB/s и 200 MiB/s (больше HDD не позволяют) это таки разница в два раза, а данные гоняются часто, причём сотнями гигабайт — разница ощутима, а luks без тюнинга таки приводил к этой разнице.
Что касается NVMe — не сказал бы что это реально заметно, просто потому что он сам по себе (даже со всеми проседаниями) очень шустрый, и мои кейсы более чувствительны к iops, с этим как раз особых проблем нет.
С другой стороны, по мере увеличения количества одновременных писателей и читателей, разница всё же становится заметной, особенно когда он используется как iSCSI target по сетке больше чем одним потребителем.
Я просто расчитывал что поставлю NVMe и забуду про производительность навсегда (или по крайней мере очень надолго) — но эксперименты показывают, что я просто лишь чуть-чуть отодвинул эти проблемы в будущее, а с учётом того что новые (gen4) NVMe имеют скорость даже выше теоретической для AES (4-5 GiB/s) — про luks, наверное, можно забыть, как-то изворачиваться с тем чтобы всегда иметь доступ к железу (для использования нативного шифрования).
luks сразу на железе, поверх него lvm-thin и ext4. При тестах без fs (dd iflag=direct bs=4M) поверх luks скорость была около 1.3 GiB/s, без luks это 2.7 GiB, поверх fs через fio (iodepth=8 4k) — как говорил выше, около 3 GiB без luks и менее 1 GiB/s с luks. В обоих случаях прогон был по 20 GiB случайных данных, т.е. "честно" без компрессий и всего такого, одно ядро было загружено почти полностью (dmcrypt не использует многопоточность для одного устройства, по понятным причинам).
Если вы всё же прочитаете статью — поймёте почему это возможно в 2020. Я тоже был очень удивлён, особенно тем что mdraid1 из обычных дисков тоже просел (но там спас тюнинг и более низкая скорость самих дисков, хотя и на пределе).
Фишка в том что для большинства применений, особенно с сеткой в 1 Gbit это почти незаметно, но у меня другой случай и сетка 10 Gbit — не заметить было сложно.
benchmark не показывает реальную производительность — это совсем не то же самое что рамдиск (и любое другое блочное устройство) с luks поверху — даже с рамдиском вы не получите такого результата. В моём случае там были цифры больше 3 GiB/s, но это как раз и есть теория, которая сильно отличается от практики.
Проблема не в самом шифровании — проблема в том как оно используется dmcrypt (блокировки, буфера, etc), в статье на которую я дал ссылку всё это хорошо описано.
Если вас устраивает скорость шифрования — ок, отлично, я всего лишь хочу сказать что потери есть и в зависимости от use case они могут быть очень ощутимы, при этом теоретическая скорость существенно выше практической.
Зачем такой ужас? Есть же mktemp, который делает ровно то что нужно.
Зачем вообще нужен bash если его фичами нельзя пользоваться? Не говоря уже о том что сейчас сложно найти систему где его нет (разве что MCU), да и статья не о shell-scripts а конкретно о bash.
Все эти заявления на тему "непортабельно" изрядно устарели — если им следовать, то можно вообще прекратить разработку чего-то нового, ибо "не рекомендуется", но я подозреваю что реально совместимость с 99% систем нужна едва-ли в 1% случаев.
Что касается POSIX… то он тоже не без нареканий, если всё притянуть за уши к соответствию, весь сделанный прогресс можно откатить лет на 20 назад, ибо работать в чём-то что строго следует стандарту (и писать под это код) — примерно как бегать с будкой на голове и обмотав ноги цепью.
Если у вас интенсивный ввод-вывод (с кучей vm/контейнеров внутри) — очень даже заметная разница.
В моём случае разница была в три раза, как я уже сказал выше — 3 GiB/s без, и чуть меньше 1 GiB/s с LUKS (PNY CS3030 1TB, Intel i7-6700, aes-xts 256b). Путём небольшого тюнинга удалось поднять до почти 2 GiB/s (на длинных блоках), но это всё — что меня тоже не устроило, потому что на 4K было всё равно плохо.
Это зависит от размера операции, типа доступа, количества слоёв блочных устройств — т.е. если у вас softraid => luks => lvm и средний размер операции ввода-вывода в десятки килобайт — это будет намного медленней чем чистый luks поверх железа с блоками от 1 MiB или выше, а если это нагруженная система с кучей ввода-вывода — то проседание будет более очевидно, плюс нагрузка процессора ("железная" поддержка AES тоже не бесплатная, он просто быстрее но всё же жрёт процессор).
Просто проведите эксперимент — сделайте luks поверх ramdisk и пропустите по нему fio с блоками по 4K — и скажите, получили вы "паспортную" скорость AES (гигабайты/c) или нет (как сделали Cloudflare). Если уж с памятью не получается (у них не получилось, у меня тоже) — то что уж про все остальные устройства говорить.
Да, у меня действительно настолько рандомный пароль — я пользуюсь генератором, каждый сайт получает свой пароль и почти рандомный логин/email (только домен неизменен), так что успехов тем кто его будет пробовать.
На действительно важные сайты (банки, paypal etc) у меня к тому же 2FA, а с запоминанием всего этого проблем нет благодаря KeePass.
Это в теории, при шифровании очень длинных блоков в
вакуумепамяти. На практике, если вы его пропускаете через LUKS, вы получаете намного меньшую производительность (особенно с длиной ключа 256 bit), а если вы вздумаете (вдруг) шифровать NVMe или толстый RAID тем же LUKS, то просядете конкретно ниже его реальной производительности.Когда я "в лоб" попытался навернуть LUKS на свой домашний сервер после установки NVMe, удивился низкой производительности (< 1 GiB/s, без него около 3 GiB/s), стал копать и обнаружил что с обычными дисками (HDD) тоже не всё так гладко (~30% ниже), в итоге наткнулся на блог Cloudflare, где очень хорошо разобран этот вопрос. Возможно, их патчи вошли в последние ядра, но до них — всё не очень радужно.
Это тем более печально что далеко не всегда можно воспользоваться встроенным шифрованием накопителей — например, если железо не ваше и шарится с кем-то ещё.
Чего именно вы опасаетесь? Вот мой реальный пароль от одного из аккаунтов на одном из сайтов (нет, не хабра) — 58CNTCzzL9Ls5hWZ — что вы с ним сделаете, не зная логина и собственно сайта? И это с учётом того что оставляя его здесь я рискую гораздо больше чем на каком-то сервисе который про меня знает только мой динамический IP, ОС и браузер.
А если отправить им SHA1, то на его реверс уйдут в лучшем годы работы всех устройств планеты (в нём 87 бит энтропии) — никто в здравом уме не будет этого делать не зная деталей, как минимум ценности аккаунта. Если бы это был пароль от кошелька биткоина на котором миллион биткоинов — думаю, в этом случае было бы проще меня найти и допросить альтернативными способами.
Во втором случае не был использован аргумент по поводу несоответствия ЧОП имеющимся определениям, думаю, грамотный адвокат легко бы это доказал (как было в первом случае), а так — рассмотрели ровно те доводы которые были — "не знал, не видел".
Я тоже совсем не сварщик, но мне кажется что вторая часть просто про другие типы объектов — подводные или подземные, и в обоих частях речь про "охраняемые в установленном порядке", которыми (в свою очередь) могут быть только объекты определяемые в 77-ФЗ — и там ни слова про ЧОП, исключительно про ведомственную охрану, ибо нигде больше (по крайней мере я не нашёл) нет определения "установленного порядка".
Так или иначе, только ведомственная и вневедомственная охрана могут применять какие-либо действия к нарушителями с целью недопущения и всего такого, но ни первые ни вторые не являются ЧОП, а ЧОП, соответственно, не может быть первым или вторым — то есть (по букве закона) прав у них нет никаких, кроме вызова полиции.
Osmotic communication немножко о другом — это подсознательное восприятие (и запоминание) информации, в обсуждаемом же случае проблема не восприятия а фильтрации, то есть если несколько человек говорят одновременно, то вы либо отфильтруете одного, максимум двух, либо запомните какие-то ключевые слова которые были произнесены всеми из них, но вряд-ли сможете запомнить (или хотя бы понять) детали того чём говорил каждый в отдельности, хотя бы потому что звуки будут в массе своей накладываться друг на друга.
Вероятно, это возможно в принципе (если бывает визуальная абсолютная память, то возможно бывает и абсолютная звуковая память), но вот собрание таких уникомов в количестве нескольких человек в одной комнате очень маловероятно, да и выделить речь кого-то одного пост-фактум тоже довольно непросто.
Попробуйте одновременно послушать три-четыре новостные программы и сравните то что запомнили с тем что было на самом деле.