История изменений

Предположу, что могут возникнуть проблемы с версиями. Одно дело, когда сервер отдаёт на исполнение свой код, точно зная что там, и другое - когда версии у библиотек у него и на стороне клиента должны совпадать для такой уверенности.

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

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

<script src="https://cdnjs.cloudflare.com/ajax/libs/intercooler-js/1.2.3/intercooler.min.js" integrity="sha512-cGFWDjclOPdq15RV16krqIZNRnaXehJpgwtcX+VrIO+UgOsdg3mURsdN27Z9PWnov+f8mZSPZfx14R7w+rSYOw==" crossorigin="anonymous"></script>

Зная хэш-сумму, браузер не обязательно даже будет скачивать код с указанного CDN. Он может обратиться к какому-нибудь собственному CDN, которым управляет некоммерческий фонд.

Далее нужно будет предусмотреть возможность инициализировать приложение с параметрами, нужными для сайта. Варианты:

1. Позволить исполнять на странице небольшие фрагменты кода, выполняющие инициализацию этих приложений. Например, FSFшный плагин LibreJS позволяет исполнять код, который он автоматически определяет как «тривиальный». Что-то такое придумать. Так себе вариант, но можно попробовать реализовать, чтобы понять реальные drawbacks.
2. Специфицировать декларативный протокол в виде json, позволяющий передать в приложение аргументы инициализации. Тут потребуются небольшие обертки под каждое приложение. Сначала, придётся их писать разработчикам этой идеи. А потом может подтянутся и авторы библиотек и сразу будут поставлять библиотеки с совместимыми API.

Может лучше стандартизованный API для каких-то нужных действий. А клиент уже на своей стороне может поддерживать это апи каким угодно кодом.

«Нужных действий» на все случаи жизни не напасёшься. Пусть браузер занимается непосредственно работой песочницы и API на уровне связи песочницы и внешнего мира. У них и так работы очень много в этой области. А на уровне логики внутри песочницы — можно управлять ею через вот такой контроль «приложений», или «протоколов», или «API». Тут суть не в названии, а в том, чтобы компонент, который обеспечивает управление такими прикладными API, был разработан и стандартизирован отдельно от движка браузера. Это позволит любой браузер с поддержкой экстеншенов превратить в совместимый с идеей.

И еще суть в том, что если вы используете обычный браузер, то в нём просто всёработает как обычно. Он исполняет код JS.

А используете браузер с такой защитой, то он… тоже просто исполняет код JS. Но весь код проверен, и есть гарантия, что это опенсорсный код без трекинга и закладок. А который не проверен, запрещен.

Предположу, что могут возникнуть проблемы с версиями. Одно дело, когда сервер отдаёт на исполнение свой код, точно зная что там, и другое - когда версии у библиотек у него и на стороне клиента должны совпадать для такой уверенности.

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

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

<script src="https://cdnjs.cloudflare.com/ajax/libs/intercooler-js/1.2.3/intercooler.min.js" integrity="sha512-cGFWDjclOPdq15RV16krqIZNRnaXehJpgwtcX+VrIO+UgOsdg3mURsdN27Z9PWnov+f8mZSPZfx14R7w+rSYOw==" crossorigin="anonymous"></script>

Зная хэш-сумму, браузер не обязательно даже будет скачивать код с указанного CDN. Он может обратиться к какому-нибудь собственному CDN, которым управляет некоммерческий фонд.

Далее нужно будет предусмотреть возможность инициализировать приложение с параметрами, нужными для сайта. Варианты:

1. Позволить исполнять на странице небольшие фрагменты кода, выполняющие инициализацию этих приложений. Например, плагин FSFшный плагин LibreJS позволяет исполнять код, который он автоматически определяет как «тривиальный». Что-то такое придумать. Так себе вариант, но можно попробовать реализовать, чтобы понять реальные drawbacks.
2. Специфицировать декларативный протокол в виде json, позволяющий передать в приложение аргументы инициализации. Тут потребуются небольшие обертки под каждое приложение. Сначала, придётся их писать разработчикам этой идеи. А потом может подтянутся и авторы библиотек и сразу будут поставлять библиотеки с совместимыми API.

Может лучше стандартизованный API для каких-то нужных действий. А клиент уже на своей стороне может поддерживать это апи каким угодно кодом.

«Нужных действий» на все случаи жизни не напасёшься. Пусть браузер занимается непосредственно работой песочницы и API на уровне связи песочницы и внешнего мира. У них и так работы очень много в этой области. А на уровне логики внутри песочницы — можно управлять ею через вот такой контроль «приложений», или «протоколов», или «API». Тут суть не в названии, а в том, чтобы компонент, который обеспечивает управление такими прикладными API, был разработан и стандартизирован отдельно от движка браузера. Это позволит любой браузер с поддержкой экстеншенов превратить в совместимый с идеей.

И еще суть в том, что если вы используете обычный браузер, то в нём просто всёработает как обычно. Он исполняет код JS.

А используете браузер с такой защитой, то он… тоже просто исполняет код JS. Но весь код проверен, и есть гарантия, что это опенсорсный код без трекинга и закладок. А который не проверен, запрещен.

Предположу, что могут возникнуть проблемы с версиями. Одно дело, когда сервер отдаёт на исполнение свой код, точно зная что там, и другое - когда версии у библиотек у него и на стороне клиента должны совпадать для такой уверенности.

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

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

<script src="https://cdnjs.cloudflare.com/ajax/libs/intercooler-js/1.2.3/intercooler.min.js" integrity="sha512-cGFWDjclOPdq15RV16krqIZNRnaXehJpgwtcX+VrIO+UgOsdg3mURsdN27Z9PWnov+f8mZSPZfx14R7w+rSYOw==" crossorigin="anonymous"></script>

Далее нужно будет предусмотреть возможность инициализировать приложение с параметрами, нужными для сайта. Варианты:

1. Позволить исполнять на странице небольшие фрагменты кода, выполняющие инициализацию этих приложений. Например, плагин FSFшный плагин LibreJS позволяет исполнять код, который он автоматически определяет как «тривиальный». Что-то такое придумать. Так себе вариант, но можно попробовать реализовать, чтобы понять реальные drawbacks.
2. Специфицировать декларативный протокол в виде json, позволяющий передать в приложение аргументы инициализации. Тут потребуются небольшие обертки под каждое приложение. Сначала, придётся их писать разработчикам этой идеи. А потом может подтянутся и авторы библиотек и сразу будут поставлять библиотеки с совместимыми API.

Может лучше стандартизованный API для каких-то нужных действий. А клиент уже на своей стороне может поддерживать это апи каким угодно кодом.

«Нужных действий» на все случаи жизни не напасёшься. Пусть браузер занимается непосредственно работой песочницы и API на уровне связи песочницы и внешнего мира. У них и так работы очень много в этой области. А на уровне логики внутри песочницы — можно управлять ею через вот такой контроль «приложений», или «протоколов», или «API». Тут суть не в названии, а в том, чтобы компонент, который обеспечивает управление такими прикладными API, был разработан и стандартизирован отдельно от движка браузера. Это позволит любой браузер с поддержкой экстеншенов превратить в совместимый с идеей.

И еще суть в том, что если вы используете обычный браузер, то в нём просто всёработает как обычно. Он исполняет код JS.

А используете браузер с такой защитой, то он… тоже просто исполняет код JS. Но весь код проверен, и есть гарантия, что это опенсорсный код без трекинга и закладок. А который не проверен, запрещен.