11% денег «Цифровой экономики» перевели в резервный фонд. Среди пострадавших направлений - 5G, госуслуги, отечественное ПО http://www.tadviser.ru/a/389793

Пришла пора поговорить о качестве данных собираемых органами власти. Забегая вперёд скажу что она невысокая, в качестве примера рассмотрим свежеопубликованный [1]
Минэкономразвития список системообразующих предприятий. его можно скачать напрямую в Excel [2].

Посмотрев на этот список внимательно, можно обратить внимание что на какие-то самые очевидные проблемы, когда указан ИНН организации с размером меньше на один символ, но даже беглая автоматизированная проверка показала что там не только с этим плохо.

Поскольку я хочу, в дальнейшем, этот кейс использовать как обучающий, дальше буду объяснять максимально подробно, надеюсь тем кто умеет работать с данными будет не очень скучно;)

Краткие выводы (Executive Summary)
В 4,3% записей в списке системообразующих предприятий содержатся ошибки, включая
- у 31 организации, неверно указан код ИНН (опечатка или ошибка форматирования с потерей первого символа)
- у 12 организаций указано устаревшее название, как правило ОАО или ЗАО вместо АО
- у 6 организаций те или иные ошибки в их наименовании, опечатки смысловые и иные
- у 2 организаций указаны реквизиты других существующих организаций, ошибки которые невозможно совершить опечатками

Причины этого в низкой культуре работы с данными в Минэкономразвития России, отсутствии мер по проверки поступающих им данных.

Методика
Итак, какие правила валидации сведений об организациях обычно применяют:
- проверка кодов реквизитов (ИНН и ОГРН), в нашем случае у организаций есть только коды ИНН
- корректность названия организации, разделяется на (устаревшее название, ошибка в названии)
- указание неверной организации, когда реквизиты и название организаций ошибочны. Например, ИНН указывает на одну, а название на совершенно другую.

Входящие данные и их подготовка
Что у нас есть на входе, Excel файл [2] со списком организаций, однако в поле ИНН по некоторым из них вписано до двух кодов, а то есть юр. лиц у нас как минимум больше на эти дополнительные коды.
1. Проводим перестройку списка и получаем на выходе список из 1173 организаций (у 22 записей были по 2 кода ИНН, так что и получается 1151 + 22 = 1173), остальные значения в строках для добавленных записей оставляем прежними.
Всё это делается автоматически, коды ИНН в колонке "ИНН" разделены запятыми.
2. Преобразуем всё в CSV файл, нормируем названия полей в англоязычный формат (удобнее для обработки и большая стандартизация названий)
3. Делаем очистку поля ИНН от пробелов, "тримминг" так чтобы остались только значения цифр.

В итоге получаем CSV файл пригодный для последующего обогащения данными

Начальная проверка
Полученного нормализованного файла достаточно чтобы провести первую, быструю проверку. В репозитории утилиты Undatum есть код проверки ИНН [3], достаточно выполнить функцию _check_inn и сохранить результаты в новом CSV файле c колонкой valid_inn.
После проверки у нас должно получиться 31 ИНН не проходящих валидацию. У 4-х кодов будут опечатки в цифрах и у 27 кодов ошибка при форматировании, "съеден" ноль в численном значении, поскольку Excel часто считает что в колонке ИНН указано число, а не численная строка, то удаляет нули. Но грамотные Excel пользователи это знают и за таким следят.

После начальной проверки переходим к углублённой и для этого обогатим данные.

Обогащение данных
Для анализа нам необходимо:
a) Проверить реквизиты, в нашем случае код ИНН, уже сделано, данные новые тут не нужны
б) Проверить названия организаций, для чего нам нужны другие названия этой организации которые можно взять в статрегистре Росстата (обновляется раз в год, может быть устаревшим) и в ЕГРЮЛе (всегда актуально).
в) Возможно нам в будущем понадобятся другие данные, поэтому почему бы нам не добавить из ЕГРЮЛа ещё и код ОГРН, он поможет сопоставить с другими реестрами и основной код ОКВЭД, вдруг мы захотим проверить как отрасль указанная в списке соответствует основной деятельности организации.

Для всего этого у нас есть доступ к API статрегистра и ЕГРЮЛа (из сервиса apicrafter.ru), но их много разных на рынке, можете воспользоваться любым. Через них проверяем каждую организацию и заполняем колонки:
- statreg_name - название организации в статрегистре,
- ogrn - код ОГРН
- egrul_name - название организации в ЕГРЮЛ (сокращённое),
- okved_code - код ОКВЭД
- okved_name - наименование основного кода ОКВЭД

На выходе имеем CSV файл где к изначальным колонкам добавлены ещё и эти, собранные в процессе обогащения данных.

Финальные проверки
Есть 2 способа проводить проверки. Для малого объёма данных, делать это вручную, для большого автоматизировано. В нашем случае объём скорее малый, вручную проверяется за пару часов, поэтому можно сделать и то и то.
Коды ИНН уже проверены, поэтому проверять надо остальные 1142 организации (1142 = 1173 всего - 31 с невалидными ИНН).
Далее я пропущу автоматическую проверку названий, она включает чуть более сложные проверки чем корректность кодов ИНН, фактически разбор и нормализация названия организации и я чуть позже опубликую её код. Пока это можно проделать и вручную.
Простейшие проверки:
а) У организации в списке указано что она в юр. форме ОАО или ЗАО, а в ЕГРЮЛе указано что это АО или ООО. Дело в том что юридические формы ОАО и ЗАО более не существуют и организации должны сменить юр. форму в ОАО или ООО по выбору при первом изменении в ЕГРЮЛ.
б) У организации понятная юр. форма ООО или АО, но в ЕГРЮЛе указана другая. Это скорее всего ошибка, неверное название.
в) Название организаций не совпадает полностью. В этом случае пробиваем ЕГРЮЛ на название в из поля названия в списке и ищем ИНН. Если у организации находится ИНН, то это ошибка с указанием другой организации. Если нет, то это ошибка в названии организации.

Всё это проверяем вручную в 2 прохода. В промышленной работе, это обычно, делают специалисты по ручной обработке, которые проверяют после алгоритмов. В данном примере, я описываю то как, примерно, ставится им задача.

Инструментально всё это можно проделать в Excel, LibreOffice, Google Spreadsheets или в OpenRefine. Я считаю что последний удобнее для любых задач преобразования данных (data wrangling), но неудобен для совместной работы нескольких человек проверяющих вручную. Выбор тут есть, и коммерческие решения тоже существуют.

Итоги и выводы

Итого у нас на выходе 20 подобных записей, а вместе с 31 записью с некорректными ИНН это 51 запись с ошибками, что около 4,3% реестра. Много это или мало? Об этом лучше судить тем кто может измерить экономические последствия неверно представленных данных. Например неполучение поддержки организациями имеющими на неё право или получение её теми что не имеют. Это вопрос уже к экономистам, аудиторам и следователям.

Если вдуматься в причины почему такой важный реестр ошибочен на 4,3% то причин тут несколько:
1) Отсутствие культуры работы с данными. Основная и главная причина, поскольку более 27 или 51 ошибки - это ошибки самого базового уровня работы с Excel.
2) Отсутствие проверки и валидации данных на стороне Минэкономразвития, что бы не поступало им на вход, они должны были перепроверить и затребовать исправление.
3) Низкое качество реестров ФОИВов где указаны устаревшие названия организаций и просто наименования с ошибками
4) Более системная проблема, отсутствие регламентов ведения подобных списков именно с точки зрения данных.

Итоговый файл с результатами и конкретными ошибками можно скачать на Data.world [4]

P.S. Этот материал - это заготовка для обучающих материалов по работе с данными. Он очень хорошо помогает в формировании наглядных примеров того как проверять корректность данных и для чего это необходимо. Вскоре на его основе будет Jupiter Notebook или какой-то его аналог где всё уже будет ещё более подробно разобрано.

Ссылки:
[1] https://data.economy.gov.ru/
[2] https://data.economy.gov.ru/system_org.xlsx
[3] https://github.com/datacoon/undatum/blob/master/undatum/validate/ruscodes.py
[4] https://data.world/infoculture/system-orgs-analysis

Итоговый файл проверки на корректность списка системных организаций опубликованного Минэкономразвития России

На ComNews неожиданно довольно вдумчивый текст про проблемы тиражирования практик Московской области в виде решений Добродел и других [1] которыми ранее занимался Максут Шадаев.

Я, на самом деле, по возможности, реже комментирую деятельность нынешнего состава Минкомсвязи. Честно говоря вообще подумываю не комментировать деятельность любого состава Минкомсвязи, потому что толку-то;)

Кто бы ни был министром связи и как бы не менялся состав федерального правительства важно запомнить следующие важные тезисы:
1. Региональные системы/функции/полномочия будут продолжать концентрировать в федеральных ГИС под управлением профильных федеральных ведомств.
2. Все "условно государственные" данные будут концентрироваться в Москве или околомосковских ЦОДах и, может быть, с какими то крупными ЦОДами в паре субъектов федерации.
3. Регионы не имеющие собственных внедрений систем автоматизации своих полномочий не будут аргументов в спорах с фед. центром когда им будут навязывать централизованные решения.
4. Почти все глубоко дефицитные регионы будут в безвыходном положении, внедрять федеральные решения.

Примеры федеральных ГИС уже работающих: ЕИС (госзакупки), ЕПБС, ГИС ЖКХ, ГИС для ведения ФРДО, ЕГР ЗАГС и ещё десятки других.

Тренд этот идёт не от Максута Шадаева и не от Константина Носкова до него и нет от Николая Никифорова до него. Это тренд исключительно корпоративно политический на ужесточение контроля над всеми субъектами федерации.

Зачем это нужно спрашивайте у политологов.

Ссылки:
[1] https://www.comnews.ru/content/205774/2020-04-27/2020-w18/pochemu-tema-tirazhirovaniya-sistem-podmoskovya-i-kremlya-okazalas-zakrytoy

#data #russia #government

В ИТ по миру начинаются крупные увольнения и сокращения. Если Google пока только прекратили нанимать новых сотрудников в подразделение маркетинга, то Uber увольняет 5400 человек (20% штата) [1].

Techcrunch выдаёт всё больше новостей по тегу layoffs [2], а Bloomberg пишет о том что крупнейшие ИТ бренды дают обещания никого не увольнять [3].

А что у нас в России? Есть ли ресурсы собирающие информацию о массовых увольнениях в ИТ и не только?

Ссылки:
[1] https://www.theverge.com/2020/4/28/21240414/uber-cto-thuan-pham-resign-layoffs-kalanick
[2] https://techcrunch.com/tag/layoffs/
[3] https://www.bloomberg.com/opinion/articles/2020-04-27/coronavirus-nvidia-cisco-paypal-are-smart-to-pledge-no-layoffs

#jobs #layoffs

В Defense One пишут о сокращении производства на российских оборонительных заводах [1] из-за COVID-19, а PWC France опубликовали записку о результатах геомониторинга экономической активности на фоне COVID-19 [2] и о падении производства на многих китайских заводах.

В обоих случаях авторы ссылаются на данные от Orbital Insight, стартапа из Palo Alto, в Кремниевой долине. С 2013 года, своего основания, они получили 128,7 миллионов USD инвестиций из которых 50 миллионов USD в 2019 году.

Их основная специализация - это геомониторинг, с распознаванием того для чего используются земельные ресурсы, скоплений людей, машин и объектов и анализу социальной активности.

Orbital Insight - это один из ключевых источников альтернативных данных, используемых параллельно с официальной корп. отченостью или госданными. Они, при этом, безусловно не единственные в этой области. Был обзор платформы Quandl по подобным проектам в 2016 году [3]

Ссылки:
[1] https://www.defenseone.com/technology/2020/05/russian-arms-production-slowed-coronavirus-analysts-find/165071/?oref=d-river
[2] https://www.pwc.fr/fr/assets/files/pdf/2020/04/en-france-pwc-covid-19-insights-from-space.pdf
[3] https://blog.quandl.com/alternative-data-satellite-companies

#alternativedata #data #satellite

Максим Смирнов очень кратко и точно [1] про правильное определение digital disruption. Это вынужденная ситуация зависимости как альтернативы потери эффективности. Наиболее эффективные стартапы автоматизируют очень узкую функцию, но очень эффективно. И в определённый момент ты оказываешься в ситуации когда, либо ты от этого сервиса отказываешься и занимаешься, прости Господи за неприличное слово, импортозамещением, или используешь с кучей рисков: санкций, банкротства сервис провайдера, смены его бизнес модели, безальтернативного повышения цены и так далее. Самый очевидный и наглядный пример сейчас - это Zoom. Нишевый сервис который создавался совсем не для того для чего сейчас используется, как следствие, при всём богатстве выбора альтернативы не радуют.

В итоге технологические решения оказываются, часто, сложнослепленным набором разных узкозаточенных профессиональных решений и современное искусство что программирования, что проектирования - это уметь собирать такие конструкторы. Крупнейшие ИТ экосистемы, такие как AWS, Azure, Google Cloud и др. имеют ценность именно в том что они предоставляют возможность получить "сразу всё из коробки" и, в то же время, поднастроить под себя то что хочется получить в иной форме.

В России в госсекторе собирать такие сложные конструкции всегда было большой проблемой и остаётся, кстати, тоже. Создатели гособлаков или ГосТеха не понимают что такое создание конкурентной среды и экосистемы для G2G сервисов. Отсюда и возникают ровно противоположные по устремлениям и одинаково вредные активности по "централизации ИТ" и "децентрализации ИТ", вместо среды где каждому есть место, а главное что любой создаваемый продукт/сервис можно было бы делать не с нуля.

В России из коммерческих сервисов только Яндекс.Облако немного приближается к созданию экосистемы, но других конкурентных преимуществ кроме отечественности у него, увы, нет.

Ссылки:
[1] https://t.me/it_arch/801

#govtech #technology #startups

Мне довольно утомительно повторять идею, которую мне внушили еще лет десять назад: digital disruption – это не о том, что надо всю деятельности перевести в цифру, а скорее о том, что завтра придет какая-то неизвестная ранее компания и начнет делать некоторую, очень малую часть вашей цепочки создания ценности в десять раз эффективней, чем вы это делали сами. При этом, скорее всего платить ей за использование этой фичи вы будете в десять раз больше, чем тратили на этот шаг цепочки раньше. Потому, что это капитализм. Отказаться будет можно только потеряв часть клиентов, возможно значительную часть. Ну, просто клиенты начнут орать: почему вы не продаёте айфоны или еще что-то подобное. Главное, что требуется от компаний (и от их айтишников), четко и экономически выгодно на это отреагировать. Т.е. не раздавать айфоны бесплатно у метро, а сделать что-то чуть более осмысленное

Тем временем Bloomberg запустил свой трекер восстановления экономики [1], в основном на альтернативных данных:
- новые случаи COVID-19
- индекс закрытия (Lockdown Index)
- запросы на пособие по безработице
- число поездок общественным транспортом
- ипотечные запросы
- удобство потребителей
- продажи в тех же магазинах (непонятный критерий)
- бронирования в ресторанах
- активные нефтяные скважины
- производство стали
- индекс S&P
- финансовое состояние рынка

Почти все индексы негосударственные, основанные на альтернативных данных.


Ссылки:
[1] https://www.bloomberg.com/graphics/recovery-tracker/

Очень часто приходится слышать термины Data Warehouse, Data Lake, Data Hub, при этом часто произносящие их не задумываются о реальных отличиях этих понятий. В блоге The Startup на Medium хороший обзор на английском [1] об отличии и сходствах таких понятий как:
- Data Lake
- Data Hub
- Data Virtualization / Data Federation
- Data Warehouse
- Operational Data Store

Все отличия объяснены на редкость доходчиво, я как-нибудь найду время перевести этот текст на русский язык.
Краткий ликбез такой:
- Data Lake (Озеро данных) - это несвязанные данные удобные для data science и аналитической работы. Работает в ситуации возникновения задач и адаптации данных под конкретные задачи.

- Data Hub - это данные собранные в одно хранилище с некоторой работой по преобразованию и обработке. Больше форматирования, контроля и управления по сравнениею с озером данных.

- Data Virtualization/Data Federation - это пробрасывание виртуальных связей между источниками, иногда уже начало ведение общих справочников. Больше ориентировано на данные реального времени и интеграцию

- Data Warehouse - наиболее подходит для подготовки управленческих отчетов, готовится на основе масштабной обработки данных, контроля справочников и так далее. Очень негибко, но наиболее пригодно к управлению циклом жизни данных

- Operational Data Store - это, как правила, зеркала для хранения транзакционных баз данных чтобы не затрагивать сами базы данных работающих в режиме реального времени.

Ссылки:
[1] https://medium.com/swlh/the-5-data-store-patterns-data-lakes-data-hubs-data-virtualization-data-federation-data-27fd75486e2c

#opendata #data #datalakes #datamanagement #datagovernance

Для тех кто хочет сделать полезное в открытых данных, имеет свободное время и свободный английский - проект OpenRefine ищет специалиста/команду/компанию тех кто создаст им документацию по продукту [1]
В общей сложности они хотят сделать эту работу за 6 месяцев и 25 000 USD (примерно 1,86 миллиона рублей). Финансируется проект полностью из грантовых источников нескольких фондов Кремниевой долины. В частности из фонда Чан-Цукерберг по поддержке науки.

OpenRefine хороший проект, важная часть многих академических проектов по созданию инфраструктуры данных. Например, они активно используются в австралийском Data61 CSIRO. Однако у команды которая им занималась с самого начала не задалась коммерциализация и попытки создать онлайн сервис для Data wrangling (Манипулирования данными) не увенчались успехом. Сейчас они все ещё предлагают услуги в виде компании RefinePro [2], но не то чтобы заметны на рынке.

Сам проект происходит из когда-то выложенного в виде открытого кода проекта Google Refine [3]. Ранее он был разработан в Metaweb , компании занимавшейся проектом Freebase, пожалуй, одним из наиболее успешных стартапов занимавшихся связанными данными и выкупленной Google в 2010 году.

Ссылки:
[1] http://openrefine.org/blog/2020/04/23/documentation-hire.html
[2] https://refinepro.com
[3] https://en.wikipedia.org/wiki/OpenRefine

#opendata #openrefine #datajobs

Вышел Open Budget Index за 2019 год [1], обзор оценок открытости бюджетов по странам мира. Он охватывает большинство значимых стран, кроме разьве что, небольших тихоокеанских островов.

Ключевое в индексе - это оценка прозрачности бюджета (budget transparency score). Это совокупность всех оценок прозрачности бюджета, бюджетного процесса на всех стадиях.
У некоторых стран эти оценки совпадают, поэтому правильно считать их места не по списку сверху вниз, а учитывая что некоторые места поделены.
На 1-м месте с оценками в 87 баллов: Новая Зеландия и Южная Африка
На 2-м месте с оценкой в 86 баллов: Швеция

Россия на 7 месте которое она делит с Францией имея 74 балла. Это довольно высокий уровень прозрачности бюджета. Это выше чем Великобритания с 70 баллами и ниже чем США с 76 баллами.

Значит ли это что в России всё хорошо с финансовой открытостью? В целом оно лучше чем у многих стран, но есть нюансы. Например, из-за нац проектов сократилась открытость бюджетной росписи, о чём я писал в колонке в РБК в прошлом году [2]. А оценки вовлечения общества в формирование бюджета очень низкие 22 балла из 100 возможных [3]

Ссылки:
[1] https://www.internationalbudget.org/open-budget-survey/rankings
[2] https://www.rbc.ru/opinions/economics/20/09/2019/5d81e9f99a7947a59b1f7cea
[3] https://live-international-budget-partnership.pantheonsite.io/open-budget-survey/country-results/2019/russia

#openbudgets #budgets #opengov

На CockroachDB [1], движок баз данных с открытым кодом с гео-масштабированием, работой в облаке и с SQL, развиваемый стартапом CockroachLabs [2], его создатели получили $86,6 миллионов финансирования от венчурных фондов [3], что в совокупности даёт $195 миллионов с 2015 года.

По сути, CockroachDB - это PostgreSQL на стероидах. В сравнении на ObjectRocket [4] довольно хорошо перечислены их отличительные особенности и возможности. Все они связаны с репликацией, геомасштабированием и многокластерностью. Важные задачи для любых геораспределённых сервисов и не так критичные для геостационарных, локальных сервисов.

Исходя из их позиционирования можно предполагать что они стали реально востребованным продуктом для крупных цифровых игроков, делающих сервисы и приложения на весь мир.

Ссылки:
[1] https://github.com/cockroachdb/cockroach
[2] https://www.cockroachlabs.com/
[3] https://www.zdnet.com/article/a-gmail-for-databases-cockroachdb-aims-for-the-top-stocks-up-with-86-6m-new-funding/
[4] https://www.objectrocket.com/blog/cockroachdb/how-to-choose-between-postgresql-and-cockroachdb/

#data #databases

Внезапно Zoom купил очень интересный стартап Keybase [1]. Однако KeyBase - это прикольные ребята помешанные на безопасности, а у Zoom с безопасностью всё из рук вон плохо. Надеюсь от этой сделки похорошеет Zoom'у и не поплохеет Keybase. Всё таки я лично пользователь Keybase со стажем.

Ссылки:
[1] https://keybase.io/blog/keybase-joins-zoom

#privacy #security

Среди многочисленных проектов и бизнесов на данных, особо интересны имеющие качественное отраслевое применение, даже если сама бизнес модель совсем не про данные.

Molbase - китайский стартап [1], маркетплейс продажи и покупки химических компонентов. Объединяет спрос и предложения от малых и средних китайских компаний на химические вещества совершенно любого типа. У маркетплейсов своя понятная ниша и, казалось бы, ну что тут можно добавить, но вот создатели Molbase добавили базу знаний по всем продаваемым компонентам, поиск по видам и типам химических веществ, по формулам, химической структуре и так далее.

В декабре они вышли на IPO и сейчас их капитализация $205.9 миллиона [2], а бизнес модель построена на автоматизации хранения и логистики и заявленное число клиентов составляет 94 тысячи покупателей и 33 тысячи продавцов [3].

При этом особенный акцент во всех публичных материалах именно на данные и на искусственный интеллект, с рекомендательными возможностями.

Ссылки:
[1] https://molbase.com
[2] https://craft.co/molecular-data/metrics
[3] http://investor.molbase.com/static-files/d06191ae-4466-449d-a56f-ff27faf808d0

#data #datamarket

Поставщик Минэкономразвития по сопровождению портала открытых данных добавлен в РНП

Компания "Рунетсофт" 13 апреля добавлена в Реестр недобросовестных поставщиков (РНП) за контракт на сопровождение портала открытых данных (data.gov.ru), исполнение которого было прекращено по инициативе Минэкономразвития в середине марта [1]. Напомню, что стоимость этого контракта - 21,8 млн руб., а фактически из ТЗ почти ничего не было выполнено (не говоря уже о качестве тех работ, которые попытались выполнить).

Интересно, что включение Рунетсофта в РНП не помешало Окружная администрация города Якутска заключить в конце апреля с ними контракт на обновление и техническое обслуживание своего сайта, стоимостью 1,3 млн руб.

[1] https://zakupki.gov.ru/epz/contract/contractCard/common-info.html?reestrNumber=1771034949419000094
[2] https://zakupki.gov.ru/epz/contract/contractCard/common-info.html?reestrNumber=3143513390720000021

Цифровая трансформация по польски - это Национальная облачная платформа (Chmura Krajowa) [1] созданная в 2019 году Банком Польши и Польским фондом развития. В сентябре 2019 года они заключили партнёрство с Google, а теперь ещё и партнёрство с Microsoft [2]. При этом Microsoft обещают проинвестировать около 1 миллиарда долларов на создание польской цифровой долины [3].

Здесь интересно многое, например, будет ли это единичным случаем или форма целенаправленной экспансии международных облачных платформ в местные рынки.

И, не могу не напомнить о том где находятся датацентры крупнейших облаков в мире для Google Cloud [4] и Microsoft Azure [5].

Ссылки:
[1] https://chmurakrajowa.pl (польский)
[2] https://news.microsoft.com/europe/2020/05/05/microsoft-announces-a-1-billion-digital-transformation-plan-for-poland-including-access-to-local-cloud-services-with-first-datacenter-region/ (английский)
[3] https://cloudcomputing-news.net/news/2020/may/05/microsoft-unveils-1-billion-poland-cloud-and-digital-investment-plan/ (английский)
[4] https://cloud.google.com/about/locations/
[5] https://azure.microsoft.com/en-us/global-infrastructure/regions/

#datacenters #poland #digital #digitaltransformation

Reuters пишут что в Евросоюзе всерьёз подбираются к регулированию технологических гигантов [1] и заказали исследование на 649 тысяч евро целью которого будет рассмотрение практики разделения бизнеса крупнейших компаний и демократизации доступа к их данным. Однозначно под прицелом будут Google, Amazon, Apple и Facebook, но и другие технологические гиганты это может затронуть.

[1] https://www.reuters.com/article/us-eu-tech-antitrust/eu-looks-for-evidence-to-rein-in-u-s-tech-giants-idUSKBN22K2IT

#tech #regulation #data

Департамент здравоохранения Австралии выложил исходный код мобильных приложений для iPhone и для Android [1] на платформе Github. Кроме того в правилах использования приложения явно указано что все данные будут удалены после пандемии [2], а сам департамент выпустил акт о биобезопасности защищающий права граждан на приватность на период пандемии и после нее [3]. Также подготовлен законопроект особым образом защищающий приватность в этом мобильном приложении на время пандемии [4].

Ссылки:
[1] https://github.com/AU-COVIDSafe
[2] https://www.health.gov.au/resources/apps-and-tools/covidsafe-app#after-the-pandemic
[3] https://www.legislation.gov.au/Details/F2020L00480
[4] https://www.ag.gov.au/RightsAndProtections/Privacy/Pages/COVIDSafelegislation.aspx

#privacy #australia #opensource

Весьма интересная общедоступная база RUPEP.org [1] по базе PEP'ов - политически значимых персон. Уровень проработки у базы весьма неплохой, не только более 5 тысяч персон, но и все юр. лица с которыми они были связаны, с визуализацией и досье на каждую персону. Однако для работы с ресурсом требуется авторизация, там нет открытых данных и самый злободневный вопрос, а кто же автор? На странице "О проекте" владельцем базы указан PEPWatch [2], без каких либо реквизитов и выходных данных. PEPWatch - это коммерческое юридическое лицо в Чехии [3] с единственным учредителем Halyna Senyk [4] и без какой-либо дополнительной информации. Соцсети PEPWatch оказались удалёнными много лет назад, а отсутствие упоминание создателя организации в подробностях - это очень большая редкость в таких проектах.

Поэтому проект интересный и любопытный, а вот его создатель на редкость странный и непонятный. Что-то тут не так с его создателем

Ссылки:
[1] https://rupep.org
[2] https://rupep.org/ru/%D0%B2%D0%BE%D0%BF%D1%80%D0%BE%D1%81%D1%8B-%D0%B8-%D0%BE%D1%82%D0%B2%D0%B5%D1%82%D1%8B/
[3] https://rejstrik-firem.kurzy.cz/06719015/pepwatch-z-s/
[4] https://rejstrik-firem.kurzy.cz/osoba/2513651/

#open #peps