rPman

Не хранить изображения в png, а подготовить видео файл из них (например секунду на кадр), крутить в video, при желании в режиме паузы, переключая по номеру времени currentTime, либо, если нужно именно на canvas, смотреть как это предлагает документация

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

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

Поэтому ответ:
- по первой схеме сервер отправляет клиентам с периодичностью информацию об итоговом изменении уровня жизней.
- по второй схеме сервер отправляет клиентам команду "начинайте увеличивать жизнь со скоростью X до уровня Y" и клиенты это выполняют, запустив свой таймер.
Для контроля состояний сервер может периодически высылать хеш своего состояния чтобы клиенты могли его сравнить со своим, если они различаются значит в коде баг (например неверно обрабатывается лаги) и как минимум нужна повторная загрузка состояния с сервера

Все правильно тебе говорят, все что видно в браузере клиенту - может видеть и программа.
Но можно очень простым способом сделать эту задачу очень сложной для "атакующих":

Сайт должен представлять из себя программу удаленного управления, а реальный сайт запускаться на кастомном браузере (без интерфейса, пишется в 10 строчек на любом языке программирования на основе готовых контролов браузерных webview - chromium/firefox/webkit).

Понадобится организовать сервере, что то типа очереди доступа к интерфейсу. Все собирается почти из готовых блоков.

На сервере xvfb + libvnc (лучше реализовывать серверную часть а не брать готовый полнофункциональный, хотя главное ведь запретить отсылку команд закрытия приложения и xserver, кажется у x11vnc есть соответствующие опции), в браузере - что то типа noVNC

Недостатки
- очень высокие требования к серверу (на каждого клиента потребуется десятки мегабайт RAM советую использовать старые или кастрированные версии компонент браузера, можно даже старой версии, например 10-летней давности webkit требовал 5-10 мегабайт, а современный полторы сотни)
- относительно высокий трафик для мультимедиа на сайте (не ваш вариант, у вас магазин)
- потребуется с осторожностью настраивать сайт и окружение (например без доступа к интернету), чтобы уменьшить шансы клиентам обойти ограничения и к примеру серфить или даже ддосить через такой механизм другие сайты

Достоинства:
- на стороне клиента - просто изображение, все что может сделать злоумышленник, это смотреть эту картинку, без какого либо анализа, ни одна рекламная сеть не рассчитывает на такой способ использования
- в некоторых случаях сетевой трафик может быть меньше чем если бы сайт открывается классическим способом (особо кривые реализации, когда html размером мегабайты, при этом без мультимедиа) и зависит не от сложности сайта а от количества действий, совершаемых с сайтом пользователем, а точнее скролинг и смена страниц), отзывчивость работы в таких случаях для пользователя может быть наилучшей, само собой эффективнее исправить сайт

веб браузер не поддерживает произвольные tcp запросы, для работы по протоколу socks именно это требуется.

это сделано чтобы защитить сетевое окружение пользователя от атак со стороны веб сервисов (по той же причине введен cors и запрет кросс http/https запросов)

В общем случае - никак

Но можно сделать этот процесс на столько сложным, что смысла в этом уже никакого не будет. С помощью обфускации кода и использовании алгоритмов шифрования данных, передаваемых в браузер (не про https а когда данные, загружаемые браузером и передаваемые в скрипты/данные - зашифрованы). А чтобы конечный скрипт нельзя было вытащить через модификацию браузера (например логировать eval) то можно саму виртуальную машину, исполняющую скрипты, реализовать на js (wasm).

Есть интересное направление - нейронные сети. В браузере вместо полноценного кода работает нейронная сеть, обученная выдавать нужный результат. Реверсить логику ее работы невероятно сложно (читай невозможно). Плюс, нейронные сети, в общем случае, потребуют либо хорошего тестирования либо принимать что их поведение в редких ситуациях может быть непредсказуемо.

Нужно понимать, что затраты на разработку такого решения будут сравнимы со стоимостью его взлома.

p.s. есть еще гомоморфное шифрование, когда есть необходимость совершать какие то операции над данными, которые зашифрованы, без их расшифровки. Особо его применить в данной задаче сложно но бывают случаи когда можно выкрутиться. Если что это решение очень сложное (читай дорогое) в реализации, готовых решений нет (по крайней мере для браузера и javascript) а еще оно потребляет процессорные ресурсы.

На тот случай, если автор вопроса буквально хочет то что сказал а не то что логично подразумевают все тут ответившие, дам ответ:

есть возможность запустить php и не только в браузере, с помощью крутой технологии wasm (это подмножество javascript, работающее за счет ряда ограничений значительно быстрее универсального js, в него компилируют почти любые программы и заставляют их работать в браузере)

никак

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

гугли electron obfuscation, может что то тебе подойдет, для сокрытия и запутывания исходников

судя по этому issue у народа до 1000 на один процесс все работало ну и он закрыт значит должно быть больше.

смотри ошибки в коде сервера, что пишет в логи

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

Есть уязвимость сайтов к click jacking, когда фрейм делают прозрачным, подвигают под текущую позицию курсора мыши и как то заставляют пользователя кликнуть. Таким образом можно выполнять действия но понять, успешно или нет не получится.

Если твоя задача не состоит в краже пользовательской авторизации, то достаточно через проксирование сайта на своем домене открыть его как свою страницу и уже к ней будет полный доступ, можно получить document страницы, делать поисковые запросы querySelector и делать клики через .click()

Правильно - websocket

Это штатный инструмент, чтобы сервер смог передать данные на клиент, не по его запросу а по собственной инициативе.

Требуется на сервере установить (реализовать в коде) websocket server, благодаря готовым библиотекам это очень просто, гуглить к примеру ReactPHP websocket (реакт - асинхронный фреймворк, добавляет асинхронные фичи, за которые полюбили nodejs), на нем вообще можно реализовать полноценный веб сервер (но nginx все равно рекомендуется ставить на выходе в мир как прокси) которые и обычные http rest запросы примет и websocket соединения подержит, да еще и раз в 10000 быстрее будет (я про сравнение типовых подходов без особых оптимизаций и кешировании), ведь приложение в этом случае не закрывается на каждый запрос а значит многое можно держать в памяти как обычные переменные (а не 100500 прослоек вида мемкеш)

p.s. есть еще устаревшая long pooling технология, когда вместо websocket открывается обычный http rest запрос, но на сервере он не закрывается сразу, периодически выдавая в поток допустим 1 символ пробела (крутя в цикле банальный sleep и проверку базы данных) чтобы по таймауту не закрылся, а по появлению на сервере нужных данных, отправлять их как обычно тем же json-ом. Клиент же сразу как этот запрос завершается должен тут же его снова отправить. Этот подход не потребует что то менять на сервере но считается быдлокодом.

ajax https -> http не допускаются,
можно схитрить и сделать get запрос через загрузку ресурса с http, например:

<script type='text/plain' src='http://127.0.0.1/...'/>

но не уверен что можно будет получить ответ (в консоли браузера будут ошибки)

upd. совсем забыл, в современных браузерах это тоже перестало работать, если формировать такую строку скриптом

и правильно сделали, несекурные запросы из https страницы это страшная дыра, можно без каких либо ограничений, зайдя на страницу злоумышленика получить различные запросы в локальной сети этого пользователя, а там на выбор, ddos, звлом или даже какие то действия (грубый пример, на админке роутере у тебя сохраненная авторизация, злоумышленник делает запрос на открытие доступа извне, например nat, и получает доступ к твоей сети)

Задачу не понял, нужно больше примеров.

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

В некоторых реализациях (например на php) вводят разную оценку на разные действия типа вставки, замены и удаления. Т.е. если сделать стоимость вставки и удаления сильно меньше замены, возможно ты получишь желаемое.. или модифицировать алгоритм до своих хотелок.

p.s. суффиксное дерево, смотри там пример использования для поиска подстроки, это если у тебя БОЛЬШИЕ строки, эта структура поможет решать задачи похожие на твою