Комментарии 34
Вот почему облачная функциональность должна быть дополнением, и никогда не иметь приоритета перед локальными настройками/данными. Другие варианты небезопасны по определению.
Ну че — классика жанра!
Приятно видеть, как люди вынуждены учиться на собственных ошибках, правда каков будет результат урока — пока что не ясно.
Удивляет связность сети, где заражение пользовательских рабочих станций кладет все. Это наводит на мысль, что, возможно, заразился не юзерский пк, а вполне себе серавр где-то посредине, если вообще не станция администратора.
В свое время, я пережил очень похожую историю, когда атака шла со стороны пк админов. Это было в 2009м и дальше шлюзов проникнуть не смогли. Т.е. у нас полегло несколько филиалов, но ядро осталось целым.
Уже потом мы выяснили, что в одном из оконечных маршрутизаторов в ргионе (!) был хитрый бекдор… Это так, к слову.
Уже потом мы выяснили, что в одном из оконечных маршрутизаторов в ргионе (!) был хитрый бекдор…
можно даже без бекдоров, достаточно забить на установку апдейтов, как очень многие админы любят и всем советую в первую очередь отключать автообновление винды и т.п.
Я учавствовал в паре тестирований на проникновение, достаточно иметь пару неустановленных патчей в уязвимых местах, специализированный софт моментально выстраивает цепочку проникновения… помню в одом случае у тестеров хватило около 4х часов чтобы получить рута на сервере в ядре сети, только потому что последние апдейты на марштуризаторы ставились месяц назад, а на ОС — две недели назад…
Полностью вся цепочка была взломана эксплойтами месячной-недельной давности, причем в автоматическом режиме и с минимальными возбуханиями со стороны сервисов мониторинга (все выглядело как обычные действия админов, пока через созвоны выясняли что происходит, было уже поздно)
Вах как интересно. А как софт называется?
Мне бы себя поломать эксперимента ради...
У меня возникает опасение что если подобное случится с Alexa, то как минимум четверть её пользователей умрут от голода, холода или жары...
Вроде, контора серьезнее некуда, а информационной безопасности не больше, чем в районной больнице.
а апи у них наслышан дерьмовый, на оаус1...
А вообще, конфликт версионности это не решает, т.к. исходные данные лежат на пользовательских устройствах(часах), и там форматы не меняются лет по десять. а весь софт для анализа этих данных уже вторичен, не так страшно что будут разные версии.
Я надеюсь, хотя и маловероятно это, что они сделают оффлайн-билд своих сервисов чтобы вернуть лояльность пользователей
Доктор или тренер должны получить их лично от меня, на USB стике или в виде файла, или даже просто посмотреть на моём экране — и ни при каких условиях они не должны получать их с сервера в интернет. Если лично не получается — передача в зашифрованном виде на устройство доктора. В любом случае — только push, никаких pull — это единственное что может минимизировать (хотя и не исключить) проблемы с их утечкой и злоупотреблениями.
В тех редких случаях когда доктору нужен постоянный доступ на протяжении длительного времени — нужно обеспечить независимое устройство с правом доступа только у меня и доктора, а при необходимости хранения в облаке — они должны быть зашифрованы, чтобы бы оператор облака не имел принципиальной возможности на них посмотреть.
При этом, я (пользователь) должен иметь возможность в любой момент этот доступ запретить, а также (при необходимости) получить полный отчёт — когда и какие данные использовались или были запрошены доктором, и с какой целью (если это не очевидно — к примеру, тренеру совсем не нужно знать сколько раз я ходил в туалет).
Более того — я, как пользователь, должен иметь возможность получить все эти данные ровно в том виде в котором их получает доктор, а также иметь возможность делать ручной или автоматический бэкап этих данных в структурированном машинно-читаемом виде без дополнительных затрат, в конце концов это мои данные и даже моё устройство.
Плюс ко всему — любые данные которые хранятся в облаке должны быть зашифрованы с ключём доступным только пользователю (или доверенным агентам, которых он сам определяет — исключительно opt in), с детальным трекингом кто, когда и что оттуда вытаскивал.
Конечно, это в идеальном мире...
Либо использовать для этого те же онлайн сервисы, но лишь в качестве дополнения к офлайн приложениям пользователей
Мастер источником логично считать всё же мастер источник — то есть собственно устройство, ибо только оно производит эти данные, а центральная БД — это просто реплика собранных данных, и что там с ними происходит дальше никак не должно отражаться на устройстве, даже если база исчезнет.
Другое дело если устройства собирают столько данных что они физически нехранимы на нём самом, тут да, проблемы могут быть — но меня терзают смутные сомнения что фитнес-браслеты требуют десятков гигабайт на хотя бы год работы.
Да и конфликты версионности вряд-ли возможны — потому что все (практически) обновления обязательны, без них устройство не допускается к передаче данных, да и без них можно построить архитектуру в виде сенсор-коллекторы-база где коллекторы будут разбираться с форматами и версиями сенсоров и в нужном виде отправлять в базу.
А так… похоже о пользователях думали лишь как об источнике данных, вариант даже просто отсутствия сети длительное время явно не учитывали (хотя это нормальное явление в ряде регионов), что уж тут говорить про катастрофу...
В конце концов, приложения типа GadgetBridge спокойно обходятся без облака, но производители устройств применяют невероятные усилия чтобы без учётки и сети ими невозможно было пользоваться, даже простой автоматический экспорт данных в чём-то типа "csv" там редкость, что уж тут говорить про открытие API для сторонних приложений.
Если у меня есть сенсор который что-то передает на сервер, каждая единица данных имеет временную метку и непрерывный id, который увеличивается строго последовательно, то есть и устройство и база всегда точно знают что уже там а что нет, и даже способны определить проблемы с синхронизацией таймеров (если это важно). Для особо важных случаев можно даже делать валидацию уже переданных данных, путём банального сравнения последних переданных N блоков или дней или (проще) посредством хешей (это позволит быстро проверять даже очень большие наборы данных).
В сочетании с уникальным идентификатором набора данных (учётка + id устройства) это обеспечивает довольно простой и отказоустойчивый способ передавать только то что нужно, причём в обе стороны (синхронизировать).
На самом деле есть куча способов это решить с минимальными усилиями, было бы желание.
Ваш вопрос очень абстрактный. Какое устройство? Была ли на нём предусмотрена возможность повторной передачи? Как оно определяет что данные нужно передавать за определенный период? Где хранятся данные (внешний носитель, внутренний, доступный извне, недоступный etc)? Какими метаданными располагает база и какие находятся в передаваемых данных (метки времени, etc)? Есть ли валидация данных (контрольные суммы etc)? Могут ли в принципе переданные данные корректироваться или дополняться пока не было связи?
Но всё же… поскольку устройство (по крайней мере если это фитнес-трекер) — изначальный генератор данных и в конечном итоге их потребитель — то верить нужно только устройству. База должна быть исключительно репликой данных устройства.
Хотя то о чём вы спрашиваете больше вопрос обработки исключительных ситуаций — если устройство изначально не было расчитано на "правильное" взаимодействие с базой, можно предположить два варианта:
- был сбой и повторная передача содержит точно те же данные что у нас уже есть — игнорировать передачу но притвориться что мы их приняли, чтобы "успокоить" устройство.
- был сбой и (возможно) старые данные уже повреждены — соответственно игнорировать, ибо по определению данные о ваших тренировках не могут измениться в принципе.
- имеет место быть намеренная попытка "переписать историю" — я бы заблокировал передачу данных и спросил пользователя что делать (это его данные и спрашивать нужно его, объяснив что происходит)
Если же оно изначально было расчитано на адекватную обработку, но ведет себя неестественно — это либо очень жёсткий сбой с повреждением критических данных, либо попытка вмешаться в его работу, в обоих случаях автоматически (без ручного анализа данных на устройстве и в базе) мало что можно сделать.
Хотя самая простая стратегия, которая покроет 99% всех случаев — это игнорировать старые данные, тем не менее подтверждая их приём, опционально сравнивая с уже имеющимися.
Если попыток несколько — значит устройство явно в неадекватном состоянии и все попытки передачи данных нужно блокировать, с информированием пользователя, или сохранять только различающиеся данные в пределах первых нескольких попыток и потом всё равно блокировать (потому что это ненормально).
Как я уже сказал, способов зиллион, но нужно знать точно о чём речь и текущую архитектуру.
И да, вы правы, могли бы быть и другие решения, такие как описываете вы.
Не решают, потому что облако служит для единственной цели — хранить данные от устройства (по крайней мере в случае трекера) и отдать их если попросят. Для любых других запросов (кроме самого устройства) — да, облако мастер.
По логике только само устройство (или его пользователь) могут решить какие данные верные, а данные нужны только на случай отсутствия данных в устройстве.
В любом случае для работы с оперативными (доступными на самом устройстве) данными доступ к облаку (и сети) вообще не нужен, особенно для просмотра, потому что данные на которые уже есть на устройстве — по определению мастер (а не те которые в облаке), и именно этот принцип был нарушен Garmin.
PS: Преставьте что вы пишете рассказ и периодически заливаете новые версии в облако, но в какой-то момент облако решает что ваша версия — совсем не мастер, и нужно вернуть то что хранится в облаке. Вы правда этого хотите? Данные трекеров — тот же рассказ.
Реквестирую создание нормального опен-сорсного софта для сохранения и анализа занятий (графики там, наложение трека на OSM карту, подсчет средних-среднеквадратичных-стандартных отклонений...), благо .fit это простой текстовый формат (то ли xml то ли csv, давно копался, не помню).
Под мак лет десять назад подобное было, но очень слабо развитое на тот момент
FIT — это полноценный бинарный формат с кучей наворотов, вроде хранения фаз сна, кровяного давления и имеет спецификацию под 200 стр.
Но открытого нормального софта под это всё — равно мало, ввиду относительно малого спроса. Большинство пользуются стандартными Garmin Connect, Strava и тд — и не парятся об открытости и «облачности».
Насколько я помню, fit конвертируется в gpx посредством gpsbabel, а gpx открывается osmand или gpxanalyser под android.
И, вроде бы, в gpsbabel есть ещё опция экспорта в какой-то простой формат (csv или txt), я прямо таки в Excel треки потом рисовал для интереса.
golden cheetah
www.goldencheetah.org
www.trilife.ru/reports/golden-cheetah-rukovodstvo
github.com/GoldenCheetah/GoldenCheetah/releases
Интересно, их не мяукнули часом?
Сервисы и устройства Garmin слегли, вероятно, из-за атаки вируса-вымогателя