This is a response to this email: https://moderncrypto.org/mail-archive/messaging/2014/000780.html?hn (I don't want to sign up to a mailing list just to send one reply, especially when I want it to be public).
If you haven't read the mail I suggest you at least skim it.
tl;dr: Spam fighting relies heavily on the provider being able to read emails plain text itself. The question is how to solve that problem in the case of "almost everyone uses end to end encryption".
It seems to me only the negative sides of end to end cryptography are seen. There is a lot it can do for us, maybe even eliminate spam altogether. Basically there are types of email we have to consider:
I have a friend (or any kind of person I somehow know directly) and want to exchange emails with him or her. Easy: I get my friends public key and tell my provider "I trust this public key, please let the mails through". He or she does the same. Done.
I have I company I want to receive mail from. It doesn't matter if I sign up with some social site or just want a receipt, I get the public key off their web site and do the same thing as above. If the company wants to receive answers from me I tell them my public key after account creation, which has to be shielded against spam account creation anyways.
The only difficult case is when I want to receive emails from addresses I don't know before. There are several sub cases here, which have different difficulties of solving the problem.
1. Company to company mails. Easy: Sign all mails with the company mail server and trust that key on the other company mail server.
2. Company to client mail. wait, since when do we want to receive mail from a company we don't know? Generally speaking, I wouldn't want to. In the small number of cases where I might want to, it would probably be ok to contact me another way first. Example: The local electricity company wants to send me the bill via email. If I don't know them since I moved to my appartment / house / whatever, they can send me a letter first and all is well. State emails are another thing, but there could be a general "This is a state mail" public key. I honestly can't think of any case where I would want to receive an email from a non-person-address I don't know and where a letter before wouldn't be the way to go.
3. Client to company mail. This is where it gets a little complicated. However there would still be the solution of "create account (CAPTCHA protected and whatnot), submit your key, done.
4. Person to Person. Someone reads a blog post and wants to reply to that on a personal level. Okay, this is the only case where I don't have a perfect solution in my mind. However until this case there are a lot of mails that got sent. Now we can talk about reputation on the provider end (how many accounts did not reject how many mails from this account), about web of trust (Would it not be awesome to let that "everyone knows everyone via 7 persons" mantra of social networking do the work for you?) and about friend requests. Yes, friend requests for emails, why the hell not? Key signing is just a technical way of expressing that (note: the word friend in "friend request" should not be read to literally). One can set rules as soft or as hard as one wants: Only one friend request per domain before one accepts any more mail? Or just "only a friend request per address before more mail to this account".
Yes I make it sound easy when it is a lot of work. But I say it's less work than plain text spam fighting.
Yes the client side tools are shitty. We need a lot of work to make that stuff usable. However it is entirely possible: Smartphones and qr codes make public key exchange easy. Add the email to the address book in the same function and it just got easier than before. We need good common APIs from email providers to send them keys we trust or do not trust anymore.
Yes, signing every mail outside of the encryption makes us horribly trackable. I don't have a perfect solution here, however not doing it isn't one either. As long as everything is sent from the same account it doesn't matter anyway. And there is always the possibility of the web of trust of self, where a different key is used for every email account, every contact, however you like it and where you can let all the keys trust each other secretly. Good keychain software is needed of course, but it is any case, if we ever want to bring end to end encryption to the masses and maybe solve the "I have to many passwords" problem on the way.
Please tell me if I have obvious flaws in my arguments, if I just overlooked some cases or if you have better ideas.
2014-08-24
I love btrfs
As I said before btrfs has raid support. That is just the newest thing I learned about it. What is also great is its support for subvolumes and snapshots. Since snapshots are copy-on-write they are instant and only cost storage capacity once you start changing files. snapshots are read only by default, which is good for backups, but can of course be duplicated to standard subvolumes, which ca be mounted at boot as root file system. So with a small amount of bash scripting and a cron job you can get a local timemachine like backup system. The script could also take care of adding entries to your boot manager. And you don't even have to revert to a state where your system worked an throw all changes out the window, you can keep those in a snapshot.
But since local snapshots are a little useless when the disk fails one needs external backup. btrfs can transfer diffs between snapshots :)
Yep, thats it, but aren't the simple "hey something works" reads the best?
But since local snapshots are a little useless when the disk fails one needs external backup. btrfs can transfer diffs between snapshots :)
Yep, thats it, but aren't the simple "hey something works" reads the best?
I love citadel
Mail servers are a mess. There may be distributions out there with a good default configuration. Any deviation from there and you just want to run back to gmail.
There are, at least in my mind, 2 alternatives, which make any sense whatsoever:
citadel and kolab. kolab is the whole stack postfix, smtp auth stuff, imap, caldav, carddav, ldap, roundcube and whatnot stuck together. I'm quite sure it's a great thing once you got it running and it has everything I want. However there is no good ebuild for gentoo and the last time I tested it on a debian? ubuntu? virtual machine it asked for 10 to 20 admin passwords for different services until I lost track of what was working together with what.
citadel on the other hand is an old bbs evolved to a mail server (or groupware). It has a lot of those features as well, but the web interface is a little clunky / dated. Also its cal- and carddav interface doesn't work (at least with kde's kontact). There are a lot of features in there like message boards, blogs, chat rooms, xmpp server and so on, but what I really like is that its a mail server that is easy to install. It just wants to know an admin account, a couple of ports and a domain and you're good to go. spamd and clamav are just a enter-127.0.0.1-here away. There is sieve support, both scripting and simple rules you can click together. And as a bonus if you have admin privileges you can just enter more email addresses into your own contact information and you will start receiving on those addresses as well, thats easy aliasing for once!
So it took me at max half an hour to get it up and running to the previous state instead of weeks.
There are, at least in my mind, 2 alternatives, which make any sense whatsoever:
citadel and kolab. kolab is the whole stack postfix, smtp auth stuff, imap, caldav, carddav, ldap, roundcube and whatnot stuck together. I'm quite sure it's a great thing once you got it running and it has everything I want. However there is no good ebuild for gentoo and the last time I tested it on a debian? ubuntu? virtual machine it asked for 10 to 20 admin passwords for different services until I lost track of what was working together with what.
citadel on the other hand is an old bbs evolved to a mail server (or groupware). It has a lot of those features as well, but the web interface is a little clunky / dated. Also its cal- and carddav interface doesn't work (at least with kde's kontact). There are a lot of features in there like message boards, blogs, chat rooms, xmpp server and so on, but what I really like is that its a mail server that is easy to install. It just wants to know an admin account, a couple of ports and a domain and you're good to go. spamd and clamav are just a enter-127.0.0.1-here away. There is sieve support, both scripting and simple rules you can click together. And as a bonus if you have admin privileges you can just enter more email addresses into your own contact information and you will start receiving on those addresses as well, thats easy aliasing for once!
So it took me at max half an hour to get it up and running to the previous state instead of weeks.
I love syncthing a little and I distrust owncloud a lot
So After my server crash I had to reinstall owncloud and then resynchronzie it. Well thats a crawl and I only have around 2.5GB, just the important stuff, not music and cat pictures ;)
I had a talk with a couple of friends and one was looking through the database of owncloud, and what he found scared me a lot. It seems owncloud uses lots and lots of tables but without any sense: usernames, groupnames and so on are saved in tables with one row (or field if you like the term better) ... varchar. So what happens when a user- or groupname is changed? Yes, owncloud has to go through all the tables and change every entry containing the name. And hopefully it doesn't miss anything. yak. I made better databases when I was 12 (and I learned it during an MS Access class in the adult education centre).
Another problem I have is the follwing: A couple of weeks ago my server had to reboot for a kernel update. After the reboot a lvm volume didn't get mounted. It was the volume with my owncloud data. How that happened is mostly irrelevant, the point is owncloud synced my "data" from the server and before I knew it, both my desktop machines had deleted everything from the owncloud folder. Since owncloud doesn't do any versioning I was really lucky that I could just mount the volume and reindex (which is not guaranteed to work or to not destroy your data!).
As I said, I got scared, that is not the alternative to dropbox I'm looking for.
Enter the world of syncthing. Basically it is an open source alternative to bittorrent sync. Currently it is at version 0.9.6 and seems stable enough. The lansync is quite fast and the upload to the server a crawl, but that's a problem with my upload speed, not with the software. Sure, there is a still a lot to do, like a native interface instead of the local webserver, a try icon, not showing a ms dos console on windows, an android app (though there is one in the making), but all in all I trust in it a lot more than in "I want to be a whole cloud with contacts, calendars, microsoft document editing, media player, everything in php and on a database that doesn't deserve to be called one" - owncloud.
To be really happy all I need is a webapp on top for up/downloading files via browser (suggestions very welcome) and an android app. Everything else is just make-up.
EDIT: I forgot to mention that syncthing has versioning: Both easy mode (keep $number-of-versions) and timemachine like (every minute the first hour, every day the first week...). Also it has a mode to protect a master-machine from changes.
I had a talk with a couple of friends and one was looking through the database of owncloud, and what he found scared me a lot. It seems owncloud uses lots and lots of tables but without any sense: usernames, groupnames and so on are saved in tables with one row (or field if you like the term better) ... varchar. So what happens when a user- or groupname is changed? Yes, owncloud has to go through all the tables and change every entry containing the name. And hopefully it doesn't miss anything. yak. I made better databases when I was 12 (and I learned it during an MS Access class in the adult education centre).
Another problem I have is the follwing: A couple of weeks ago my server had to reboot for a kernel update. After the reboot a lvm volume didn't get mounted. It was the volume with my owncloud data. How that happened is mostly irrelevant, the point is owncloud synced my "data" from the server and before I knew it, both my desktop machines had deleted everything from the owncloud folder. Since owncloud doesn't do any versioning I was really lucky that I could just mount the volume and reindex (which is not guaranteed to work or to not destroy your data!).
As I said, I got scared, that is not the alternative to dropbox I'm looking for.
Enter the world of syncthing. Basically it is an open source alternative to bittorrent sync. Currently it is at version 0.9.6 and seems stable enough. The lansync is quite fast and the upload to the server a crawl, but that's a problem with my upload speed, not with the software. Sure, there is a still a lot to do, like a native interface instead of the local webserver, a try icon, not showing a ms dos console on windows, an android app (though there is one in the making), but all in all I trust in it a lot more than in "I want to be a whole cloud with contacts, calendars, microsoft document editing, media player, everything in php and on a database that doesn't deserve to be called one" - owncloud.
To be really happy all I need is a webapp on top for up/downloading files via browser (suggestions very welcome) and an android app. Everything else is just make-up.
EDIT: I forgot to mention that syncthing has versioning: Both easy mode (keep $number-of-versions) and timemachine like (every minute the first hour, every day the first week...). Also it has a mode to protect a master-machine from changes.
2014-08-23
mdadm + lvm + dead harddisk = cluster-f-up
So another rant and this time it's not about ssl! I promise! really!
So there were two nice disks in my server. What do we do with disks in servers? raid of of course! Data must be safe an all... But since this server is on the cheap side of things, it doesn't have a (true) raid controller. So what do we use anyway? mdadm of course. and lvm on top, just for good measure. Actually we used it to seperate some stuff like user homes, certain data, just so we don't wake up one day with our server unable to boot because of some runaway 300GB log file...
Then one of the disks died. But hey, we have a raid right? One support ticket and five minutes later the server has a new disk and isn't booting. Well, the bootloader was on the first disk, so fair enough, lets sync the boot partition (on a seperate raid) first and lets do the rest later without downtime.
me: So how does one go about removing absent disk from a software raid?
mdadm: NO.
me: What?
mdadm: NO. JUST NO
me: But the disk isn't coming back, I just want to...
mdadm: NO.
me: okay, mdadm if you don't want to remove it fine, just take another one on top, will you?
mdadm: Fine, but I will only take it as spare :P
me: enough already, I'm increasing your active disk number to 3.
mdadm: Wait, I'm confused, now I have 1 working disk, 2 disk with the same id as the working one, but they are missing, and 1 spare.
me: wtf?!
me: internet to the rescue! *google*
internet: erm, well, nope.
me: really?
internet: well, you could just re-create the array and then add the new disk. only solution add all.
me: seems kind of dangerous, but everyones talking about no dataloss
one reboot later...
me: raid: go!
raid: ok
me: lvm go!
...
me: lvm?
...
me: god dammit!
some hours later I was looking at binary dumped raid headers in vim in hex mode, diffed side by side. let that sink in for moment. there were some insignificant differences between the working version without data from the new spare disk and the not working version with data from the old disk. differences like creation date or uuid. nothing a one-disk-present-one-disk-missing-newly-created raid should stop from spewing up it's contained lvm.
After that I dumped the first 500mb of the disk, vim, hex mode again, and looked for the lvm header itself. first good message that day: it was present. I could even pinpoint it to the byte on disk. However pvck (lvm fsck-like tool to check for lvm headers) did not find it, however much I told it where to look.
Well that's as far as I got before saying "screw it, I'm using btrfs with integrated raid and subvolumes and safe the data later".
Then I reinstalled Gentoo, quite smoothly.
Except for ssl certificates of course, they still suck, but I promised not to talk about that again. This time.
So there were two nice disks in my server. What do we do with disks in servers? raid of of course! Data must be safe an all... But since this server is on the cheap side of things, it doesn't have a (true) raid controller. So what do we use anyway? mdadm of course. and lvm on top, just for good measure. Actually we used it to seperate some stuff like user homes, certain data, just so we don't wake up one day with our server unable to boot because of some runaway 300GB log file...
Then one of the disks died. But hey, we have a raid right? One support ticket and five minutes later the server has a new disk and isn't booting. Well, the bootloader was on the first disk, so fair enough, lets sync the boot partition (on a seperate raid) first and lets do the rest later without downtime.
me: So how does one go about removing absent disk from a software raid?
mdadm: NO.
me: What?
mdadm: NO. JUST NO
me: But the disk isn't coming back, I just want to...
mdadm: NO.
me: okay, mdadm if you don't want to remove it fine, just take another one on top, will you?
mdadm: Fine, but I will only take it as spare :P
me: enough already, I'm increasing your active disk number to 3.
mdadm: Wait, I'm confused, now I have 1 working disk, 2 disk with the same id as the working one, but they are missing, and 1 spare.
me: wtf?!
me: internet to the rescue! *google*
internet: erm, well, nope.
me: really?
internet: well, you could just re-create the array and then add the new disk. only solution add all.
me: seems kind of dangerous, but everyones talking about no dataloss
one reboot later...
me: raid: go!
raid: ok
me: lvm go!
...
me: lvm?
...
me: god dammit!
some hours later I was looking at binary dumped raid headers in vim in hex mode, diffed side by side. let that sink in for moment. there were some insignificant differences between the working version without data from the new spare disk and the not working version with data from the old disk. differences like creation date or uuid. nothing a one-disk-present-one-disk-missing-newly-created raid should stop from spewing up it's contained lvm.
After that I dumped the first 500mb of the disk, vim, hex mode again, and looked for the lvm header itself. first good message that day: it was present. I could even pinpoint it to the byte on disk. However pvck (lvm fsck-like tool to check for lvm headers) did not find it, however much I told it where to look.
Well that's as far as I got before saying "screw it, I'm using btrfs with integrated raid and subvolumes and safe the data later".
Then I reinstalled Gentoo, quite smoothly.
Except for ssl certificates of course, they still suck, but I promised not to talk about that again. This time.
There and back again
Hello my dear readers,
yes you, all of you ... 3 or 4 ;)
After a journey via octopress, probably something(s) else and wordpress on my own server I'm back here. Why? Well, f'ed up. More on that in the next post, however one thing is clear to me now:
Since I don't use the pretty code rendering of octropress anymore and the data is public anyway using my own server is just a matter of pride. And that got a lot of my posts deleted or at least into digital limbo. So why not just host it here, where it's probably safe from accidental server crashes and probably also from nuclear wars? Well I don't know either anymore, so back I am.
yes you, all of you ... 3 or 4 ;)
After a journey via octopress, probably something(s) else and wordpress on my own server I'm back here. Why? Well, f'ed up. More on that in the next post, however one thing is clear to me now:
Since I don't use the pretty code rendering of octropress anymore and the data is public anyway using my own server is just a matter of pride. And that got a lot of my posts deleted or at least into digital limbo. So why not just host it here, where it's probably safe from accidental server crashes and probably also from nuclear wars? Well I don't know either anymore, so back I am.
Subscribe to:
Posts (Atom)