. Sheer numbers. There are literally millions of them. Manual entry into a database was checked and okay. Export from the database's proprietary, obscure storage format to common as dirt Excel was already too big to spot the fault.

That may convince the management to get us better CPUs, but we'd be still short on RAM.

I suggest 10 GOSUB 10

Another of *these* assumptions - that the code will ever be maintained before it reaches end of life.

I'd written code that runs to this day and it's nearly a decade since anyone ever saw the sources.

Yet another is that it's going to be expanded, and so needs to be written in a modular fashion with abstractions for potential expansions.

Data is read from socket, frames are identified in the stream, then decoded, and depending on the content several reactions are undertaken. Four function calls and a switch(). No, I'm not going to implement an event listener system, just because someone imagines we *might* someday receive the data from something else than sockets, that the protocol is changed in unpredictable manner (I define that protocol!), and that someone might (gasp!) need to edit the switch() code, instead of registering handlers for new commands through the API. Twenty lines of code turn into five files by making this more "versatile".

At least eight meters of documentation..

It's not so simple: the initial investment is huge, and the returns are slow. It takes a visionary (like Musk), with a bottomless well of cash (like Tesla Motors) to enter the playfield. There are safer investments with higher and faster returns if one has that kind of money, and wants to multiply it. Without the "vision" it's simply not going to happen - corporations prefer easy, immediate profits over multi-decade investments, and the asian ones are more conservative that way than the western ones.

For this to happen, it takes a special kind of person in a leadership position. This *might* happen, but I don't see any candidate currently.

They have a turing-complete CPU. They have memory and storage. They have input and output devices.

That pretty much sets them as general purpose computers.

Oh, that's not their intended purpose - not what they are marketed at. Overcoming the lockdown may take some work. But you CAN run arbitrary computation on them, even with the lockdown.

Even on IPad, where they paid close attention to disable general computing to a degree where Commodore 64 emulator was banned because it runs Commodore BASIC, you can still load a page that contains:

<textarea id=x></textarea> <input type="button" onclick="eval(document.getElementById('x').value)"/>

and type away your general computation in Javascript.

Note, by the same virtue, a Postscript printer is also a general purpose computer. But yeah, using the right Postscript, people were playing chess against Postscript printer/scanner devices - the printer would print the chessboard with the pieces, the player would draw the move with an arrow, then scan it in, the printer would recognize the move, calculate a response and print it out. So, yeah, that's general purpose computers for you.

Oh, you just didn't hear about them.

There haven't been many *LOUD* wide-scale attacks on these devices.

Their malware tends to stay under the radar and do its thing without drawing attention. It's quite ubiquitous though.

There are apps that run bitcoin mining on your Android phone.

There are apps that cheat on ad revenue, loading ads en masse (and not displaying them, or you'd long uninstall them).

There are quite a few spyware apps.

Due to the lockdown, traditional "viral" spread is limited. In most cases, "trojan horse" technique is employed. Legal, useful apps in the app store, that have a second, clandestine function. Since getting rid of the malware is pretty easy, and malware that can't make its way into some official store will never reach broader victim base, they just stay under the radar, doing their thing without alerting the users to their presence and without being *overly* harmful.

How's Kennedy Assassination documents declassification going? They were supposed to hit the public sometime this year, I heard.

You MUST be monitoring the sandbox to tell if it's been corrupted by malicious code. Otherwise the whole scheme crashes and burns, as the attacker hijacks the sandbox and infects the clean uplink. And that can take a very short time, so "periodic re-creation of sandbox" is not a solution. Tight monitoring a'la running in a debugger is the way.

Of course in case the sandbox is corrupted, it would need to be re-created, but that *hopefully* wouldn't be too frequent.

Not always viable, but that point is a very weak point anyway. The host's kernel *can* pass all traffic transparently to VM and never be at risk. It just needs to be done, no challenge here.The challenge is assuring the sandboxed environment isn't hijacked - the same way currently the root's environment is being hijacked. While the hijack would be unable to escape the sanbox by itself (or at least only with great difficulty), it can infect the "clean" uplink, and infect the host with other malware (albeit on receiving user's rights, not root.)

Currently, this is unavoidable, as the moment the malware has admin rights (moreover, KERNEL rights!) it can disable any control mechanisms and operate freely. With the VM, the host could supervise the sandbox and prevent infection of host in case the sandbox kernel is compromised. This is important, this is the real danger, and this is difficult.

Yes, unless the attacker is prepared for this. They won't attempt jailbreak if they are not aware they are on VM (plus it IS difficult), and with the right setup the kernel will pass data to VM pretty much transparently - IF the traffic is directed at the VM. Not quite the case if the traffic is directed at the host, and the kernel squeezes it into VM regardless (though still possible to do safely).

Plus the only thing that goes back to host from the VM is display, and well-encapsulated I/O to be passed through without peeking in. Not the entire inbound network traffic, and all the data from disk. If the sandboxed filter is compromised, and can infect the stream, the host can be compromised.

In case a mainstream antivirus implements this, the attacker will know this and may attack the sandboxed environment, never even trying to jailbreak, then just infect the pass-through data and use that to infect the host, instead of acting on it directly.

Imagine you have a hardware firewall, and your computer plugged into it. Now the attacker takes control over the firewall's system... how secure is the computer now?

Setting up a sandbox is a one-time deal on startup. Giving the process a preferential treatment in the scheduler is viable approach; another is to bypass the whole heavyweight system of accounts and authentication and carve your own sandbox from scratch, a separate, minimal subsystem of lowered privileges, a'la VM.

The 'real kernel' still needs to pass it down into the VM from physical media for processing. And the VM would need to be supervised by the host, not just launched and forgotten - the sandboxing won't help much if the virus hijacks the sandbox, and makes it pass everything through as 'clean' regardless of the content - the host needs to constantly monitor integrity of the checking process.

There are 'jailbreak' attacks that allow escaping VM sandbox and infecting the host, but they are difficult and rare.

They need to hijack all network and file operations, so they do need hooks in the kernel. But these should be minimal, passing the data down to a sandbox without even peeking inside. The fact data that is *expected to be malicious* is allowed to interact directly with kernel level code is definitely FUBAR.

In response to community backlash, Oculus has decided to change its DRM policy (again) to allow HTC Vive games to play on the Oculus Rift virtual-reality system.

--BeauHD.

-1. Offtopic.