On Monday 02 August 2010 18:49:24 Ximin Luo wrote: > On 02/08/10 17:20, Arne Babenhauserheide wrote: > > On Sunday 01 August 2010 12:14:51 Ximin Luo wrote: > >> So yes we should just drop "physical security". To do it properly we'll > >> have to fuck with parts of people's machines we really shouldn't be > >> fucking with; and if they are that paranoid (I am) they should just > >> encrypt their entire disks, which will cover non-freenet stuff too. > > > > For me that would take away one of the main strengths of freenet: People > > need only install one program and have anonymous and mostly secure > > communication right away. > > AISB, "the freenet service" (ie. the theoretical design) tries to provide an > anonymous/DDoS-resistant insert/request service, it doesn't try to protect you > after you actually *get* that data. If you run freenet, but never access > anything through FProxy, disk encryption is (for the most part) irrelevant. > > Encrypted node.db4o is for when your computer gets seized, and you've accessed > (ie. obtained the keys for, and decrypted) incriminating data. But there are > many other things that may incriminate you, which we can't possibly predict. > > This is a general issue that applies to any access of incriminating data, not > just freenet. Therefore, it's better to some give general advice:
It is not an intractable problem, nor is it is not unique to Freenet. > > - full-disk encryption is best This is good advice and we can tell the user in the post-install wizard if they select a higher physical seclevel. We can e.g. provide a link to TrueCrypt's website. > - 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. 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 than to rely solely on full disk encryption. The reason for this is that each such temporary file has a single key which is kept only in RAM - or in node.db4o if it is a persistent temp file. Once the download is finished the key is wiped: For non-persistent requests, there is no way to get it back, even if the enemy compromises the full disk encryption, provided that they can't pick it up from RAM - e.g. if there has been enough memory churn (e.g. a full gc), or if the computer has been rebooted. > > 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. > - a separate project would benefit other services that depend on this, such > as Tor. Not true. > > > Why throw away one of the strength freenet already has? > > It's NOT a strength that freenet already has. It gives a false sense of > security (take eg. the claims you're making right now!). 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. > > > Freenet can only attain the goal of spreading uncensorable information, if > > it is really easy to use. Else it can only reach the geek part of the > > population. > > Security is more than installing one program. If you use freenet to get some > incriminating documents then spray paint it all over the front of your house, > of course you're going to get fucked. Or what if your computer gets seized > while freenet is running, and everything is in RAM? Encrypting swap is similar > - it's completely outside of what freenet does. I have never proposed that Freenet *IMPLEMENTS* swap encryption. We cannot write a VXD in Java! I have simply suggested that we offer to enable the built-in functionality via changing a windows config setting. > > Relying on freenet developers to provide total security, is extremely naive. > Centralising security into the hands of a few - sound familiar? What's the > difference between trusting *us*, and trusting the government? 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. > > "Spreading uncensorable information" is a nice goal, but it can only work if > everyone participates. You're (as in, one is) not being helpful, if all you do > is sit on your ass and let us encrypt your swap file without understanding wtf > you're letting us do to *YOUR COMPUTER*, believing that this absolves you from > watching your own back. > > "When the freedom they wished for most was freedom from responsibility, then > Athens ceased to be free and was never free again. " 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20100802/09d2ef25/attachment.pgp>
