Way back when I wrote that, the conductor had no way of authenticating any client (e.g., locally running UI) who made calls to a zome. Now at least there’s a plan: capability grants can restrict who can make that call. The conductor doesn’t enforce this yet – it treats all client calls over the local WebSocket RPC interface as authenticated – but soon it will be enforced. Here are the three different kinds of capability grants your user can protect their zome functions with:
Unrestricted: anyone from anywhere can call it – local clients on your device, other DNA instances (cells), or other nodes on the same network.
Transferrable: only those who can produce the right capability secret are allowed to call the function. This is similar to OAuth2 bearer tokens.
Assigned: callers must produce the right capability secret and prove possession of the right private key, as proven by their signature on the function call.
As an app dev it’s your job to design all the ways that a user can grant/deny access to their functions. As yet I don’t know how a UI might ask Holochain to have its public key registered as a valid client, but I suspect that the conductor will pop up a little dialog saying “Did you approve this UI?”
Anyhow, I think that a combination of good DNA design and assigned grants can protect against the malware attack vector. You’re right that any app or network faces this challenge, and the level of damage an attacker can do is relative to the user’s privilege in the app.
I feel like there’s a slight extra risk with Holochain, in that the attacker gains full access to all the shared DHT data, including IP addresses of other DHT members. This is comparable to a system-level attack for a centralised service. This will be mitigated somewhat by the fact that all DHT and source chain data will soon be encrypted at-rest so the attacker would have to intercept the user’s keystore-unlocking password in order to actually get at that data.
Now, re: your other question:
For now, yes, but there are a number of devs actively building Holochain apps who will want to also build native mobile apps that use Holo (at least until we can manage to compile Holochain for mobile and figure out the delicacies of battery usage for an app that expects itself to be always connected to the DHT). So I believe/hope that Holo can be integrated into, say, a Flutter or React Native app, and that we’ll be building the plumbing to make that happen.