Забей в гугл "верификация третьей стороной в телеграме", должно выдать ссылку на их доку по этому вопросу. Я тоже сначала прифигел мол "ого, прям настолько сотрудничают", но по ходу у Паши Дурова работают толковые креативщики и предусмотрели занятный функционал.
Мастер пароль в обычных менеджерах ставится на список этих самых паролей. Т.е. чтобы получить список паролей нам нужно знать и мастер пароль, и иметь зашифрованный список на руках. Тут ноль вопросов и безопасней только хранить в своей голове (либо аппаратные ключи, но это не для обычных смертных).
В предлагаемом решении нам нужно знать только пароль (алгоритм в криптографии всегда считается известен), по которому будем подбирать доступ к интересующим сайтам. А, ну и логин/почту, но это зачастую открытая инфа.
На всякий подчеркну ещё раз что всё это "не очень" именно как массовое решение, к которому будут проявлять интерес условные хакеры. Чисто для себя побаловаться -- норм.
С точки зрения безопасности это конечно никуда не годиться: просто подсматриваем один пароль и зная алгоритм получаем ВСЮ базу паролей пользователя. Т.е. грубо говоря сидим в кафешке с ноутом и нам понадобилось перелогинится на сайте любителей домашних ежей. Сайт не критичен, мы не боимся что нашу учётку на нём угонят поэтому не шибко смотрим по сторонам и тем более на верх. А наверху камера и скучающий охранник уже пробивает на каких сайтах без двойной авторизации сидит данный пользователь.
Поэтому как личная фича может и жизнеспособно, но как массовый стандарт -- точно нет.
Ну и ещё несколько весёлых вещей:
требования к паролю (спецсимволы, регистр). Можно конечно задать алгоритм построения предусматривающий и это, но всегда найдется тот самый упоротый ресурс, на котором ваш алгоритм не будет работать.
пароль взломали на сайте А из-за админов (например профукали базу) и вас просят его поменять. Теперь вам нужно помнить что на сайте А у вас другой пароль.
порой пароль задаёте не вы, а вам выдают случайный и нужно только запомнить
если требуется несколько учётных записей на один ресурс -- у всех будет один и тот же пароль? Тоже не всегда хорошо (допустим мне нужно завести 10 учёток, и при этом расшарить доступ к каждой отдельному человеку, которые не должны пересекаться по доступу)
Не особо понял про константы и длл. Вся "прелесть" констант в том что компилятор явно прописывает значения в коде без каких либо переменных. И это приводит к "нежданчикам" когда в либе сначала одно значение, на его основе компилируется код использующий константу, далее либа заменяется на новую путём простой замены файла с иным значением и вуаля -- программа работает неправильно. Поэтому выносить в константы всё подряд не ок.
Я не знаком с java, поэтому нубский вопрос -- без throws в описании метода можно вызвать throw? Если да, то выглядит как прикольная фича, но в c# можно указать исключения в summary.
Ну и пример с callback был к тому, что на момент компиляции мы не можем знать всех исключений, которые прилетят из метода.
Я слабо представляю как это должно выглядеть. Самое банальное -- метод принимает делегат обратного вызова, который может выкинуть своё уникальное исключение.
Ну, стоит хоть немного понимать что ретранслируешь. Пример с IReadOnlyList ну прям вообще ни о чём (мягко говоря) и кажись даже у новичков нет проблем с пониманием как работает приведение типов. Выше уже упоминали что interface != class, и такое явное приведение допускается исходя из логики что разработчику известно больше, чем компилятору. Более того, со временем в C# добавили такую возможность как после проверки на тип сразу привести к нему в одну строку, например if(variable is MyType myType) { /* использование переменной myType */ } что как бы намекает.
По второму примеру вообще мимо: показано явное приведение, которое явно задекларировано в ЯП, повсеместно используется и при этом автор говорит что это нехорошо. Ну ок, автору виднее. =)
Хотя тут вся статья в духе Wat, чисто посмеяться -- норм. Но на практике конкретно эти вещи не шибко мешают, а вот например непонимания как работают константы может подкинуть реальных сюрпризов на практике.
Первая мысль при прочтении: "и это всё?" Ну т.е. "оно децентрализировано и работает". Окей, а как? Почему имеет смысл выбрать этот вариант, а не скажем дублировать бэкапы на 4-5 классических сервисах? По факту после прочтения статьи нужно идти и разбираться в основах IPFS.
Отдельно раздражает кликбейтный заголовок и наличие в тегах "Веб-разработка + DevOps" которых по факту тут нет.
Они кажись ещё год назад грозились всё это добро отключить. Так что в этой новости для меня нове скорее что оно до сих пор работало. А, ну и вездесущий ИИ, куда же без него... Лучше бы таки вернули возможность в системном календаре видить запланированные задачи, как это было в старом Mail.
Я конечно понимаю что против монополиста воевать сложно, но кажись если людей не перетянул текущий edge, то остается только ждать что Chrome превратится в тыкву, и пользователи будуть искать альтернативу.
Ну или тот же встроенный Copilot таки сможет перетянуть часть людей (хотя с учетом того что они вынесли его отдельным приложением, может и не сработает)
CrowdStrike -- это не тот, из-за которого лежали все терминалы на аэропортах?
Можно небольшое уточнение: просили расшарить экран и просто подсказывать что к чему или дать прям удалённый доступ?
Забей в гугл "верификация третьей стороной в телеграме", должно выдать ссылку на их доку по этому вопросу. Я тоже сначала прифигел мол "ого, прям настолько сотрудничают", но по ходу у Паши Дурова работают толковые креативщики и предусмотрели занятный функционал.
Ну, вкинуть аргументы почему статья не очень всё же лучше. Так читающий школьник поймёт почему это плохо.
Только SS+
Мастер пароль в обычных менеджерах ставится на список этих самых паролей. Т.е. чтобы получить список паролей нам нужно знать и мастер пароль, и иметь зашифрованный список на руках. Тут ноль вопросов и безопасней только хранить в своей голове (либо аппаратные ключи, но это не для обычных смертных).
В предлагаемом решении нам нужно знать только пароль (алгоритм в криптографии всегда считается известен), по которому будем подбирать доступ к интересующим сайтам. А, ну и логин/почту, но это зачастую открытая инфа.
На всякий подчеркну ещё раз что всё это "не очень" именно как массовое решение, к которому будут проявлять интерес условные хакеры. Чисто для себя побаловаться -- норм.
С точки зрения безопасности это конечно никуда не годиться: просто подсматриваем один пароль и зная алгоритм получаем ВСЮ базу паролей пользователя. Т.е. грубо говоря сидим в кафешке с ноутом и нам понадобилось перелогинится на сайте любителей домашних ежей. Сайт не критичен, мы не боимся что нашу учётку на нём угонят поэтому не шибко смотрим по сторонам и тем более на верх. А наверху камера и скучающий охранник уже пробивает на каких сайтах без двойной авторизации сидит данный пользователь.
Поэтому как личная фича может и жизнеспособно, но как массовый стандарт -- точно нет.
Ну и ещё несколько весёлых вещей:
требования к паролю (спецсимволы, регистр). Можно конечно задать алгоритм построения предусматривающий и это, но всегда найдется тот самый упоротый ресурс, на котором ваш алгоритм не будет работать.
пароль взломали на сайте А из-за админов (например профукали базу) и вас просят его поменять. Теперь вам нужно помнить что на сайте А у вас другой пароль.
порой пароль задаёте не вы, а вам выдают случайный и нужно только запомнить
если требуется несколько учётных записей на один ресурс -- у всех будет один и тот же пароль? Тоже не всегда хорошо (допустим мне нужно завести 10 учёток, и при этом расшарить доступ к каждой отдельному человеку, которые не должны пересекаться по доступу)
Не особо понял про константы и длл. Вся "прелесть" констант в том что компилятор явно прописывает значения в коде без каких либо переменных. И это приводит к "нежданчикам" когда в либе сначала одно значение, на его основе компилируется код использующий константу, далее либа заменяется на новую путём простой замены файла с иным значением и вуаля -- программа работает неправильно. Поэтому выносить в константы всё подряд не ок.
Я не знаком с java, поэтому нубский вопрос -- без throws в описании метода можно вызвать throw? Если да, то выглядит как прикольная фича, но в c# можно указать исключения в summary.
Ну и пример с callback был к тому, что на момент компиляции мы не можем знать всех исключений, которые прилетят из метода.
Я слабо представляю как это должно выглядеть. Самое банальное -- метод принимает делегат обратного вызова, который может выкинуть своё уникальное исключение.
Ну, стоит хоть немного понимать что ретранслируешь. Пример с IReadOnlyList ну прям вообще ни о чём (мягко говоря) и кажись даже у новичков нет проблем с пониманием как работает приведение типов. Выше уже упоминали что interface != class, и такое явное приведение допускается исходя из логики что разработчику известно больше, чем компилятору. Более того, со временем в C# добавили такую возможность как после проверки на тип сразу привести к нему в одну строку, например
if(variable is MyType myType) { /* использование переменной myType */ }что как бы намекает.По второму примеру вообще мимо: показано явное приведение, которое явно задекларировано в ЯП, повсеместно используется и при этом автор говорит что это нехорошо. Ну ок, автору виднее. =)
Хотя тут вся статья в духе Wat, чисто посмеяться -- норм. Но на практике конкретно эти вещи не шибко мешают, а вот например непонимания как работают константы может подкинуть реальных сюрпризов на практике.
Ради понимания: а почему на данный момент сроки отзыва сертификата довольно существены?
Первая мысль при прочтении: "и это всё?" Ну т.е. "оно децентрализировано и работает". Окей, а как? Почему имеет смысл выбрать этот вариант, а не скажем дублировать бэкапы на 4-5 классических сервисах? По факту после прочтения статьи нужно идти и разбираться в основах IPFS.
Отдельно раздражает кликбейтный заголовок и наличие в тегах "Веб-разработка + DevOps" которых по факту тут нет.
Они кажись ещё год назад грозились всё это добро отключить. Так что в этой новости для меня нове скорее что оно до сих пор работало. А, ну и вездесущий ИИ, куда же без него... Лучше бы таки вернули возможность в системном календаре видить запланированные задачи, как это было в старом Mail.
Я конечно понимаю что против монополиста воевать сложно, но кажись если людей не перетянул текущий edge, то остается только ждать что Chrome превратится в тыкву, и пользователи будуть искать альтернативу.
Ну или тот же встроенный Copilot таки сможет перетянуть часть людей (хотя с учетом того что они вынесли его отдельным приложением, может и не сработает)
Ого -- и даже не приплели защиту детей? Что- то новенькое.
Вы же в курсе что аудитория разных каналов будет пересекаться?
К почтовым сервисам неприменимо априори, т.к. они независимы и не подразумевают подтверждения доставки.
В меседжере... не уверен.
Будет забавно если это выстрелит и в итоге продлят ещё на кучу лет.