
Modern anti-spam and E2E crypto - timmclean
https://moderncrypto.org/mail-archive/messaging/2014/000780.html?hn
======
petercooper
It's amazing how little sender reputation can count for with Gmail in the face
of other features, however. I have a good reputation as a sender but also send
almost a million mails a month and I spend a lot of time investigating
oddities in Gmail deliverability.

All of my mails are newsletters containing 10-30 links, and more than once
I've found the mere inclusion of a single link to a certain domain can get
something into spam versus a version without that link, often with no clear
reason why (domains that are particularly new are one marker, though). Or..
how about using a Unicode 'tick' symbol in a mail? That can get a reputable
sender into Spam versus a version without the same single character (all
double tested against a clean, new Gmail account) :-) Or how about if you have
a link title that includes both ALL CAPS words and ! anywhere? Your risk goes
up a good bit, but just go with one of them, you're fine..

I now have a playbook based around numerous findings like this, some based on
gut feelings looking at the results and some truly proven, and even with my
solid reputation as a sender, I'm having to negotiate a lot content-wise each
week. But do I like it? Yeah, in a way, because it's also what stops everyone
else being a success at it.. Gmail sets the bar high! :-)

(Oh, a bonus one.. include a graphic over a certain size? Your chance of
ending up in the Promotions folder just leapt up. Remove it, you're good. It
doesn't seem to be swayed much by actual content. So I've stopped using images
where at all possible now and open rates stay up because of it.)

~~~
higherpurpose
I think the author has developed too much the kind of thinking he needed to
fight spam at regular e-mail companies.

I think there could be multiple, relatively easy methods to avoid encrypted
spam.

Someone here already suggested the first email being a "poke". And only if you
send a poke back, would that user be allowed to send you an e-mail.

The user could also have some description about him, from his profile, appear
when you hover over his profile image or whatever. If you receive an e-mail
say from a company you're expecting to receive email from, then you could poke
back, so they can send you that email. I mean there should be ways to make it
easy for people to know who's a total stranger that could be a spammer, or
someone trying to reach out to them for good reasons.

Then you could also have the emails under different labels by default. All the
_trusted_ e-mails would come to the regular Inbox, while the rest will go
under a different label.

As you said, the email provider could also see the user's reputation over
time, and if he's a spammer or not.

And these are just some easy solutions we can come up with almost immediately.
I'm sure there can be others with a little bit more thought put into it. I
certainly don't see encrypted email as some kind of "doomsday scenario" like
the author predicts in the post.

~~~
mike_hearn
Actually the "poke" method would work and I suggested it on a different thread
on that mailing list. It's the S/MIME model although these days you'd just
stick an ECC key into a header and sign it with DKIM, then upgrade the
clients. Doesn't have to be technically complicated.

There are at least three major downsides:

1) You still leak lots of metadata and the full data of the poke including
most obviously the subject line.

2) Do users understand that their spangly new "encrypted mail" actually fails
to protect a lot of important data? What if they (gasp) came to rely on it?
I'd want to see usability studies showing a clear understanding of what is
protected and what isn't.

3) You break other features that rely on the server being able to see content,
like search, and the ads that pay for all of this.

------
runeks
> A possibly better approach is to use money to create deposits. There is a
> protocol that allows bitcoins to be sacrificed to miners fees, letting you
> prove that you threw money away by signing challenges with the keys that did
> so.

This wouldn't work, because a miner can easily pay himself any amount of
bitcoins that he has saved up in fees, and include this transaction in his own
block (not broadcasting it). Thus he can basically create these "deposits" for
free, and sell them for a profit.

That's the thing: whatever you try as a counter-measure, you _always_ come
back to money: in the above scenario, money would replace "deposits" because
"deposits" would just be sold on the open market for money. Proof-of-work
becomes money: if something important requires proof-of-work, you can be sure
that a web app would surface that performs proof-of-work in exchange for
money.

It always comes back to money, because whatever restriction you put on
something, whether it be "pay fee to Bitcoin miners", "Solve proof-of-work
puzzle", or something else entirely, these things will always end up being
sold for money in an efficient market, because of the increased efficiency of
division of labor: why should I use my inefficient smartphone to calculate
proof-of-work, when I can pay a service with custom ASICs to do the job for me
at a fraction of the cost?

As far as I can see, the only alternative that can work besides money is
something that cannot be sold for money. And I can't come up with anything
that fits this requirement.

~~~
tomjen3
But your smartphone is something you already have. If it takes ten seconds
then you already paid for those ten seconds when you brought it.

Of course spammers can buy their services but when the price for normal
sending is effectively free for normal users you can jack up the price for
spammers to make it too expensive for them.

A nice benefit is that it forces sites to use something other than email, such
as RSS, since they can't afford to send newsletters anymore.

~~~
comex
Maybe, but the performance difference between a power-strapped smartphone CPU
and an ASIC tailored for the specific task is so massive I doubt you could
make it expensive enough for the latter while maintaining a reasonable
experience for the former.

~~~
IgorPartola
I see two solutions to it. First: have the phone include a chip specifically
for doing this type of work. Second: make the calculation such that it cannot
be performed faster on cheap hardware specialized for the task. I believe that
is the peppery of scrypt, and the reason why we do not see LiteCoin ASIC's
yet.

------
sounds
One important concept that seems to be missing from the discussion is Sender
Stores.

Email currently uses a Receiver Stores model. SMTP servers can relay messages,
but in almost all cases the message is transmitted directly from the
originator's network to the recipient's network. The storage of the message
only effectively changes _ownership_ once, even if the message headers say it
was forwarded many times.

That makes email a Receiver Stores model: the recipient's network is expected
to accept the message at any time and then hold it until the recipient comes
to look at it.

Some of the bitcoin messaging protocols propose a Sender Stores model. That
is, the message may be transmitted any number of times but the recipient's
network is not responsible for long-term storage. The sender's network must be
able to provide the message at any time up to the point when the recipient
actually looks at the message.

There are some obvious restrictions such as requiring that the message be
encrypted with a Diffie-Helman key (negotiated when the message is first
transmitted to the receiver's network) to reduce the feasibility of de-
duplicating millions of messages. And in order to prevent revealing exactly
when the recipient reads the message, the recipient's network doesn't ack the
message for a while.

Ultimately all of this is just designed to make bulk email (slightly) more
expensive. Spammers run on very, very thin margins. But it doesn't do anything
to solve the problem of account termination or blacklisting.

~~~
fanf2
The problem with the sender stores model is that the sender does not need to
store anything: they just generate the spam message at retrieval time. So it
does not actually increase their costs. Spam moves to the notification
mechanism that tells receivers that a message is available: this is just as
unsolicited as in current junk mail, and needs to contain enough information
for the receiver to know if it is worth retrieving the message. All the
current spam and anti-spam techniques will apply fairly exactly to these
notification messages.

~~~
dredmorbius
A fair point, but it _does_ require that the sending host _persist_ in its
network location (or have continuously updated DNS which reports its present
location).

Since early recipients of the spam will likely report it, it's fairly likely
that subsequent retrieval attempts will find a downed (or sanitized) host, no
longer delivering spam.

This will reduce the amount of spam actually delivered, and the spammer's
production / revenue margins.

------
patio11
Worth reading for confirmation regarding the importance of reputation in
deliverability, which is something that is not widely understood by non-
experts but which has really toothy consequences for many HNers' businesses.

------
idlewords
This is an incredible write-up. Can someone who knows the author plead with
him to write up the long history of the Spam Wars that he mentions in this
document? I could read this stuff all day.

~~~
baudehlo
Read Spam Kings. It covers a lot of the history.

------
beloch
I'm not too knowledgeable about this stuff, but would it work if end-to-end
encryption was only initiated after the first time somebody replies to an
address? e.g. If somebody contacts you for the first time, they lack your
public key (and/or a shared secret for authentication) and must send you
plaintext. Then, if you reply, you automatically provide them with your public
key and/or authentication info to send you encrypted messages in the future.
Thus, most spam would be in plain-text, anyone who knows how the system works
would avoid discussing sensitive info in the first email they send somebody,
and everybody else wouldn't know the difference.

~~~
superuser2
MITMing the message with the public key attached would be pretty
straightforward and impossible to catch without verification over some other
secure channel

~~~
macrael
This would be solved by public key encrypting and signing both sides of those
messages. Nothing stops people from sharing your public key, so you could
develop some kind of one off token for everyone instead, that way you can kill
those tokens after a time.

~~~
superuser2
The question is how do you know that it's actually _their_ public key.

The usual approaches are:

1) verification of they key fingerprint by some other channel, such as the
PSTN, but this is obnoxious and feels like tradecraft; you are unlikely to get
normal people to do this for normal communications.

2) certification of trust based on 3rd-party verification of government
identity documents or control of some address.

3) the web of trust. Might work well for a bunch of security-conscious HN
types, but unlikely to be a good solution for people such as our mothers who
have neither the cryptographic background to make intelligent decisions about
signing keys, nor the inclination to care.

------
thaumaturgy
Well this is pretty neat.

I've been working on custom software to improve the spam filtering on my mail
server for the last year (side project). It currently works by letting hosted
users forward spam messages to a flytrap account, and then the daemon runs,
reads the forwarded message, tracks down the original in the user's mail
directory, does a whois on the origin in the mail headers, consults its logs,
and then adds a temporary network-wide blackhole to iptables.

Originally it was intended to work alongside SpamAssassin and SQLGrey and all
that, but last night I started considering replacing SpamAssassin altogether.
I love SA, but the spammers are beating it regularly now. My TODO notes in the
code actually say, "reputation tracking for embedded URLs, domains, ccTLDs and
gTLDs, sender addresses, and content keywords." I wrote the first bits of code
for reputation tracking this morning.

It's not much of a step for the software really, because it already uses
embedded URLs in a message as part of the profile "fingerprint" for finding
the original message from a forwarded version.

But I'm a bit chuffed to hear that I'm on the right track, considering how
effective Gmail's tactics have been. :-)

Small service providers have it really tough right now. Users don't tolerate
any spam at all. A few years ago, the state of the art for small independent
services was SpamAssassin + SQLGrey (or other greylisting) plus a few other
tricks; that's not sufficient anymore, and most of us smallfry lack the
resources to come up with something much better.

After just 6 weeks in production, the software already has 20+million IPs
blocked at any given time.

~~~
baudehlo
I think SA has suffered from some of the original core developers (myself
included) moving on to other projects in a completely different tech area. The
good news is that other projects have taken up some of the mantle, like
Haraka, check out the karma plugin. It does some amazing blocking of spam and
penalizing clients.

Beyond that also one of the things SA doesn't do well is actually rejecting
hard on sensible blacklists like the CBL. We worked hard to make everything
heuristic based but it wasn't always the right choice. Some things need to be
black and white. There's some code on SA for short circuiting now but it's not
really the best solution. In my own spam filtering I have a bunch of hard
rejects and they work really well.

Anyway, check out Haraka or Qpsmtpd for solid anti spam mail serving
solutions. They work really well.

~~~
patio11
Hey wait, I _did_ vaguely recognize your username from somewhere. Thanks for
SpamAssassin! I spent more hours spelunking through your guys' source code and
community rulesets than you'd want to know, about a decade ago, while working
for the anti-spam group in our R&D department at a tech incubator.

------
zokier
One thing nice about E2E crypto in messaging is that it implies strong
identities, which most importantly allow building whitelists with high level
of confidence. And of course if we can make those identities costly to
acquire/burn, either by proof-of-work or even just with a CA model, that alone
should cut spam significantly.

------
ch
Couldn't some form of proof-of-work system be used to increase the cost of
sending a message without it having much of an economic impact on a casual
sender? Was that what he was alluding to with the "burning bitcoin" reference?

~~~
diafygi
Funnily enough, proof-of-work was originally invented to combat spam and
denial of service attacks[1][2]. I asked that in a reply, and it seems that
the large gap between server compute power and mobile compute power would make
a reasonably taxing proof-of-work system too costly for mobile phones[3].

[1] -
[https://en.wikipedia.org/wiki/Hashcash](https://en.wikipedia.org/wiki/Hashcash)

[2] - [http://hashcash.org/papers/pvp.pdf](http://hashcash.org/papers/pvp.pdf)

[3] - [https://moderncrypto.org/mail-
archive/messaging/2014/000782....](https://moderncrypto.org/mail-
archive/messaging/2014/000782.html)

~~~
drfuchs
Just to be clear, "Pricing via Processing or Combatting Junk Mail" (Crypto
1992), by Dwork and Naor, invented the idea of Proof Of Work, suggested it for
fighting Spam (before the term was even coined!), provided actual functions,
and more. This predates HashCash by half a decade. [Edited to de-obfuscate.]

~~~
diafygi
Ummm, that's the paper referenced in [2]…

------
sgentle
I wonder if this would be an interesting application for Homomorphic
Encryption. True FHE is still wildly inefficient, but there are some
interesting applications like CryptDB where sort-of-Homomorphic-Encryption is
feasible for certain restricted operations (keyword search being one).

In a system like that, maybe you could send your encrypted message along with
some encrypted keywords that you consider to be spammy to some centralised
service. That would, at least, avoid some of the client-side-filtering-is-too-
hard problem.

As far as reputation, this might be one of the rare times where a Web of Trust
seems like a good idea. Generating lots of false positives and negatives would
be a lot less powerful if the value of those reports was filtered by how much
you trust the account that made them. With email you already have an implicit
source of trust, in that anyone you mutually email with is unlikely to be a
spammer.

Seems like a really interesting problem space to be involved in.

------
fdsary
Btw, this is written by Mike Hearn, who'd I'd like to nominate to hacker of
the year. Super cool guy, mad respect to him :)

------
skrebbel
I don't understand the objection against email costing money. I send you a
mail? I pay $0.0001 to you. You reply? You pay $0.0001 back.

There is idea that this somehow blocks access to email for people who have a
hard time paying for things on the internet (for whatever reason), but it is
misguided: everybody who has access to the _internet_ pays for it. ISPs could
easily give every subscribed 10000 free emails every month.

Texting costs money and yet people do it.

What am I missing?

~~~
mike-cardwell
"What am I missing?"

The specs and the software for a start.

Then there's the fact that it's not the spammers that will end up paying, but
the people running the systems that are compromised and abused to send spam,
be they shared hosting servers or home computers.

Then there's the network effect. I'm not going to feel good telling my friends
and family that it will now cost them money to email me. Especially when they
can just contact me using Facebook instead for free and without having to set
anything new up. Especially when the email service they're already using
probably wont even support this new fangled paid-email system.

It would be a massive task to add this functionality to email, and it wouldn't
stop the spam, so it's not worth it.

------
anon4
So why not use one key per source, kind of something like this:

Alice wants to receive mail from Bob. Alice generates a public/private key
pair and gives the public half to Bob. When Bob wants to send mail to Alice,
Bob uses the public key Alice gave him. If Alice receives spam, she marks the
public key it was encrypted with as "fuck it, the spammers got it" and never
receives mail with that key again. Then she notifies Bob that the key he had
has been compromised and sends him a new one. Alice could then, after Bob has
lost her key to spammers one too many times, simply decide not to talk to
someone like him.

This would give mailing list operators a large incentive never to share your
email with anyone, otherwise you could just block them forever.

On the flip side, if the mailing list is really important to you, the operator
could reject your new key and tell you you'll either receive their spam or you
won't be part of the mailing list. Though I don't see why someone would do
that in favour of just including ads in the mails themselves.

~~~
chii
Lets suppose Bob was a spammer pretending to be a mailing list operator.

Alice gives her key to Bob, in the expectation that Bob would not be sending
her spam. Bob then sends both spam, as well as legit mail that alice did want.
Assuming that alice does not want to stop receiving the legit mail, but want
to stop the spam, how does she do it in this scenario?

If alice blacklist the key for bob, but sends a new one, the situation didn't
improve. If she doesn't send a new one, she stops receiving legit mail (that
she wants, and cannot go without).

------
PaulHoule
I think reputations are part of it but there are other aspects to.

I switched to gmail because my mail with every other provider and client was
choked with phishing messages from major banks. So much work has been done on
preventing origin spoofing in 2014 that accepting phony mail from chase.com is
a sign of gross incompetence.

------
p4bl0
The discussion here is already quite long so maybe I missed it, but I don't
see anyone asking (or answering) the first question that came to me while
reading the linked email:

Why is the cost of end-to-end crypto never taken into account?

I just can't believe that we have reached a point where it is possible to
cheaply mass mail the way spammers do if you need to encrypt each email for
each recipient. That alone should be disuasive enough, at least that's always
what I thought. If I'm right, all the discussion about the need for client to
extract features from emails and send them to a necessarily trusted
centralized third party is useless. But I may be missing something, where am I
wrong?

~~~
hueving
Even at a reduced rate, end to end crypto means spammers will have a much
higher success rate since they don't have to fight a centralized spam system
with global knowledge. This more than makes up for the extra time to encrypt a
message.

~~~
p4bl0
Mh, okay.

But let's make the crazy assumptions that we are effectively in a world where
end-to-end crypto is massively used, virtually by everyone.

I guess it would be stupid to assume that the message are encrypted but not
signed.

This means that it would be easy to have a list of identities (i.e., keys)
which are sending spams, for instance using a web of trust, without users
having to disclose any other informations that "I trust these identities, not
these ones" (which could be as easy to do as clicking "spam" or "not spam" for
the users).

Now that means that the spammers not only have to encrypt every single email
for every single recipient but also to generate new key-pairs for almost each
encryption.

Of course it is also very easy to mark as spam any email signed with a key
that is considered too small (i.e., too quick to generate).

Now if you tell be that still won't do it without a "centralized spam system
with global knowledge", I have to seriously rethink a lot of my assumptions
about the cost of some computations.

~~~
Perseids
Some numbers:

\- Public key encryption: 2048bit RSA can achieve up to about 200k encryptions
per second on a high end cpu [1]. ElGamal-like encryption schemes using
elliptic curve cryptography can get to about 100k encryptions [2].

\- Public key signatures: RSA is hopelessly slow for good keys. There is no
reason to use strong keys for this case, though. If you reuse primes you can
use a 1000 primes to generate a million RSA modules (you need two primes per
public key), effectively eliminating the costly prime search. Using elliptic
key cryptography the key generation step is dirt cheap: With ed25519 you get
200k key generations per second [3]

[1] [http://bench.cr.yp.to/results-
encrypt.html](http://bench.cr.yp.to/results-encrypt.html) [2]
[http://bench.cr.yp.to/results-dh.html](http://bench.cr.yp.to/results-dh.html)
[3] [http://bench.cr.yp.to/results-sign.html](http://bench.cr.yp.to/results-
sign.html)

Formula used for each of the above numbers: 3500x10^6/[median for Intel Xeon
E3]x4

~~~
p4bl0
Thanks for the number, it's very informative.

I guess there's still the solution to only accept message from trusted keys
but that means that 1- we have to be able to detect signature-rings from
spammers in the graph (that clearly should not be a big problem), and 2- that
there is an easy and realistic way to have a legitimate key in the trusted
network before it can be used to sends emails…

Anyway, all that is very interesting from a theoretical point of view, but we
are far from being in a world where end-to-end crypto is massively used.

~~~
pyre
> trusted keys

The problem with Web-of-Trust is that once you try to roll it out mainstream,
most people will just click "accept" or "I trust this key" without thinking
about it. Instead of "signature-rings from spammers" you would have spammers
duping less-aware real people into trusting their keys.

That said, it would seem to be a longer feedback loop to get a number of
_actual_ people to open emails and trust their keys.

~~~
p4bl0
> most people will just click "accept" or "I trust this key" without thinking
> about it

What if they don't have to do that because it's transparently done for them
when they use the "flag as spam", "not spam", and "reply" buttons for
instance?

------
dochtman
I submitted this without the ?hn at approximately the same time. Pretty weird
that this one gained traction while my submission did not.

[https://news.ycombinator.com/item?id=8275787](https://news.ycombinator.com/item?id=8275787)

------
hendzen
Mike Hearn is also a core Bitcoin developer, as well as an HN commenter. Hi
Mike!

------
lazylizard
could there be a antispam gateway that replies to 'maybe'(as in spam, ham and
maybe) mails with a temporary url that hosts a webform, before they reach the
inbox? the webform could even limit message length, prevent attachments, be
protected by akismet and so on. let the message from the form be actually
relayed to the real mail server. and once the recipient replies, automatically
whitelist that sender or possibly even the domain?

------
zerr
>we had put sufficient pressure on spammers that they were unable to make
money using their older techniques

Could anyone comment how spammers make money actually?

~~~
skizm
One way is referral links. If you click on a link in my email and buy
something on, say, Amazon, I could potentially make up to 10% of the purchase
price (Amazon is actually normally around 5% I think).

------
Zigurd
Some of my contacts have been using verification gateways/whitelists for email
for decades. If spam were to become a problem, I would use one.

------
loup-vaillant
> _Botnets appeared as a way to get around RBLs, and in response spam fighters
> mapped out the internet to create a "policy block list" \- ranges of IPs
> that were assigned to residential connections and thus should not be sending
> any email at all._

So basically, I can't send email from home? This is… unfortunate. If we want
freedom, we need decentralization, and this kills it.

~~~
Spearchucker
Hey I've no idea of anything, and don't have a dog in this fight either, but
reading everything here I think decentralization is actually the answer. Yes,
you'd not get that global reach, and your network of contacts would be
severely limited (presumably to those you know). But a decentralised system
could do E2E and P2P and run from home. Running that beside traditional,
clear-text and consequently spam-proof email strikes me as a sensible balance.

One (open, centralized) system for global comms. Another (closed,
decentralized) for secure comms. Maybe even more than one "another", if
contexts require different audiences.

~~~
loup-vaillant
I'd rather not have most of my communications (even mundane ones) read by a
third party that also reads everything else. Gmail is bad enough, but this is
a _really_ Big Brother.

------
bilalhusain
I wish Google provided an API to lookup a sender's reputation so that even a
locally deployed spam filter could use the information.

~~~
JohnTHaller
It wouldn't be in Google's best interest to do so. First, it could be used by
spammers to lookup their own reputation for a given IP or domain before
deciding whether to move on. Second, it would enable competitors to use some
of Google's hard work in their products.

~~~
serf
a central authority for email reputation is one of the ideas put out by Mike
during his presentation at RIPE, not that his ideas are Googles'.

[https://ripe64.ripe.net/archives/video/25/](https://ripe64.ripe.net/archives/video/25/)

------
rwallace
> When we started gmails were about $25 per 1000 so we were able to quadruple
> the price. Going higher than that is hard because all big websites use phone
> verification to handle false positives and at these price levels it becomes
> profitable to just buy lots of SIM cards and burn phone numbers.

How does that work? Don't SIM cards cost more than 10 cents?

~~~
cjg
Not all the accounts need verification by phone.

------
orf
The Gmail spam filter is indeed impressive, but on several occasions I have
found 'real' emails being triggering it. Those times were just me browsing the
spam folder randomly and I hate to think what else it has swallowed.

~~~
raverbashing
Even worse, I've seen Google originating emails being flagged in GMail as
spam/fishing

(in mailing lists, and yes, I checked, it seemed to be a legitimate email, so
I let the sender know, but never heard back)

~~~
ams6110
I have had gmail flag a message I sent to myself as spam.

------
Oculus
Really interesting article until it gets into the Bitcoin talk. I feel like
his passion towards Bitcoins seeped a little too much into the article towards
the end.

------
awt
No mention of Bitmessage, which provides E2E crypto and anti-spam.

~~~
Canada
Bitmessage is hardly immune from spam. I've seen it there.

And cranking up the proof of work isn't going to do anything to prevent it.
The only thing that prevents Bitmessage from becoming a cesspool is its
obscurity.

~~~
awt
I would not call the random strings showing up in the general chan spam. I
highly doubt it is profitable for whoever sent it. Industrial scale spam seems
unlikely on Bitmessage.

~~~
Canada
I get it on some chans I run. I'm not talking about the annoying "test"
message either, I'm telling you there is already actual spam.

And the only reason there isn't tons of it is because Bitmessage doesn't have
the kind of user base that it's profitable to spam to.

It is much eaiser to spam Bitmessage on an industrial scale and profit than it
is to do so against Gmail's anti-spam systems today. If Bitmessage had a
hundred million users, then it would be profitable to spam there and it
absolutely would happen a lot. In my opinion spam would quickly become the
dominant form of traffic on the network, and the broadcast message feature
would go the way of VRFY and open relays in SMTP.

------
joelthelion
Can someone explain botguard? I'm not sure I get it.

~~~
chii
my understanding (which may be wrong - please i welcome all corrections) is
that an obfuscated piece of code that is somewhat randomized is generated on
the signup page. If you ran it, it produced a token, which is submitted as
part of the signup.

If you didn't obtain a fresh piece of this script, but instead either reused,
or tried to guess the token, then your signup still succeeds, but is marked as
bad. Then, in an undetermined amount of time, a wave of bans would occur on
all accounts that got marked as bad.

This prevents signups via scripts, but does so via making signup scripts
untrustworthy, and so no one would be willing to put money in for they cannot
be sure that it actually works.

~~~
joelthelion
But what prevents you from requesting another token from Google?

~~~
chii
I suppose nothing does, except for the resources required to do so (i.e., you
need to run your script in a browser, which means lots more overhead and
resources).

------
danso
Fascinating read, and as amazing as email is, the OP manages to still make me
realize how much I take it for granted:

> _So I think we need totally new approaches. The first idea people have is to
> make sending email cost money, but that sucks for several reasons; most
> obviously - free global communication is IMHO one of humanities greatest
> achievements, right up there with putting a man on the moon. Someone from
> rural China can send me a message within seconds, for free, and I can reply,
> for free! Think about that for a second._

~~~
nsns

        Someone from rural China can send me a message within seconds, 
        for free, and I can reply, for free!
    

Yeah, you both "only" need some machine that can go online, an internet
connection, electricity, the required technical knowledge, and to (implicitly)
agree to your personal data getting harvested... otherwise it's "free".

~~~
scrollaway
I am willing to give you £50 in cash for free as long as you come pick it up
at my place in Sweden.

This offer is only available for you alone and in person. Are you interested?
Because I'd really like to know how your pedantic definition of "free" works
out for you when it's obvious that things that require infrastructure (such as
online communications, or traveling to a different country)... require
infrastructure.

(TLDR: If you don't find it amazing that with a very small indirect investment
we can actually communicate with people anywhere in the world _for free_ , you
and I need to have a long chat about being spoiled.)

~~~
meepmorp
Well, you could mail the money. Using the national postal systems that exist
in both countries that have established means of transferring mail long
distances. Same as the farmer in rural China could send a message to the
Google engineer.

It costs money, yes, but if you're sending a one off message and it's not time
citical, it's not unreasonable to say that sending the message via email is
cheaper overall.

Edit: which isn't to say that communication via the Internet isn't really
cool, just that it's not actually free, nor would it necessarily be cheaper
than sending a message via other means, depending on the circumstances.

~~~
scrollaway
You missed the critical "within seconds" in the original message. Email is
near-instantaneous.

Are we seriously debating the merits of email over snail-mail on hacker news?
I hope this is merely people enjoying being thick and provocative, because the
alternative is that there's some massive bubble-blindness going on right now.

~~~
meepmorp
And I was considering nsns' point about how the costs associated with sending
email aren't nonexistent, and how, given a certain set of concerns and
constraints, might be higher than other means.

I also thought your £50 example was a bit silly. Of course infrastructure
costs money. There's means of communicating and delivering things like money
that use infrastructure that require a far lower initial investment for a
user, and that might be a better deal for that user, circumstances dependent.
And not all communications need to be near-instantaneous.

~~~
scrollaway
> the costs associated with sending email aren't nonexistent

> Of course infrastructure costs money.

You do realize you're.. well, you're not contradicting yourself, but on the
one hand you agree it's obvious and on the other hand you insist it must be
pointed out.

My example about money was just that. I _could_ use Western Union or a bank
transfer. Those things also have non-nonexistent (sic) costs. If you start
pointing out everywhere that "Oh but there's _this_ cost you didn't think
about!", you won't be done by next week. You know all those libraries that let
you check out books for zero cost? Reading those books requires education,
which in turn is no free (No matter how much you wish to contradict that
statement, the road you've taken requires you to admit to an unending set of
cost upon cost which you don't think about in your day to day life).

You live in a society which expects you to have access to certain things. In
the case you can't, there usually is infrastructure in place to help you out
at little to no cost.

So again, please, just take this in: You can communicate with people at the
other end of the globe. _For free_. This is not a legal forum and we don't
need asterisks everywhere.

