Adamos, согласен. Поскольку господин Назаров отказался объяснять от чего он скрывается - то в топике можно дать общие советы цифровой гигиены. Как-то - использовать одноразовые ОС наподобие Tails, Whonix. Не хранить никаких файлов нигде и никогда. Часто менять провайдеры интернета. Жить под чужими документами.
Но честно говоря жить в таком режиме - некомфортно. Как будто ты уже - преступник.
Adamos, эта прога будет операционной системой. А задачи слива будут поставлены в рамках например глобальной борьбы с миграцией и терроризмом. Я просто привел пример технической возможности. А организационную или правовую - вы уж придумайте
Adamos, тема топика - анонимность. Сценарии придумай сам. Купил местный смартфон в зарубежной стране. И тут - хопа. Два профиля двух телефонов - matched.
Мне кажется что анонимность напрямую связана с отказом от сервиса. Ну хочешь полной и абсолютной анонимности - продай все и иди жить в лес. Питаясь грибами и ягодами.
Я себе сматрт купил уже тогда, когда работодатель стал руки выкручивать. Надо было для многофакторки на телефон поставить генераторы токенов MS-Authenticator, Duo-Mobile e.t.c.
Еще о новых методах человеского профилирования. Скорость набора текста и особые паузы между буквами. Это физиология каждого человека. По ней тоже можно достаточно точно если не профилировать то классифицировать людей.
И еще о мобилах. Встроенный акселерометр позволяет достаточно точно определять походку человека по ритму и характерным качаниям телефона когда он лежит в кармане. Этот ритм так-же индивидуален как и кардиограмма сердца например.
Adamos, когда грузят много данных - то отключают любую логику проверки. В частности триггеры могут быть узким местом. Или констрейнты. Особенно если они проверяют регулярку. Впрочем это - up to you. Если тебе надо загрузить десяток строк - то такой метод нормален. Просто тебе надо будет на каждое срабатывание реагировать. Согласись если битых строк много то оператор просто устанет нажимать ОК в UI. А битых строк бывает много.
У меня как-то была идея - составлять цифровой грамматический профиль в соц-сетях. Идея была такая. Все люди имеют какие-то уникальные ошибки-очепятки в тексте. И чем больше текста я собираю - тем точнее этот грамматический профайл. Далее - дело техники. Ты зашел на политический телеграм прикинувшись борцуном. А тут я. Хлоп тебя. Вот он. Даенонимизирован.
Не спец по крипте. Но если подходить с точки зрения принципов торговли - то каждый раз когда вы продаете или покупаете - вы себя чуть деанонимизируете. Без этого никак.
Кстати многие хацкеры 2000х были пойманы именно на обналичивании крипты. Жадность .. как говорицца фрайера сгубила. Не смогли залечь на дно на пару лет.
По поводу VPN и прокси-анонимайзеров. Есть такое понятие как honey-pot. Это ресурс который обычно привлекает "мамкиных хакеров" обещанием быть анонимными. Но при этом сами владельцы VPN например могут неограниченно накапливать информацию о вашей активности чтобы в нужный час X предоставить ее кому надо. Это скорее всего указано в договоре мелким шрифтом.
По поводу tor и прочего. Кибердед-Масалович в одном из своих блогов рассказывал вариант атаки на тор позволяющий за несколько итераций установить сеанс пользователя по времени выхода в сеть. Я тут не специалист. Пускай знающие прокомментируют.
По поводу средств симметричной криптографии. В простейшем сферическом случае (Алиса и Боб) все крипто-средства скрывают контент но не могут скрыть транспорт. Тоесть факт взаимодействия Алисы и Боба невозможно скрыть с точки зрения следящих органов невзирая ни на какие крипто-алгоритмы. Что делать с этим фактом? ХЗ. Следователь знает что делать. Он просто спрашивает дескыть вы товаришь такого-то числа выходили в сеть. Что вы передавали? И так далее...
Leonid_V, смотри. По поводу выбора способа хранения данных. Есть целая матрица стратегий как и чего хранить. В основном она зависит от доступа. Обсуждать эту задачу нужно сразу в свете сразу трех прожекторов. Первое - это ООП. И объект должен максимально отражать бизнес. Тоесть это должен быть не массив массивов массивов. А именно коллекция абстрактных бизнес-объектов (отчеты) которые имеют под-типы (Основной отчет, Расширенный, Годовой и т.п.). Второй прожектор это перформанс. Объекты должны лежать в максимально-детализованном виде. Тоесть никаких JSON строк быть не должно. Должны быть Java Maps, Lists e.t.c. С вложениями. И есть третий прожектор - это экономия Java Heap если ты решил прогрузить терабайтный CSV файл. Третий пункт вообще-то противоречит первым двум. И если мы докатились до такого кейса то надо снова обсуждать и ООП и перформанс.
Вобщем как ты понимаешь здесь нету идеального решения. Есть матрица стратегий. И твой Java-ментор не смог тебе ответить просто потому что здесь нет лучшего решения. Здесь есть оптимальные для данного класса условий.
Сам по себе формат CSV - достаточно плоский. Он на 99% близок к реляционной таблице где в полях лежат атомы. Строки. Числа. Но не JSON документы. Если вы ступили на такой грешный путь - то вам дорога в другую (не реляционную систему). Mongo или CouchDb к примеру.
Когда мы работали с одним хедж-фондом - то загружали данные биржевых сводок из CSV в Apache Ignite и мы выбрали такой способ хранения как Vertical Arrays. Это обычные Java массивы которые хранят колонки таблицы. Они - примитивны. Int, Long, String. Но для нашего варианта доступа такой способ подходил лучше чем хранение Java entities. Грубо говоря мы развернули способ хранения на 90 градусов.
Даже такое бывает. Вот думай. Вопрос сложный. И на него нельзя просто так ответить в рамках тех условий что ты рассказал.
Но честно говоря жить в таком режиме - некомфортно. Как будто ты уже - преступник.