rPman

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

Отключаяя сессию rdp для машины это сигнал блокировки экрана, браузер это отлавливает и тормозит обработку скриптов (точно так же как и при минимизации окна/смены таба)

Полагаю headless версии браузера тебе не подходят? те что selenium к примеру запускают?

Решения:
- универсально, рекомендую - рекурсивный rdp, сессия, где запущен браузер должна быть открыта в другой сессии (другой пользователь, и не обязательно с этой же машины, но нет смысла заводить вторую машину), вот уже к этой второй сессии можно подключаться удаленно, при ее отключении открытое окно сессии mstsc к браузеру не будет передавать сигнал о дисконнекте, ее даже можно безопасно минимизировать (не проверял)
- запускать браузер не в rdp сессии а в консоли сервера (это та что подключена к монитору), используя vnc/teamviewer/anydesk и аналоги
к сожалению на серверах ее может не быть или она недоступна, к тому же она только одна на машине.
- виртуализация, установи виртуальную машину, где запускай хоть десктопные версии windows (это легально только с pro/ultimate версиями), каждый браузер будет запущен в своей сессии-консоли, доступ по rpd средствами виртуальной машины
- смени операционную систему на linux, тебе ведь только браузер запускать, там с помощью xserver-xvfb можно запускать любое количество серверов xserver, подключаться к ним по vnc (есть врапперы rdp), это будет проще и дешевле в обслуживании

Исключительно ради стеба.

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

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

Пример использования - криптовалюта zcash, в ней для анонимных монет использовано было именно это шифрование.

На хабре недавно была статья о компиляторе C (сильно упрощенный) который позволяет писать такой код относительно свободно. Библиотек под разные языки полно, правда они не так красивы как прямо целый компилятор.

Гомоморфное шифрование очень серьезно тратит вычислительные ресурсы и память, не уверен, экспоненциальная ли от сложности алгоритма или просто константа большая, но к примеру сложение двух чисел в статье выполнялось 7 секунд

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

Есть два основных направления
* устаревший, но не требующий javascript на клиенте - это разделение страницы на фреймы (iframe и frame) таким образом, чтобы изменяющиеся части попадали на свой фрейм
в этом случае будет мигать не вся страница а только изменяющаяся часть, и вообще то браузеры прекрасно это обрабатывают, даже курсор в формах остается на старом месте
Не рекомендую этот подход, он устарел и имеет смысл только если действительно нужно разрабатывать сайт для условий отключенного javascript (например tor/i2p сети).
Очень много логики можно реализовать на основе css, язык там уже на столько сложен и многофункционален что простые вещи типа отображение и смокрытие элементов на основе кликов - обычное дело.
Совет, чтобы мерцание не было видно, оптимизируйте ответ бакэнда таким образом чтобы ответ выдавался по времени быстрее некоторого порога (при его превышении страница будет мерцать)

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

Собирать на стороне клиента страницу можно по разному:

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

Интеллектуальная пересборка - полная аналогия разделения страницы на области соответственно логики их обновления как в решении с iframe, когда элементы на странице обновляются блоками ровно тогда и там, когда это нужно.

Как частный случай обновляется даже не структура html а только текстовые значения (и даже значения атрибутов), так как очень часто обновление имеет смысл для данных а не структуры, за исключением случаев когда есть списки и размеры их меняются. Этот подход спорный, я видел когда так реализовывали мультиязыковую поддержку (т.е. по умолчанию страница как бы пустая, а затем загружается языковой json и все элементы наполняются текстом соответственно уникальным id), несет некоторую нагрузку на процессор (незначительную, никто так не оптимизирует уже давно), требует некоторого учета при верстке (нужно везде прописывать минимальные размеры) но гарантированно не мерцает даже на медленных соединениях, так как данные можно сначала загузить полностью и только потом менять на странице
------------------------------

Обновления со стороны сервера можно получать двумя способами
- периодическими опросами (генерирует квадратичную нагрузку на сервер при увеличении одновременно работающих пользователей) но очень простой в реализации
- воспользоваться websocket/events, эти технологии специально созданы для того чтобы сервер мог оперативно сообщить какую то информацию клиентам без постоянных опросов и лишней нагрузке на сервер, но требует поднятие websocket сервера, удерживающего открытые соединения, для тех кто привык к http rest подходу с cgi короткоживущими приложениями, это может быть сложно, но результат того стоит

когда запросы блочатся, когда есть проверка браузера. Задавая вопрос,

но ты не задала вопрос про свою проблему

покажи свой код, покажи свои попытки, где именно затык, вот тогда тебе дадут советы

p.s. лучше всего парсить с помощью браузера, гуглить к примеру selenium

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

запускай полноценный браузер, симулируй клики пользователя, способов миллион, от инжекта javascript на страницу нормально запущенного браузера и прередачи информации через http до полноценных библиотек типа selenium

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

Теперь по теме - тебе нужна обучающая выборка. Грубо говоря набор данных в виде таблички (количество колонок в строках одинаковое), где каждая строчка это 2 набора чисел - входящие и выходящие. Входящие числа это набор чисел, на основе которых ты должен сделать предположение, а выходящие - это искомое значение.

В твоем случае водящие числа это твой набор, а выходящие - одно число.

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

В некоторых случаях можно умножить обучающую выборку, генерируя дополнительные данные, например у тебя количество чисел во входящей последовательности 5, но понять ее можно уже по 4-ем, тогда можно создать из каждой последовательности по две более коротких, используя подпоследовательность, для первой итоговое число будет 5-ое число последовательности, а для второй первое число входной последовательности будет второе число оригинальной. Для твоих 100 чисел можно попробовать брать 50 чисел, и сделать 49 обучающих записей на основе одной известной

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

по ip
первый же запрос в гугл

Не хранить изображения в 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, в него компилируют почти любые программы и заставляют их работать в браузере)