On Saturday 31 July 2010 14:52:43 xor wrote: > On Friday 30 July 2010 04:29:54 pm Matthew Toseland wrote: > > > > 1. Offer to turn on encrypted swap in the installer. Keep encrypting > > everything. Warn users about saving files out, and media files, and work > > towards playing media files in an embedded (e.g. java) player that doesn't > > use plaintext temp files. > > Offering to reconfigure swap to be encrypted is out of scope. And not > possible > on Windows > > > 2. Give up on encrypting anything on disk, and > > offer to install TrueCrypt if it isn't already installed. > > Offering TrueCrypt is out of scope > > I see a third option: > > 3. Realize that most users have a real LOAD of stuff on their hard disks > which > could get them screwed. Get rid of physical security. Encrypting the Freenet > stuff does not help because they will use browsers which cache dangerous > stuff > and do downloads of dangerous stuff etc. The really paranoid ones will use > TrueCrypt anyway. And encryption makes stuff slow. > > I mean it IS nice that we have a physical security level but I wouldn't have > offered that feature from the beginning on. > > If you want to be safe when your computer gets seized you absolutely have to > do full disk encryption, something will ALWAYS leak out otherwise. > This is the typical, modularist, perfectionist unix philosophy that so many geeks espouse. It has many advantages. It is not however what is best for the *typical* end user.
It needs to be possible to install Freenet quickly and easily, and to then use it without grossly compromising yourself. If you choose to improve your local security later on, or if you do something that we have clearly warned against, that's not our problem. But we cannot expect users to wait for hours while Truecrypt creates volumes, nor can we leave users who just want to try it *completely* unprotected. What we can do is: - Offer to turn on swap encryption in the installer, since on Windows 7 and Vista Business/Ultimate it is very easy, and since as a java application we do not have access to locked memory (unlike e.g. pgp). - Ask the user what their physical security needs are. - Prevent obvious threats such as web-bugs in HTML, and caching of pages. - Strongly recommend, and automatically use if possible, the "incognito" or "privacy" mode present in both Chrome and Firefox in recent versions. Combined with the above, this makes HTML essentially safe. - Encrypt everything that we usefully can encrypt. - Warn them when they are going to do something potentially dangerous: Downloading a file to disk (as opposed to temporary space), loading a file that is likely to be opened in an external tool i.e. be written to disk first, etc. Make the warning permanently dismissable. - Recommend to them that they install Truecrypt, and provide a hyperlink. This is the philosophy that we have taken so far, partly as a result of my talking with people with contacts in Nedanet. What they told me was that physical security is by far the biggest threat. Even before that, we have always taken reasonable precautions - if we take the minimalist approach we wouldn't even filter HTML, we would stick instructions for setting up a safe browsing VM in a README somewhere! The point is that Freenet should be: 1) Easy AND 2) Secure by default unless it tells you otherwise -------------- 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/20100731/05fcf8ad/attachment.pgp>
