ссылки для программистов (англ.)

[avva]

Немного из недавнего и накопившегося:

• Learning to Program: What are the best sites for learning programming?
  
  Неплохой обзор сайтов с подробными уроками программирования (где видеоуроками, где просто) для тех, кто совсем не умеет и хочет научиться.
  
  
  
• Data Compression Explained.
  
  Нечто среднее между очень длинным FAQ'ом и небольшой книгой. Краткое введение в основы сжатия данных и подробный обзор основных подходов и алгоритмов. Написано, по-моему, ясно и аккуратно, но несколько сжато для совсем неопытного в программировании читателя. Не требует знаний об алгоритмах сжатия.
  
  
  
• You Are Dangerously Bad At Cryptography.
  
  Отличная запись о том, почему опасно самому наивно использовать криптографические алгоритмы, с несколькими наглядными примерами.
  
  В дискуссии на HN есть тоже немало интересного. В частности, Томас Птачек напоминает, что его компания Matasano продолжает предлагать широкой публике Crypto Challenges - набор упражнений по прикладному криптоанализу, не требующих предварительных знаний в криптографии. Я сам не пытался пока делать Crypto Challenges, не нашел на это времени, но несколько моих знакомых, которым я доверяю, очень и очень их хвалят. Думаю, что всем, кому хочется больше знать в этой области, стоит попробовать.

Comments

[trueblacker.livejournal.com]

>о его пойнт, очевидно, в том, что настолько полагаться на HTTPS не стоит и пароль надо защитить дополнительно

нет, его поинт, очевидно, не в этом. Его поинт в том, что HTTPS (якобы) защищает клиента, а не сервер, поэтому использование HTTPS ничем не поможет серверу защититься от хакера, имитирующего запросы валидных пользователей.

>А клиентские сертификаты, к сожалению, особенно не в ходу, потому что управление ключами и защита их от утечек - дело геморройное

согласен в части "к сожалению". А что приводит к большему геморрою - использование надёжного, но трудного метода или попытки придумать костыль "для нашего простого случая" - вопрос открытый.

Гугл что-то в последнее время часто упоминает token-based аутентификацию. Авось что-нибудь сдвинется в этом направлении. Хотя, подозреваю, выльется в очередную профанацию.

[cat mucius (from livejournal.com)]

Хотя, подозреваю, выльется в очередную профанацию.
Ну почему же - я вот Вам сейчас отвечаю, используя именно её. :-)

Хотя у этого подхода свои проблемы: если Google может залогинить меня в LiveJournal, предоставив токен, значит, Google может залогиниться вместо меня в LiveJournal. :-) Пока мы исходим из предположения, что Гуглу это нафиг не надо, то это не беда. А вот если таким identity provider'от служит родное государство, службы которого таки да могут возжелать сунуть нос в чужую переписку, к примеру?

[huzhepidarasa.livejournal.com]

родное государство может всякими способами сунуть свой нос куда не надо, и не будучи identity provider'ом.

[cat_mucius]

Может, конечно - и я даже знаю, как. :-)

Но это дополнительная возможность, причём не требующая что-то подсовывать и перехватывать.