On 02/08/10 19:33, Matthew Toseland wrote: >> All the work on physical security - encryption of node.db4o in particular - >> resulted directly from my discussions with the Nedanet people. In such >> places as Iran, by far the most likely attack is seizing people's computers >> and looking at what they have been downloading.
Why, oh why, are they not just recommending full-disk encryption? Why make Freenet do all this complicated case-by-case patching stuff, when a single full-disk encryption will be enough? >> If Tor doesn't use locked pages I'd be very surprised. Even if it doesn't, >> GPG does. I understand you're not suggesting to implement swap encryption yourself. The point of bringing it up is that it's an intrusive step *that's also not enough* to provide physical security. It changes system performance, and is only one small fraction of what's needed to achieve the supposed aim. On 02/08/10 19:33, Matthew Toseland wrote: >> - alternatively, use the browser in "private mode", > > When we install Freenet we open a browser for the user. When they click the > rabbit after we have installed, again we open a browser for the user. We > have control over what browser is opened and with what settings. We do not > have to merely advise them to use incognito/private mode, we can open it for > them. > >> don't save any files to disk, > > We can warn the user, depending on the seclevel, with a dismissable warning > when they try to download a file direct to disk, and/or when they set a > higher physical seclevel. > >> encrypt your swap, > > On recent Windows, this is one very short command. We can offer to execute > that command. > >> and delete any state that fred (and plugins) leave behind. > > This is freenet's responsibility simply because we are the program doing the > deleting a lot of the time: On uninstall, when rewriting on-disk files, etc > etc. >> >> There are programs that do this already. If you want to make these "easier >> to use", go develop for those projects, or start your own project that >> does all of this in one easy program (or more likely, OS distribution). > > I have demonstrated above that most of these are things that we either must > implement, should implement if they are relatively easy, or should > recommend. > I wasn't trying to make an exhaustive list; even if you are right about each of the individual things, they are not ENOUGH to provide proper physical security. For example, a lot of the plugins will have to be modified to store data inside node.db4o, usage advice will need to be given to users (eg. have your mail client not cache stuff, etc). Every single plugin author will need to think about such things, and design plugin-specific advice and security mechanisms to take care of those things. The FAR simpler option is to go for full-disk encryption, *if the user feels they need it*. > Another interesting point is that even if you have full disk encryption, > provided swap is encrypted, it is actually slightly *more* secure for > Freenet to encrypt its temporary files This is a non-point, you don't want the disk encryption to be breakable *anyway*. If the enemy has a knife in your heart you're already dead, it doesn't matter if you're also wearing a helmet. >> >> But freenet should not be this program, because: >> >> - it greatly increases the complexity we have to deal with, and we are >> short on developer time already. > > Not true in general. > (see above about plugins) > Even if we tell people to install Truecrypt, many users won't do so until > they find some interesting material. By which time it might be too late. We'll just have to make it clear how important it is. To be quite fair, people are not stupid, if they are in serious danger they will follow the advice. If someone is stupid enough to not use full-disk encryption in a hostile environment, they are also stupid enough to bypass the security mechanism *you're* suggesting. > If we want to compromise users, practically speaking we can, unless they are > *very* dedicated. However, in practice it works because if we did distribute > compromised builds, eventually somebody would reverse engineer them and > figure out what was going on. Not if everyone has this "oh let the freenet devs look after all our security needs for us" attitude. > So lets disable ALL local security features and require everyon who wants to > speak freely to have a PhD in computer security... > > For example we could marginally simplify the code by not using incognito > mode when launching a browser, not sending no-cache headers to the browser, > not encrypting the client cache and client layer database, and not filtering > HTML. My point was to *simplify* the security mechanism, by recommending full-disk encryption instead of implementing a complicated hard-to-maintain mish-mash that only 90% works. You don't need a PhD to run TrueCrypt/cryptsetup, but you may well need a PhD to maintain all the random "security" patchwork hacks that people have added to the source code over several years. If users can't take 1 hour out of their year to do this, then it's not important enough to them (and in most cases this will be *true*). X
