Hacker News Reader

> you can make a one-time donation of $5 to a charity of your choice ...

The Alcoholics Anonymous San Francisco website had to implement CAPTCHAs on their website because scammers were making one-time donations to make sure their stolen credit cards were still valid. Every morning we had to invalidate a dozen obviously-fake donations.

Definitely an issue. I don't really like the idea of long-term Patreon-eseque relationship between the individual user and the attestor/issuer site, but it could be done. The charitable giving is more of a means-to-and-end than a goal, functioning as a kind of "observed spending" which is harder to fake than, say, buying something from yourself on ebay.

If tokens had to mature for X days before being used that could deter laundering pretty handily, but stopping "tests" of cards would require hiding payment errors from the user for a certain period... which would not be a great experience.

Yup. Charitable donations are a way to spend money without it pointing to you and thus a common test for a stolen card.

what happens if you don't invalidate them?

It's an unauthorised payment so I guess at that point the police get involved.

You'll get a chargeback when the owner sees it

And if you get too many chargebacks your account gets closed

Every SaaS platform with a reasonably cheap offering deals with these. I work for a recognizable SaaS and there are checks that flag both the accounts and reports the credit cards that are used after a fairly low threshold of "add payment method attempts". High levels of fraud usage hurt your reputation with payment processors and that's bad for business.

It doesn't stop the truly determined ones I'm sure, but it does mean that it adds complexity. You don't need to be impossible to test cards on, you just need to be harder to use than someone else (like a lower resource charity). We've even debated "fake accepting" some payment methods after we're confident it's someone trying to find working credit card numbers to add some false positives into the mix.

It seems to me that ideas like this are unworkable due to income inequality.

$5 isn't much for a wealthy westerner. It's a reasonable amount for an unemployed westerner. It's 12% of their weekly budget for someone earning median wage ($160/month) in Vietnam. But if you put in place regional pricing, it'll be cheap enough that spammers will just operate out of low income countries and buy thousands of cheap accounts.

> It seems to me that ideas like this are unworkable due to income inequality.

There's no reason you can't have an attestation entity that's based on volunteer hours, provided you can convince sites-in-general that your proof-units are good.

The core theme isn't about cash, but that:that:

1. There are kinds of activity someone can do which demonstrates some kind of distinct actual expenditure of time or effort (not self-dealing.)

2. A trusted agent could attest to that activity.

3. Requiring (proof of) activity gives you an decent way to ward off the majority of bots/spam in a relatively simple way that doesn't become a complex privacy nightmare.

It's a similar outcome to sending CPU-bound challenges to a client, except without the deliberate-waste and without a strong bias towards people who can afford their own fast computer.

The issue is that it another system that puts the "blame" and/or work people instead of dealing with the root cause. So in that case nothing changes.

Because I wonder how are people going to do volunteering hours, get it recognized trough red tape/bureaucracy if they're already struggling to survive.

Is still completely asymmetric in that the poorer you are, the harder you have to work to now simply access the same resources online as everyone else.

And the poor get poorer.

Well not in places like Vietnam (7% gdp growth/year) or a lot of the less developed world.

As a poor disabled citizen who also cares about privacy and freedom, I haven't heard a single idea for attestation that doesn't scare the shit out of me. But then, I'm a poor, disabled citizen, so my opinion doesn't hold much weight.

Given that being summarily blocked from participation by paranoid site-operators is already a existing scary problem, what kind of fix would you suggest that adds the least additional scariness?

Personally, I am particularly concerned with avoiding the scariness of a government agency that inherently knows all the websites all people are using.

I would at least hope we'd consider whether more 'fixes' are actually worth it. It seems to me that 40 years of 'fixes' haven't done much to combat spam and the like, and has instead just made it harder for people like me to access and browse the Internet.

I'm trying to discern a positive proposal from that, and the best I can extract seems to be "stop fighting and just let the bad people operate unopposed", which doesn't seem workable to me.

Security/anti-spam is probably not biggest accessibility factor in the last 40 years of change anyway: It's easier to make an alternate CAPTCHA route than to convince management a phone-app is unnecessary, or to correctly annotate everything with aria/alt-text properties in all the languages.

> I'm trying to discern a positive proposal from that, and the best I can extract seems to be "stop fighting and just let the bad people operate unopposed."

That's not a very generous reading, I think. I am suggesting that the "bad people" seem to be doing fine, so at a certain point we might want to ask ourselves how far we take this "fight" in terms of sacrificing accessibility and privacy (to only name 2 concerns) to stop some percentage of bad actors.

As someone who has been hurt by these efforts over the past 20+ years, and who has yet to hear a proposal for next steps that doesn't greatly worry me, I'm not going to be in favor of propositions just because "well we have to do something"

> It may also be blaming the wrong factors and growing pains. It's easier to make an alternate CAPTCHA route than to convince management to not rely on a phone app or to correctly annotate everything with aria-properties in all the languages.

We've had 20 years to make CAPTCHAs more accessible, yet they've gotten worse. Not to mention their efficacy being in question, hence the discussion about next steps (i.e., attestation)

Have you checked out the L402[0] protocol?

It's basically using the HTTP 402: Payment Required status code and serving up a Lightning Network payment invoice.

Edit to add: it basically solves all of the caveat issues you identified.

[0]: https://l402.org/

>Possible social fix: Put in a fake token, if the site "accepts" then you know it's misbehaving.

IIUC the tokens would need to be cheaply verifiable by anyone as authentically issued, so a fake token would never be accepted (or if it somehow was, it would only tell you that the acceptor is fantastically lazy/incompetent).

I think that that verifiability, plus a guarantee that tokens will not be spent twice, plus visibility of all transactions, suffice: Then anyone can check the public ledger x minutes after they spent their and verify that the acceptor sent it straight to the burn address after receiving it. IOW, blockchain suffices. OTOH, it would be nice not to have to need the public ledger.

I think blockchain is (as usual) the wrong tool for the job here, since it would dramatically increase code/bugs/complexity/onboarding-cost while also introducing new privacy risks. After all, we're already trusting that a given attestor/issuer isn't just handing out tokens willy-nilly.

By comparison, here's a simpler "single HTTP call" approach, where a site like HN makes a POST to the issuer's API, which would semantically be like: "Hey, here is a potential token T and a big random confirmation number C. If T is valid, burn it and record C as the cause. Otherwise change nothing. Finally tell me whether-or-not that same T was burned in the last 7 days along with the same C that I gave."

The benefits of this approach are:

1. The issuer just has to maintain a list of surviving tokens and a smaller short-lived list of recent (T,C) burning activity, and use easy standard DB transactions to stop conflicts or double-spending.

2. All the social-media site has to do is create a random number C for burning a given T, and temporarily remember the pair until it gets a yes-or-no answer.

3. A malicious social-media site cannot separate testing the token from spending it on a legitimate site, which deters a business model of harvest-and-resale. However it could spend it immediately for its own purposes, which is worth further discussion.

4. The idempotent API call resists connection hiccups and works for really basic retry logic, avoiding "wasted" tokens.

5. The issuer doesn't know how or where a given token is being used, beyond what it can infer from the POST request source IP. It certainly doesn't know which social-media account it just verified, unless the two sites collude or the social-media site is stupid and doesn't use random C values.

This is going in the right direction, but you identified the acceptor double-spend problem.

What about if, instead of the spender handing the token directly to the acceptor, the spender instead first makes an HTTP "I want to spend token 456" request to the issuer, which replies with a "receipt" that the spender then sends to the acceptor, which in turn sends a "If the token associated with this receipt is not yet burnt, burn it, record C next to it and report OK, otherwise if it was already recently burnt using C also report OK (for idempotence), otherwise (if it was already burnt with some other C') report FAIL" request to the issuer. The receipt not being valid as a spendable token cuts out the double-spend issue, at the cost of one extra HTTP request for the spender.

I think that's the right direction but it seems incomplete: The new indirect-thingamabob can still be retargeted to a different site. (Ex: I sign up to AcmeWidgetForum which falsely claims it needs to confirm I'm a real person, and AcmeWidgetForum secretly sends the data onwards to verify an unrelated spam-account on Slashdot.)

[Edit: This has a flaw, but I already typed it out and I think it makes an incremental advancement.] How about:

1. User earns Token (no change from before)

2. User visits the Site and begins the "offer proof" process, the Site generates and records two random numbers/UUIDs for the process. The first is the previously-discussed Confirmation Code, which is used for idempotency and is not shared with the User. The second is a Site Handshake code which the user must copy down.

3. User goes to Attestor site and plugs in two pieces of information, the Token and the Site Handshake code. This returns a Burning code (valid for X hours) which the user carries back to the Site.

4. User passes the Burn Trigger to the Site, and it calls the previously-discussed API with both the Confirmation Code and the Site Handshake. If the Site Handshake does not match what's on file for that Burn Trigger, the attempt immediately fails with a security error.

____

No, wait, that doesn't really work. Although it protects against EvilForum later leveraging the data into a spam account on Slashdot, it fails when EvilForum has pre-emptively started a spam account on Slashdot and is reusing Slashdot's chosen Site Handshake as its own.

>AcmeWidgetForum secretly sends the data onwards

It can't do this, because the only "data" it has from the spender is a receipt. A receipt is by design not a spendable token itself; this is trivial to make evident to any party (e.g., tokens are all 100 characters, receipts are all 50).

> It can't do this, because the only "data" it has from the spender is a receipt.

It can because nothing in that artifact binds it to the one and only one site that the user expects. The only thing keeping it from being used elsewhere is if everybody keeps it secret, and the malicious not-really-spending site simply won't obey that rule.

In scenario form:

1. User goes to Attestor, inputs a Token for an output of a Burn Trigger. (I object to "receipt" because that suggests a finalized transaction, and nothing has really happened yet.)

2. Users submits that Burn Trigger to malicious AcmeWidgetForum, which (fraudulently) reports a successful burning and puts a "Verified" badge on the account.

3. In the background, AcmeWidgetForum acts like a different User and submits the Burn Trigger to InnocentSite, which sees no issue and burns it to create a new "verified" account.

Even if the User can somehow audit "which site actually claimed responsibility for burning my Token" and sees that "InnocentSite" shows up instead, most won't check, and even knowing that AcmeWidgetForum was evil won't do much to stop the site from harvesting more unwitting Users.

Ah, you're right. The receipt is "spendable" by the acceptor, since it contains nothing identifying the original spender.

What If: The Site chooses and exposes a public key (a simple one, like SSH, unrelated to TLS/DNS/certs) which the User carries over to create the Burn Trigger.

The Attestor generates a random secret associated with each Burn Trigger, and encrypt it with the supplied public key to create a non-secret Challenge. (Which is carried back by the User or else can be looked up by another API call.)

To burn/verify the Token, the Site would need to use its private key to reverse the process, turning the Challenge back into the secret. It would they supply the secret to the burn/verify API call. The earlier Confirmation Code would no longer be needed.

Thus AcmeWidgetForum would be the only site capable of using that Burn Trigger. (Unless they granted that ability to another site by sharing the same keypair, or stole a victim-site's keypair.)

... I know this is reinventing wheels, but I'm gonna choose to believe that there's some minor merit to it.

> Lately I've been pondering how one might create a "probably a human"/skin-in-the-game system.

This has the same energy as the "we need benchmarks for LLMs" startups. Like sure it's obvious and you can imagine really complex cathedrals about it. But nobody wants that. They "just" want Apple and Google to provide access to the same APIs their apps and backends use, associating authentic phone activity with user accounts. You already get most of the way there by supporting iCloud login, which should illuminate to you what you are really asking for is to play outside of Apple's ecosystem, a totally different ask.

There is the much slagged off but maybe effective Worldcoin.

Nothing like this or Worldcoin ever will be useful in any capacity for qualifying non-fraudsters, because fraudsters will have an infinite supply from people they tricked while non-fraudsters will only have what they've personally been given. So it'll basically do the opposite of what you want.

Worldcoin IDs are one per person and I've not heard of people tricked to give them away. Some have been bought for cash but there's a limit to how many of those will be available. In practice they are no good for verifying humans on blogs and the like though because only about 0.0003% of humans have one. But maybe something a bit like that that's easier to get?

> I've not heard of people tricked to give them away.

People can be tricked to give anything away.

> In practice they are no good for verifying humans on blogs and the like though because only about 0.0003% of humans have one.

Even if every human had one it'd still be useless.