Сам дошёл, причём вполне естественным образом: статья, конечно, больше поток сознания из воспоминаний трёхлетней давности, но логику постепенного создания формата привёл без искажений. Поскольку я увидел очевидные предположения (пункты 1-3) по сжатию метки времени — оставалось смасштабировать время с 50 лет до максимальной теоретической продолжительности одного трека (что заведомо было меньше недели, а в своём большинстве ограничивалось одним-двумя днями). С координатами было чуть сложнее — можно было только предполагать, как далеко может пользователь сместиться от первой точки, поэтому в первой версии протокола могли отказаться от этой оптимизации.
К сожалению, я не знаю, как устроено сжатие в MPEG. Возможно, что перед тем, как начинать оптимизировать, нужно было изучить матчасть.
Даже в отсутствии загружаемых карт можно писать трек. Ведь карты нужны только для показа пользователю на экране телефона.
В простом варианте можно использовать оффлайновый «сриншот» кусочка карты, где мы знаем, например, координаты левой верхней и правой нижней точки прямоугольника. Если, конечно, речь не про северный полюс.
Если вас интересует использование SMS API в Android, то здесь я вам не подскажу. Если речь про base64 от бинарных данных, то я не очень понимаю, что вы хотите в итоге увидеть?
К сожалению, примера готовой СКСки нет, так как само мобильное приложение писал не я, а только предоставил библиотеку для упаковки трека в массив массивов байтов (так как трек мог быть больше 84 точек и нужно было делать несколько жирных СМСок).
Схема работы была следующей: Сырые данные -> Преобразование в массив байтов (бинарный формат из статьи) -> Base64 -> Использование SMS API в Android.
Для других платформ предоставил описание формата (заголовок, тело, первая точка трека, последующие точки трека, правила заполнения флагов).
Если скрипт был добавлен предшественником — согласен, XSS-атакой это называть неуместно.
Основной поинт в проблеме выявления организованной подобным образом XSS-атаки, когда зловредный код отдаётся в зависимости от ip-адреса или других доступных данных, например User-Agent.
Единственный способ обезопасить себя — не использовать сторонние ресурсы, тогда выявить подгрузку будет проще простого.
К сожалению, я не знаю, как устроено сжатие в MPEG. Возможно, что перед тем, как начинать оптимизировать, нужно было изучить матчасть.
В простом варианте можно использовать оффлайновый «сриншот» кусочка карты, где мы знаем, например, координаты левой верхней и правой нижней точки прямоугольника. Если, конечно, речь не про северный полюс.
Схема работы была следующей: Сырые данные -> Преобразование в массив байтов (бинарный формат из статьи) -> Base64 -> Использование SMS API в Android.
Для других платформ предоставил описание формата (заголовок, тело, первая точка трека, последующие точки трека, правила заполнения флагов).
Метод Array.prototype.fill появился только в ES6, чтобы было кроссбраузерно используют polyfill.
Основной поинт в проблеме выявления организованной подобным образом XSS-атаки, когда зловредный код отдаётся в зависимости от ip-адреса или других доступных данных, например User-Agent.
Единственный способ обезопасить себя — не использовать сторонние ресурсы, тогда выявить подгрузку будет проще простого.