То, что люди знают МОЙ номер не означает, что я им дал его для общения где-нибудь ещё, кроме телефонных звонков и после этого не забанил их у себя, например, то есть отозвал право мне звонить.
Какой-то совершенно притянутый за уши пример.
Возьмем аналогию:
Вы дали кому-то свой физический почтовый адрес (грузы возить). Этот кто-то его записал, и в какой-то момент ему транспортная служба сообщила "по этому адресу теперь можно не только Камаз-ами позвонить груз доставить, но и курьера послать, потому что вы нормальную дорогу к себе проложили.
Возмущаться будем?
Или нужно возмущаться не по поводу оповещения, а что этот кто-то адрес записал?
В игровых магазинах полно игр, которые отлично идут на этой конфигурации. Людей, которые заранее согласны, что в 'современные игры' в 4k поиграть не получится (точнее, это не стоит той цены, которую за это заплатить надо) — и будут брать. А рендерингом и обучением нейросетей обычный покупатель и не занимается.
Ответ такой: можно считать, что эмуляция. Независимо от того, как оно есть 'на самом деле'. Правда, от этого термина возникает вопрос "эмуляция чего?", поэтому лучше бы взять другой.
Следующий вопрос, как тут указывают выше — и что с этим ответом делать?
Идея выглядит рабочей, но…
Тут же рядом хотелось и мета-информацию о том, что вообще переписка была и вообще список контактов на посторонние сервера не отдавать.
Как утерявший устройство и потом затребовавший восстановление доступа к учетке (потому что пока устройство есть — пароля вводить не надо и потому он забывается) вообще список контактов получит, с которых потом старые беседы скачать можно?
Вообще, когда-то уже довольно давно я описывал, хотя и довольно коряво, способ борьбы с утратой пароля, который заодно сильно облегчит проблему бакапов сообщений. Но оно требует, чтобы у человека как минимум три физических артефакта было, которые на учетку завязано. Пока слишком жирная хочушка.
Можно предложить, пожалую, еще один способ — автоматизировать разделение основного ключ на несколько частей и раздачу его нескольким контактам.
После чего, тот кто утерял доступ к своей учетке, может пообщаться с ними по сторонним каналам, собрать кусочки ключевой информации и полностью восстановить доступ ко всему, что было.
то могут быть варианты с репликацией аки в распределённых системах.
Тут есть сложность в том, что речь идет(вроде бы) о секретных чатах. Нужно еще где-то ключики ко всему шифрованию взять, причем не храня их на сервере на случай 'ой, я пароль забыл, давайте его сбросим'.
Или мы всё-таки изучаем криптографию и идём читать про Signal Protocol, Double Ratchet Algorithm, OMEMO и узнаем, как можно организовать end2end шифрование с множеством одновременных участников.
А какие протоколы читать, чтобы закрыть тот самый очень частый случай для популярного месседжера 'я пароль забыл, но хочу старые сообщения увидеть'? Если этой возможности не будет — месседжер в прессе, обзорах и при личном общении просто размажут и настойчиво предложат 'оно неудобное, пользуйтесь лучше вот этим'.
почему Saved Messages нельзя сделать зашифрованными?
Потому что большей части пользователей возможность сказать 'ой, я пароль забыл' с последующим его восстановлением важна. Причем так, чтобы все старые сообщения оставались доступными?
А кто параноик, может вместо встроенной функции копировать сообщение в любимую программу для заметок, которая все что хочется шифровать умеет.
Даже безотносительно самого таргетинга, мне ютуб с завидным упрямством суёт ролики, которые я уже просмотрел от начала до конца. Что это? Зачем? Для чего?
Если ему говорить, что "не интересно, потому что уже посмотрел" — практически перестает.
Если у вас там такие крутые «алгоритмы», то неужели так трудно влепить элементарный фильтр на основе истории просмотра?
А они и влепили. И, похоже, средний человек любит пересматривать ролики — потому и повторяют. А остальным приходится объяснять, что они не средние.
И ну да, разуметься, это не работает, если явно запретить ютубу и гуглу себя отслеживать баннерозками, обрезателями кук итд итп.
Смартфон удобен тем, что его можно положить в карман.
Только учиться с таких все таки, наверное, не стоит. Мелкий же слишком. Хотя бы "если бы я был султан" — то запрет бы проводил по наличию подключенной клавиатуры. Потому что экранная для нормальной работы (кроме "выбрать вариант из теста") мало пригодна.
Не нужно преувеличивать способность человека придумать систему генерации паролей. Если бы это было просто — то предупреждений вида 'не используйте дату рождения' не было бы. А 'хитрые алгоритмы' уже давно в криптографии придуманы.
Если хочется самодельной системы — то сразу надо что-то вроде password = base64(pbkdf2(secret, username@url_cайта))
secret помним наизусть. Сам калькулятор этой штуки запускается на железке, которая принципиально оффлайновая и залита со всех сторон в эпоксидку — чтобы злые хакеры не добрались и прошивку не подминили.
Не лучше ли держать в голове пару десятков фраз
Не лучше. Потому что голова человек очень плохо запоминает именно рандомные фразы, даже если построены таким образом. Две-три-шесть штуки, которыми постоянно пользуешься — нормально. Все больше — забудешь и начнешь путаться 'да как же там было-то?'
А если в построении есть какая-то система — то уже имеем резкое уменьшение энтропии.
Какое нахрен тогда 5G, если им надо технический долг отдавать и баги фиксить критичные…
Потому что смысла отдавать его нет. Весь этот голосовой трафик стремительно замещается просто передачей данных. Где проверку абонента можно сделать прямо средствами самого устройства, а не транспортной сети. Ну вот как никто особо не следить за IP адресами собеседников в месседждерах. Потому что какая разница, какие они?
Тем что это не дата. А timestamp. Нужно поле с типом даты. Как в "договор заключен 3 февраля 2021 года".
"2021-02-03T22:46:33.0640330+03:00" — передаем это в систему, находящуюся в зоне Владивостока. Десериализуем в локальную переменную. Пытаемся напечатать эту самую дату как дату и видим что?
при чем тут браузер?
В качестве примера одной из реализаций сериализатора-десериализатора.
Это все хорошо, но вопрос был, к каким проблемам может проводить Deserialize(Seialize(obj))
Ну вот именно к таким. И надо следить, чтобы они не возникли. Например, не пользоваться XML для формата сериализации даты. JSON, кстати, не сильно лучше — что получится при наивном подходе, если в бразуере, запущенном в таймзоне MSK попытаться сериализовать объект, представляющий сегодняшнюю дату?
Какая тут ошибка может возникнуть? Deserialize(Seialize(obj)) === obj.
Где то так:
obj — дата. сериализация и десериализация — на разных серверах. Где настроены разные таймзоны да еще базу данных таймзон забыли на некоторых обновить. Ну просто потому что языки сервисов разные и они не одновременно это делают. В результате один сервер думает, что в Москве летнее время есть, а другой — что его нет. Оригинальный запрос — генерируется где-нибудь внутри бразуера у пользователя во Владивостоке. Ну и так далее.
Особенно весело, если сериализация — xml и для типа используется слишком правильный тип xsd:date. Который, сюрприз, от таймзоны зависит. У него смещение таймзоны есть. И как правильно работать с этим смещением — зависит от фантазии разработчиков библиотеки. В результате сериализуем одну дату на одном узле, а на соседнем, если не повезет, получаем на день меньше или позднее.
Из статьи не понял, у кого в конце концов акции остались. У всей этот толпы с reddit? Т.е. теперь они голосующие владельцы и могут на компанию влияние оказывать? Например, точно так же пообщавшись директоров назначать/снимать?
То, что люди знают МОЙ номер не означает, что я им дал его для общения где-нибудь ещё, кроме телефонных звонков и после этого не забанил их у себя, например, то есть отозвал право мне звонить.
Какой-то совершенно притянутый за уши пример.
Возьмем аналогию:
Вы дали кому-то свой физический почтовый адрес (грузы возить). Этот кто-то его записал, и в какой-то момент ему транспортная служба сообщила "по этому адресу теперь можно не только Камаз-ами
позвонитьгруз доставить, но и курьера послать, потому что вы нормальную дорогу к себе проложили.Возмущаться будем?
Или нужно возмущаться не по поводу оповещения, а что этот кто-то адрес записал?
В игровых магазинах полно игр, которые отлично идут на этой конфигурации. Людей, которые заранее согласны, что в 'современные игры' в 4k поиграть не получится (точнее, это не стоит той цены, которую за это заплатить надо) — и будут брать. А рендерингом и обучением нейросетей обычный покупатель и не занимается.
Более того, оно не только nested, но и закольцовано. Т.е. в графе зависимостей 'во вселенной A эмулируют вселенную B' есть циклы.
Ответ такой: можно считать, что эмуляция. Независимо от того, как оно есть 'на самом деле'. Правда, от этого термина возникает вопрос "эмуляция чего?", поэтому лучше бы взять другой.
Следующий вопрос, как тут указывают выше — и что с этим ответом делать?
Идея выглядит рабочей, но…
Тут же рядом хотелось и мета-информацию о том, что вообще переписка была и вообще список контактов на посторонние сервера не отдавать.
Как утерявший устройство и потом затребовавший восстановление доступа к учетке (потому что пока устройство есть — пароля вводить не надо и потому он забывается) вообще список контактов получит, с которых потом старые беседы скачать можно?
Вообще, когда-то уже довольно давно я описывал, хотя и довольно коряво, способ борьбы с утратой пароля, который заодно сильно облегчит проблему бакапов сообщений. Но оно требует, чтобы у человека как минимум три физических артефакта было, которые на учетку завязано. Пока слишком жирная хочушка.
Можно предложить, пожалую, еще один способ — автоматизировать разделение основного ключ на несколько частей и раздачу его нескольким контактам.
После чего, тот кто утерял доступ к своей учетке, может пообщаться с ними по сторонним каналам, собрать кусочки ключевой информации и полностью восстановить доступ ко всему, что было.
Тут есть сложность в том, что речь идет(вроде бы) о секретных чатах. Нужно еще где-то ключики ко всему шифрованию взять, причем не храня их на сервере на случай 'ой, я пароль забыл, давайте его сбросим'.
Предложить — несложно. Пользоваться — сложно. С бакапами регулярно ошибаются и их утрачивают даже те люди, для которых это работа.
А какие протоколы читать, чтобы закрыть тот самый очень частый случай для популярного месседжера 'я пароль забыл, но хочу старые сообщения увидеть'? Если этой возможности не будет — месседжер в прессе, обзорах и при личном общении просто размажут и настойчиво предложат 'оно неудобное, пользуйтесь лучше вот этим'.
Потому что большей части пользователей возможность сказать 'ой, я пароль забыл' с последующим его восстановлением важна. Причем так, чтобы все старые сообщения оставались доступными?
А кто параноик, может вместо встроенной функции копировать сообщение в любимую программу для заметок, которая все что хочется шифровать умеет.
Даже безотносительно самого таргетинга, мне ютуб с завидным упрямством суёт ролики, которые я уже просмотрел от начала до конца. Что это? Зачем? Для чего?
Если ему говорить, что "не интересно, потому что уже посмотрел" — практически перестает.
Если у вас там такие крутые «алгоритмы», то неужели так трудно влепить элементарный фильтр на основе истории просмотра?
А они и влепили. И, похоже, средний человек любит пересматривать ролики — потому и повторяют. А остальным приходится объяснять, что они не средние.
И ну да, разуметься, это не работает, если явно запретить ютубу и гуглу себя отслеживать баннерозками, обрезателями кук итд итп.
Смартфон удобен тем, что его можно положить в карман.
Только учиться с таких все таки, наверное, не стоит. Мелкий же слишком. Хотя бы "если бы я был султан" — то запрет бы проводил по наличию подключенной клавиатуры. Потому что экранная для нормальной работы (кроме "выбрать вариант из теста") мало пригодна.
Не нужно преувеличивать способность человека придумать систему генерации паролей. Если бы это было просто — то предупреждений вида 'не используйте дату рождения' не было бы. А 'хитрые алгоритмы' уже давно в криптографии придуманы.
Если хочется самодельной системы — то сразу надо что-то вроде
password = base64(pbkdf2(secret, username@url_cайта))secret помним наизусть. Сам калькулятор этой штуки запускается на железке, которая принципиально оффлайновая и залита со всех сторон в эпоксидку — чтобы злые хакеры не добрались и прошивку не подминили.
Не лучше ли держать в голове пару десятков фраз
Не лучше. Потому что голова человек очень плохо запоминает именно рандомные фразы, даже если построены таким образом. Две-три-шесть штуки, которыми постоянно пользуешься — нормально. Все больше — забудешь и начнешь путаться 'да как же там было-то?'
А если в построении есть какая-то система — то уже имеем резкое уменьшение энтропии.
Потому что смысла отдавать его нет. Весь этот голосовой трафик стремительно замещается просто передачей данных. Где проверку абонента можно сделать прямо средствами самого устройства, а не транспортной сети. Ну вот как никто особо не следить за IP адресами собеседников в месседждерах. Потому что какая разница, какие они?
Тем что это не дата. А timestamp. Нужно поле с типом даты. Как в "договор заключен 3 февраля 2021 года".
"2021-02-03T22:46:33.0640330+03:00" — передаем это в систему, находящуюся в зоне Владивостока. Десериализуем в локальную переменную. Пытаемся напечатать эту самую дату как дату и видим что?
В качестве примера одной из реализаций сериализатора-десериализатора.
Это все хорошо, но вопрос был, к каким проблемам может проводить Deserialize(Seialize(obj))
Ну вот именно к таким. И надо следить, чтобы они не возникли. Например, не пользоваться XML для формата сериализации даты. JSON, кстати, не сильно лучше — что получится при наивном подходе, если в бразуере, запущенном в таймзоне MSK попытаться сериализовать объект, представляющий сегодняшнюю дату?
Где то так:
obj — дата. сериализация и десериализация — на разных серверах. Где настроены разные таймзоны да еще базу данных таймзон забыли на некоторых обновить. Ну просто потому что языки сервисов разные и они не одновременно это делают. В результате один сервер думает, что в Москве летнее время есть, а другой — что его нет. Оригинальный запрос — генерируется где-нибудь внутри бразуера у пользователя во Владивостоке. Ну и так далее.
Особенно весело, если сериализация — xml и для типа используется слишком правильный тип xsd:date. Который, сюрприз, от таймзоны зависит. У него смещение таймзоны есть. И как правильно работать с этим смещением — зависит от фантазии разработчиков библиотеки. В результате сериализуем одну дату на одном узле, а на соседнем, если не повезет, получаем на день меньше или позднее.
Не выйдет. Точнее, выродится в почти централизованный. Потому что больше узел, тем больше он пропускает данных, тем выгодней.
Из статьи не понял, у кого в конце концов акции остались. У всей этот толпы с reddit? Т.е. теперь они голосующие владельцы и могут на компанию влияние оказывать? Например, точно так же пообщавшись директоров назначать/снимать?