report-uri — указывает URL, на который будут отправляться JSON-отчеты о нарушениях… Некоторые браузеры также указывают в отчете ссылку и строку JS, которые привели к нарушению политики безопасности.
офтопик. не про вас, а про механизм отчетов CSP вообще. расскажите подробнее как работает эта магия. интересно, может-ли таким образом владелец сайта получать дополнительную информацию о пользователях, которую раньше нельзя было бы получить?
смущает что владелец ресурса может получать в отчетах CSP ссылки. ведь ссылки могут содержать конфиденциальные данные (допустим, индентификатор пользователя в социальной сети, секретные ключи и т.п.). можно-ли намеренно «запретить» политиками CSP интересующие домены, чтобы затем получать эти сведения в отчетах?
гипотетический сценарий. допустим есть виджет социальной сети (//yy.ru/widget.js), который смотрит в куки своего домена и делает ajax-запрос к сервису авторизации, передавая логин в урле (//passport.yy.ru/?login=username). штатными средствами мониторить ajax запросы браузер не даст. добавляем виджет на страницу, политиками разрешаем загрузку виджета c домена yy.ru, но запрещаем доступ к домену авторизации passport.yy.ru. когда на сцену выходит CSP в отчетах получаем урлы с логинами, по которым пользователей можно идентифицировать. профит.
если все это нереальный бред про паранойю, буду признателен за конструктивную критику. :)
#include <string>
#include <cstdlib>
int main ()
{
// I do not hope that the empoyee will write a LL-parser. But we still have a vacancy web developer.
std::string const formula = "1 + 2 * (3 + 4)";
std::string const cmd = std::string("php -r 'echo ") + formula + ";'";
std::system (cmd.c_str());
return 0;
}
спасибо за перевод увлекательной серии. пусть изложенная автором в цикле статей точка зрения не претендует на абсолютную истину и в чем-то спорна, в ней определенно есть ряд рациональных моментов.
кажется, пример в последнем абзаце сбивает с толку. я всегда считал Entiy вполне нормальными объектами, т.к. они, по определению, обладают собственным абстрактным поведением. скорее, ближайшим родственником DTO является «сообщение», как пример структурированных данных, не обремененных собственной прикладной семантикой, которые летают между границами систем.
DTO это взгляд на сообщение со стороны кода. они абстрагируют приложение от конкретного формата сообщений (sql, xml, json,… ), предоставляя доступ к внутренностям в виде родных синтаксических конструкций языка (в случае с EF это еще и аннотации для автоматической сериализации/десериализации, схемогенерации, миграций и т.п. полезных наворотов, реализуемых фреймворком, но роли самих DTO это не меняет). в плане структурно-поведенческого дуализма объектов, DTO представляю собой вырожденный случай структурности в чистом виде.
как скрывание рефереров будет соотноситься с Островами, которые, если я правильно понимаю, были призваны формировать заходы с поисковой выдачи на посадочные страницы с еще более релевантными аргументами — разве здесь нет нарушения конфиденциальности и еще большего расширения возможностей для навязчивой рекламы и впаривания товара, который уже не нужен?
круть. теперь не только пользователи осчастливлены пресонификацией поисковой выдачи, но и владельцы сайтов будут вынуждены уверовать в данные об интересах пользователей, отображаемые метрикой. пожалуй, это самое любопытное. ведь таким образом обе стороны, из субъектов, взаимодействовавших через яндексный поиск, становятся объектами одной модели.
вы молодцы, дизайнерам отдельный респект. движок и правда получается интересный, но у него еще есть потенциал для ускорения.
в анимационной верстке лучше использовать абсолютное позиционирование. float: left для контейнеров со слайдами это reflow на всю глубину при трансформациях. особенно при ресайзах сейчас это заметно.
чтобы исключить лишние перерисовки и вычисления скрывайте невидимые объекты и отключайте для них анимационную логику. сейчас все слайды пересчитываются постоянно. это серьезная заморочка, если ваша цель «сколь угодно страничный параллакс».
при работе с css из js старайтесь избегать чередования чтения и модификации css-свойств. особенно тех, которые связаны с геометрией и способны приводить к запуску reflow.
запись непосредственно в style.cssText при модификациях пачек свойств работает в разы быстрее, чем вызовы $.css().
планирование операций, связанных с рендером, лучше поручить requestAnimationFrame()
вообще, чаще используйте профайлер, он дает много информации к размышлению.
от кода, по мимо документации, хочется модульности какой-нибудь. осталось ощущение, что вся эта простыня собрана из отдельных, изначально, кусочков. какая-то особенность сборки примера для github?
наблюдая, как отключение box-shadow и прочих удивительных градиентов из мира css3 решает кучу проблем, связанных со скоростью анимации страниц в мобильных браузерах, идея чего-то простого, плоского и тонкого начинает напрашиваться как-то сама собой. :)
т.е. да, может мода, может стиль, может тенденции, но сейчас у меня есть по крайне мере один логичный довод в пользу данного эстетического безобразия.
расскажите подробнее про принципы работы автокомплита. кольт использует статический анализ или в самом деле выполняет набираемый код приложения? что если приложение обладает какими-то непоправимыми сайд-эффектами (диски форматирует, за путина голосует, ракеты на луну запускает и т.п.) — это же не будет случаться за ради любопытства разработчика?
могу предположить, что наличие некоторой доли опасной рекламы в AdMob повышает конверсию нормальным приложениям. поэтому её не выпиливают, а дают вот возможность разработчикам самим влиять на долю показа.
напрягает не столько реклама как таковая, а наличие непрерывно висящей на экране штуки, которая с ненулевой вероятностью дает возможность выполнить опасное действие. ведь есть еще дети, жены и прочие человеки, далекие от вопросов компьютерной безопасности, тем не менее являющиеся пользователями приложений. спасибо разработчикам, которые предлагают вариант за деньги, без опасной кнопки. хотя, в каком-то смысле, это на терроризм похоже :-/
вроде как статья показывает, что безопасность вашей информации целиком зависит от владельцев ресурса, а вовсе не сложности пароля. они вот «угадали» 100% — наглядная иллюстрация того, почему не стоит использовать одинаковые пароли на разных ресурсах. :)
То есть вы можете сделать <img src='hd_img_1280x720px.jpg' style='width:200px' alt='Retina image'>, и на iPhone 4/5 оно отобразится в высоком разрешении, несмотря на то, что в CSS задан размер 200px.
выходит, если сделать картинку физически 200px то на экране получится «мыло». как в таком случае рассчитать оптимальный размер картинки? %)
в LaTeX есть несколько замечательных штук — «блочная» модель для всего, «резиновые» распорки, вертикальное выравнивание и стили на языке программирования. это позволяет делать практически любые трюки с отображением для высокоуровневой разметки, в то время как в CSS приходится ждать очередного стандарта или расширения.
офтопик. не про вас, а про механизм отчетов CSP вообще. расскажите подробнее как работает эта магия. интересно, может-ли таким образом владелец сайта получать дополнительную информацию о пользователях, которую раньше нельзя было бы получить?
смущает что владелец ресурса может получать в отчетах CSP ссылки. ведь ссылки могут содержать конфиденциальные данные (допустим, индентификатор пользователя в социальной сети, секретные ключи и т.п.). можно-ли намеренно «запретить» политиками CSP интересующие домены, чтобы затем получать эти сведения в отчетах?
гипотетический сценарий. допустим есть виджет социальной сети (//yy.ru/widget.js), который смотрит в куки своего домена и делает ajax-запрос к сервису авторизации, передавая логин в урле (//passport.yy.ru/?login=username). штатными средствами мониторить ajax запросы браузер не даст. добавляем виджет на страницу, политиками разрешаем загрузку виджета c домена yy.ru, но запрещаем доступ к домену авторизации passport.yy.ru. когда на сцену выходит CSP в отчетах получаем урлы с логинами, по которым пользователей можно идентифицировать. профит.
если все это нереальный бред про паранойю, буду признателен за конструктивную критику. :)
кажется, пример в последнем абзаце сбивает с толку. я всегда считал Entiy вполне нормальными объектами, т.к. они, по определению, обладают собственным абстрактным поведением. скорее, ближайшим родственником DTO является «сообщение», как пример структурированных данных, не обремененных собственной прикладной семантикой, которые летают между границами систем.
DTO это взгляд на сообщение со стороны кода. они абстрагируют приложение от конкретного формата сообщений (sql, xml, json,… ), предоставляя доступ к внутренностям в виде родных синтаксических конструкций языка (в случае с EF это еще и аннотации для автоматической сериализации/десериализации, схемогенерации, миграций и т.п. полезных наворотов, реализуемых фреймворком, но роли самих DTO это не меняет). в плане структурно-поведенческого дуализма объектов, DTO представляю собой вырожденный случай структурности в чистом виде.
не исключаю, что самые сообразительные начнут заправляться прямо на месте, исключая из схемы лишние цепочки.
в анимационной верстке лучше использовать абсолютное позиционирование. float: left для контейнеров со слайдами это reflow на всю глубину при трансформациях. особенно при ресайзах сейчас это заметно.
чтобы исключить лишние перерисовки и вычисления скрывайте невидимые объекты и отключайте для них анимационную логику. сейчас все слайды пересчитываются постоянно. это серьезная заморочка, если ваша цель «сколь угодно страничный параллакс».
при работе с css из js старайтесь избегать чередования чтения и модификации css-свойств. особенно тех, которые связаны с геометрией и способны приводить к запуску reflow.
запись непосредственно в style.cssText при модификациях пачек свойств работает в разы быстрее, чем вызовы $.css().
планирование операций, связанных с рендером, лучше поручить requestAnimationFrame()
вообще, чаще используйте профайлер, он дает много информации к размышлению.
от кода, по мимо документации, хочется модульности какой-нибудь. осталось ощущение, что вся эта простыня собрана из отдельных, изначально, кусочков. какая-то особенность сборки примера для github?
т.е. да, может мода, может стиль, может тенденции, но сейчас у меня есть по крайне мере один логичный довод в пользу данного эстетического безобразия.
думаю, логи сайта там тоже кто-то смотрит.
расскажите подробнее про принципы работы автокомплита. кольт использует статический анализ или в самом деле выполняет набираемый код приложения? что если приложение обладает какими-то непоправимыми сайд-эффектами (диски форматирует, за путина голосует, ракеты на луну запускает и т.п.) — это же не будет случаться за ради любопытства разработчика?
он путает методы с функциями. сам ведь дальше пишет, про сайд-эффекты и состояния.
напрягает не столько реклама как таковая, а наличие непрерывно висящей на экране штуки, которая с ненулевой вероятностью дает возможность выполнить опасное действие. ведь есть еще дети, жены и прочие человеки, далекие от вопросов компьютерной безопасности, тем не менее являющиеся пользователями приложений. спасибо разработчикам, которые предлагают вариант за деньги, без опасной кнопки. хотя, в каком-то смысле, это на терроризм похоже :-/
выходит, если сделать картинку физически 200px то на экране получится «мыло». как в таком случае рассчитать оптимальный размер картинки? %)