Превьюшки (эскизы) аттачей на странице чтения письма рендерятся на серверах Mail.ru в Москве.
То что авторы статьи называют «превьюшками» — это если кликнуть на аттач, то документ откроется в Microsoft Office Online. См. скриншот. Т.е. отправляются в MS не все аттачи, а только те, что юзер открывает в браузере.
В cloud.mail.ru (в b2c варианте) используется тот же самый просмотрщик Microsoft Office Online.
Жаль, что авторы не захотели ни разобраться в вопросе сами, ни вставить в статью скриншот, чтобы технически грамотные читатели осознали ошибку авторов.
Когда локальный клиент сохраняет токен, это лучше, чем когда он сохраняет пароль.
Пароль, сохраненный на компе может украсть троян.
Токен тоже может быть украден трояном, но, во-первых, такие трояны менее распространены, во-вторых, в этом случае пострадает только почтовый аккаунт, а в случае, если будет украден пароль — и все остальные аккаунты пользователя с этим паролем.
А еще, когда юзер авторизуется по IMAP паролем, сервису сложнее отличать настоящего юзера от хакеров и брутфорсеров. При авторизации через OAuth, можно показать юзеру в WebView капчу, спросить дополнительные данные и т.д. Причем, при использовании пароля, IMAP-авторизации с паролем повторяются из раза в раз, и сервис каждый раз должен принимать решение — пользователь это или брутфорсер, при этом имея очень мало информации для принятия такого решения.
Многие думают, что онлайн-конкурсы должны бороться с накрутками «на лету» и максимально затруднять возможность накрутить голоса.
Проблема такого подхода в том, что это превращается в бесконечную борьбу организаторов и накрутчиков. Организаторы могут усложнять накрутку, а накрутчики будут все это обходить.
На практике гораздо проще засчитывать все голоса, а перед подведением итогов инвалидировать накрученные. В таком случае, накрутки обычно бывает легче выявить, потому что большинство накрутчиков не будет заморачиваться сменой IP-адресов, юзерагентов и т.п., ведь «и так работает».
Например, героиню поста можно легко вычислить по большому количеству голосов из Tor :)
Спасибо. Мы посмотрели логи, по всем признакам похоже на то, что перед обращением в поддержку Вы забыли пароль (или же забыли, что меняли пароль за некоторое время до этого)
Сейчас наверное ffmpeg уже все это умеет, но в 2012 когда я занимался этим — не умел.
MP4Box использовался для перекладывания индекса в начало файла.
Еще там был mediainfo, который был чем-то лучше чем ffprobe. И утилиты шифрования видео в wiidevine и f4fpackager.
Тут одно кодирование — 300 строк на C.
А в цепочке конвертации могут участвовать и другие утилиты: MP4Box, m3u8-segmenter, измерение громкости (r128gain). У некоторых из них вообще нет никакого api.
И разные параметры вызовов придется время от времени подкручивать. А еще ffmpeg иногда крешится.
Ок, так Вы считаете, что вот такой цикл по кадрам видео-дорожки будет в проекте смотреться лучше, чем вызов ffmpeg?
/* encode 1 second of video */
for (i = 0; i < 25; i++) {
av_init_packet(&pkt);
pkt.data = NULL; // packet data will be allocated by the encoder
pkt.size = 0;
Проблема тут не только в том, что Ваша статья менее известна, а в том, что 2FA по SMS со всеми ее недостатками — на сегодняшний день индустриальный стандарт.
Предлагайте миру новые безопасные решения, продвигайте их, и может через 5-10 лет в вики будет другое определение :)
У SMS есть важное преимущество перед ключами и токенами — при утере симки ее можно восстановить по паспорту. Для широких масс пользователей это важнее, чем опасность перехвата смски
Эта тема заслуживает отдельного поста, но если кратко, то польза EV-сертификатов сильно переоценена: они не улучшают защиту от MiTM-атак, а польза их в защите от фишинга в нашем случае тоже сильно ограничена.
Это не означает, что EV-сертификат не нужно покупать, просто это не такой просто вопрос как кажется на первый взгляд.
По теме могу порекомендовать вот эту презентацию: www.blackhat.com/presentations/bh-usa-09/ZUSMAN/BHUSA09-Zusman-AttackExtSSL-SLIDES.pdf
«Бессмысленных» блокировок аккаунтов не бывает: в каждом случае существует конкретная причина, и наша цель – это действительно защита данных пользователей. Теперь по пунктам.
Первый ящик никогда не блокировался. Была необходимость восстановить пароль, поскольку Вы его забыли. В таких случаях мы всегда запрашиваем у пользователя большое количество информации. Мы понимаем, почему это может вызвать раздражение, но это необходимое зло, ведь мы должны удостовериться, что пароль восстанавливает именно владелец ящика, а не кто-либо другой. Что касается Вашего второго ящика и ящика Вашей жены – с обоих была зафиксирована подозрительная активность, которая позволяла допустить, что доступ к аккаунтам получил злоумышленник. Именно поэтому они были заблокированы. Однако, к сожалению, в случае с ящиком Вашей жены блокировка действительно сработала с задержкой и произошла уже после того, как Вы сменили пароль. Приносим за это извинения, мы работаем над улучшением этой системы. Пожалуйста, проявите терпение и понимание и все-таки заполните форму для восстановления пароля.
Да, полностью отключенный SSL 3.0 в клиенте или на сервере не позволит хакеру провести атаку.
Потому что стороны никогда не начнут общение по этой версии протокола.
Но если какая-то из сторон (клиент или сервер) поддерживает только SSL версии 3.0, то требуется обновление — потому что если отключить на другой стороне SSL 3.0, то они просто не смогут установить соединение.
То есть, исправить уязвимость со стороны сервера можно, но ценой того, что клиенты, умеющие только SSL 3.0 перестанут работать совсем.
НЕ ЗАМЕНИЛ!!!
То что авторы статьи называют «превьюшками» — это если кликнуть на аттач, то документ откроется в Microsoft Office Online. См. скриншот. Т.е. отправляются в MS не все аттачи, а только те, что юзер открывает в браузере.
В cloud.mail.ru (в b2c варианте) используется тот же самый просмотрщик Microsoft Office Online.
Жаль, что авторы не захотели ни разобраться в вопросе сами, ни вставить в статью скриншот, чтобы технически грамотные читатели осознали ошибку авторов.
Пароль, сохраненный на компе может украсть троян.
Токен тоже может быть украден трояном, но, во-первых, такие трояны менее распространены, во-вторых, в этом случае пострадает только почтовый аккаунт, а в случае, если будет украден пароль — и все остальные аккаунты пользователя с этим паролем.
А еще, когда юзер авторизуется по IMAP паролем, сервису сложнее отличать настоящего юзера от хакеров и брутфорсеров. При авторизации через OAuth, можно показать юзеру в WebView капчу, спросить дополнительные данные и т.д. Причем, при использовании пароля, IMAP-авторизации с паролем повторяются из раза в раз, и сервис каждый раз должен принимать решение — пользователь это или брутфорсер, при этом имея очень мало информации для принятия такого решения.
Проблема такого подхода в том, что это превращается в бесконечную борьбу организаторов и накрутчиков. Организаторы могут усложнять накрутку, а накрутчики будут все это обходить.
На практике гораздо проще засчитывать все голоса, а перед подведением итогов инвалидировать накрученные. В таком случае, накрутки обычно бывает легче выявить, потому что большинство накрутчиков не будет заморачиваться сменой IP-адресов, юзерагентов и т.п., ведь «и так работает».
Например, героиню поста можно легко вычислить по большому количеству голосов из Tor :)
Напишите, пожалуйста, в личку Ваш email и подробнее о ситуации. Спасибо!
MP4Box использовался для перекладывания индекса в начало файла.
Еще там был mediainfo, который был чем-то лучше чем ffprobe. И утилиты шифрования видео в wiidevine и f4fpackager.
А в цепочке конвертации могут участвовать и другие утилиты: MP4Box, m3u8-segmenter, измерение громкости (r128gain). У некоторых из них вообще нет никакого api.
И разные параметры вызовов придется время от времени подкручивать. А еще ffmpeg иногда крешится.
Это точно будет смотреться в проекте лучше, чем вызов ffmpeg? :)
Вот примеры кодирования видео с этими либами:
www.ffmpeg.org/doxygen/0.6/api-example_8c-source.html
ffmpeg.org/doxygen/trunk/doc_2examples_2decoding_encoding_8c-example.html
Вы действительно считаете, что такой кусок кода в проекте будет смотреться лучше вызова ffmpeg? :)
Предлагайте миру новые безопасные решения, продвигайте их, и может через 5-10 лет в вики будет другое определение :)
У SMS есть важное преимущество перед ключами и токенами — при утере симки ее можно восстановить по паспорту. Для широких масс пользователей это важнее, чем опасность перехвата смски
Чтобы спорить о терминах, нужно выбрать авторитетное определение этого термина :)
На какой источник определения термина 2FA Вы ссылаетесь?
Это не означает, что EV-сертификат не нужно покупать, просто это не такой просто вопрос как кажется на первый взгляд.
По теме могу порекомендовать вот эту презентацию: www.blackhat.com/presentations/bh-usa-09/ZUSMAN/BHUSA09-Zusman-AttackExtSSL-SLIDES.pdf
Первый ящик никогда не блокировался. Была необходимость восстановить пароль, поскольку Вы его забыли. В таких случаях мы всегда запрашиваем у пользователя большое количество информации. Мы понимаем, почему это может вызвать раздражение, но это необходимое зло, ведь мы должны удостовериться, что пароль восстанавливает именно владелец ящика, а не кто-либо другой. Что касается Вашего второго ящика и ящика Вашей жены – с обоих была зафиксирована подозрительная активность, которая позволяла допустить, что доступ к аккаунтам получил злоумышленник. Именно поэтому они были заблокированы. Однако, к сожалению, в случае с ящиком Вашей жены блокировка действительно сработала с задержкой и произошла уже после того, как Вы сменили пароль. Приносим за это извинения, мы работаем над улучшением этой системы. Пожалуйста, проявите терпение и понимание и все-таки заполните форму для восстановления пароля.
Потому что стороны никогда не начнут общение по этой версии протокола.
Но если какая-то из сторон (клиент или сервер) поддерживает только SSL версии 3.0, то требуется обновление — потому что если отключить на другой стороне SSL 3.0, то они просто не смогут установить соединение.
То есть, исправить уязвимость со стороны сервера можно, но ценой того, что клиенты, умеющие только SSL 3.0 перестанут работать совсем.