Да, мне что-то подобное и нужно, только детальнее и с моими фильтрами, только этих открытых данных в sql или xml или любом другом разбираемом формате пока не нашёл.
как в гифке выше - если не отправляется какая-то телеметрия, бесполезные js - то юзер и не видит ничего, и скачать не может. Только если перехватить запрос - видим прямую ссылку, а большего и не требуется.
понятно, только это не то, хочется именно интеграции с браузером, да и списков не нужно. Там ссылку регуляркой не достать - она придёт только при корректном выполнении js...
под текстовиком подразумеваете банально текстовый файл и какой-то его парсер?
А вы как решали?
Если самому писать софт, можете посоветовать, от чего отталкиваться?
предполагаю, опять же, что тут дело скорее всего не в ограничении скорости, но в том, что почтовые серверы имеют сложную структуру и разные файлы легко могут лежать физически в разных местах, поэтому, возможно, получается быстрее параллельно качать, чем вешать на сервера доп. задачу предварительно объединять нужные данные... а вообще самому стало интересно, а то это смутное предположение.
про cisco любопытно (хотя тоже думаю что чересчёр дорого), а точнее не можете сказать, куда копать?
А вообще я ищу это всё разом, а не по отдельным пунктам.
RemotePC -
1. Это не трансляция экрана, это удалённое управление через неизвестный проприетарный софт с заявленным шифрованием 128-bit RC4/SSL ...
2. We may collect IP addresses for the purposes of system administration and/or to audit the use of our site. We can and will use IP addresses to identify a user when we feel it is necessary to enforce compliance with our policies, Terms, or to protect our Service, site, customers, or others. Some services, such as user logs and registration emails, may also display IP addresses.
Rsa97: Ну тут согласен, панацеей его никак не назвать. Но для личного пользования - отличная штука ведь, вы так не считаете?
Вечная проблема. И в то же время, каждый отвечает за себя и не обязан слепо идти за стадом. Вам, конечно, покажется это странным, но да, когда я знаю в общих чертах всю конструкцию своего автомобиля, знаю, как работает его электронная начинка, знаю потенциальные слабые места. Пусть не досконально, но до определённого компромисса с безопасностью и вложенным временем. И пусть я в этом переусердствую, меня считают странным, но я хотя бы даю окружающим повод задуматься, что, возможно, адекватность их компромисса основана на ложных данных.
Да, его самого. Я думаю, главное чтобы размер таких областей в ключе не перекрывал размер каждой значащей сущности в данных, а то мы передадим эту сущность без шифрования вовсе или в инверсии. Если вы глубже понимаете эту тему, поделитесь, какие ещё параметры стоит учитывать и каковы оптимальные соотношения, было бы интересно.
То есть это вы предлагаете запихать в заголовок к каждому сообщению, правильно понимаю? А соль - на основе сообщения? Если так, то... возможно, но вот тут уже крайне сложно понять, будет ли итоговая энтропия больше или меньше от таких "обёртываний"... Мне кажется, хотя и возможно, что энтропия будет действительно больше, но шифрование этой формулой наверняка наложит свой характерный отпечаток (достаточно взглянуть на большинство шифровок, чтобы примерно распознать, каким из известных методов это было зашифровано), что будет ярко выделять значимые сообщения на фоне цифрового "шума".
Rsa97: С RSA я вижу несколько проблем:
Во-первых, я не математик, не криптоаналитик и лично для меня это чёрная коробка. Может быть, я и мог бы написать свою реализацию, но у меня нет такого количества времени. А пока я не понимаю, что использую - как я могу полагаться на это?
Во-вторых, ваша информация устарела habrahabr.ru/post/120257 , да и сам подход - каждые 2-3 года просто увеличивать кол-во бит - кажется мне каким-то странным...
В-третьих, сейчас вы можете посоветовать использовать, например, 4096-битый ключ, но, даже если отмести в сторону первый пункт, написать свою проверенную реализацию, - тогда я уже столкнусь с серьёзными проблемами в скорости.
В-четвёртых, решая проблемы скорости единственным доступным способом - использованием аппаратного ускорения - я снова сталкиваюсь с чёрной коробкой, которую уже точно не могу проверить или воссоздать за какое-то адекватное время.
И, наконец, в пятых:
Cмешно, сам только что впервые зашёл на эту вики) https://ru.wikipedia.org/wiki/%D0%A8%D0%B8%D1%84%D...
"Шифр Вернама является единственной системой шифрования, для которой доказана абсолютная криптографическая стойкость[4]. При этом он является одной из простейших криптосистем[5]." Вот оно как, оказывается.
xmoonlight: вы можете наглядно пояснить (в условных битах, байтах, цифрах, примерах псевдо или реального кода)? Ответом ниже - описание основы моего алгоритма.
Там же смотрите "формулу" генерацию ключей.
Я понимаю также, что энтропия может распределяться по ключу неравномерно (например, внезапно матрица сгорела и пошли 000... или 111..). Пока в качестве борьбы с этим я рассматриваю расчёт среднего отношения 0/1 за определённое время или объём данных. То есть, если, к примеру, данные какое-то время статичны, % энтропии падает от средних 47-53% до заданного порога (скажем, 40%), то генератор переходит в режим ожидания, продолжая наблюдать за данными. Если энтропия восстанавливается, пишет дальше, в противном случае через какое-то время тестирует систему и пишет ошибку.
xmoonlight: Но это же замечательно? Мне и нужно, чтобы его невозможно было восстановить.
Не понял вас, зачем хорошему рандомайзеру кодирование? Я о таком не говорил.
