Ну тут как. Раз вы используете КВН для доступа к ресурсу, значит, доступ к ресурсу ограничен (неважно кем), иначе зачем вам КВН? Ну и ваш КВН наверняка не сотрудничает с Роскомнадзором, не подключен к системе запрещенных сайтов и все такое. В результате вырисовывается в чистом виде правонарушение, предусмотренное ст.13.52 КоАП РФ (нарушение порядка использования на территории РФ программно-аппаратных средств доступа к информационным ресурсам, информационно-телекоммуникационным сетям, доступ к которым ограничен)
Оплатить 50т.р. вы можете в любом банке РФ, а так же через Госуслуги в течение 30 дней
Ну, как мне видится, есть несколько вариантов 1) На нехорошем ресурсе стоит яндекс-метрика или еще какой-нибудь из "дружественных" трекеров 2) да нехорошего ресурса добрались физически и копаются в логах либо сделали владельцу предложение от которого он не смог отказаться 3) то же про впн-сервер 4) черный ящик у провайдера словил запрос на ресолв нехорошего ресурса 5) на клиенте гражданина стоит мессенджер Max анальный зонд
Господа, а подскажите за ДНС поподробнее. Вот, к примеру, есть роутер (192.168.1.1), на нем настроен DoH и КВН, причем КВН умный, ютубчик заворачивает в тоннель, а мейлрушечку отдает как есть. Есть клиент, допустим, телевизор. На нем в свойствах соединения указан DNS: 1.1.1.1. Все работает. Вопрос: как будет ресолв ютуба и мейлрушечки? Через дох, тоннель, или по классике в открытом виде? А если я на телевизоре пропишу DNS: 192.168.1.1 - пойдет через дох? А если прописать в DNS айпишник сервера квн, где по совместительству крутится dns? Понятно, что ресолв будет средствами моего сервера, но dns-запросы туда пойдут через тоннель или в открытом виде?
вот поддержу. Почему-то противники Security through obscurity подразумевают, что в качестве секретного алгоритма обязательно должна использоваться какая-нибудь никому не известная написанная на коленке хрень с кучей уязвимостей. Почему бы не использовать "Открытые и проверенные криптографические стандарты", но при этом не афишировать всем подряд какие именно?
Сдается мне, тут просто слишком широко трактуется термин "данные". Вот есть например окно. У него есть куча т.н. "данных": координаты, размер, цвет, прозрачность, маржины там всякие, оффсеты.... И вот у меня есть объект Window, который все нужное хранит у себя внутрях в удобном себе виде и избавляет меня от необходимости таскать все это отдельно - так это же прекрасно.
И есть бизнес-данные, с которыми мы работаем, которые мы получаем с веба, пишем/читаем в базу, как-то обрабатываем, сериализуем/десериализуем, показываем пользователю. Тот же User из примеров. И тут уже функциональный подход смотрится интереснее: отдельно есть структуры, в идеале иммутабельные, содержащие только данные, и отдельно методы их обработки. Всякие там фильтры, мапы, трансформы, аггрегирующие функции, да с возможностью комбинации, да еще с concurrency - разве это не прекрасно. Реактивщина к тому же легко подвязывается, тестировать именно бизнес-логику удобно.
Тот же getDisplayName() я бы вообще не стал пихать в класс/структуру User, ибо это не его дело знать, как там выводить надо. Может, в одном месте надо выводить "John Smith", в другом "J. Smith", в третьем "Smith, J.", а четвертом вообще "Mr. Smith" или какой-нибудь "Dr. Smith". Это надо делать на уровне представления в какой-нибудь вьюМодели, ну или сделать отдельный форматтер, если надо реюзать один формат в куче мест.
Про самсунгПей подтверждаю, надо самому запускать приложение, но там это изначально было сделано для поддержки эмуляции магнитной полосы (MST (Magnetic Secure Transmission), на Хабре про это есть, например, тут: https://habr.com/ru/companies/fondy/articles/322822/), что позволяло платить телефоном даже на терминалах, не оборудованных NFC. И тогда, помню, SamsungPay за это хейтили, мол, что это такое, какие-то приложения запускать, в ApplePay/GooglePay достаточно просто телефон приложить, 21 век же на дворе.
А вот мирПей у меня не так работает. Если экран включен при заблокированном телефоне или телефон был разблокирован слабой биометрией (лицом), то приложение запустится, но при оплате затребует сильную биометрию (палец) либо пин. Если телефон был изначально разблокирован сильной биометрией, то оплата пойдет без вопросов. Возможно, в вашем случае у вас отключена настройка "Запрос подтверждения при оплате", тогда да, платежи на сумму до 3т.р. будут проходить и с заблокированного устройства. Собственно, как и в случае с бесконтактной картой
Гуглопей же вроде так же работает. Если телефон был разблокирован сильной биометрией - достаточно просто приложить к терминалу и плата пройдет, если слабой биометрией или вообще не разблокирован - потребует разблокировку. В МирПей просто аналогично сделали.
Мне кажется, тут суть в другом. Изначальная идея ООП - это объединить данные и методы их обработки в некую единую сущность - объект. Для своего времени идея была прорывная: позволяла скрывать реализацию и выставлять наружу простой интерфейс, выносить общий код в родителя, и все такое, чем знаменито ООП. И не сказать, что оно плохо работает, тот же гуй на ООП вполне себе ложится. Потом научились делать многоядерные процессоры и ВНЕЗАПНО оказалось, что объекты с мутабельным стейтом очень плохо ложатся на многопоточность. Ну и, почесав репу, умные люди решили данные и методы разделить, но на качественно ином уровне: пусть у нас будут глупые данные (в идеале немутабельные) отдельно и функции для их обработки (в идеале чистые) отдельно. Получилось вполне неплохо: отлично параллелится и векторизуется, очень удобно писать автотесты. Модный реактивный поход тоже залетел. В итоге каждый подход хорош в своей области. Многие языки поддерживают оба похода, и это хорошо: UI с окошками и формочками удобнее писать на ООП, а обрабатывать данные с бэка, фильтровать, форматировать и байндить на UI удобнее функциональщиной. А когда пытаются натянуть одно на другое - начинаются непонимания, конфликты, боль и страдания.
Это как ОТО и квантовая механика: каждая неплохо работает в своих границах применимости, а если попытаться натянуть одно на другое - фигня получается. Ученые пытаются разработать Единую Теорию Всего - пока выходит не очень, но кто знает. Глядишь, и в программировании изобретут подход, сочетающий преимущества ООП и функциональщины.
Сдается мне, тут как раз тот случай, когда можно посмотреть в сторону яблока:
1) Доступ через системные сервисы. К примеру, понадобилась приложению фотка для аватара - открывается системная галерея, выбирается фотка и только одна эта фотка отдается приложению. Доступа к другим фото, а уж тем более ко всему стораджу, у приложения нет.
Аналогично можно сделать с контактами, файлами, да вообще со всем.
2) Более гибкое разграничение доступа. К примеру, приложению таки нужен доступ именно ко всем фото (например, чтобы найти похожие и сделать коллаж). Ок, просим у пользователя пермишн и получаем доступ только к фото. В музыку, фильмы и прочие документы доступа нет.
3) Ограничение доступа по времени. Например, однократный, только когда приложение активно, перманентный. Вроде как такое есть уже в новых андроидах
Насчет браслетов не знаю, но некоторые банки, например, Авангард, предлагают специальные стикеры.
Можно налепить хоть на лоб и расплачиваться бесконтактно :)
Ну тут как. Раз вы используете КВН для доступа к ресурсу, значит, доступ к ресурсу ограничен (неважно кем), иначе зачем вам КВН? Ну и ваш КВН наверняка не сотрудничает с Роскомнадзором, не подключен к системе запрещенных сайтов и все такое.
В результате вырисовывается в чистом виде правонарушение, предусмотренное ст.13.52 КоАП РФ (нарушение порядка использования на территории РФ программно-аппаратных средств доступа к информационным ресурсам, информационно-телекоммуникационным сетям, доступ к которым ограничен)
Оплатить 50т.р. вы можете в любом банке РФ, а так же через Госуслуги в течение 30 дней
Ну, как мне видится, есть несколько вариантов
1) На нехорошем ресурсе стоит яндекс-метрика или еще какой-нибудь из "дружественных" трекеров
2) да нехорошего ресурса добрались физически и копаются в логах либо сделали владельцу предложение от которого он не смог отказаться
3) то же про впн-сервер
4) черный ящик у провайдера словил запрос на ресолв нехорошего ресурса
5) на клиенте гражданина стоит
мессенджер Maxанальный зондНет, конечно. Про избирательность закона что-нибудь слышали?
Господа, а подскажите за ДНС поподробнее. Вот, к примеру, есть роутер (192.168.1.1), на нем настроен DoH и КВН, причем КВН умный, ютубчик заворачивает в тоннель, а мейлрушечку отдает как есть.
Есть клиент, допустим, телевизор. На нем в свойствах соединения указан DNS: 1.1.1.1. Все работает.
Вопрос: как будет ресолв ютуба и мейлрушечки? Через дох, тоннель, или по классике в открытом виде? А если я на телевизоре пропишу DNS: 192.168.1.1 - пойдет через дох?
А если прописать в DNS айпишник сервера квн, где по совместительству крутится dns? Понятно, что ресолв будет средствами моего сервера, но dns-запросы туда пойдут через тоннель или в открытом виде?
Сразу куча вопросов. Как обеспечить помехоустойчивость и коррекцию ошибок? Эквалайзер? Микширование?
попросить ИИ (возможно, другой) проанализировать его на безопасность и закрыть найденные дыры
хм, если все запущенное оказывается в ring0 и должно добровольно отдать процессор, вирус может быть ОЧЕНЬ интересным
вот поддержу. Почему-то противники Security through obscurity подразумевают, что в качестве секретного алгоритма обязательно должна использоваться какая-нибудь никому не известная написанная на коленке хрень с кучей уязвимостей. Почему бы не использовать "Открытые и проверенные криптографические стандарты", но при этом не афишировать всем подряд какие именно?
Сдается мне, тут просто слишком широко трактуется термин "данные". Вот есть например окно. У него есть куча т.н. "данных": координаты, размер, цвет, прозрачность, маржины там всякие, оффсеты.... И вот у меня есть объект Window, который все нужное хранит у себя внутрях в удобном себе виде и избавляет меня от необходимости таскать все это отдельно - так это же прекрасно.
И есть бизнес-данные, с которыми мы работаем, которые мы получаем с веба, пишем/читаем в базу, как-то обрабатываем, сериализуем/десериализуем, показываем пользователю. Тот же User из примеров. И тут уже функциональный подход смотрится интереснее: отдельно есть структуры, в идеале иммутабельные, содержащие только данные, и отдельно методы их обработки. Всякие там фильтры, мапы, трансформы, аггрегирующие функции, да с возможностью комбинации, да еще с concurrency - разве это не прекрасно. Реактивщина к тому же легко подвязывается, тестировать именно бизнес-логику удобно.
Тот же getDisplayName() я бы вообще не стал пихать в класс/структуру User, ибо это не его дело знать, как там выводить надо. Может, в одном месте надо выводить "John Smith", в другом "J. Smith", в третьем "Smith, J.", а четвертом вообще "Mr. Smith" или какой-нибудь "Dr. Smith". Это надо делать на уровне представления в какой-нибудь вьюМодели, ну или сделать отдельный форматтер, если надо реюзать один формат в куче мест.
А вам именно синусы нужны или частотный анализ вообще? А то для акустических сигналов вейвлеты (wavelet) хорошо подходят
Про самсунгПей подтверждаю, надо самому запускать приложение, но там это изначально было сделано для поддержки эмуляции магнитной полосы (MST (Magnetic Secure Transmission), на Хабре про это есть, например, тут: https://habr.com/ru/companies/fondy/articles/322822/), что позволяло платить телефоном даже на терминалах, не оборудованных NFC. И тогда, помню, SamsungPay за это хейтили, мол, что это такое, какие-то приложения запускать, в ApplePay/GooglePay достаточно просто телефон приложить, 21 век же на дворе.
А вот мирПей у меня не так работает. Если экран включен при заблокированном телефоне или телефон был разблокирован слабой биометрией (лицом), то приложение запустится, но при оплате затребует сильную биометрию (палец) либо пин. Если телефон был изначально разблокирован сильной биометрией, то оплата пойдет без вопросов. Возможно, в вашем случае у вас отключена настройка "Запрос подтверждения при оплате", тогда да, платежи на сумму до 3т.р. будут проходить и с заблокированного устройства. Собственно, как и в случае с бесконтактной картой
Гуглопей же вроде так же работает. Если телефон был разблокирован сильной биометрией - достаточно просто приложить к терминалу и плата пройдет, если слабой биометрией или вообще не разблокирован - потребует разблокировку. В МирПей просто аналогично сделали.
Мне кажется, тут суть в другом.
Изначальная идея ООП - это объединить данные и методы их обработки в некую единую сущность - объект. Для своего времени идея была прорывная: позволяла скрывать реализацию и выставлять наружу простой интерфейс, выносить общий код в родителя, и все такое, чем знаменито ООП. И не сказать, что оно плохо работает, тот же гуй на ООП вполне себе ложится.
Потом научились делать многоядерные процессоры и ВНЕЗАПНО оказалось, что объекты с мутабельным стейтом очень плохо ложатся на многопоточность. Ну и, почесав репу, умные люди решили данные и методы разделить, но на качественно ином уровне: пусть у нас будут глупые данные (в идеале немутабельные) отдельно и функции для их обработки (в идеале чистые) отдельно. Получилось вполне неплохо: отлично параллелится и векторизуется, очень удобно писать автотесты. Модный реактивный поход тоже залетел.
В итоге каждый подход хорош в своей области. Многие языки поддерживают оба похода, и это хорошо: UI с окошками и формочками удобнее писать на ООП, а обрабатывать данные с бэка, фильтровать, форматировать и байндить на UI удобнее функциональщиной. А когда пытаются натянуть одно на другое - начинаются непонимания, конфликты, боль и страдания.
Это как ОТО и квантовая механика: каждая неплохо работает в своих границах применимости, а если попытаться натянуть одно на другое - фигня получается. Ученые пытаются разработать Единую Теорию Всего - пока выходит не очень, но кто знает. Глядишь, и в программировании изобретут подход, сочетающий преимущества ООП и функциональщины.
Только Ситхи все возводят в абсолют
у меня уже установленное соединение по AWG не разорвалось и через него все продолжало работать. О сбое только тут узнал.
я правильно понял, что к Evernote претензий особо и нет, если не считать утерянный клиентом фактор авторизации и возможный уход/слив данных?
По удобству и функциональности все устраивает?
Сдается мне, тут как раз тот случай, когда можно посмотреть в сторону яблока:
1) Доступ через системные сервисы. К примеру, понадобилась приложению фотка для аватара - открывается системная галерея, выбирается фотка и только одна эта фотка отдается приложению. Доступа к другим фото, а уж тем более ко всему стораджу, у приложения нет.
Аналогично можно сделать с контактами, файлами, да вообще со всем.
2) Более гибкое разграничение доступа. К примеру, приложению таки нужен доступ именно ко всем фото (например, чтобы найти похожие и сделать коллаж). Ок, просим у пользователя пермишн и получаем доступ только к фото. В музыку, фильмы и прочие документы доступа нет.
3) Ограничение доступа по времени. Например, однократный, только когда приложение активно, перманентный. Вроде как такое есть уже в новых андроидах
Можно налепить хоть на лоб и расплачиваться бесконтактно :)