Comment by mockery | Hacker News Reader

Comment by mockery | Hacker News Reader

A big downside is that it seems like this would make spam harder to block. (Intuitive claim, I'm not familiar with the technical details.) It also seems like it has the disadvantage of chicken-and-egg adoption before it's a useful service.

So here's a possible solution to both problems at once: I've always liked the idea of disincentivizing spam by charging a micropayment per email. So include a tiny bitcoin payment encoded into each layer of the doll to reward the intermediary, and you'll simultaneously provide an incentive for participation in the network (payment for participating) while simultaneously discouraging frivolous emails (since you now have to pay per spam message.) Obviously you'd make the charge small enough to not matter to most people for daily use (<$0.01) but I assume any nonzero price would hurt spammers badly.

You'd have to prevent intermediaries from decoding all the layers and taking the full payment, but presumably the Dark Mail folks have a solution for this already. Otherwise otherwise anyone in the middle could decrypt all the layers and read the contents of the email, and Dark Mail wouldn't work at all.

Or maybe I'm missing something. (Decent chance of that, since all I'm going on is a Time article and I'm not a security guru.)

I'm at Defcon and was able to catch this talk. Someone asked this exact question after the talk—how can you deal with spam if you you can't scan encrypted messages for trigger words on the server. I'll try to explain what I remember: Ladar mentioned that DIME heavily encourages the use of DNSSEC, so you can verify the sender is definitely coming from the domain they're representing which should reduce spam. He also said everything we're currently doing on the server-side like keyword scanning can be done on the client side. Pretty sure he also acknowledged that it's a nontrivial problem and that the team is still investigating.

"everything we're currently doing on the server-side like keyword scanning can be done on the client side"

See the problem there?

I think they mean scanning on the receiver's client, not the sender's. There's no security problem there - a spammer with a rogue client will just send spam that's blocked by each client, and if you don't want to get spam, upgrade your client.

I am still doubtful that this will work - spam filtering a la GMail requires a good deal of aggregated data, being able to piece together related e-mails from many people's inboxes. It's effectively the reverse problem as NSA surveillance: instead of piecing together patterns in messages to highlight them, you piece together the patterns to block them. And so anything that blocks the NSA will make the spam filters we've come to depend upon non-functional. But that's because of lack of data, not because of client insecurity.

As nostrademons said, I meant on the receiving client, not the sender. Other than it being a potentially difficult nut to crack I don't really see any technical reason it'd be infeasible. Is that what you meant?

I've been having a rather frustrating conversation with someone who's convinced that the present regime of port-25 blocking DUL lists, etc., are all part of some vast conspiracy to keep people from talking to one another. Truth is, they grew out of 1) an exceptionally open email protocol that 2) grew up on a very much smaller network ( dozens to hundreds, eventually a few thousand hosts), in which 3) norms and fairly tight interpersonal relationships kept nefarious behavior at bay.

Among other things, I've been unable to convince him that, in fact, I would like to see a secure and useful system designed with end-to-end crypto and other factors associated with it.

Among positives, a secure communications channel would put a lot more onus on message originators in preparing their content -- if mail is encrypted to the recipient, then the recipient needs to be identified, encryption executed, and delivery made. This also effectively stops the process of providing a single message intended to large numbers of recipients. It's fairly likely that a great deal of spam would not be encrypted.

So long as the receiving system knows the originating system, then trust metrics can come into play. A "policy of first refusal" in which the first delivery attempt from any previously unknown system is enforced, and whitelisting of known good / valuable peers, would help somewhat.

I really don't see micropayments as workable, though some work-factor mechanism could well operate.

Perhaps instead of a bitcoin payment, a better solution would be to solve PoW such as what is implemented in Bitmessage.

https://bitmessage.org/wiki/Proof_of_work

This will just put a lower-bound on the market for spam emails, at the cost of making legitimate email more expensive (especially at scale). It doesn't matter if it's a micropayment through bitcoin or hashcash. The only real way to solve the spam problem is a web-of-trust where spam is disincentivized because it harms your reputation in the system. That is kind-of the situation we have now, except encryption isn't baked into email yet (if it will ever be).

Why is it a problem if legitimate email costs $0.01? If it's not even worth that to you, perhaps it's not so "legitimate" after all. (Organization internal mail doesn't need to pay itself)

The main casualty would be mailing lists, which would likely have to move to forums or subscriptions. It might be technically possible to also say "I accept mail from X without demanding payment" but that's not necessary to make a pay-for email market work, and have much less spam.

$0.01 is just arbitrary. Some people might find that too expensive, and some spammers might find it cheap enough to profit from anyway. The problem is that the threshold for affordability is in NO way attached to the profit margins of spammers, let alone the true value of the email.

And your last point is really just a specialized form of a web of trust anyway.

The usual objection is mailing lists.

A large list may have hundreds, thousands, and potentially millions of recipients (though I'm not aware of any such at present). The Debian Project provides email subscription stats, with its biggest list being debian-security-announce, at 34,234 subscribers. That's a cost of $342.34 per message transmitted.

https://lists.debian.org/stats/

It would also be a large overhead to any system with a large userbase that relied on email based notifications. Facebook's financials put its per-user revenues at around $8-$10/year, which would be completely eaten up at the rate of only 3 emails per user per day.

The thing about email is that it's really, really cheap. That's the benefit and the detriment to the system. What you want to do is make the costs asymmetric. Cheap for legitimate and white-hat users, really expensive for the black hats.

Could you combine it with a whitelist system? Email from people on your personal whitelist always makes it through for free while email from strangers always costs $0.01. Anyone signing up for debian's mailing list would just have to click a button to add it to their whitelist, same for anyone wanting to receive email from Facebook.

My read: not really. Micropayments are too fussy in a whole lot of ways. Though of course, if someone wants to prove me wrong they're free to try it.

The solution I'd like to see isn't payments but bonds. E.g., on every email I send I can offer $5. If the recipient thinks the email isn't worthwhile, they can claim the $5 for themselves. If the balance for my bond account doesn't have enough money to cover the bond, that's a great signal that the email is spam.

Legitimate email would still end up being free, but spammers would have a much harder time getting mail through. And large mailing lists would be forced to be pretty responsible. Or to offer very small amounts per mail, which would be a great signal to file something under "promotions".

Why wouldn't I claim a bond on every e-mail I received from e.g. google and twitter?

Why not, indeed. The question is whether that would be a bad thing. It could serve as a great signal to those companies that they shouldn't send you any email.

What about, say emails from police or courts, who legally required to contact you, and you don't want to receive it?

What about it? If you claimed the bonds, they'd just require you to pay them back, possibly with interest.

Then they would stop sending you email. And, presumably, close your accounts.

My guess is that high-reputation places wouldn't feel obliged to offer large bonds, or wouldn't offer any bonds on communications for established relationships. They wouldn't have to, because their mail gets through. The bonds would be much more useful for senders with deliverability or attention issues. That is, individuals, small companies, and new companies. It could also be great for marketing. If somebody's willing to bet $20 that their email is interesting enough to me that I won't collect the bond, I'd be interested to read it.

I suspect make more sense to build in a hashcash check into the protocol. It would be easier to implement and wouldn't tie the protocol to the Bitcoin blockchain.

By adopting micropayment systems, even as minuscule as those, you're cutting off email as a form of communication to significant demographics of people. On top of that, it's Bitcoin, so the effects are even more profound.

I don't want email to be taxed any more than I want IRC to be taxed.

Not necessarily. You could just use a service that is secure and handles the payment aspect for you. In such a scenario the top email providers would send email between themselves using the same pool of bitcoin. It's essentially a zero-sum transaction for them at scale. Outside entities that want their message heard would have to pay for it (mailing lists and the like) as a disincentive to send unwanted email.

Are we talking about people in the developing world? Because otherwise yes you can afford to pay 0.01 usd pr email. It is still significantly cheaper than mailing a letter and, likely, a lower cost than the time it cost you to write that email - unless of course you run a newsletter, which you could then move to a blog, where such things belong anyway.

Reply on news.ycombinator.com