Обновить

Трекер отказа от стиков и вейпа: вайбкодинг, веб‑приложение и ноль персональных данных

Уровень сложностиПростой
Время на прочтение8 мин
Охват и читатели5.7K
Всего голосов 4: ↑4 и ↓0+6
Комментарии4

Комментарии 4

От сигарет отвыкли, это хорошо. А как теперь отвыкнуть от вайбкодинга?

Думаете вызывает привыкание?

Рабочий Offline first - уже за это можно в браузерном решении многое простить.

JS/CSS/woff файлы можно вынести отдельно (woff шрифтов больно много по кол-ву и весу - очень странно). Идеально - разбить HTML/JS/CSS на блоки по макс. 14Кб (особенности типичного Congestion Control; по 4-6 с одного домена, если больше, то добавить достаточное кол-во поддоменов, чтобы оно всё шло параллельно при первой загрузке и при обновлении только определённые блоки перегружались SWшкой).
Для мобильных сетей (особенно плохих) текущий вариант с одним файлом лучше всего (можно и иконку зашить в виде data uri), без учёта обновлений.

Наверное, хорошо бы шифровать ПД с использованием солёных хэшей локальных пар логин-пароля (утекли локальные данные и там всё открытым текстом - такая себе ситуация), даже для локальных данных. Предусмотерть их смену для перешифровки данных (вдруг все знают вашего кота и его ДР). Аналогично разграничить пользователей на одном устройстве. По этой же теме можно задать максимально жёсткие правила CSP и прибить CSS/JS ресурсы разрешёнными гвоздями-хэшами, чтобы нельзя было добавить доп. скриптов/стилей и пр. для соседних профилей или исполнить любой чужой JS код из-за наивности юзверя (генерацию HTML вывел бы из строк в создание DOM нод, т.к. через всякие innerHTML можно что-то смешное со своими ногами сделать из этой пушки).

localStorage - размер ограничен и обязательно у кого-то закончится (можно замерить кодом на устройстве, обычно 5Мб или чуть больше на один ресурс). Возможно стоит глянуть в сторону более прозрачной работы с файлами через File System API/OPFS раз всё равно выгрузка/загрузка предполагается (можно WebRTC [только по локальной сети или ещё и через интернет] накрутить сверху для автоматизации синхронизации между устройствами). Или придумать блочное представление из сырых блоков шифрованных данных, на минимальных xor/bloom/DAWG/Ахо-Корасик/дополненных битовых матрицах переходов [байтов/букв/токенов/слов] фильтрах с указанием блоков, в которых они встречается, для поиска по всему объёму данных, что много больше макс. размера localStorage.

Подписка здесь видится в хранении зашифрованных данных и предоставлении удобного сервиса их синхронизации между устройствами. Но, это уже выглядит как e2e шифрование, что проще прикрутить апишки Google Drive/Dropbox/YandexDisk/и пр. с их собственной авторизацией и лимитами, чтобы не забивать свою голову подобными вещами. А так, через WebView для Android/iOS/Desktop можно собрать обёртку сверху и распространять в обычных магазинах. Прикрутить выбор донат/реклама и смотреть дальше (может свой Offline first магазин подобных приложений соберёте и что-то из этого выйдет - хотя бы для своих периодически повторяющихся задач).

Спасибо за такой масштабный развернутый анализ. На пару моментов обратила внимание - поправила. Тут в целом нет задачи монетизировать само приложение как таковое, а сбор и хранение ПД намеренно отсутствует и им не очень хочется заниматься, так как это обязывает и влечёт за собой всякие юридические усложнения. Поэтому и монетизация реализована только в виде донатов по желанию.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации