Such "overlong" encodings are not valid UTF-8.

(Unity employee here) While I can't comment on legal specifics, the controversy is entirely about Improbable's server-side use of Unity, so you should be fine. That said, you can send us an email (with details of your specific situation) on terms@unity3d.com and our team can clarify. (You can also wait and see, as we'll be updating the ToS again, as they're evidently much too vague at the moment...)

Unity will automatically exclude the things that can be excluded. See "Strip Engine Code" at https://docs.unity3d.com/Manual/webgl-building.html

This only goes so far. E.g. Unity doesn't have a separate 2D renderer, so your 2D game will use the 3D renderer. (But obviously, a 2D game won't include any 3D materials etc.)

FWIW, I don't see a 10 second delay. I see a delay of roughly 2.5 seconds (Firefox; Chrome is a bit slower), followed by a Unity splash screen (which you can disable once you buy a license). But the delay obviously depends on the speed of the user's machine and network.

The startup overhead is mostly downloading and parsing of the JavaScript. (WebAssembly basically reduces both by being more compact and easier to parse, but it requires browser support.)

Be sure to read the WebGL section of the manual thoroughly, as it contains several tips on reducing this overhead. Also, the overhead varies a lot depending on the browser, so be sure to test all the major ones (Edge, Chrome, Firefox, Safari).

A classic pitfall is to have collider on some of your game objects, even though the game isn't physics driven. This forces Unity to include the entire physics system in the build.

Even if some systems, like physics, can be removed if not used, Unity is still a full-blown 3D game engine. It can of course also do 2D, but it'll almost inevitably have a higher overhead than a dedicated 2D WebGL engine.

You can also consider showing your own loading screen before/on top of the Unity WebGL player, which can camouflage the load time.

TL;DR: To deploy on mobile, you should compile your Unity project as an app.

Per the manual: "Mobile devices are not supported by Unity WebGL." (https://docs.unity3d.com/Manual/webgl-gettingstarted.html)

You're not just rendering a picture, you're running a full-fledged high-end game engine, in JavaScript (meaning a ~50% slowdown), and using that to render a picture. It is to be expected that even high-end phones will struggle with that.

Unity WebGL is intended to be used as a frictionless way of distributing games to desktop users (think sites like Kongregate). On mobile, the respective app stores arguably already provides a similarly frictionless distribution option... so just build your project as an app.

Alternatively, you can look into lightweight engines that specifically target WebGL. These will usually run just fine on mobile, though they obviously don't offer the same feature set as Unity.

Moving memory management into the OS often makes sense, because the OS has the big cross-application picture, knows the system-wide memory pressure, and most importantly, already manages the memory of applications, by swapping between RAM and disk.

For the same reason, OS X and Android Linux both have systems for OS managed caches, and AFAIK Firefox already uses these: https://bugzilla.mozilla.org/show_bug.cgi?id=748598

The status on mainline Linux is a bit more nebulous (seems Android's ashmem has been upstreamed, but it's not directly usable on GNU/Linux systems?), and other efforts have stranded: https://lwn.net/Articles/602650/

For some more thoughts about memory management on OS level vs. application level, I can recommend this "random outburst" from the designer of the Varnish HTTP cache: https://www.varnish-cache.org/docs/trunk/phk/notes.html

Buh? Encryption is de-facto illegal in China. To the extent SSL is used, you can be sure that the government already has a copy of the master key. I've worked on Chinese deployed train systems, and we were banned from encrypting train control signals (signing was allowed, though), just in case someone might try to sneak in a political message in an ATO control telegram...

Incidentally, the Varnish HTTP cache uses this technique; whenever the config is reloaded, the config files are translated to C, compiled to a shared library, and loaded into the running server process.