Перед вами — забавная и поучительная история Шантну Тивари, небрежность которого привела к крайне печальным последствиям: более десяти тысяч телефонов в Южной Америке в один момент оказались заблокированными. Люди не могли даже позвонить, не говоря уж про более сложные действия. О том, как это было — под катом.
Перед вами ужасная история о том, что происходит, когда ваш код/тестовые скрипты работают не так, как планировалось. Это также ужасная история о том, как плохо не тестировать свой код. Надеюсь, благодаря ей вы тоже поймёте, что тестовые сценарии требуют такого же внимания и планирования, как и «правильный» код.
Ночь ужасающего скрипта
Как и во многих страшилках, моя началась в пятницу вечером, примерно в 17:15. Я как раз собирался уходить с работы, как вдруг получил email от коллеги:
Помнишь тот скрипт, который мы выкатили вчера? Он заблокировал тысячи телефонов в Южной Америке. Боюсь, нас уволят.
Когда я прочёл сообщение, меня обуял ужас. Это был разгар самоизоляции из-за COVID-19, а я был обычным подрядчиком с чуть ли не устными договорённостями. В случае чего найти новую работу было бы непросто. Но как, чёрт возьми, мой скрипт мог совершить такое?
Небольшая предыстория о телефонной компании K-Pop
Я работал в ИБ-компании в группе автоматизации тестирования. Основным нашим продуктом было приложение, поставляемое операторам мобильной связи. С его помощью оператор мог заблокировать любой свой телефон, если его украли или хозяин переставал своевременно оплачивать покупку.
Приложение создавалось как часть ОС Android, поэтому удалять его было нельзя. Иначе все низкоуровневые функции телефонов переставали работать. То есть владелец телефона не смог бы звонить, пользоваться Wi-Fi и публиковать фотографии в Instagram/Facebook ( ужасно, правда? ). Как только телефон возвращался владельцу/платежи возобновлялись, все функции снова восстанавливались.
Всё просто и удобно. Компания-разработчик даже создала программу, которая помогала операторам понять, какой именно телефон нужно заблокировать. Этот внутренний инструмент работал просто отлично. Я бы даже мог сказать, что это было исключительно благодаря мне, но это слишком высокомерно звучит. Так что работало хорошо в основном благодаря мне.
Но один производитель мобильных телефонов (я назову его K-Pop Phone Manufacturing Company ), базирующийся в Корее, счёл себя слишком гордым, чтобы пользоваться нашим софтом. И требовал работать только на их веб-инструменте. Хозяин — барин. Мне платят, и я работаю с тем, что дают.
В какой момент всё пошло не по плану? Когда друг на друга наложилось несколько факторов.
Медленное крушение
Нашу компания купила одна инвестиционная фирма. Которая хотела не просто отбить вложенные средства, но и подзаработать. Поэтому сроки всех проектов были изменены. Было время, когда мы тестировали три продукта параллельно. И все имели разные требования.
То есть мы тестировали совсем по минимуму, надеясь, что всё идёт хорошо.
Одним из последних тестов была проверка функции блокировки телефонов, данные которых находились в загружаемом оператором CSV-файле. Проще простого. Я написал скрипт на Python, который генерировал несколько случайных телефонных номеров, входил на сервер и блокировал телефоны, а затем входил на другой сервер и проверял результаты. Таким образом, мы смогли протестировать десятки тысяч комбинаций с помощью одного скрипта, выполнение которого заняло всего несколько часов.
Последний скрипт фактически генерировал сотни тысяч случайных номеров, потому что у нас было несколько разных вариантов действий в разных ситуациях.
Вы, наверное, уже сообразили, к чему я веду.
Из-за нехватки времени (или политической воли) мы не проверили, правильно ли написан скрипт. Как только я его допилил, его пустили в работу. Серьёзно, через 10 секунд после нажатия мной кнопки «Сохранить», скрипт запустился на действующих серверах.
Я мог бы проверить свою работу, но это означало, что придётся копаться в коде до поздней ночи. Нет уж, спасибо. Я уже потратил на это несколько ночей и выходных.
Я запустил скрипт — он нормально отработал. Руководители подтвердили, что скрипт делает то, что от него просят. Все были довольны, так как продукт можно будет запустить уже в понедельник, а в выходные не придётся работать.
А потом я получил электронное письмо о том, мы заблокировали тысячи телефонов в Южной Америке: в Перу, Чили и других странах.
Ч-ч-чёрт! КАК!?
Помните, я говорил вам, что телефоны генерируются «случайным образом«? Скрипт случайным образом генерирует 11-значный «номер телефона».
И, конечно же, некоторые из этих телефонов были действующими! И из-за того, как я написал скрипт, и из-за какой-то странной особенности IMEI, все эти телефоны были из Южной Америки.
Очень долгая ночь
Всё это я понял уже спустя 15 минут.
«У нас все ещё есть старый CSV-файл, которые использовался при тестировании?», — спросил мой коллега. Мы могли бы снова выкатить скрипт, но на этот раз с настройкой разблокировки.
Разумеется, нет! У меня была только самая свежая версия. Планировалось, что это будет разовая задачка для быстрой проверки.
Был способ обойти проблему: я мог задействовать K-Pop, чтобы скачать рабочий список у них. Вот только компания разрешала загружать только 100 номеров за раз, а мне нужно было загрузить более 10 000 номеров.
Итак, требовался скрипт для загрузки телефонных номеров. И ещё один, чтобы очистить кривые CSV, которые они нам вернули, чтобы не было новых проблем. И третий скрипт для переподключения к серверу и разблокировки всех телефонов.
Мы работали в паре с коллегой, что позволило закончить работу уже к 18:30. К этому времени все телефоны были разблокированы. Менеджер проекта подтвердил разблокировку и я быстренько отключился, пока не нашлись ещё какие-нибудь косяки.
Уроки, которые мы усвоили (или, что более вероятно, не усвоили):
Сценарии тестирования требуют такой же заботы и любви, как и обычный код.
Вы никогда не должны тестировать критически важный код в сжатые сроки и под высоким давлением. Вне зависимости от того, что думает руководство ( увы, никто не следует этому совету, ведь если вы хотите сохранить свою работу, вы делаете то, что вам сказали, или ищете новую работу в другом месте).
Регистрироваться в системе K-Pop было непросто, но после регистрации вы могли заблокировать любой телефон в любой точке мира.
Компания K-Pop благодаря IMEI знала, какой мобильный оператор «владел» телефоном, и, следовательно, несла за него юридическую ответственность. То есть, если вы покупаете телефон у T-Mobile, он регистрируется на них (в нескольких базах данных), и только T-Mobile имеет право блокировать телефон. По крайней мере, до тех пор, пока клиент не внесёт последний платёж за свой телефон или не сменит провайдера.
И всё же K-Pop Central позволял любому желающему блокировать любой телефон, если вы просто знали его номер телефона или IMEI (оба значения нетрудно получить; номер телефона во многих случаях общеизвестен и известен многим людям).
Урок здесь таков: Сделайте несколько чёртовых проверок, прежде чем блокировать чей-то телефон. Вот только я не знаю, применим этот урок ко мне или к K-Pop (скорее всего, к нам обоим).
Тестирование следует проводить постепенно. Вместо того, чтобы тестировать окончательную систему, мы должны сначала протестировать каждый компонент. Почему мы этого не сделали? Потому что у нас не было времени.
Сценарий, по которому вы единожды проходитесь по упорядоченному массиву (проверяете «лучший случай»), никогда не бывает хорошим. В идеале нам следовало бы подумать о тестировании вариантов, при которых блокируется чужой телефон. Или предусмотреть мошеннический скрипт, который сделает то же самое, что и мы. Это не только хороший контроль качества, но и хорошая безопасность.
Мы считали, что, раз наше собственное программное обеспечение проверяет такие вещи, то и софт K-Pop телефона тоже. Фигушки. На Аллаха надейся, а верблюда привязывай.
Не тестируйте ничего в продакшене! У нас был сервер разработки и промежуточный сервер, но их даже не подключали к боевому приложению (из-за нехватки времени и нехватки людей). Кроме того, нам нужно было выпустить продукт в ближайшие 2-3 дня, так что «не могли бы вы просто заткнуться и продолжить тестирование, пожалуйста»?
Как я уже сказал, мы не усвоили ни одного из этих уроков, как только продукт был официально выпущен на следующей неделе, мы вернулись к нашим прежним скриптам, сбрасывающим мусор в базы данных и делая вид, что мы «протестировали» код.
Нас не уволили, потому что мы исправили ошибку очень быстро, но что более важно, некоторые менеджеры проектов и топ-менеджеры по продажам делали то же самое: придумывали номера телефонов и блокировали реальные телефоны. Конечно, они делали это вручную, поэтому блокировке подвергались только 3-4 телефона, а мы заблокировали 10 000, но конечный эффект был таким же. Мы все писали в бассейн, в котором плавали.
Все сделали вид, что это просто ошибка. Но ничего страшного, живи и учись, дружище, живи и учись. Тем более что никто особо не пострадал, за исключением рандомного бедняги из Перу, который не смог позвонить по телефону или опубликовать фотографию с дакфейсом в Instagram. Но, согласитесь, это не такая уж и большая беда.
Что ещё интересного есть в блоге Cloud4Y
→ Изучаем своё железо: сброс паролей BIOS на ноутбуках
→ Физики смогли придать жидкости квадратную и шестиугольную форму
→ Клавиатуры, которые постигла неудача
→ Как уловки древних полководцев воскресают в современной математике
→ Самый большой космический телескоп Уэбб должен изменить наши представления о космосе
Подписывайтесь на наш Telegram-канал, чтобы не пропустить очередную статью. Пишем не чаще двух раз в неделю и только по делу.
Комментарии (86)
VitalKoshalew
20.10.2021 19:23+23Продолжайте покупать телефоны, в которых с низкоуровневыми правами системы работает приложение, написанное нелегалом Шантну Тивари и его коллегами за еду и удалённо управляемое ими же без всякого контроля.
Да, и электронные замки и прочий «умный дом» от Skykharkov в комментариях выше.
И нет, я не имею в виду какую-то или какие-то конкретные фирмы.
P.S.
Поясню свою мысль — традиционно, на протяжении десятилетий, к программным и аппаратным продуктам был достаточно взвешенный (может быть и не намеренно, просто так сложилось) подход: все системы были, по сути, air-gapped, а возможность их поломки учитывалась в оценке рисков (даже если пользователь и не производил её формально). То есть какого бы низкого качества не была разработка — ну «сломается», бывает.
Этот подход в последние годы перенесли не задумываясь (десятки лет же всё нормально было!) на подключённые к Internet устройства. И в эти же устройства, с другой стороны, люди вкладывают всю свою жизнь и всю свою информацию.
dartraiden
20.10.2021 20:16+1Продолжайте покупать телефоны, в которых с низкоуровневыми правами системы работает приложение, написанное нелегалом Шантну Тивари и его коллегами за еду и удалённо управляемое ими же без всякого контроля.
Чаще всего, это телефоны, которые берут в рассрочку или в лизинг. Иногда всплывают на Авито, счастливый покупатель через некоторое время обнаруживает, что телефон заблокирован намертво, так как продавцу он не принадлежал.VitalKoshalew
20.10.2021 20:50+2Вы готовы поручиться, что в телефоне от условного Samsung на другом конце провода не будет Тивари? В умных дверях от Amazon, например, были и им ничего за это, насколько я знаю, не было.
VitalKoshalew
20.10.2021 21:08+1Стоймость прокладки отдельной инфраструктуры для передачи данных настолько высока (даже низкоскоростной), что кроме как единичные объекты её позволить не могут.
Жили как-то всю жизнь с локальными сетями с, как минимум, контролем доступа в Internet, и ничего, не разорялись. С сотовыми телефонами сложней — тут вся инфраструктура защиты должна быть внутри телефона, а для этого нужны другие телефоны.Плюс универсальная, бесплатная и свободная ОС.
Это Google Android+GMS+все blob-ы от производителей телефонов, частью которых и были творения команды Тивари или вы про только делающий первые шаги на этом рынке Linux?Даже создать более менее независимую сеть для передачи в радио диапазоне, это очень трудное и не очень надёжное занятие.
ИнфоБез достаточно давно изобрели. Air gap — просто один из многих инструментов. То, что он был всюду раньше по умолчанию и на нём одном всё висело, не означает, что другие инструменты (поверх существующей инфраструктуры) не могли бы его заменить, если бы круглые сутки из каждого утюга не гремело «Альтернативы просто нету, надо это принять».
anonymous
00.00.0000 00:00Leksa7
21.10.2021 07:47+3традиционно, на протяжении десятилетий, к программным и аппаратным продуктам был достаточно взвешенный (может быть и не намеренно, просто так сложилось) подход: все системы были, по сути, air-gapped, а возможность их поломки учитывалась в оценке рисков (даже если пользователь и не производил её формально). То есть какого бы низкого качества не была разработка — ну «сломается», бывает.
Разработчики Therac-25 криво усмехнулись.
VitalKoshalew
21.10.2021 17:56+3После Therac-25 как раз в индустрии медицинского оборудования AFAIK произошёл перелом и всё стали проверять 25 раз и, к сожалению, цены взлетели до небес, потому что
построить коммунизм в отдельно взятом городеразвивать безопасный подход в одном микросегменте рынка — дорого.
Остальной рынок ПО и оборудования всё ещё ждёт своего Therac-25. Думалось, кража кредитных историй всех жителей континента или отсутствие бензина на Восточном побережье или глобальные перебои с поставкой мяса что-то изменят. Пока что всё успешно списывают на force majeure.
Ну и сам инцидент с Therac-25 — он ведь не про информационную безопасность, а только про надёжность. Водители ритма с дистанционным управлением, которое может перехватить кто угодно, всё ещё на рынке, а вот журналиста, который про это кричал, уже нет с нами.
GarretThief
21.10.2021 14:14+3Я начал бояться за свои данные только когда я попал в реальную разработку.
До этого я думал что-то типа "все программисты - профессионалы, все сначала подумают, затем проверят, а после реализации много раз протестируют. Особенно на безопасность, более особенно, если это реальные данные, максимально особенно, если с этими данными есть реальная возможность украсть деньги/имущество пользователей. Ну и вообще за безопасностью все следят, всякое хранение паролей, разные уровни доступа, поиск возможных ошибок в API.".
Но когда я окунулся в это сам, то оказалось, что в разработке полно косоруких программистов, костылей, ужасного кода, переноса сроков, отсутствия тестирования, а все мои данные, по большей части, защищены лишь фактором Неуловимого Джо. И всё это дополнительно узким местом завязано на номера телефонов, что ставит под вопрос даже идеально продуманную безопасность сервиса.
И теперь я, скорее, не понимаю, почему вообще что-то работает, а не выдаёт 5xx на открытие приложения.
ksbes
21.10.2021 16:09Ну дык - вот так вот протестировано на продакшене!
И это кстати, не только в софте бывает. Просто, на физических объектах тяжело такое устроить быстро и далеко. Хотя вон - в Припяти умудрились ...
DIITHiTech
21.10.2021 20:16+1А не косорукие компаниям в 99% не надо. Менеджменту всегда подавай все "на вчера", и чтобы за три копейки. А как известно в дилемме "дешево быстро и качественно" можно только 2 из 3х выбить.
OptimumOption
21.10.2021 07:47+11"...Менеджер проекта подтвердил разблокировку и я быстренько отключился, пока не нашлись ещё какие-нибудь косяки..." - типичный представитель касты индусского кодостроения....
vlreshet
21.10.2021 10:24+4Скрипт случайным образом генерирует 11-значный «номер телефона».
Я правильно понял, эти «гении» работали на «боевом» сервере, и генерили телефонные номера в надежде что они получатся несуществующими? Серьёзно?
И, конечно же, некоторые из этих телефонов были действующими
ledascho
21.10.2021 12:29Не тестируйте ничего в продакшене!…
Как я уже сказал, мы не усвоили ни одного из этих уроков,
nixtonixto
21.10.2021 12:42+3То есть у автора статьи даже не возникла мысль при генерации базы номеров для скрипта использовать несуществующий код страны, или после генерации проверить, нет ли в сгенерированном списке активных номеров? Такого раздолбайства я ещё не встречал… «Кто бросил валенок на пульт?!!»
unsignedchar
21.10.2021 13:01+2Думаю, что автору статьи за это не платили. Насяльнике ставиль задачу копать быстрее —
ТивариДжамшут копаль. Зачем ругаешься, насяльнике?
Kanut
21.10.2021 14:18+3Казалось бы, ничего не предвещало беды...Это был разгар самоизоляции из-за COVID-19, а я был обычным подрядчиком с чуть ли не устными договорённостями
…
Хозяин — барин. Мне платят, и я работаю с тем, что дают
…
Нашу компания купила одна инвестиционная фирма. Которая хотела не просто отбить вложенные средства, но и подзаработать. Поэтому сроки всех проектов были изменены. Было время, когда мы тестировали три продукта параллельно. И все имели разные требования.
…
Из-за нехватки времени (или политической воли) мы не проверили, правильно ли написан скрипт.
…
Руководители подтвердили, что скрипт делает то, что от него просят. Все были довольны, так как продукт можно будет запустить уже в понедельник, а в выходные не придётся работать.
ex-human
21.10.2021 13:42+1"...это просто ошибка. Но ничего страшного, живи и учись, дружище, живи и учись.."
Mike-M
21.10.2021 15:02+1В очередной раз подтвердилась старая истина: спешка важна при ловле блох.
Но пока погоня завременембаблом у акционеров/руководителей/исполнителей ставится превыше всего остального, качество нашей жизни так и останется на уровне «good enough».
0xC0CAC01A
21.10.2021 18:53-1Ну, чтоб погони за баблом не было, надо запретить выпускать софт с "никакие гарантии любого вида" в лицензионном соглашении. Чтобы эти 10000 латиноамериканцев могли отсудить ущерб.
unsignedchar
21.10.2021 19:13Если что-то запретить… Ну не будет того что запретили. Совершенно не факт, что вместо вместо погони за баблом вида «экономить ФОТ» не появится погоня за баблом вида «кнопочный телефон ценой в автомобиль». Что ж, всё имеет свою цену, в том числе и много проверок и лицензий.
0xC0CAC01A
21.10.2021 19:51-3Нет, просто появится качественный телефон. И совсем не факт, что дороже, ибо сейчас большую часть времени разработчики занимаются тем, что ищут способ обойти баги коллег.
vikarti
21.10.2021 20:40+1Как при этом быть со всем opensource ПО? За которое в большинстве случаев разработчики денег не получают, а если получают то косвенно и в котором авторов может быть просто огромное количество. Вот допустим я предлагаю патч какой то в LKML, его принимают. Затем мне дедушка в наследство оставляет миллион долларов но все желающие у которых что-то не так с андроидом (там же линукс ядро) — могут отсудить с меня ущерб? Или попробовать это сделать.
0xC0CAC01A
21.10.2021 21:52Для опенсорсного ПО можно сделать исключение. Странным образон оно получается качественнее, чем коммерческое.
Видимо, потому что... https://www.youtube.com/watch?v=P5k71azl6N4&t=172s
unsignedchar
22.10.2021 09:34+1Странным образон оно получается качественнее, чем коммерческое.
Воу… Мой калькулятор, который я написал just for lulz и собираюсь выложить на github, обязательно получится качественнее, чем аналог, разработанный программистами MS за зарплату?0xC0CAC01A
22.10.2021 11:53Хорошо, вы меня поймали на том, что я забыл в моё высказывание вставить "в среднем". И да, можно найти очень плохое опенсорсное ПО и очень хорошее коммерческое. Но в среднем, по моим ощущениям (да, теперь уже не прицепиться к формулировке), опенсорсное ПО существенно качественнее, чем коммерческое.
Про калькулятор от майкрософта тут уже как то была статья на Хабре. Ну, а про качество Skype Вам, я думаю, рассказывать не надо?Kanut
22.10.2021 11:55Хорошо, вы меня поймали на том, что я забыл в моё высказывание вставить "в среднем".
То естъ у вас будет опенсорсный код, часть которого будет однозначно хуже чем имеющиееся коммерческие проекты, но всё равно будет использоваться без всякий гарантий. И как это должно помочь полностью избежать ситуаций вроде той что описана в статье?
0xC0CAC01A
22.10.2021 12:03Если Вы коммерческий разработчик, то Вы будете использовать только качественный опенсорсный код, потому что теперь это Ваша зона ответственности. Проведёте код ревью.
Ну, а как иначе? Если Вы производитель автомобилей или медицинского оборудования и Вы туда вкорячили китайский подшипник, который заклинило и Ваше изделие нанесло ущерб, то да, Вы несёте ответственность, которую потом (если получится), можете попробовать перенести на китайского поставщика.
Kanut
22.10.2021 12:07Если Вы коммерческий разработчик, то Вы будете использовать только качественный опенсорсный код, потому что теперь это Ваша зона ответственности. Проведёте код ревью.
Во первых с чего это вдруг? То есть либо у нас есть отвественность за опенсорс код, либо её нет.
Во вторых в такой ситуации большинство просто перестанет пользоваться опенсорсом и куча людей перестанет и контрибьютить. То есть это будет солидный удар по этому самому опенсорсу.
Ну и в третьих коммерческий опен сорс тоже бывает. Что помешает мне, как коммерческому разработчику, писать опенсорс, а деньги официально скажем брать за саппорт. То есть деньги я получил, а отвественности у меня нет.
0xC0CAC01A
22.10.2021 15:01Во первых с чего это вдруг? То есть либо у нас есть отвественность за опенсорс код, либо её нет.
Всё просто. Продал софт или поддержку к нему - неси ответственность. А если забесплатно, то нет.
Во вторых в такой ситуации большинство просто перестанет пользоваться опенсорсом и куча людей перестанет и контрибьютить. То есть это будет солидный удар по этому самому опенсорсу.
И что, все пересядут с серверов на линуксе на сервера под виндой?
Ну и в третьих коммерческий опен сорс тоже бывает. Что помешает мне, как коммерческому разработчику, писать опенсорс, а деньги официально скажем брать за саппорт. То есть деньги я получил, а отвественности у меня нет.
Получил хоть копейку - ответственность. Её, кстати, можно страховать.
Kanut
22.10.2021 15:08Всё просто. Продал софт или поддержку к нему — неси ответственность. А если забесплатно, то нет.
Ну вот смотрите: у нас фирма держит свой опенсорс-проект. Им пользуются наши клиенты. Клиенты платят нам деньги. Но не напрямую за опенсорс-проект. Мы несём отвественность или нет?
И дальше: у нас отдельные сотрудники контрибутят в этот проект в рабочее время. Они получают зарплату. Они несут отвественность или нет?
И что, все пересядут с серверов на линуксе на сервера под виндой?
А куда они денутся если линукса не будет? А его не будет потому что практически никто никто не захочет рисковать.
Получил хоть копейку — ответственность. Её, кстати, можно страховать.
Классная идея. Вот человек держит опенсорс проект. В проекте баги. Но это не страшно так как он за свой проект денег не берёт. Кто-то берёт и донатит этому человеку 1$. И бац, на человеке уже висит оствественность и его можно штрафовать.
0xC0CAC01A
22.10.2021 15:19Но не напрямую за опенсорс-проект. Мы несём отвественность или нет?
Тогда нет.
И дальше: у нас отдельные сотрудники контрибутят в этот проект в рабочее время. Они получают зарплату. Они несут отвественность или нет?
Кстати, а сотрудники вроде медсестёр, экскаваторщиков или электриков вообще несут материальную ответственность за свои ошибки или это всё-таки ответственность их работодателя?
А куда они денутся если линукса не будет? А его не будет потому что практически никто никто не захочет рисковать.
Ну, тогда давайте жить как сейчас, когда всё в руках разваливается, баги никто не чинит, "а зачем"
Классная идея. Вот человек держит опенсорс проект. В проекте баги. Но это не страшно так как он за свой проект денег не берёт. Кто-то берёт и донатит этому человеку 1$. И бац, на человеке уже висит оствественность и его можно штрафовать.
Не надо путать. Донат - это дело добровольное. Это не оплата.
Kanut
22.10.2021 15:25Тогда нет.
Что мешает всем остальным оформить всё похожим образом?
Кстати, а сотрудники вроде медсестёр, экскаваторщиков или электриков вообще несут материальную ответственность или это всё-таки ответственность их работодателя?
А причём здесь это?
Ну, тогда давайте жить как сейчас, когда всё в руках разваливается, баги никто не чинит, "а зачем"
А кто вас застваляет использовать вещи, которые "разваливаются в руках". Не используйте и всё. Лично для вас эффект будет ровно такой же.
Зато если кто-то хочет такими вещами пользоваться, то у него такая возможность есть. Почему вы считаете себя врпаве эту возможность у них отнимать?
Не надо путать. Донат — это дело добровольное. Это не оплата.
Во первых я не вижу чтобы в вашем "Получил хоть копейку — ответственность" было написано про добровольность или не добровольность.
А во вторых оплата она обычно тоже добровольная: не хочешь не плати и не пользуйся. Никто не заставляет.
Ndochp
22.10.2021 20:17Ну так в этом и разница:
платят тебе как хорошему человеку (донат) — ответственности не несешь.
Платят за возможность использования софта — несешь в объеме обещаний из лицензии. Забыл написать "и не применяйте в атомной энергетике" — вплоть до строительства новой АЭС.
Платят за сервис — так в SLA написано что можете вы, и что может покупатель. Главное чтобы софт, который под сервисом был бесплатно доступным. А то получится как сейчас — фактическая плата за что-то без гарантий.
Kanut
25.10.2021 09:59платят тебе как хорошему человеку (донат) — ответственности не несешь.
Вот только для налоговой и суда доход это доход. И им не особо важно донат это или нет. Потому что очень просто что-то, что не является донатом, задекларировать как таковой.
А то получится как сейчас — фактическая плата за что-то без гарантий.
Во первых гарантийный срок есть даже у софта. По крайней мере у нас. Другое дело что мало кто с этим связывщется. А во вторых кто вам запрещает прописать требования к гарантиям в договоре? Или не покупать что-то без этих самых гарантий?
Ndochp
25.10.2021 15:42-
Налоговую вы странно приплели… вроде она тут вне контекста. Можно конечно развести длинный тред про учет донатов физическим и юридическим лицам в бухгалтерском и налоговом учете в разных юриздикциях, но это кажется оффтоп в этой ветке. А налоги конечно надо платить.
-
Не покупать ОС без этих гарантий мне мешает отсутствие таковых на рынке. Поэтому хочется, что бы пришло государство и подвинуло планку AsIs повыше, хотя бы на B2C рынке. Так как оплатить индивидуальное производство софта под физлицу не под силу. И как показывает практика государство приходит. Вот только что была "Антилопа Гну", а вот уже "Евро5" почти обязательное требование.
-
Kanut
25.10.2021 15:46Налоговую вы странно приплели… вроде она тут вне контекста.
Если вы начнёте вписывать такие формулировки в законы, то внезпано налоговая будет в контексте. Потому что в куче стран благотворительность и подобные вещи налогами не облагаются или облагаются по другому.
Не покупать ОС без этих гарантий мне мешает отсутствие таковых на рынке.
В смысле "отсутсвие таковых"? А у вас в стране нет никаких законов об обязательном гарантийном сроке при продаже? Или эти законы на софт не распространяются?
Ndochp
25.10.2021 17:13AsIs это не гарантия а недоразумение.
Проблема софта в том, что если лампочка перегорела, то её можно заменить на такую же, но горящую.
А если Soft v1.99 сломался, то весь. Поэтому менять не на что. Только деньги возвращать.
Хотя мне было бы интересно посмотреть на мир с возможностью манибэка за любую софтину с непустым баглистом. Причем пожизненного, так как гарантия это по сути только вопрос того, кто оплачивает экспертизу.
Kanut
25.10.2021 17:18Ну так и в случае с хардом часто остаётся только вариант вернуть деньги. Особенно учитывае что у нас в хард чем дальше тем менее ремонтопригоден.
А в случае с софтом проблема скорее в том что большинству с таким связываться лень. Как минимум у нас.
yoz
22.10.2021 15:57Ну вот смотрите: у нас фирма держит свой опенсорс-проект. Им пользуются наши клиенты. Клиенты платят нам деньги. Но не напрямую за опенсорс-проект. Мы несём отвественность или нет?
Если они вам платят за услуги, как-то связанные с этим проектом, то да, несете. А если опенсорс проект у вас про погоду, а клиенты вам платят за заправку картриджей, то мимо.
Kanut
22.10.2021 15:59"Как-то связанные" это очень интересное определение. Предлагаете прямо так в законах и написать? :)
yoz
22.10.2021 16:03Это должно у вас в договоре с клиентом быть написано, а не в законе. Ответственность то нести вы будете перед клиентом. Если у вас прописано, что клиент вам платит за поддержку/доработку/использование/etc такого-то продукта. А если я, не имея с вами никаких договорных отношений, скачал ваши исходники с гитхаба и начал использовать, то вы мне ничего не должны.
Kanut
22.10.2021 16:05Ну так и сейчас никто никому не запрещает прописать ответственность в договоре. Зачем тогда что-то менять?
yoz
22.10.2021 16:10Ну да.
В более сложных ситуациях, например, я взял ваш код, сделал на базе его какой-то свой проект и начал его продавать. Даже если кодовая база на 90% не моя — ответственность за работу ее несу я, так как я получаю деньги.
0xC0CAC01A
22.10.2021 17:49Ну давайте тогда ещё уберём из законов ответственность магазинов за качество продаваемых продуктов? Отравились - ну Ваша проблема, вот на стене висит отказ от гарантий. Пойдёт?
unsignedchar
22.10.2021 18:10+1Ну давайте тогда ещё уберём из законов ответственность магазинов за качество продаваемых продуктов?
Нет у магазина ответственности за качестово. За несоответствие нормативам — есть.
Так вот, измерить наличие патогенной флоры в молоке — возможно. Что измерять в коде?
0xC0CAC01A
22.10.2021 20:52Что измерять в коде?
Вы правда не знаете? Работает, как ожидается или нет.
Если Вы купили электродрель в магазине, а она не крутится, то что будете измерять, прежде чем вернуть обратно?
unsignedchar
22.10.2021 22:17Работает, как ожидается или нет.
Тот же openssl - он работает как ожидалось или нет? И наличие уязвимостей тоже ожидалось?
Да, с дрелью хороший пример. Есть за N денег с редуктором из пластика и силумина - ее хватит повесить полочку. Есть за N*m - ею можно сверлить 24*7. Обе крутятся.
С программами сложнее.
0xC0CAC01A
22.10.2021 23:06Тот же openssl - он работает как ожидалось или нет? И наличие уязвимостей тоже ожидалось?
Ну, давайте дальше развивать аналогию: дрель крутится, но сегодня ударила Вас током.
unsignedchar
23.10.2021 07:59К любому компонента дрели есть формальные требования (стандарты). Если их соблюдать - не ударит. Их соблюдение несложно проконтролировать.
Соблюдение формальных требований к коду не приводит автоматически к отсутствию уязвимостей.
0xC0CAC01A
23.10.2021 10:45Вот беда-то... ну возьмите другую аналогию: соблюдение ПДД водителем автобуса не гарантирует непопадание оного в ДТП. При этом в случае ДТП автобусная компания несёт ответственность перед пассажирами.
А ещё, кстати, есть стандарты, соблюдение которых и, в правду, поможет избежать уязвимостей.
unsignedchar
23.10.2021 13:44есть стандарты
Допустим. И зачем мне их придерживаться? Мой калькулятор и так хорош. Я художник, я так вижу. Opensource же.
А те, кто пишут с соблюдением стандартов, захотят получать вознаграждение за свой труд.
И телефон станет по цене как самолёт.Собственно, можно посмотреть на строительство. Заметная часть сметы - проектная документация. То есть плата за соблюдение стандартов. Зато дома, построенные без отклонения от проекта, как правило, не падают.
0xd34df00d
24.10.2021 06:59+1Соблюдение формальных требований к коду не приводит автоматически к отсутствию уязвимостей.
На самом деле приводит, но увеличивает время разработки на два-три порядка минимум.
unsignedchar
24.10.2021 08:48Время - деньги. При таких раскладах телефон ценой в автомобиль - вполне реально. Ведь подорожает не только звонилка в телефоне, но и ПО для разработки плат, и автомобиль, на котором рабочий ездит на работу..
Кстати, как формальные требования к коду могут гарантировать отсутствие ошибок в железе? Была, например, история, когда для анализа работы крипточипа успешно использовали потребляемую мощность.
0xd34df00d
24.10.2021 21:26+1Время — деньги. При таких раскладах телефон ценой в автомобиль — вполне реально. Ведь подорожает не только звонилка в телефоне, но и ПО для разработки плат, и автомобиль, на котором рабочий ездит на работу.
Именно так, разработка софта подорожает на порядки, причём не только за счёт самого времени разработки: в отличие от фигак-фигак-продакшен-дривен-разработки, доступный пул работников чуть меньше.
Кстати, как формальные требования к коду могут гарантировать отсутствие ошибок в железе? Была, например, история, когда для анализа работы крипточипа успешно использовали потребляемую мощность.
Можно верифицировать всякие верилоги и прочее.
Но, конечно, в итоге это всё упирается в ваше доверие основаниям математики.
unsignedchar
25.10.2021 09:07+1Можно верифицировать всякие верилоги и прочее.
Это начинает напоминать формулу Циолковского, но для разработки ПО ;) Чем дальше, тем дороже.
unsignedchar
22.10.2021 12:11+2Проведёте код ревью.
Хе-хе. Код openssl смотрели тысячи глаз, и никто не рассмотрел Heartbleed.0xC0CAC01A
22.10.2021 15:21Ну бывает. И на этом основании давайте теперь вообще не будем заботиться о качестве, да?
unsignedchar
22.10.2021 16:09Давайте сначала определимся, в чем мерить качество. В частности, качество кода
0xC0CAC01A
22.10.2021 21:12Уже ответил - https://habr.com/ru/company/cloud4y/blog/584578/comments/#comment_23620094
(Как, блин в этом новом ужасном редакторе ссылку написать?)
0xd34df00d
24.10.2021 06:56+1И всех обязать писать на идрисе со всеми спеками в виде типов. Французам можно оставить кок.
Одобряю такой подход. Сами вы на чем пишете из этого?
rtkprg2
10.11.2021 15:49Я верно понял, что механизм отключения смартфона встроен в Андроид на ВСЕХ смартфонах, а не только на залоченных мобильным оператором?
Если это так, то почему про этот функционал я ранее не встречал упоминаний? Почему этот функционал не юзается для блокировки украденных смартов у нас, в России?
Skykharkov
Я как-то вызвал полицию в примерно пятьсот домов одновременно, в одном небольшом американском городе. :) Там были установлены железяки "умного дома", софт для которых писал я и вместо тестовой базы, с "виртуальными" устройствами, накатил флаг датчиков вскрытия окон на "боевую" базу. Все сработало как надо.
Хорошо хоть заказчики нормальные были. "Хорошо потестировали" сказали они.
Теперь в любом проекте, где есть тестовая и живая базы, всегда стоит куча проверок где именно будут происходить изменения. Хватило одного раза.
titsi
Интересно, что подумала полиция в этот момент?
Mimizavr
"Так, 500 одновременных срабатываний - явно какой-то технический сбой. Надо сообщить в компанию от которой это пришло и выкатить им штраф" (с)
На заре развития ЧОПов, ПЦН и зоопарка разных систем сигнализации во вневедомке это вполне обычная ситуация была. Может не в таких масштабах. Как правило на пультах особо не паниковали. Хотя особо отчаянные головы могли коктейль Молотова в какой-нибудь щиток запустить, чтобы массово обрубить связь и что-то важное обнести. Но это прям настолько редкие случае были, что рассказы о них ходили на уровни баек.
ader
Ну "коктейль Молотова в щиток" от 500 одновременно "открытых" окон на пульте отличили бы сразу. Но ГНР отправили бы всё равно. Так, для душевного спокойствия прокатиться...
Гораздо чаще случался пьяный экскаваторщик, разрывающий
пасть львустопарник... Вот тогда-то и можно было в течение пары дней наблюдать картину: "сидят мужики, плетут проводки".nickolaym
Накатил стопарик и разорвал стопарник!
Mimizavr
Когда всё на охранялось по телефонным линиям,коктейл Молотова был очень эффективным способом)) Одна бутылка - и обноси в целом районе что угодно!
VitalKoshalew
Сложно отвечать на такие глобальные тезисы, но как минимум многие нашумевшие взломы и downtime-ы как раз показали, что причиной были Тивари. Или даже, я бы сказал, первопричиной было то, что stakeholders не волновала безопасность, а руководство волновала только финансовая отчётность. И не в последнюю очередь именно менталитет «дырочку всегда найдут», «Альтернативы просто нету» приводит к отсутствию запроса на информационную безопасность. Все технические возможности делать в достаточной степени безопасные системы есть. Нет рыночного спроса.
Сам Linux — не панацея, телефоны, заблокированные Тивари, формально, работали на ядре Linux. Я подозреваю, Amazon Ring — тоже.
Вы про отставных советских милиционеров и ГБ-шников, которые во славу Культа Карго ставят портить жизнь людям? Я сомневаюсь, что они вообще имеют отношение к науке об Информационной Безопасности, про которую я упоминал.
scarab
Наука-то есть, а людей нет.
А которые есть, тех исчезающе мало и они либо работают в паре-тройке крупных контор по ИБ, либо занимаются чем-то смежным типа админства.
В подавляющем же большинстве случаев руководство нанимает «инфобезов», которые в самом лучшем варианте пишут нормативную документацию в соответствии с требованиями регулирующих органов, а чаще - изображают активность и мешают работать, а потом пишут кляузы руководству, дабы уверить его в своей необходимости.
VitalKoshalew
Это, на мой взгляд, вопрос исключительно рыночного спроса. На разработку ПО, сервисов, оборудования затрачиваются миллиарды $. Ни копейки из них не идёт целенаправленно на информационную безопасность, потому что спроса нет. И так покупают, а затраты на ИнфоБез, порой, могут кратно увеличить стоимость разработки, но это в самом худшем случае и если надо всё переделывать; если «вплетать» ИнфоБез с самого начала разработки, то всё достаточно умеренно. На сегодняшний день нет никакого стимула у руководства тратить хоть копейку на безопасность.
Исключение — работа с кредитными картами. Стали Visa и MasterCard заставлять банки следовать разумному и выполнимому стандарту PCI DSS и за десяток лет, с воем и причитаниями, но худо-бедно «вплели» все безопасность в работу с кредитными картами и оказалось, что ничего невозможного в этом нет. Я не говорю, что всё стало идеально и нет организаций, которые обманули аудиторов или уровень аудитора был такой, что никаких нарушений в упор не заметили. Всё может быть. Но мне абсолютно очевидно, что за 10 лет отрасль преобразилась в плане защиты данных кредитных карт.
Если появится массовый спрос на безопасность работы с другими типами данных, я уверен, возможно распространить разумные практики на всю индустрию разработки. Исключения будут, тивари местами останутся, но будет и альтернатива, которой сейчас нет.
И про Культ Карго и бывших милиционеров я уже писал, это не то. Нельзя нанять специалиста, даже не фальшивого, а настоящего, и ожидать, что безопасность придёт. Безопасность стоит денег и времени. Программы должны проектироваться и писаться по-другому, а не в конце кто-то будет приходить и «мешать работать». Это стоит денег, на это почти никто пока не идёт, хотя разговоры и симуляция уже начались.
scarab
Полагаю, Вы правы.
И пока в отрасли действует правило "программное обеспечение поставляется как есть" и разработчик не несёт никакой ответственности, если софт работает как-то не так - то так оно и будет продолжаться.
Paskin
Это тот стандарт, который прямо запрещает передачу терминала в руки пользователя? Ну-ну...
VitalKoshalew
Можете указать, в каком именно пункте PCI DSS есть такое требование? Обращение с терминалами регулируется §9.9, и, конкретно, §9.9.3. Там речь идёт о том, чтобы не дать подменить или модифицировать устройство — вполне логично и достаточно, на мой взгляд.
В ресторанах и прочих не-стационарных местах вроде уличных ярмарок мобильные терминалы дают в руки, никакой проблемы в этом я не вижу при умеренном уровне преступности. Если уровень преступности высокий и терминалы крадут, тогда да — надо принимать меры, на цепь их крепить и т.д. Сам стандарт выдвигает лишь требование, как конкретно противодействовать краже — решает бизнес.
Paskin
Я не знаю точно из-за какого пункта - но, например, установить кард-ридер на тележке для супермаркета или сканере бар-кодов (которые физически невозможно вынести из магазина) - не согласилась ни одна из ведущих мировых компаний в соответствующей области. И ссылались все как один на PCI DSS.
VitalKoshalew
Я не знаком с описываемой вами ситуацией, может быть они ответили «мы вам перезвоним», просто другими словами. Считыватели карт в Канаде, например, где только не установлены. Вообще, я отвечал на ваше безапелляционное заявление, что PCI DSS, якобы «прямо запрещает передачу терминала в руки пользователя». Как видно из моей цитаты — не запрещает. И даже на телегу, которую можно закатить в тёмный угол, и там сделать со считывателем карт что угодно, не запрещает: просто придётся принять меры к предотвращению вышеупомянутого действия, например, обвешать тележку камерами, проверять каждую тележку между пользователями. На месте компаний, я бы взвесил иллюзорное улучшение в виде считывателя на самой тележке, а не где угодно на выходе, и тоже отказал, но не потому, что стандарт плохой, а потому что не всё, что можно сделать, нужно делать.
Jsty
Можете расскать подробнее, что позволяет NDA, а каким образом "дома" в полицию сообщили о проблеме?
Skykharkov
Железяка умела подтягивать конфигурацию с сервера. Сделано было для того чтобы централизованно обновить номера служб или адреса серверов, деактивировать\активировать типы датчиков, в случае непредвиденных ситуаций. Можно было установить флаг срабатывания датчиков. Конечно, это было для тестирования сделано. Ну и одной из возможностей было позвонить по установленному номеру (номерам) при срабатывании датчика и проиграть записанное сообщение, согласно типу события. Пожар там, взлом потоп и так далее. Часть железяк была подключена к уже имеющимся сигналкам.
Так что часть домов начала упорно звонить в полицию, часть послала сигнал на пульт, часть включила всё внешнее и внутреннее освещение ночью...
Короче нормально так было. Даже в местные новости попали.
И кстати штраф таки выкатила полиция. Но сугубо символический. Зато тестирование в полевых условиях признали полностью успешным.
Muzzy0
А в маленьком городке достаточно полицейских, чтобы навестить 500 домов одновременно?