Needed: JS loader which obeys EU law

[hilbix]

• Imagine a max. download rate of 1KB/s.
• Imagine a tiny application page which supports a huge application.
• Imagine, this tiny page is reloaded very often
• Imagine, everything is protected with subresource integrity. So only the first page needs to be kept secure, everything else could even be loaded via plain HTTP and any unauthorized change can be detected.
• Imagine, the first page is signed with asymmetric cryptography, such that you can check the validity of the first page. For now and eternity.
• And imagine, this all fits in less than 3KB.

Today each device has huge caches. So even force-loading a 100 MB JS application could take less than 1s at 1KB/s, in case the loading page is small. You can prime the cache in case you have wLAN, then you can use the cache when you are mobile with less than 1 KB/s.

Hence what I need is:

a) A minified JS loader. With "minified" I think about ess than 1 KB of code.

• It must support subresource integrity.
• It must be able to load AMD modules.

However:

• It must not support all browsers on it's own. In contrast, there must be variants of the loader for all known browsers. Each variant as small as possible. So no bloat. Nothing you do not need on a particular browser.

• It must be AMD compatible. However it must not be fully AMD compatible on the first invocation. AMD compatibility can be provided by a module loaded later on.

b) Easy to use.

• It should be easy to use with <script>.

• No JS required for bootstrapping and configuration. All done on DOM level.

c) Fast first response

• If you happen not to enable JavaScript, you must be informed to enable JS.
• If you happen not to enable CSS, you still must be informed to enable JS.
• If you happen not to use a graphical Browser, you still must be informed to enable JS as well.
• You must not be distracted by some irritating message to enable JS when your browser has JS enabled.
• Assume XHMTL (so you have no <noscript>)

This means:

• If everything and really everything fails, like you look at the page with curl, there must be a prominent note that you need some browser with JS enabled.

• If you are looking at the page with a JS enabled browser, this prominent note must be wiped away, automatically.

This has to go into the loader.

d) Asynchronous loading of everything else

• The page is loaded
• On the page there is a synchronous <script> tag loading the loader
• Then the page finishes loading and presents you with the "Enable JS" message (see c)
• Now the loader activates and wipes this message (or replaces it with something more appropriate)
• Then the loader starts to load things asynchronously.
• If loading breaks, an error message must be presented.

Hence, the loading of everything else must

• be decoupled from the forced refresh of the main page.
• be done after the "Enable JS" message distracts the user.
• give the user the impression, that loading works as expected, even if it takes days.

e) Full blown monitoring

One of the first modules loaded must be something, which gathers all uncaught errors and is able to reports them.

• This must be, even in the most awful edge cases, fully and completely compliant to every bit of the Regulation (EU) 2016/679

Another extremely important module is a module, which allows to send remote-diagnose information, which includes standard information like the used browser environment, but also special application data, which was gathered by the application.

• This must be, even in the most awful edge cases, fully and completely compliant to every bit of the Regulation (EU) 2016/679

Hence, nothing will be sent out from the Browser without full prior consent of the user. This consent must be fully by free choice and completely free will of the user, and it must not happen, that the data is sent accidentally, ever.

[hilbix]

Why is e) something the loader must care about?

Just because. Usually the error reporting module must be the first thing active, to wrap everything.

• As we cannot do that (the error reporting module might be too big) it must be the first thing loaded by the loader.

But the loader is asynchronous. Hence we cannot rely on the fact, that the error reporting is able to wrap everything first. Hence the loader must ensure this.

This is a Must-Have which must be built into the loader right from the beginning.

• Either the loader just loads this module and then vanishes in favor of the module.

• Or the module cooperates with the loader.

However the latter needs an API. APIs are big and bloaty. Hence the loader cannot support this.

Hence we are back to "the loader gives up in favour of the module".

But now we are missing a loader again. Hence the error reporting module must provide a loader again.

This is an Antipattern. Hence we are back to the loader itself. As the module must not cooperate with the loader, the only thing the loader can do is to load the error reporting module and then continue.

However the error reporting module needs another beast. The data reporting module, which is able to pull a consent from the user.

This should not be build in the error reporting module itself, else we would re-invent the wheel, when it comes to other reporting functions, like the browser's environment.

This leads to another variant of the same problem:

Silent errors.

This is, the user loads the page, and no error happens, but it still does not work.

What to do in that case? We need to gather user response information and send them back, such that we can diagnose the whole environment the user uses, not only the error (as there is none)

This needs the reporting module as well.

Hence the loader must do:

• Load the error catcher and activate it.
• Load the reporting module and activate it.
• Load the diagnostic module and activate it.
• Load the real big and bloaty loader (which is AMD compatible) and activate it.
• Invoke the new loader to load the application and all of it's modules etc.
• This then might trigger error or diagnostic reporting

This then can lead to 2 other variants:

A) Running without net in case the user does not want error reporting etc.

The first 3 steps are skipped. In certain situations, diagnostic and reporting might be loaded later.

• Load the real big and bloaty loader (which is AMD compatible) and activate it.
• Invoke the new loader to load the application and all of it's modules etc.

B) Just run diagnostics

• Load the error catcher and activate it.
• Load the reporting module and activate it.
• Load the diagnostic module and activate it.
• Load the real big and bloaty loader (which is AMD compatible) and activate it.
• Invoke diagnostics (instead of the new loader)

Diagnostics then can trace how the application is processed by the bloaty loader. Or whatever seems fit.

[hilbix]

All effort for "obeys the EU law" is put into the "reporting module".

Other countries might not need that and even in certain situations (i. E. the application is run by testers) this module may be replaced by something fully automatic, which runs in background.

Hence this is a module which needs to be flexible enough. This should not affect any other part of the whole software stack.