А мне нравится новый дизайн папок, я вообще люблю синий цвет и не люблю острые углы :)
Например, мне не нравились папки в Vista и 10, но нравились в XP и 7.
А вообще — давно пора разрешить пользовательские темы оформления, позволяющие менять системные иконки и сделать каталог тем с рейтингом. Чтобы каждый мог выбрать то, что ему нравится :)
Для пользователей и разработчиков игр/мультимедиа приложений.
Да, сейчас есть развитая поддержка SVG, Canvas, элементы audio и video и Audio API, и время уже не то, так что актуальность Flash сомнительна. Но…
Я вот совсем недавно занимался переносом анимаций на паре своих веб-страниц с SWF на SVG. Могу сказать, что в целом SWF воспроизводится несколько более плавно. Точнее даже не так, более быстро. В общем, есть ощущение, что там лучше задействуется аппаратное ускорение отрисовки, и код работы с графическим буфером более эффективен. Масштабирование без потерь простых Flash-анимаций, не использующих растровые элементы — такое же, как в SVG, то есть тут паритет.
А ещё могу как веб-разработчик сказать, что у элементов audio есть один фатальный недостаток: отсутствие хоть какой-то возможности управлять буферизацией.
Спросите, зачем это может быть нужно? Ну вот вам простой пример. Страница SHOUTcast радиостанции. Есть плеер. Допустим, я хочу реализовать код, который позволит при достижении некоторого порога времени прекращать наращивание буфера и его обнуление (чтобы пользователь при нажатии «плей» слушал актуальный эфир).
В случае обычного Flash проигрывателя буфер писался практически бесконечно; в случае с HTML5 Audio (как минимум в Firefox, но думаю что везде так же) он пишется только какое-то время. Но во-первых, это время нельзя изменить или даже узнать, кроме как эмпирическим путём; а во-вторых, по истечении этого времени в буфере остаётся «хвост» длиной в 3-4 секунды от старого аудиоконтента. В итоге после нажатия на «плей» пользователь сначала услышит этот «хвост».
Я уверен, что на ActionScript это всё в лоб решалось написанием нужного кода в проигрывателе. Сейчас же приходится городить странные костыли вроде переназначения атрибута src по таймеру. При этом, кстати, если у элемента autoplay="true", то после такого переназначения ещё и принудительное воспроизведение начнётся, то есть нужно ещё и об этом позаботиться.
Можно монетизировать средства создания — что Adobe и делал с Flash и сейчас продолжает делать с софтом для создания анимаций и приложений под HTML5. Сам Flash Player для конечного пользователя был бесплатный, как и браузеры сейчас бесплатны. Не вижу никакой разницы, в общем.
Да и как-то я не верю, что за больше чем 15 лет там внутри под капотом ничего не изменилось. Наверняка изменений было очень много, в плане безопасности в том числе.
Больше похоже на то, что кто-то Adobe дал очень много денег за то, чтобы они сами похоронили свой продукт.
Я просто топил за автономность и устойчивость системы.
Ну вот представьте, что завтра случится какой-то апокалипсис и интернет рухнет. И рухнет всё, что на него было завязано. Все эти Dropbox/Spotify/VK/нужное добавьте сами.
А софт, который работает локально — работать не перестанет, пока есть электричество.
С остальным полностью согласен. Кроме того, что и поверх модемной связи без проблем можно применять шифрование (только скорость будет довольно отстойной, так что нет особого смысла).
Создал раздел на SSD такого же или большего размера, перенёс Acronis-ом прямо из-под винды (или через Ghost), рядом создал бы пустой раздел в несколько гигабайт. Затем загрузился бы с установочного диска/флэшки и начал установку ОС на второй пустой раздел на SSD до перезагрузки. После этого оба раздела появятся в меню, можно загрузиться в скопированный (главное не перепутать, впрочем методом тыка в любом случае он будет обнаружен). Затем удалить лишний раздел и загрузочную запись уже из-под винды (EasyBCD в помощь).
Не знаю, как там с десяткой дела обстоят, но я отлично помню, что во времена семёрки и xp у меня по какой-то причине никогда не восстанавливался загрузчик. В xp юзал recovery console, в семёрке мастер устранения проблем с загрузкой. Ни то, ни другое не восстанавливало работоспособность от слова "совсем".
Зато прекрасно помогало проведение первого этапа установки (до перезагрузки) на новый раздел. Главное, чтобы место под него было неразмеченное. Ну или на один из существующих разделов можно это сделать. Главное — от предварительного форматирования отказаться :)
Почему тогда у меня при канале 50 Мбит получилось вдвое быстрее на новой версии Firefox? Мутная история какая-то. Может, есть какие-то промежуточные кэширующие узлы на пути между мной и сервером Хабра, и я «прогрел» именно их?
Опыт иранской изоляции, протянувшейся от силы неделю — наглядно демонстрирует
Ну в масштабах страны остаться без интернета — конечно, очень неприятно и уже почти что апокалипсис.
Но я же не об этом :)
Ну вот представим какую-нибудь огромную компанию с собственной сетью (локальной и между филиалами, с собственными каналами). Что мешает им сидеть только в рамках этой сети? Сайты в интранет, почта там же через свой сервер, свои чаты. Я не про военку, а про фирму, пишущую софт какой-нибудь, или каких-нибудь рисователей условного аниме в Японии.
То есть я к тому, что если все программы работают без интернета (офисные, графические пакеты) — то жить вполне можно при отвале последнего, хоть в гугл и не залезешь поискать информацию. А вот если отвалится весь софт — то это уже всё, финиш :)
Вообще ничего не понял. Можно ещё раз, по порядку и помедленнее?)
невозможно N-байтными блоками однозначно представить все строки длиной до N байт включительно
В смысле?
именно сбой HTTPS-сессии и является тем каналом, через который извлекается информация о зашифрованном содержимом запроса.
Там будет сбой не HTTPS сессии, а именно логический. Ну вот представьте: клиентский код «думает», что отправил один запрос, а сервер отвечает на другой (после модификации). Где гарантия, что не получится фейл из-за несоответствия реального результата ожидаемому?
У вас Linux или Windows? Какая скорость канала? Кэш прогревали перед этим, перезагрузив несколько раз? У вас подозрительно большие цифры, такое ощущение, что кэш вообще не работает.
Чтобы точно знать, сколько байтов нужно отрезать с конца после расшифровки и перед проверкой MAC.
Зачем? Набивка ведь и так имеет совершенно особый формат. Неужели не очевидна ситуация, когда у неё нулевая длина? Хотя бы исходя из общей длины данных об этом можно «догадаться».
MitM подменяет только пакеты от клиента к серверу, от сервера к клиенту — оставляет без изменения.
Тогда логически ответы сервера не сойдутся с ожидаемыми ответами уже на уровне приложения, и обязательно возникнет какой-нибудь сбой, что нарушит сессию в целом и для пользователя сделает очевидным то, что его «прослушивают».
Злоумышленник формирует путь и тело запроса, но куки в запрос вставляет браузер жертвы.
Вообще-то, технически, куки может ставить либо браузер напрямую через JS, либо сервер через заголовок Set-Cookie (этот заголовок может подсунуть и злоумышленник). Так кто и на каком этапе ставит куки в данном сценарии? Если я правильно понял, куки ставит сервер в момент успешной авторизации, но потом они отправляются в HTTP заголовке браузером при каждом запросе, и это просто некая постоянная строка, которую мы хотим расшифровать, а изменяя путь, мы просто её «двигаем»?
Вы валите всё в кучу. Каким образом описанный выше бардак противоречит демократическим убеждениям того, кто у руля? Демократ и либерал может не быть сильным лидером, может не быть хорошим управленцем (вспомните Керенского), но он от этого не перестаёт быть демократом и не становится диктатором.
В год будет тоже 0.1%, если что) Хотя конечно, с учётом требования неповторяемости проверяемых элементов и частичного пересечения элементов, выводимых каждый день, возможно будет чуть больше. Но пока нет условия, что ни в какой день не добавляется ничего нового, вы не можете просто брать и умножать.
Позвольте, но при чём тут Гугл? Реклама такси, судя по дизайну, не принадлежит Гуглу. Вы обвиняете Гугл исключительно в неудачном выборе места вывода блока? А что, если реклама такси была встроена посредством JS не до, а после встраивания вашего рекламного блока Гуглом?
Не всё понял из текста… Ну во-первых, непонятно, почему исторически допускалась ситуация, когда сообщение + MAC точно укладываются в целое число блоков, но набивка всё равно зачем-то требовалась. В чём смысл, этого действия, чтобы точно знать, что это конец MAC, а не покорёженная набивка в результате искажения данных при передаче?
И по последней атаке тоже объяснено как-то криво. Во-первых, каким образом в принципе злоумышленник встанет посередине, если браузер проверяет сертификат сервера? Он будет просто транслировать всю передачу данных без изменений в обе стороны, а свои запросы просто отправлять на реальный сервер параллельно с этим?
Окей, но в чём суть «угадывания байтов в POST запросе», ведь злоумышленник сам целиком формирует этот запрос? Или речь про угадывание неких данных, отправленных прямо перед этим запросом, но зашифрованных в рамках того же блока? Тогда у меня вопрос, начинается ли шифрование заново в терминах блоков SSL в момент отправки браузером нового GET/POST запроса.
А мне нравится новый дизайн папок, я вообще люблю синий цвет и не люблю острые углы :)
Например, мне не нравились папки в Vista и 10, но нравились в XP и 7.
А вообще — давно пора разрешить пользовательские темы оформления, позволяющие менять системные иконки и сделать каталог тем с рейтингом. Чтобы каждый мог выбрать то, что ему нравится :)
Да, сейчас есть развитая поддержка SVG, Canvas, элементы audio и video и Audio API, и время уже не то, так что актуальность Flash сомнительна. Но…
Я вот совсем недавно занимался переносом анимаций на паре своих веб-страниц с SWF на SVG. Могу сказать, что в целом SWF воспроизводится несколько более плавно. Точнее даже не так, более быстро. В общем, есть ощущение, что там лучше задействуется аппаратное ускорение отрисовки, и код работы с графическим буфером более эффективен. Масштабирование без потерь простых Flash-анимаций, не использующих растровые элементы — такое же, как в SVG, то есть тут паритет.
А ещё могу как веб-разработчик сказать, что у элементов audio есть один фатальный недостаток: отсутствие хоть какой-то возможности управлять буферизацией.
Спросите, зачем это может быть нужно? Ну вот вам простой пример. Страница SHOUTcast радиостанции. Есть плеер. Допустим, я хочу реализовать код, который позволит при достижении некоторого порога времени прекращать наращивание буфера и его обнуление (чтобы пользователь при нажатии «плей» слушал актуальный эфир).
В случае обычного Flash проигрывателя буфер писался практически бесконечно; в случае с HTML5 Audio (как минимум в Firefox, но думаю что везде так же) он пишется только какое-то время. Но во-первых, это время нельзя изменить или даже узнать, кроме как эмпирическим путём; а во-вторых, по истечении этого времени в буфере остаётся «хвост» длиной в 3-4 секунды от старого аудиоконтента. В итоге после нажатия на «плей» пользователь сначала услышит этот «хвост».
Я уверен, что на ActionScript это всё в лоб решалось написанием нужного кода в проигрывателе. Сейчас же приходится городить странные костыли вроде переназначения атрибута
srcпо таймеру. При этом, кстати, если у элементаautoplay="true", то после такого переназначения ещё и принудительное воспроизведение начнётся, то есть нужно ещё и об этом позаботиться.Да и как-то я не верю, что за больше чем 15 лет там внутри под капотом ничего не изменилось. Наверняка изменений было очень много, в плане безопасности в том числе.
Больше похоже на то, что кто-то Adobe дал очень много денег за то, чтобы они сами похоронили свой продукт.
Я просто топил за автономность и устойчивость системы.
Ну вот представьте, что завтра случится какой-то апокалипсис и интернет рухнет. И рухнет всё, что на него было завязано. Все эти Dropbox/Spotify/VK/нужное добавьте сами.
А софт, который работает локально — работать не перестанет, пока есть электричество.
С остальным полностью согласен. Кроме того, что и поверх модемной связи без проблем можно применять шифрование (только скорость будет довольно отстойной, так что нет особого смысла).
Скажите пожалуйста, а почему процесс так сложен?
Я бы сделал так:
Создал раздел на SSD такого же или большего размера, перенёс Acronis-ом прямо из-под винды (или через Ghost), рядом создал бы пустой раздел в несколько гигабайт. Затем загрузился бы с установочного диска/флэшки и начал установку ОС на второй пустой раздел на SSD до перезагрузки. После этого оба раздела появятся в меню, можно загрузиться в скопированный (главное не перепутать, впрочем методом тыка в любом случае он будет обнаружен). Затем удалить лишний раздел и загрузочную запись уже из-под винды (EasyBCD в помощь).
Или я чего-то не учитываю?
А в чём суть такой атаки?
Не знаю, как там с десяткой дела обстоят, но я отлично помню, что во времена семёрки и xp у меня по какой-то причине никогда не восстанавливался загрузчик. В xp юзал recovery console, в семёрке мастер устранения проблем с загрузкой. Ни то, ни другое не восстанавливало работоспособность от слова "совсем".
Зато прекрасно помогало проведение первого этапа установки (до перезагрузки) на новый раздел. Главное, чтобы место под него было неразмеченное. Ну или на один из существующих разделов можно это сделать. Главное — от предварительного форматирования отказаться :)
Ну в масштабах страны остаться без интернета — конечно, очень неприятно и уже почти что апокалипсис.
Но я же не об этом :)
Ну вот представим какую-нибудь огромную компанию с собственной сетью (локальной и между филиалами, с собственными каналами). Что мешает им сидеть только в рамках этой сети? Сайты в интранет, почта там же через свой сервер, свои чаты. Я не про военку, а про фирму, пишущую софт какой-нибудь, или каких-нибудь рисователей условного аниме в Японии.
То есть я к тому, что если все программы работают без интернета (офисные, графические пакеты) — то жить вполне можно при отвале последнего, хоть в гугл и не залезешь поискать информацию. А вот если отвалится весь софт — то это уже всё, финиш :)
В смысле?
Там будет сбой не HTTPS сессии, а именно логический. Ну вот представьте: клиентский код «думает», что отправил один запрос, а сервер отвечает на другой (после модификации). Где гарантия, что не получится фейл из-за несоответствия реального результата ожидаемому?
Зачем? Набивка ведь и так имеет совершенно особый формат. Неужели не очевидна ситуация, когда у неё нулевая длина? Хотя бы исходя из общей длины данных об этом можно «догадаться».
Тогда логически ответы сервера не сойдутся с ожидаемыми ответами уже на уровне приложения, и обязательно возникнет какой-нибудь сбой, что нарушит сессию в целом и для пользователя сделает очевидным то, что его «прослушивают».
Вообще-то, технически, куки может ставить либо браузер напрямую через JS, либо сервер через заголовок Set-Cookie (этот заголовок может подсунуть и злоумышленник). Так кто и на каком этапе ставит куки в данном сценарии? Если я правильно понял, куки ставит сервер в момент успешной авторизации, но потом они отправляются в HTTP заголовке браузером при каждом запросе, и это просто некая постоянная строка, которую мы хотим расшифровать, а изменяя путь, мы просто её «двигаем»?
В год будет тоже 0.1%, если что) Хотя конечно, с учётом требования неповторяемости проверяемых элементов и частичного пересечения элементов, выводимых каждый день, возможно будет чуть больше. Но пока нет условия, что ни в какой день не добавляется ничего нового, вы не можете просто брать и умножать.
Позвольте, но при чём тут Гугл? Реклама такси, судя по дизайну, не принадлежит Гуглу. Вы обвиняете Гугл исключительно в неудачном выборе места вывода блока? А что, если реклама такси была встроена посредством JS не до, а после встраивания вашего рекламного блока Гуглом?
И по последней атаке тоже объяснено как-то криво. Во-первых, каким образом в принципе злоумышленник встанет посередине, если браузер проверяет сертификат сервера? Он будет просто транслировать всю передачу данных без изменений в обе стороны, а свои запросы просто отправлять на реальный сервер параллельно с этим?
Окей, но в чём суть «угадывания байтов в POST запросе», ведь злоумышленник сам целиком формирует этот запрос? Или речь про угадывание неких данных, отправленных прямо перед этим запросом, но зашифрованных в рамках того же блока? Тогда у меня вопрос, начинается ли шифрование заново в терминах блоков SSL в момент отправки браузером нового GET/POST запроса.