Change: rename email essay draft, drop obsolete draft

2 files changed, 0 insertions, 351 deletions

diff --git a/email2.md b/email2.md
deleted file mode 100644
index c807871..0000000
--- a/email2.md
+++ /dev/null
@@ -1,351 +0,0 @@
----
-title: Reinventing electronic mail
-...
-
-Introduction
-=============================================================================
-
-I am fed up with the existing Internet email system. There's spam, and
-the email system is
-getting centralised in all sorts of bad ways. This idea is about
-sketching what a good email system would look like, if it were
-re-designed from scratch, using everything we've learnt over the
-decades, and not necessarily using any part of the existing system.
-
-Good aspects
------------------------------------------------------------------------------
-
-* Ubiquitous. Approximately everyone on the Internet has email, or can
-  get it.
-
-* Anyone can email anyone. This lowers barriers for communication,
-  globally. It's especially important for free and open source
-  projects, but also to allow people all over the world to
-  easily self-organise to build a better world in general.
-
-* Distributed: sender and recipient don't need to use the same server.
-
-* Standardised, with many (many!) inter-operable implementations.
-
-* Supports off-line use. Not everyone can, or wants to, be online all
-  the time.
-
-
-Problems with the existing email system
------------------------------------------------------------------------------
-
-* Spam. Worse, anti-spamming measures drive centralisation, and are
-  still ineffective, especially for those not using the huge
-  providers. End result: you either sacrifice privacy or you get tons
-  of spam.
-
-  - This is a result of the desirable feature that anyone can email
-    anyone, combined with the fact that sending an email costs
-    approximately nothing, and that sending a million email also costs
-    approximately nothing, and aggravated by the fact that spamming
-    has de facto no real financial or legal repercussions.
-
-* Scam. There is no widely used method to digitally sign email, and
-  thus criminals can easily fake messages to look like they come from,
-  say, Amazon, Netflix, Paypal, or other companies the recipient is
-  likely to use. Everyone needs to be constantly on their toes to
-  avoid mistakes.
-
-  - There are standards for digitally signed email, but 
-
-* Becoming centralised to a few huge providers. This is bad for
-  privacy and can be catastrophic for security. If one of the big
-  providers gets breached, up to hundreds of millions of people's
-  communications are at risk.
-
-  - We're moving towards a future where if you host email yourself,
-    you're suspicious. It's already the case that it can be difficult
-    for a self-hosted email server to reach people on Gmail.
-
-* No real privacy, even if you self-host. Email is by default in
-  clear text, and while there are standards for encryption, they are
-  not widely used, and tend to also leave metadata (headers)
-  unencrypted.
-
-* HTML email is not well standardised, and is a security and privacy
-  risk. Different email clients implement HTML in different ways, and
-  the web standards are not followed very closely.
-
-  - Worse, there's an assumption that HTML emails can embed images
-    from the Internet, which results in more security problems (images
-    are complicated data provided by a potential attacker, and just
-    viewing them is a security risk), and privacy issues (the image
-    hoster will be notified when you view the email, see tracking
-    pixels).
-
-    There are moves to restrict this, but the problems have been known
-    since soon after HTML email was introduced, and at least some of
-    the problems still exist.
-
-* Attachments fill disks. Email is commonly used to share files,
-  because it's easy and ubiquitous, even if it's not very good at it.
-  There are services that make this better, but they are mostly
-  proprietary, and require extra effort.
-
-* There is no good support for group discussions. Massive dumps of
-  forwarded discussions are commonplace in most large organisations.
-  Mailing list managers exist, but they tend to be clunky, and tend to
-  not be great for having discussions among large groups of people.
-  They're better at sending out announcements and newsletters.
-
-* The technologies and standards for email are getting ridiculously
-  complicated. Email was originally designed for relatively short
-  messages in English only. To support non-English languages in a
-  backwards compatible manner, email has gained whole extended
-  families of ways to encode text and data: uuencode, base64,
-  quoted-printable, and header encoding, to start with.
-
-  The email tech stack is getting so hard to understand that it's
-  difficult to even use, never mind implement correctly. Never mind
-  that the complexity results in more effort to operate and keep
-  secure the servers.
-
-
-Possible solutions
-=============================================================================
-
-This document tries to outline a possible solution to all the problems
-above.
-
-
-Overview
------------------------------------------------------------------------------
-
-The shape of a possible solution might be something like this:
-
-* everyone has any number of "email identities", which are roughly
-  like email addresses; it's easy to create new identities, and to
-  optionally link them together; each identity has cryptographic keys
-  for encryption and digital signatures
-
-* all email is encrypted to the recipient(s), and signed by the sending
-  identity
-
-
-Spam
------------------------------------------------------------------------------
-
-Spam, or unsolicited bulk email, is probably the first problem to
-solve, as the solution will likely constrain other aspects of the
-system.
-
-The reason current email has a spam problem is three-fold:
-
-* anyone can send email to anyone
-* sending any amount of email is basically free of cost
-* there are no real consequences from sending unwanted email, except
-  for the sender's reputation
-
-What we want from the solution:
-
-* anyone can send email to anyone who wants to receive it
-* sending email should be basically free of cost, if the recipient
-  wants it
-* sending email without prior arrangement does not need to be free of
-  cost
-
-A possible solution might be a kind of digital stamps.
-
-* Alice can give Bob a stamp to allow Bob to send email to Alice
-* Alice can give her friends permission to give out stamps on her
-  behalf, to allow friends to introduce new people to Alice
-  - as a variation, Alice might give permission to her employer to
-    give out stamps on her behalf to co-workers
-* If Bob doesn't have a stamp, but still wants to reach Alice, his
-  email software can ask Alice's server for one, and this can be made
-  "costly" in some way so that it's hard for spammers to automate
-
-When Bob sends an email to Alice, the email will come with a stamp to
-allow Alice's response to reach Bob.
-
-
-Stamps
------------------------------------------------------------------------------
-
-Digital stamps are not exactly like paper stamps. Paper stamps cost
-money, and can only be used once. A digital stamp can be more
-versatile:
-
-* might be used any number of times, or only once
-* might be valid indefinitely, or only for a specific time span
-* might be valid for any sender, or only for a specific sender, or
-  require specific keywords in the email, or have other filtering
-  rules
-* might not allow sending an email, but instead might delegate the
-  power to issue stamps to someone else; the delegation might
-  constrain the kind of stamps the delegate can issue
-* might be cancelled by its issuer at any time
-
-Stamps can be created manually via the mail user interface,
-automatically when sending email, or when joining a mailing list or
-signing up for a service.
-
-The format of stamps is open, for now. However, they should probably
-be compact enough that they can easily be communicated manually. QR
-codes might be useful.
-
-
-Generating stamps to reach someone else
------------------------------------------------------------------------------
-
-Each email server can issue stamps for an identity hosted on the
-server, if the identity has delegated the server that power. This
-would probably be a web service provided by the server to someone
-requesting a stamp.
-
-* stamp issuing might be rate limited - per server, or per group of
-  collaborating server; possibly a group based on the social graph of
-  the issuer
-
-* the requester might need to do some work to raise the cost of
-  stamps: solve a cryptographic puzzle, or do some similar task; this
-  would be easy enough that it's not expensive enough if it happens
-  occasionally, but enough that it stops spammers from doing it en
-  masse
-
-
-
-Signing up for newsletters and services
------------------------------------------------------------------------------
-
-Currently, the operator of a newsletter can add any email addresses to
-their mailing list. It's more of a convention than a technical
-requirement that the recipient must confirm they want the newsletter.
-This is abused often by the less scrupulous operators.
-
-With the stamp model, the recipient would create a stamp (possibly
-single-use, or limited to a time period) and provide it to the
-operator to be added to the mailing list. The recipient can get off
-the mailing list by cancelling the stamp. The mailing list doesn't
-need to even have an unsubscription feature. Without a valid stamp,
-the newsletter doesn't reach the recipient. Rejecting a stampless
-message can be made cheap enough that it's not a problem.
-
-Likewise, when using a service (buying tickets to an event? flights?
-stuff from an online shop?) that may need to send a message, the
-customer would provide the service with a stamp for such information
-messages. Such a stamp might be time-limited, and might delegate the
-power to, say, issue additional stamps to a third party necessary for
-providing the service (e.g., Amazon might issue stamps to the courier
-to let them reach the customer).
-
-
-Email identities
------------------------------------------------------------------------------
-
-An email identity is not an address. Email addresses are tied to
-locations (servers, domains). This makes it difficult to move one's
-email to another location.
-
-An identity in the new system is a large randomly generated number
-(UUID4). Routing messages is an unsolved problem.
-
-Each user can have any number of identities they like.
-
-To an identity some metadata is attached:
-
-* one or more names
-* for each name, zero or more certificates from other identities
-* zero or more other identities for the same person (optional)
-  - FIXME: give rationale for this
-* one or more public key pairs for encryption, certificates,
-  authentication
-
-Each message is signed by at least one certification key of the
-sender, and encrypted with every public key of every recipient.
-
-
-Names
------------------------------------------------------------------------------
-
-All names attached to an identity are decided by the identity's owner.
-Others can certify that they believe the identity and name belong
-together. This is similar to the Secure Scuttlebutt pet name system.
-
-
-
-FIXME
-=============================================================================
-
-All of this needs to be thought about.
-
-
-Routing messages
------------------------------------------------------------------------------
-
-FIXME: this needs to be solved in some way. The SSB approach probably
-doesn't scale.
-
-
-Message format
-----------------------------------------------------------------------------
-
-FIXME: this needs to be sketched. For now, assume something that's
-roughly on par with RFC2822, but with simplicity. Possibly JSON.
-
-
-Group discussions, mailing lists, signing up for services
-------------------------------------------------------------------
-
-FIXME: this needs to be sketched.
-
-
-Withdrawing or removing sent messages
------------------------------------------------------------------------------
-
-Remove sent messages? At least to groups?
-
-
-Encryption
-----------------------------------------------------------------------------
-
-Allow rotation of keys. Allow multiple keys per identity, at least one
-per device. Allow future versions to change encryption algos etc.
-
-Perfect forward security?
-
-Revoke sent message?
-
-
-Mobile as a first class citizen
------------------------------------------------------------------------------
-
-About half the people using the Internet now are using mobile only. A
-new email system should take that into account.
-
-That said, desktop/laptop computers are still hugely important and
-can't be neglected.
-
-Ideally it would be easy to implement the client software in any
-platform, to allow maximum diversity.
-
-
-Specifications, conformance
------------------------------------------------------------------------------
-
-All aspects of protocols and messages should be specified in
-sufficient detail and clarity to allow independent, inter-operable
-implementations. There should probably be a common test suite for
-conformance, and some dedicated interoperability testing.
-
-
-
-SEE ALSO
-=============================================================================
-
-Links to more information, sources, etc.
-
-* Preventing spam on the Fediverse.  Serge Wroclawski. Suggests
-  stamps. Idea via Christopher Lemmer Webber from Taler, and it might
-  not have originated there.
-  - <https://github.com/emacsen/rwot9-prague/blob/ap-unwanted-messages/topics-and-advance-readings/ap-unwanted-messages.md#postage>
-  - <https://podbay.fm/podcast/252333772/e/1503662400>
-
-* Hashcash is a system where the sender proves they do some work
-  before the recipient accepts a message.
-  - http://hashcash.org/
diff --git a/email2-v2-draft.md b/rethinking-email.md
index bddd818..bddd818 100644
--- a/email2-v2-draft.md
+++ b/rethinking-email.md