DataPacRat comments on Open thread, Sep. 19 - Sep. 25, 2016 - Less Wrong

2 Post author: DataPacRat 19 September 2016 06:34PM

You are viewing a comment permalink. View the original post to see all comments and the full post content.

Comments (92)

You are viewing a single comment's thread. Show more comments above.

Comment author: DataPacRat 21 September 2016 04:46:44PM 0 points [-]

a lot of open-source projects are very buggy and remain very buggy

Yep.

there is closed-source software which is considerably more bug-free

Yep.

You're looking for impossible guarantees.

I'm not looking for guarantees at all. (Put another way, I'm well aware that 0 and 1 are not probabilities.) What I am doing is trying to gauge the odds; and given my own real-world experience, open-source software /tends/ to have fewer, less severe, and shorter-lasting exploitable bugs than closed-source software, to the extent that I'm willing to make an important choice based on whether or not a piece of software is open-source.

And remember, that you are not making choices, but requests.

True, as far as it goes. However, this document I'm writing is also something of a letter to anyone who is considering reviving me, and given how history goes, they are very likely going to have to take into account factors that I currently can't even conceive of. Thus, I'm writing this doc in a fashion that not only lists my specific requests in regards to particular items, but also describes the reasoning behind the requests, so that the prospective reviver has a better chance of being able to extrapolate what my preferences about the unknown factors would likely be.

if someone revives you with malicious intent

If someone revives me with malicious intent, then all bets are off, and this document will nigh-certainly do me no good at all. So I'm focusing my attention on scenarios involving at least some measure of non-malicious intent.

Comment author: Lumifer 21 September 2016 08:47:26PM 0 points [-]

open-source software /tends/ to have fewer, less severe, and shorter-lasting exploitable bugs than closed-source software

On the basis of this "tends" you make a rather drastic request to NOT revive you if you'll be running on top of some closed-source layer.

Not to mention that you're assuming that "open-source" and "closed-source" concepts will still make sense in that high-tech future. As an example, let's say I give you a trained neural net. It's entirely open source, you can examine all the nodes, all the weights, all the code, everything. But I won't tell you how I trained that NN. Are you going to trust it?

Comment author: DataPacRat 21 September 2016 11:20:51PM 0 points [-]

On the basis of this "tends" you make a rather drastic request to NOT revive you if you'll be running on top of some closed-source layer.

That's true. But given the various reasonably-possible scenarios I can think of, making this extreme of a request seems to be the only way to express the strength of my concern. I'll admit it's not a common worry; of course, this isn't a common sort of document.

(If you want to know more about what leads me to this conclusion, you could do worse than to Google one of Cory Doctorow's talks or essays on 'the war on general-purpose computation'.)

As an example

You provide insufficient data about your scenario for me to make a decent reply. Which is why I included the general reasoning process leading to my requests about open- and closed-source - and in the latest version of the doc, have mentioned part of the reason for going into that detail is to let revivalists have some data to extrapolate what my choices would be in unknown scenarios. (In this particular case, the whole point of differentiating between open- and closed-source software is the factor of /trust/ - and in your scenario, you don't give any information on how trustworthy such NNs have been at performing their intended functions properly and at avoiding being subverted.)

Comment author: Lumifer 22 September 2016 02:44:40PM 0 points [-]

I am well aware of the war on general computation, but I fail to see how it's relevant here. If you are saying you don't want to be alive in a world where this war has been lost, that's... a rather strong statement.

To make an analogy, we're slowly losing the ability to fix, modify, and, ultimately, control our own cars. I think that is highly unfortunate, but I'm unlikely to declare a full boycott of cars and go back to horses and buggy whips.

Since you're basically talking about security, you might find it useful to start by specifying a threat model.

how trustworthy such NNs have been at performing their intended functions properly and at avoiding being subverted

What do you mean by "such NNs"? Neural nets are basically general-purpose models and your question is similar to asking how trustworthy computers have been at performing their intended functions properly -- it's too general for a meaningful answer.

In any case, the point is that the preference for open-source relies on it being useful, that is, the ability to gain helpful information from examining the code, and the ability to modify it to change its behaviour. You can examine a sufficiently complex trained NN all you want, but the information you'll gain from this examination is very limited and your ability to modify it is practically non-existent. It is effectively a black box even if you can peer at all the individual components and their interconnects.

Comment author: DataPacRat 22 September 2016 06:37:52PM 0 points [-]

Since you're basically talking about security, you might find it useful to start by specifying a threat model.

I thought I had; it's the part around the word 'horrifying'.

What do you mean by "such NNs"? Neural nets are basically general-purpose models and your question is similar to asking how trustworthy computers have been at performing their intended functions properly -- it's too general for a meaningful answer.

We actually already have a lot of the fundamental software required to run an "emulate brain X" program - stuff that accesses hardware, shuffles swap space around, arranges memory addresses, connects to networking, models a virtual landscape and avatars within, and so on. Some scientists have done extremely primitive emulations of neurons or neural clusters, so we've got at least an idea of what software is likely to need to be scaled up to run a full-blown human mind. None of this software has any particular need for neural-nets. I don't know how such NNs as you propose would be necessary to emulate a brain; I don't know what service they would add, how fundamental they would be, what sort of training data would be used, and so on.

Put another way, as best as I can interpret your question, it's like saying "And what if future cars required an algae system?", without even saying whether the algae tubing is connected to the fuel, or the exhaust, or the radiator, or the air conditioner. You're right that NNs are general-purpose; that is, in fact, the issue I was trying to raise.

You can examine a sufficiently complex trained NN all you want, but the information you'll gain from this examination is very limited and your ability to modify it is practically non-existent. It is effectively a black box even if you can peer at all the individual components and their interconnects.

Alright. In this model, in which it appears that the training data is unavailable, that the existing NN can't be retrained or otherwise modified, and that there doesn't seem to be any mention of being able to train up a replacement NN with different behaviours, then it appears to match the relevant aspects of "closed-source" software much more closely than "open-source", in that if a hostile exploiter finds a way to, say, leverage increased access and control of the computer through the NN, there is little-to-no chance of detecting or correcting the aspects of the NN's behaviour which allow that. I'll spend some time today seeing if I can rework the relevant paragraphs so that this conclusion can be more easily derived.

Comment author: Lumifer 23 September 2016 03:00:45PM 0 points [-]

the part around the word 'horrifying'

That's not a threat model. A threat model is basically a list of adversaries and their capabilities. Typically, defensive measures help against some of them, but not all of them -- a threat model helps you figure out the right trade-offs and estimate who you are (more or less) protected from, and who you are vulnerable to.

stuff that accesses hardware, shuffles swap space around, arranges memory addresses

That stuff usually goes by the name of "operating system". Why do you think that brain emulations will run on top of something that's closely related to contemporary operating systems?

a hostile exploiter

You seem to worry a lot about your brain emulation being hacked from the outside, but you don't worry as much about what the rightful owner of the hardware and the software on top of which your em lives might do?

Comment author: DataPacRat 23 September 2016 07:12:42PM 0 points [-]

A threat model is

I'm merely a highly-interested amateur. Would you be willing to help me work out the details of such a model?

Why do you think that brain emulations will run on top of something that's closely related to contemporary operating systems?

Because even as a scifi fan, I can only make so many guesses about alternatives, and it seems at least vaguely plausible that the same info-evolutionary pressures that led to the development of contemporary operating systems will continue to exist for at least the next couple of decades. At least, plausible enough that I should at least cover it as a possibility in the request-doc.

the rightful owner of the hardware

Without getting into the whole notion of property rights versus the right to revolution, if I thought whoever was planning to run a copy of me on a piece of hardware was fully trustworthy, why would I have included the 'neutral third-third party' clause?

Comment author: Lumifer 27 September 2016 06:27:40PM *  0 points [-]

You are writing a, basically, living will for a highly improbable situation. Conditional on that situation happening, I think that since you have no idea into which conditions you will wake up, it's best to leave the decision to the future-you. Accordingly, the only thing I would ask for is the ability for your future-you to decide his fate (notably, including his right to suicide if he makes this choice).

Comment author: DataPacRat 28 September 2016 01:33:52AM 0 points [-]

living will

In the latest draft, I've rewritten at least half from scratch, focusing on the reasons why I want to be revived in the first place, and thus under which circumstances reviving me would help those reasons.

future-you

The whole point about being worried about hostile entities taking advantage of vulnerabilities hidden in closed-source software is that future-me might be even less trustable to work towards my values than the future-self of a dieter can be trusted not to grab an Oreo if any are left in their home. Note to self: include the word 'precommitment' in version 0.2.1.

Comment author: Lumifer 28 September 2016 02:22:46PM 0 points [-]

is that future-me might be even less trustable to work towards my values

If whoever revives you deliberately modifies you, you're powerless to stop it. And if you're worried that future-you will be different from past-you, well, that's how life works. A future-you in five years will be different from current-you who is different from the past-you of five years ago.

As to precommitment, I don't think you have any power to precommit, and I don't think it's a good idea either. Imagine if a seven-year-old past-you somehow found a way to precommit the current-you to eating a pound of candy a day, every day...