Controlling use of Assemblers - ROM, 18/Oct/05


At some point it seems likely that general purpose assemblers will be possible. One major issue will be that assemblers will be able make almost anything, no matter how undesirable it is to have around, including other assemblers.

One technique to control assemblers is based around the idea 'Notification of Assembly'. This is about having a two-way dialogue, with a sufficiently distributed number of other assemblers, so that the information on what is assembled will not be lost.

This notification would incorporate some checking procedures, to ensure an assembler has not been modified, or to restrict assembly of exceptional varieties of product. Notification also provides the opportunity to fetch updates of existing products, or to add new things to be assembled.

There are three proposed varieties of notified assembly: non-notifiable, which means no notification is required, post-notifiable, which means that notification must be done at some point, and pre-notifiable, which means notification must take place before assembly.

A further requirement is that assemblers be capable of recognising products which contain embedded active nanotech, in particular other assemblers, and things which are on their product list. There is no consideration in this scheme for controlling disassembly of undesirable things, e.g. people.

For example:

Limited Domestic Assemblers cannot disassemble anything containing embedded active nanotech.

These could be freely distributed, with little fear that they would cause problems, except by making excessive amounts of products. Though, they wouldn't be able to make anything newly developed.

The list of possible products cannot be updated to add new varieties of assembler to it, and in particular the Domestic Assembler on the list must precisely match the one that is making it. Updated versions of Limited Domestic Assembler may replace the current one on the list, and must not be capable of making anything with embedded active nanotech.

Newly assembled Domestic Assemblers will not make further assemblers until they have announced themselves, and received responses from, the communication net.

Domestic Assemblers are capable of disassembling anything which does not contain embedded active nanotech, and anything which does that is on their product list. This includes Limited Domestic Assemblers, which are not the latest version, and replacing them with one that is. Updating Limited Domestic Assemblers, by disassembling one and assembling a replacement, can be freely done, as long as this is post-notified.

This prevents an unknown explosion in assembler numbers, as each can only make one further assembler without notifying of it. However, it allows extensive use of the assembler, off the net.

One restricted product might be more General Assemblers, though there will not be a restriction on assembling Domestic Assemblers or Limited Domestic Assemblers. Updates to the specification of assemblers in the product list will need a widely distributed confirmation.

This means that general-purpose assemblers must be in two-way communication with the net, to be able to be used. Though, it might be possible to use them in a highly restricted mode, as if they were Domestic Assemblers, if they are not on the net, as long as they act with all the restrictions which are on Domestic Assemblers. The main reason for making Domestic Assemblers a different product to General Assemblers, is the (built-in) limits that they have on making more assemblers.

The whole scheme does its best to avoid there being any central authority, which could be subverted, or, if communication is not possible with, making no assembly possible.

The idea is that the communicating network of assemblers contains all the authorisation, so there is no single point of failure, and communication failures just restrict assemblers to a (safe) restricted set of functions.

The scheme is also intended to minimise the risk of 'hacked' assemblers, which do not need to communicate to the net, and freely assemble restricted products, in particular other hacked assemblers.

The Network

This whole idea is based around assemblers being, at least part of the time, connected together by a communication net. But, it doesn't say what the communication method is, as conceivably a number of different ones could be in use, and it is currently unclear just what nanotech and assemblers will use for communications.

The net has to be the assemblers, and their means of communicating. Yes, there are very likely other things connected to the net, but as far as the assemblers are concerned, these are things that they get instructions on what to assemble from, and send reports to. Any nanotech assembly info from outside the assembler net itself is treated with considerable suspicion. And needs to be voted on as 'OK'.

Yes, the bad guys can get in, with their own hacked assembler (this scheme is intended to make that difficult), but, that assembler will be initially out-voted, and may well get cut-off into a "suspect net area", if a number of assemblers appear without prior warning, which this scheme is intended to ensure you can detect.

Yes, a secure net is required, but it cannot be one where one password is the only thing protecting it from the world.

Whatever is used, it will have to be secure, in that you don't want the info tampered with, you want it to be clear who the info is from, and you don't want unauthorised persons reading info they shouldn't. I don't see any way to do this without strong encryption.

You cannot afford to have isolated nets. And, we need to ensure that government good-will is not the only thing that ensures people's privacy.

No, ultimately you cannot trust governments and companies. That's why we have voting and anti-monopoly laws.

It is possible to put together a system where there is no one link, no single point of failure, that destroys everything. But, we need to use a co-operative approach, not a hierarchical one.

Yes, you keep your privacy. If you want to, you can ensure info that just you are responsible for and use dies with you. But, your privacy only works with the co-operation of society. And anyone else who shares responsibility for info with you, or makes use of info with you. And, other people's need for privacy may need your co-operation to work.

I don't say that this will be easy, but I believe it is possible.

A Few Comments

These are not in any particular order, but are included as they may be of interest.

--
The communication method, as said above, is not defined. I would envisage a turn-around for communication with the comms network, sufficient to ensure you are still in contact with a significant portion of it, once per day being good enough for a lot of applications.

--
The Limited Domestic Assembler is the 'safest' assembler - no comms needed, stand-alone, fixed list of products, can't make more assemblers. Ideal for someone who wants their privacy. Make sure you have a few spare for when they break, and you can be a hermit, having nothing to do with the world.

A Domestic Assembler is the next 'safest' assembler, that does a pretty good job of preserving your privacy. You can use this in a completely non-connected mode, if all you ever want to do is have a spare assembler or two, and don't feel the need for updates. Again, should do for your hermit who wishes to avoid communicating what they are doing to the world.

In particular the scheme is intended to make it difficult to use a Domestic Assembler to produce a hacked assembler - if a few too many of the warning alarms go off in the 'detect being hacked' functionality, this assembler might even lobotomise itself into a Limited Domestic Assembler.

--
For the functionality agreement (FA) to work you need to get the basic notification scheme agreed.

This allows for upgrades, and should allow an awful lot of possibilities. Now, I don't claim that it will allow for anything that might develop, but it might help keep us alive long enough to take a few breaths in the nanotech age.

As for a bad FA, you need to be able to roll-back to the previous one if needed, and make it quite clear you are doing this. No, this isn't perfect, but, it stops you cutting yourself off from something that mostly works.

You cannot afford any function creep which upsets the notification scheme - anyone who tries this will have to be treated as if they are playing with rogue nanoech.

That is why I agree with the CRN (if I understand them correctly; http://www.crnano.org/). We need international laws and agreements in place, preferably which work better than the nuclear weapon ones.

--
Destruction of private property, if nanotech can readily replace it, may become far less of an issue. Threats to public safety by breaking the notification scheme...

If we get something like this notification scheme in place, then I think we could reap a lot of the benefits of nanotech, while keeping some sort of handle on the risks.

--
So, you claim your competitors are producing assemblers that do not comply with the notification scheme. You claim that they have done this by having constructed general-purpose assemblers that are not connected to the net, when they make items not agreed to be on the 'safe' list.

In particular, they are doing this outside a nanotech-secure lab.

The monitoring agency will initially do an audit of their nanotech facilities, based on the normally private logs from the notification scheme. This will not require them to go on site.

The company will be informed they are audited, as this impacts on their company privacy, though if there was hard evidence they were in violation, the warning might be delayed.

If the company found that the monitoring agency was using their company private data for anything but nanotech monitoring for the public good, they could sue the monitoring agency.

If there is need for further investigation, you may have managed to disrupt the operations of your competitor, but false accusations, where it is proved that you didn't have good reason to make them, could be bad for you.

Untrusted nanotech production facilities probably get the thermite wash treatment. Following by a really determined hunt for all their products, repeat ditto.

Unless you can assemble a nanotech-safe lab on the spot, and nano-dissect the suspect product, thermite might be the only choice. Remember, the investigation will have access to all appropriate logs from the notification scheme, and while you can replace goods, replacing lost people...

--
Real protection of privacy, rather than as a sales point, needs to be part of the network logic on a basic level. Hence my comments above on strong encryption.

--
There is no need for absolutely trustworthy employees. The system is not designed that way.

Everything works on a distributed, peer-to-peer, basis, with access to only the info you can prove you need for a particular purpose, and a distributed, secure, log is kept of who accesses what (this is normally unaccessible, except to that person, for privacy reasons).

Before you get access to a secured area, the fact that you are doing so is off-site, in multiple places, so you can't tamper with it. If the off-site links are broken, you don't get access. This will help keep government honest, if nothing else.

The schemes to make the security agencies work in this setting, with everything they do being recorded, should be ... interesting.

Where there is something risky going on, a voting scheme by distributed peers, who should not all be able to be simultaneously coerced, is required. And, it's not always the same peers.

The question of "Who will watch the watchers?" is answered by, "Everyone watches everyone else".

--
We need a whole new raft of laws on privacy of information, and these implemented in network logic, to make quite a few things work properly.

Anyone who attempts to distribute assemblers which break the notification protocol is potentially playing with rogue nanotech.

--
Yes, the scheme is intended to make hacking very difficult.

To hack nanotech you use nanotech. Where do you get that from? You design your own. But, if you haven't got a hacked assembler on which to do this, the notification scheme should at least ensure there is a record of this. And, if you use 'red flagged' designs, there is an off-site record that you attempted to do this, but had your assembly request rejected.

That is why the scheme needs to work the way it does, so that there is an audit trail back to the hackers, and that they will know this.

Keep trying to use 'red flagged' designs, and it is likely that someone will want to talk to you about your design problems.

I know this isn't perfect, but it might at least give us a chance of surviving mature nanotech.

--
Saying you can ignore a nanotech functionality agreement comes under the same order of things as saying you don't need to know or agree to keep the rules of driving, for safety on the roads. With empty roads you may get away with it for a while, but something really nasty is going to occur sooner or later.

--
Note that Limited Domestic Assemblers don't need connectivity, Domestic Assemblers only need occasional connectivity, and only General Assemblers need connectivity, and then for 'red flagged' designs (which definitely include assemblers).

Comms is only needed on an intermittent basis, and not with 'us', but with all the other assemblers, which enforce the policy.

Also note that there is no website, just connections to other assemblers. The network effectively bootstraps itself into existence as more assemblers are made.

--
An assembler that tried DoS attacks is very likely to get cut-off say 90% of the time, or whatever is enough to let it go on functioning, but not DoS-ing.

Once your assembler has its confirmed OK, it gets on with what it is making, and likely only reports back when it finishes your very large and expensive item - and that 'finished' report can be queued to go off later.

As for viruses, a virus must change the behaviour of the assembler. You could lock things up so that the only way to do that is to make a new assembler. If this messes-up, you sensibly still have the old one, and anyway you still have the design for the old one.

Periodic disconnects are not a problem, just permanent ones. These kill the functionality of your assembler that needs connectivity.

---

Parts of this article are based on the kind feedback of Warren Okuma, on the alt.sci.nanotech Usenet newsgroup, in October 2005, though none of his text is included. It was inspired by a question that James A. Donald asked in his post "Basic reproductive architectures", on sci.nanotech, early October 2005.

Quite a few of the ideas here revolve around control of meta data, which is derived from the work of Dr I.A. Newman, of Loughborough University, UK.


(c) Rory O. McLean, October 2005
    Permission granted to use for non-profit making purposes