Честно говоря, вот это кино, на мой взгляд, самое лучшее обозрение того, что мы называем "рунет" глазами гуманитария, которому социальное ближе и интересней технологического. И это достойно. В конце концов про софт и DRM здесь все и так знают. А о влиянии на общество задумываются не все.
Вот тут Вы не совсем правы. Хотя это зависит от точки зрения.
С точки зрения типичного участника, скажем, Хабра, интерес представляют именно люди, чьи руки и головы стояли и стоят за технологиями, которые обеспечивают проистекание общественных процессов. То есть таки инженеров, делавших и делающих рунет технический.
А кино — оно про сами процессы, текущие в "народных массах". С этой точки зрения ключевые уже не инженеры, а движетели потоков. Пусть бы и поначалу движетелями бывали инженеры.
Все же рунет — как и любое другое общественное явление — это, в первую очередь, движение. Поток, внутри которого существуют другие потоки, во главе которых оказываются люди. Причем покуда задача людей во главе потока — определять повестку членов потока, инженеры в таких ролях — случайная случайность. В основном же во главе гуманитарии по складу ума. А софт вообще вторичен.
Так что все вполне сходится. Со временем вместо ролей "восторженных инноваторов-романтиков" на передний план выходят роли "Потупчик", "Навальный" и "Носик".
Берём контору, использующую MDM для BYOD (ну там, в корпоративный exchange ходить с айфончика, который парень на день рождения подарил).
Ставим в ближайшей кафешке сканер HS-платформы
Таргетируем на сотрудников, досягаемых через HS-платформу, фишинг с раздачей собственного SCEP профиля
????
PROFIT
Ручная модерация кампаний в диджитал маркетинге — это хорошо, но очень сильно дорого, когда кампании не свои, а партнёрские, и выручка от канала пропорциональна объему партнёрской базы и их кампаний. ИИ не панацея — примеров промахов существующих вендоров хватает.
Уповать на то, что если контора практикует BYOD, то конторский профиль запрещает установку сторонних — возможно. Но ровно до момента, пока сотрудникам массово очень сильно не захочется себе ещё профилей. То есть, пока предложения партнёров HS-платформы недостаточно щедры или всеобъемлющи.
С другой стороны, в свое время все тоже самое было с email каналом. И на сей раз приспособимся.
В aggregated отчётах DMARC по моим доменам видны случаи, особенно от yahoo/outlook.com и пары локальных европейских esp, когда письмо не прошло DMARC из-за fail'а DKIM и реже SPF, а IP-адрес в отчёте о таких письмах — один из хостов того самого esp. Сделать с этим вряд ли что-то можно, а включать reject с такими отчётами (единицы % от общей массы трафика) — страшно.
Кажется, форварлинг форварлингу рознь.
На практике postmaster MailRu настоятельно советует, например, включать для домена DMARC в p=reject вместо p=none, но в то же время множество случаев, когда большие ESP пересылают письма между своими внутренними хостами без поддержки ARC и все — DKIM сломан, DMARC не проходит, при p=reject письмо отвергается.
Как быть с таким?
Я дико извиняюсь, последний раз с апачем имел дело в 2010, но во-первых, CharsetSourceEnc требует включенного mod_charset, а во-вторых, внутри используется iconv на каждый запрос — не слишком ли это дорого для шаред хостингов?
Справедливо, но нет. Или нужна открытая документация, а ещё лучше — способ описать "важное" письмо самим письмом: метадата в верстке или ещё что-то. В противном случае сервис не может никак заранее предвидеть будет ли его уведомление в текущем дизайне действительно распознано как "важное", или свалится вслед за остальным маркетингом. Или заводить десятки ящиков сотрудникам и тренироваться на них, что тоже даёт такие себе гарантии.
Забороть спам — намерение, безусловно, благое. Но мы все ведь знаем, куда такие намерения могут привести.
Вот просто например.
Есть сферический сервис в вакууме — service.tld. Этот сервис шлёт с info@service-mail.tld письма с маркетингом ("черная пятница", етц) и письма "ваша подписка продлена".
Юзер получает за год 3-5 писем с маркетингом, "отписывается" от рассылки, и в итоге уведомления о продлении подписки или, что хуже, невозможности продления (карта кончилась) не увидит. Как быть?
Так тоже самое происходит с доменами, например. И, если мне память не изменяет, были в прошлом истории с регистрацией освободившихся доменов и чтением писем, на них приходящих "по старой памяти".
А не означает ли это, что скомпрометированный компьютер в корпоративной сети потенциально будет иметь доступ к локальному веб-серверу на других компьютерах сети? Есть ли в локальном веб-сервере проверки на то, откуда пришел запрос?
Или ответственность за это перекладывается на админов?
Это все, конечно, замечательно, но держать в продукиве апач только ради SSO как-то не охота. А nginx, когда я последний раз смотрел, с керберосом особо не дружил.
Приходится пользователям немного страдать все еще…
Не очень понятно о чем конкретно статья.
Автомобиль лучше или хуже велосипеда? А вертолет автомобиля?
Облако — суть еще один способ решения задачи, остается задача выбора способа решения и эту задачу каждый решает сам.
Развернуть сегодня 1С внутри офиса на 10-15 пользователей стоит на круг (железки и софт) порядка полумиллиона рублей в клиент-сервере и сильно меньше (можно уложиться и в сто тысяч) при толстых клиентах и файловых базах на шарах. Или за 50-150 тысяч в год облака.
А вот развернуть у себя, например, сервис для большого количества заказчиков (sla, резервирование и вот это вот все) — уже миллион и выше. Или опять 50-150 в год облака.
Но как часто в SMB нужно обновлять серверные парки 1С? А серверные парки растущих клиентских сервисов?
Вокруг облака много пиара, просто потому, что про другой способ все и так знают, а единовременные затраты оборотных средств на облако всегда ниже, на это и упор.
Что значит «не в их компетенции»? Я не холивара для, а интереса из.
Ведь если вы продаете услуги отечественным юрлицам — у вас либо есть ооо/ип/проч., зарегистрированный в РФ (и как тогда быть с предписанием?), либо бухгалтерия клиента должна уметь и смело платить иностранным контрагентам (что тоже не всегда и везде просто).
Или платит лично директор с карточки?
Выходит, смысл исключительно в том, чтобы привести клиента на страницу перевода денег с предзаполненным получателем?
Честно говоря, вот это кино, на мой взгляд, самое лучшее обозрение того, что мы называем "рунет" глазами гуманитария, которому социальное ближе и интересней технологического. И это достойно. В конце концов про софт и DRM здесь все и так знают. А о влиянии на общество задумываются не все.
Вот тут Вы не совсем правы. Хотя это зависит от точки зрения.
С точки зрения типичного участника, скажем, Хабра, интерес представляют именно люди, чьи руки и головы стояли и стоят за технологиями, которые обеспечивают проистекание общественных процессов. То есть таки инженеров, делавших и делающих рунет технический.
А кино — оно про сами процессы, текущие в "народных массах". С этой точки зрения ключевые уже не инженеры, а движетели потоков. Пусть бы и поначалу движетелями бывали инженеры.
Все же рунет — как и любое другое общественное явление — это, в первую очередь, движение. Поток, внутри которого существуют другие потоки, во главе которых оказываются люди. Причем покуда задача людей во главе потока — определять повестку членов потока, инженеры в таких ролях — случайная случайность. В основном же во главе гуманитарии по складу ума. А софт вообще вторичен.
Так что все вполне сходится. Со временем вместо ролей "восторженных инноваторов-романтиков" на передний план выходят роли "Потупчик", "Навальный" и "Носик".
А можете заодно подсказать толковых ресурсов по админству и внедрению AEM? Документация адоби, как обычно, местами потрясающе неочевидна.
Ручная модерация кампаний в диджитал маркетинге — это хорошо, но очень сильно дорого, когда кампании не свои, а партнёрские, и выручка от канала пропорциональна объему партнёрской базы и их кампаний. ИИ не панацея — примеров промахов существующих вендоров хватает.
Уповать на то, что если контора практикует BYOD, то конторский профиль запрещает установку сторонних — возможно. Но ровно до момента, пока сотрудникам массово очень сильно не захочется себе ещё профилей. То есть, пока предложения партнёров HS-платформы недостаточно щедры или всеобъемлющи.
С другой стороны, в свое время все тоже самое было с email каналом. И на сей раз приспособимся.
Так DKIM цел. От остальных esp приходят отчёты с успехами обработки политик. То есть это именно локальные проблемы и/или некорректные реализации esp.
В aggregated отчётах DMARC по моим доменам видны случаи, особенно от yahoo/outlook.com и пары локальных европейских esp, когда письмо не прошло DMARC из-за fail'а DKIM и реже SPF, а IP-адрес в отчёте о таких письмах — один из хостов того самого esp. Сделать с этим вряд ли что-то можно, а включать reject с такими отчётами (единицы % от общей массы трафика) — страшно.
Кажется, форварлинг форварлингу рознь.
На практике postmaster MailRu настоятельно советует, например, включать для домена DMARC в p=reject вместо p=none, но в то же время множество случаев, когда большие ESP пересылают письма между своими внутренними хостами без поддержки ARC и все — DKIM сломан, DMARC не проходит, при p=reject письмо отвергается.
Как быть с таким?
Нашел для себя не менее (в чем-то и более) декларативную штуку — docopt: https://github.com/docopt/docopt
Я дико извиняюсь, последний раз с апачем имел дело в 2010, но во-первых, CharsetSourceEnc требует включенного mod_charset, а во-вторых, внутри используется iconv на каждый запрос — не слишком ли это дорого для шаред хостингов?
Справедливо, но нет. Или нужна открытая документация, а ещё лучше — способ описать "важное" письмо самим письмом: метадата в верстке или ещё что-то. В противном случае сервис не может никак заранее предвидеть будет ли его уведомление в текущем дизайне действительно распознано как "важное", или свалится вслед за остальным маркетингом. Или заводить десятки ящиков сотрудникам и тренироваться на них, что тоже даёт такие себе гарантии.
Забороть спам — намерение, безусловно, благое. Но мы все ведь знаем, куда такие намерения могут привести.
Вот просто например.
Есть сферический сервис в вакууме — service.tld. Этот сервис шлёт с info@service-mail.tld письма с маркетингом ("черная пятница", етц) и письма "ваша подписка продлена".
Юзер получает за год 3-5 писем с маркетингом, "отписывается" от рассылки, и в итоге уведомления о продлении подписки или, что хуже, невозможности продления (карта кончилась) не увидит. Как быть?
Так тоже самое происходит с доменами, например. И, если мне память не изменяет, были в прошлом истории с регистрацией освободившихся доменов и чтением писем, на них приходящих "по старой памяти".
Или ответственность за это перекладывается на админов?
Приходится пользователям немного страдать все еще…
Автомобиль лучше или хуже велосипеда? А вертолет автомобиля?
Облако — суть еще один способ решения задачи, остается задача выбора способа решения и эту задачу каждый решает сам.
Развернуть сегодня 1С внутри офиса на 10-15 пользователей стоит на круг (железки и софт) порядка полумиллиона рублей в клиент-сервере и сильно меньше (можно уложиться и в сто тысяч) при толстых клиентах и файловых базах на шарах. Или за 50-150 тысяч в год облака.
А вот развернуть у себя, например, сервис для большого количества заказчиков (sla, резервирование и вот это вот все) — уже миллион и выше. Или опять 50-150 в год облака.
Но как часто в SMB нужно обновлять серверные парки 1С? А серверные парки растущих клиентских сервисов?
Вокруг облака много пиара, просто потому, что про другой способ все и так знают, а единовременные затраты оборотных средств на облако всегда ниже, на это и упор.
Ведь если вы продаете услуги отечественным юрлицам — у вас либо есть ооо/ип/проч., зарегистрированный в РФ (и как тогда быть с предписанием?), либо бухгалтерия клиента должна уметь и смело платить иностранным контрагентам (что тоже не всегда и везде просто).
Или платит лично директор с карточки?