Это символы, похожие на перевернутые русские буквы, надерганные из разных наборов unicode.
Есть онлайн и не-онлайн генераторы, которые переворачивают атоматически
ʚ — например этот символ latin small letter closed open e (U+029A)
ʎ — очевидно, лямбда
итп
Ну мне, например, inbox не зашел. Слишком прикипел к удобству десятилетнего хлама. Хотя несколько фич из inbox мне очень понравились. Был очень рад, когда они постепенно переползали в gmail.
Собственно я видимо как раз тот средний пользователь, чьи хотелки в этом случае гугл удовлетворил полностью.
Про адекватные коэффициенты… закон гудхарта
Сталкивались ли вы с тем, что как только вы выбрали адекватную метрику для оценки сотрудников, как она переставала быть адекватной?)
В 90ые-начало 00хх, когда были крутые дневники с картинками, у меня были справочники по математике/химии, таблички неправильных глаголов, телефонные коды/столицы/часовые пояса стран, итп. Обычно в конце дневника.
Я просто закончил школу в 2003м.
Ну формально, два одинаковых треугольника расположенных ребром к ребру уже дадут бесконечное количество фигур. Если сдвинуть один относительно другого на 0.1 длины ребра — получаем одну фигуру. Сдвигаем 0.01L — получаем другую.
Так что количество фигур не только бесконечно, но и несчетно, если ограничений не вводить
Можно попробовать выпустить альтернативный клиент + обертку над API
В клиенте перед тем как шифровать всё телеграмовским алгоритмом — шифровать открытым ключом.
На стороне стороннего сервиса в обертке расшифровывать.
Только придется думать о независимом от телеграмма канале передачи открытого ключа от стороннего сервиса клиенту.
Ну очевидная (и скорее всего неправильная) реализация:
1. ТГ выступает в роли автоматизированного дропбокса
2. Вы своим открытым ключом шифруете свои данные и заливаете в ТГ.
3. При авторизации в стороннем сервисе (СС):
3.1. СС отдает вам свой открытый ключ напрямую (без посредничества ТГ) как? А хз — это один из самых сложных моментов в таких схемах.
3.2 Вы выкачиваете у телеграмма свои данные себе (не все, а только те, что нужны СС)
3.3. Расшифровываете их своим закрытым ключом, шифруете открытым ключом СС, отдаете обратно зашифрованные данные ТГ
3.4. ТГ отдает зашифрованные данные СС, они их там своим закрытым ключом расшифровывают.
Фуллскан портов — обыденность. Если ssh не прятать за port-knocking'ом и шодан и ботнеты о нем узнают.
Месяца два назад смотрел логи на своей VPS для домашних проектов, в нестандартный порт openvpn стучались также часто, как в стандартные порты ssh/ssl.
Не, сами данные всё-таки шифруются вот этим в качестве ключа для AES:
bytes::vector GenerateSecretBytes() {
auto result = bytes::vector(kSecretSize);
memset_rand(result.data(), result.size());
const auto full = ranges::accumulate(
result,
0ULL,
[](uint64 sum, gsl::byte value) { return sum + uchar(value); });
const auto mod = (full % 255ULL);
const auto add = 255ULL + 239 - mod;
auto first = (static_cast<uchar>(result[0]) + add) % 255ULL;
result[0] = static_cast<gsl::byte>(first);
return result;
}
Вопрос в том, где этот секрет хранится. Если только на клиенте — то end-to-end де-юре.
Я не смог проследить за перемещениями секрета — просто смотрел код глазами, продебажить возможности нет сейчас.
CountPasswordHashForSecret используется только в методе FormController::submitPassword
Что бы он ни делал — он не отправляет данные в облако
Прикольное устройство, правда в продаже не нашел…
Есть онлайн и не-онлайн генераторы, которые переворачивают атоматически
ʚ — например этот символ latin small letter closed open e (U+029A)
ʎ — очевидно, лямбда
итп
Первый должен будет найти собственно конец строки.
Собственно я видимо как раз тот средний пользователь, чьи хотелки в этом случае гугл удовлетворил полностью.
закон гудхарта
Сталкивались ли вы с тем, что как только вы выбрали адекватную метрику для оценки сотрудников, как она переставала быть адекватной?)
Я просто закончил школу в 2003м.
На русском, к сожалению, не нашел перевода
Я имею ввиду нечто такое
Отношение A / (A+B) может принимать любое значение от 0 до 1.
Множество точек в [0,1] бесконечно и несчетно.
Так что количество фигур не только бесконечно, но и несчетно, если ограничений не вводить
В клиенте перед тем как шифровать всё телеграмовским алгоритмом — шифровать открытым ключом.
На стороне стороннего сервиса в обертке расшифровывать.
Только придется думать о независимом от телеграмма канале передачи открытого ключа от стороннего сервиса клиенту.
Хотя… *картинка с троллейбусом*
1. ТГ выступает в роли автоматизированного дропбокса
2. Вы своим открытым ключом шифруете свои данные и заливаете в ТГ.
3. При авторизации в стороннем сервисе (СС):
3.1. СС отдает вам свой открытый ключ напрямую (без посредничества ТГ) как? А хз — это один из самых сложных моментов в таких схемах.
3.2 Вы выкачиваете у телеграмма свои данные себе (не все, а только те, что нужны СС)
3.3. Расшифровываете их своим закрытым ключом, шифруете открытым ключом СС, отдаете обратно зашифрованные данные ТГ
3.4. ТГ отдает зашифрованные данные СС, они их там своим закрытым ключом расшифровывают.
Зачем в этой схеме ТГ? А не знаю.
Месяца два назад смотрел логи на своей VPS для домашних проектов, в нестандартный порт openvpn стучались также часто, как в стандартные порты ssh/ssl.
blog.shodan.io/dont-be-clever
Вопрос в том, где этот секрет хранится. Если только на клиенте — то end-to-end де-юре.
Я не смог проследить за перемещениями секрета — просто смотрел код глазами, продебажить возможности нет сейчас.
CountPasswordHashForSecret используется только в методе FormController::submitPassword
Что бы он ни делал — он не отправляет данные в облако