Логика в том, что если нельзя экспортировать из ЕУ вещи комерческим путём, то почему их можно экспортировать частным путём? Ведь вы могли купить ноутбук в ЕУ и ввезти его в Россию.
Т.е. по идее ввозить в ЕУ все эти вещи вы можете, вопросов нет. Но если вы хотите их вывезти из ЕУ чтобы отвезти в Россию, тогда получается что вы обходите санкции.
То что вы свой макбук вывезли из России, теперь возвращаете его обратно в Россию, и его хотят забрать - тут уже получается казус, вообще не согласен что его могут забирать.
Но на самом деле, я сам не понимаю смысла этих действий направленных на частные лица и если везут в малых объёмах (свой личный ноутбук и тп). Если везут например 5 ноутбуков - тогда другой вопрос.
А для чего это нужно большим игрокам? Например google и microsoft?
Они уже давно (как минимум года 3 назад) реализовали возможность отправлять письма в режиме конфеденциальности. Это даёт даже больше возможностей пользователю чем подпись с помощью шифрования, в частности:
возможность ограничить, сколько письмо будет доступно (например через 3 дня письмо невозможно будет открыть
возможность заблокировать скачивание, печать(относительно) и тп письма.
Видел так же системы где можно даже отозвать письмо, после его отправки.
Во всех случаях, фактически письмо даже не уходит с серверов отправителя, то есть, "перехватить" содержание намного сложнее.
Так же есть DKIM ключи, которые подписывают что да, это ваш сервер отправил это письмо, а не сторонее лицо.
Ещё один важный вопрос стоит учесть: Как много людей пользуются только 1 почтовым клиентом? Очень многие пользуются тем же Outlook на компьютере, на телефоне и иногда заходят через веб. Как сделать чтобы подпись работала на всех устройствах (где будем шифровать, на клиенте или на сервере? ) И чтобы каждый из клиентов знал у кого из получателей есть возможность читать зашифрованную почту? Опять получается что это всё происходит на стороне сервера, и о какой безопасности мы говорим? Как минимум почтовый сервис может читать все ваши письма.
И да, судя по всему в Outlook есть эта функция, но она скорее всего мало кому интересна.
На тему нативного-не нетивного преподавания - есть интересный пример.
В Финляндии, очень популярно преподавания на финском языке. Т.е. ты приходишь туда, учитель не говорит ни на одном из знакомых тебе языков. Только на финском. Преподаватель может не знать английский, русский, китайский и тп(естественно он знает как минимум английский, тут все его знают), но на уроке - он говорит только на финском.
Учат начиная с полного нуля и достаточно быстро доводят до уровня B2.
Основные идеи данного подхода: максимальное быстрое и полное погружение в язык, начало с прошлого и постепенный переход к сложному, объяснение сложного с помощью простых слов и тп.
И да, русскоязычные знакомые учились у русского и финского преподавателя - у финнского было легче запомнить и понять. Одна из причин как раз в том, что русский переходил на русский язык постоянно, и из-за этого в голове был стопор.
Ну и самое главное что это дало - снялся блок на общение на финском языке.
За 10 лет уже очень много изменилось. И текущий стандарт это делать : display_errors = off, log_errors = on. Т.е. ошибки не выводить, а логировать в файл.
Ну и да, в случае с открытием файла: если проверять всё до того как делать fopen, то и вероятность ошибки близится к нулю :) Т.е. is_readable и тп.
Apple - iPhone, appstore, mac компы и OS, девайсы (телефоны, наушники, ипады и тп).
Microsoft - office 365, windows, azure облако, sql server, windows server, cloud, github, linkedin, xbox экосистема.
Заметели принципиальную разницу?
Apple - это устройства для удобств, премиум устройства, развлечения и тп. Microsoft - сервисы для бизнеса, без которых серьёзный бизнес часто даже не сможет нормально работать.
В особенности на фоне эпидемии, когда все начали работать удалённо - Microsoft сервисы очень были востребованы. А вот айфоны можно было и не покупать.
Если что, интересные ссылки, с описанием начём фирмы зарабатывают:
Раньше покупал и читал книги про PHP. У тех которые читал были следующие основные проблемы:
Книга про новый сиинтаксис языка и новые особенности языка (PHP 5, есть книга про PHP 6 , PHP 7) - намного легче прочитать информацию в интернете.
Книги про рефакторинг, архитектуру и тп - достаточно узко мыслят, намного проще общие книги про построение архитектуры в сети. Без привязки к PHP
Книги про Laravel - фактически не книга, а перепечатка документации. Опять же, легче читать документацию онлайн.
Ну и самая большая проблема всех книг про PHP, в особенности переводных на русский - они сильно отстают по времени. PHP как язык слишком быстро развивается.
Таак что больше я книги про PHP не читаю, думаю так же делают многие. Соответственно и нет смысла писать книги про PHP не для новичков.
Системой этих рецептов заведут государство, т.е. государсовт обеспечивает что служба электронных рецептов работает (ну или заказывают услугу у частных фирм). Любая медицинская фирма может получить доступ (скорее всего за деньги) и аптеки тоже обязаны иметь доступ.
Из плюсов которые не назвали:
Рецепт работает в любой аптеке страны. Т.е. позвонил своему врачу в Хельсинки, он выписал электронный рецепт, обналичил его в Imatra (250 км от Хельсинки примерно).
Вроде можно получить выписанный рецепт даже в Эстонии, но не проверял.
Можно заказывать по интернету рецептурные вещества. Работает так что ты делаешь заказ указываешь личный код, имя, фамилию. Магазин проверяет что ты имеешь право заказывать это лекарство, отправляет по почте. На почте, при получении ты обязан предьявить документ и почтовый работник проверяет что ты это ты. Т.е. происходит разделение обязанностей: магазин проверяет что получатель имеет право получить лекарство, а почта - что тот кто получает - это тот кто написан на коробке.**
Можно смотреть список своих лекарств в системе Omakanta - там так же виден список всех посещений государственых врачей, их диагнозы, результаты коронатестов, корона пасспорт и тп.
Все врачи видят список всех твоих активных лекарств и диагнозов, и могут проверить чтобы лекарства не мешали друг другу.
При продаже ревизор в аптеке должен проверить чтобы лекарства не конфликтовали, и имеет право не продавать тебе лекарство.
** Почта - это абстрактное понятие тут. Т.е. фактически посылка приходит в магазин и ты забираешь её с кассы. Официальных "почтовых отделений" почти не осталось,
В Финляндии похожая система, но выкупать можно по частям. Т.е. например может быть выписано лекарство "на 2 года, 2 раза в день по 1 таблетке". Из за ковида продают только 2 коробки за раз (100 штук в коробке). Поэтому и ходишь каждые 3 месяца и берёшь по 2 коробки - проблем особо нет.
Можно так же брать за другого человека, если есть с собой его карточка с личным кодом. Спрашивают только название лекарства. Брал много раз для жены например.
Так же можно попросить врача "обновить рецепт" по телефону. Врач выписывает новый рецепт, идёшь в аптеку и выкупаешь его - без визита к врачу.
Слышал конечно. Но, и програмисту безусловно доверять нельзя. Как я выше писал — одна и таже строка может быть одновремённо и безопасна, и опасна, в зависимости от использования.
Т.е. мой основной вопрос — даст ли это что то, или это будет очередной «театр безопасности» или «ложное ощущение защищённости».
но это не даёт никакой особой гарантии :) То что программист добавил строку — не значит что она безопасна для любого использования, и даже хуже — даёт ощущение излишний безопасности.
Не совсем понимаю, что даст "[RFC] Is_Noble"?
Т.е. мы проверяем, что строка была захардкодена в коде или хотя бы «несильно изменена».
При этом: мы не гарантируем что строка изначально безопасна для любого использования. Т.е. строка может содержать кавычки которые безопасны для html, но небезопасны для sql, или же, безопасны/небезопасны в зависимисоти от того, какие кавычки используют в запросе.
У простого хакера со стороны так не получится сделать — он не сможет слать коммиты с университетского имейла, поэтому на него по-любому сразу будут смотреть с бОльшим подозрением
А вот тут вопрос — использовался ли какой либо «доверенный» аккаунт университета, или же просто «вася пупкин из университета».
Если первый — то согласен, они пользовались незаслуженным доверием.
Если же «Вася Пупкин», то стоит помнить что обычно его может получить любой студент университета. Т.е. только поступил — и уже у тебя есть такой емайл, т.е. ни о каком спец доверии говорить не имеет смысла — то что Вася Пупкин поступил в университет не даёт ему особого доверия.
И второй вопрос — что же там были за уязвимости, которые удалось протолкнуть в основной код? Т.е. если исследователи смогли, и их смогли поймать только когда они опубликовали статью об этом, то фактически, получается, что кто угодно с большим желанием сможет протолкнуть такие проблемные изменения в основной код :) Т.е. проблема и в самому процессе ревью комитов.
Или я не понял сути вопроса?Логика в том, что если нельзя экспортировать из ЕУ вещи комерческим путём, то почему их можно экспортировать частным путём? Ведь вы могли купить ноутбук в ЕУ и ввезти его в Россию.
Т.е. по идее ввозить в ЕУ все эти вещи вы можете, вопросов нет. Но если вы хотите их вывезти из ЕУ чтобы отвезти в Россию, тогда получается что вы обходите санкции.
То что вы свой макбук вывезли из России, теперь возвращаете его обратно в Россию, и его хотят забрать - тут уже получается казус, вообще не согласен что его могут забирать.
Но на самом деле, я сам не понимаю смысла этих действий направленных на частные лица и если везут в малых объёмах (свой личный ноутбук и тп). Если везут например 5 ноутбуков - тогда другой вопрос.
А для чего это нужно большим игрокам? Например google и microsoft?
Они уже давно (как минимум года 3 назад) реализовали возможность отправлять письма в режиме конфеденциальности. Это даёт даже больше возможностей пользователю чем подпись с помощью шифрования, в частности:
возможность ограничить, сколько письмо будет доступно (например через 3 дня письмо невозможно будет открыть
возможность заблокировать скачивание, печать(относительно) и тп письма.
Видел так же системы где можно даже отозвать письмо, после его отправки.
Во всех случаях, фактически письмо даже не уходит с серверов отправителя, то есть, "перехватить" содержание намного сложнее.
Так же есть DKIM ключи, которые подписывают что да, это ваш сервер отправил это письмо, а не сторонее лицо.
Ещё один важный вопрос стоит учесть: Как много людей пользуются только 1 почтовым клиентом? Очень многие пользуются тем же Outlook на компьютере, на телефоне и иногда заходят через веб. Как сделать чтобы подпись работала на всех устройствах (где будем шифровать, на клиенте или на сервере? ) И чтобы каждый из клиентов знал у кого из получателей есть возможность читать зашифрованную почту? Опять получается что это всё происходит на стороне сервера, и о какой безопасности мы говорим? Как минимум почтовый сервис может читать все ваши письма.
И да, судя по всему в Outlook есть эта функция, но она скорее всего мало кому интересна.
На тему нативного-не нетивного преподавания - есть интересный пример.
В Финляндии, очень популярно преподавания на финском языке. Т.е. ты приходишь туда, учитель не говорит ни на одном из знакомых тебе языков. Только на финском. Преподаватель может не знать английский, русский, китайский и тп(естественно он знает как минимум английский, тут все его знают), но на уроке - он говорит только на финском.
Учат начиная с полного нуля и достаточно быстро доводят до уровня B2.
Основные идеи данного подхода: максимальное быстрое и полное погружение в язык, начало с прошлого и постепенный переход к сложному, объяснение сложного с помощью простых слов и тп.
И да, русскоязычные знакомые учились у русского и финского преподавателя - у финнского было легче запомнить и понять. Одна из причин как раз в том, что русский переходил на русский язык постоянно, и из-за этого в голове был стопор.
Ну и самое главное что это дало - снялся блок на общение на финском языке.
Про Fatal был удивлён - не знал.
Редко пользуюсь @ - обычно всё же display_errors + log_errors + нормальные проверки, чтобы ошибок небыло.
За 10 лет уже очень много изменилось. И текущий стандарт это делать : display_errors = off, log_errors = on. Т.е. ошибки не выводить, а логировать в файл.
Ну и да, в случае с открытием файла: если проверять всё до того как делать fopen, то и вероятность ошибки близится к нулю :) Т.е. is_readable и тп.
Эм, не согласен. В PHP @ значит не показывать ошибку, но не значит "пропустить строку в случае ошибки".
Пример @notexistFunction() остановит программу с "пустым экраном", без показа ошибки.
В VB6 on resume next перейдет к следующей строке в этой ситуации.
Чем же они переспективнее ?
Apple - iPhone, appstore, mac компы и OS, девайсы (телефоны, наушники, ипады и тп).
Microsoft - office 365, windows, azure облако, sql server, windows server, cloud, github, linkedin, xbox экосистема.
Заметели принципиальную разницу?
Apple - это устройства для удобств, премиум устройства, развлечения и тп. Microsoft - сервисы для бизнеса, без которых серьёзный бизнес часто даже не сможет нормально работать.
В особенности на фоне эпидемии, когда все начали работать удалённо - Microsoft сервисы очень были востребованы. А вот айфоны можно было и не покупать.
Если что, интересные ссылки, с описанием начём фирмы зарабатывают:
https://www.investopedia.com/how-microsoft-makes-money-4798809
https://www.investopedia.com/how-apple-makes-money-4798689
Раньше покупал и читал книги про PHP. У тех которые читал были следующие основные проблемы:
Книга про новый сиинтаксис языка и новые особенности языка (PHP 5, есть книга про PHP 6 , PHP 7) - намного легче прочитать информацию в интернете.
Книги про рефакторинг, архитектуру и тп - достаточно узко мыслят, намного проще общие книги про построение архитектуры в сети. Без привязки к PHP
Книги про Laravel - фактически не книга, а перепечатка документации. Опять же, легче читать документацию онлайн.
Ну и самая большая проблема всех книг про PHP, в особенности переводных на русский - они сильно отстают по времени. PHP как язык слишком быстро развивается.
Таак что больше я книги про PHP не читаю, думаю так же делают многие. Соответственно и нет смысла писать книги про PHP не для новичков.
Информация всем:
Cloudflare.com тоже использует Le'ts encrypt сертификаты для части доменов своих клиентов.
Поэтому, будьте готовы что и клиенты не смогут открывать ваш сайт. Или например сервера, если их не обновляли.
В Финляндии тоже есть электронные рецепты.
Системой этих рецептов заведут государство, т.е. государсовт обеспечивает что служба электронных рецептов работает (ну или заказывают услугу у частных фирм). Любая медицинская фирма может получить доступ (скорее всего за деньги) и аптеки тоже обязаны иметь доступ.
Из плюсов которые не назвали:
Рецепт работает в любой аптеке страны. Т.е. позвонил своему врачу в Хельсинки, он выписал электронный рецепт, обналичил его в Imatra (250 км от Хельсинки примерно).
Вроде можно получить выписанный рецепт даже в Эстонии, но не проверял.
Можно заказывать по интернету рецептурные вещества. Работает так что ты делаешь заказ указываешь личный код, имя, фамилию. Магазин проверяет что ты имеешь право заказывать это лекарство, отправляет по почте. На почте, при получении ты обязан предьявить документ и почтовый работник проверяет что ты это ты. Т.е. происходит разделение обязанностей: магазин проверяет что получатель имеет право получить лекарство, а почта - что тот кто получает - это тот кто написан на коробке.**
Можно смотреть список своих лекарств в системе Omakanta - там так же виден список всех посещений государственых врачей, их диагнозы, результаты коронатестов, корона пасспорт и тп.
Все врачи видят список всех твоих активных лекарств и диагнозов, и могут проверить чтобы лекарства не мешали друг другу.
При продаже ревизор в аптеке должен проверить чтобы лекарства не конфликтовали, и имеет право не продавать тебе лекарство.
** Почта - это абстрактное понятие тут. Т.е. фактически посылка приходит в магазин и ты забираешь её с кассы. Официальных "почтовых отделений" почти не осталось,
В Финляндии похожая система, но выкупать можно по частям. Т.е. например может быть выписано лекарство "на 2 года, 2 раза в день по 1 таблетке". Из за ковида продают только 2 коробки за раз (100 штук в коробке). Поэтому и ходишь каждые 3 месяца и берёшь по 2 коробки - проблем особо нет.
Можно так же брать за другого человека, если есть с собой его карточка с личным кодом. Спрашивают только название лекарства. Брал много раз для жены например.
Так же можно попросить врача "обновить рецепт" по телефону. Врач выписывает новый рецепт, идёшь в аптеку и выкупаешь его - без визита к врачу.
За 4 года - сильно меняется ландшафт в мире PHP.
Часть модулей уже не актуально, например проверки совместимости с пхп 7.0. Сейчас уже нужен модуль проверки совместимости с 8.0 :)
Вроде всё даже ок с точки зрения RFC. Везде — програмист написал код сам. Но… упасть всё может всё равно, и не особо секьюрности это добавляет.
да даже если убрать SQL Injection, это ничего не даст, кавычки то всё равно нужно использовать.
Т.е. мой основной вопрос — даст ли это что то, или это будет очередной «театр безопасности» или «ложное ощущение защищённости».
Т.е. мы проверяем, что строка была захардкодена в коде или хотя бы «несильно изменена».
При этом: мы не гарантируем что строка изначально безопасна для любого использования. Т.е. строка может содержать кавычки которые безопасны для html, но небезопасны для sql, или же, безопасны/небезопасны в зависимисоти от того, какие кавычки используют в запросе.
Т.е. что даст эта «защита»?
У меня до сих пор крупный проект на бутстрап 3, и его нереально перетащить на 4ый или тем более пятый.
А вот тут вопрос — использовался ли какой либо «доверенный» аккаунт университета, или же просто «вася пупкин из университета».
Если первый — то согласен, они пользовались незаслуженным доверием.
Если же «Вася Пупкин», то стоит помнить что обычно его может получить любой студент университета. Т.е. только поступил — и уже у тебя есть такой емайл, т.е. ни о каком спец доверии говорить не имеет смысла — то что Вася Пупкин поступил в университет не даёт ему особого доверия.
И второй вопрос — что же там были за уязвимости, которые удалось протолкнуть в основной код? Т.е. если исследователи смогли, и их смогли поймать только когда они опубликовали статью об этом, то фактически, получается, что кто угодно с большим желанием сможет протолкнуть такие проблемные изменения в основной код :) Т.е. проблема и в самому процессе ревью комитов.
Точнее «утечки» были — когда я сохранял ссылки на объекты которые были не нужны уже. Начал удалять ссылки — утечки пропали.
Сейчас стало ещё лучше всё в этом плане.