Practical problems in real name policies | Hacker News Reader

Practical problems in real name policies

shkspr.mobi

42 pointsedent25 comments

Open articleView on HN

Better argument against “Real Names”:

https://geekfeminism.wikia.org/wiki/Who_is_harmed_by_a_%22Re...

Even better, a technical argument: http://habitatchronicles.com/2017/05/what-are-capabilities/

Did you link the wrong essay? That one is about Capabilities and access control, not real name policies.

I think I get it.

The idea is that you assign capabilities based on whatever authentication mechanism. Access to read email sent to this email address, access to withdraw money from this bank account, etc.

The way a lot of people think about this is that a set of permissions is associated with a person with a Real Name and then a person with a Real Name is associated with an account or some other context.

But the middle step is irrelevant from a technical perspective. Your name isn't a secret and can't reasonably be used for any kind of authentication. It's effectively an alphabetic account number.

Using the same Name for all of your accounts is only useful if you want to give companies the ability to correlate them all, which is often the opposite of what you want.

If you take it out you're left with a set of capabilities associated with an authentication context, which works just as well from a technical perspective and doesn't have that problem.

Yup. Or, worded differently: you do not need authentication to achieve authorization. So many people conflate the two.

As sibling says, they are deeply linked.

"The capability paradigm is about access control. When a system, such as an OS or a website, is presented with a request for a service it provides, it needs to decide if it should actually do what the requestor is asking for. The way it decides is what we’re talking about when we talk about access control. If you’re like most people, the first thing you’re likely to think of is to ask the requestor “who are you?” The fundamental insight of the capabilities paradigm is to recognize that this question is the first step on the road to perdition."

"That’s highly counterintuitive to most people, hence the related controversy."

All the identity politics aside; I find a simpler argument tob be “One can easily triangulate my real life identity, and interact with my corporal body from finding my real name, and I do not wish for that..”

I had a discussion on H.N. a while back where I found that the G.D.P.R., in fact, prohibits the collection of “biometric data” but not real name and address, which I found rather odd to say the least.

If I had to choose between my real name and address, or my retinal or fingerprint patterns ending up on H.N., I would certainly choose the latter, and I think I'm not alone in that. — it is far easier to triangulate someone's corporal body based on the former than the latter.

Odd? Not every business is a social media platform. Businesses shouldn’t keep more data than they need (including/especially biometrics) but there are plenty of legitimate reasons why many businesses will absolutely need your name, address etc.

There are reasons why they need it, because the same politicians that claim to be so concerned about privacy do not create the frameworks to obviate those reasons.

It would be trivial to implement a scheme where I might requæst at the postal service a randomly generated code that maps to my address and name. The postal service is the only one that actually needs my address, and they will ensure that every package onto which that sterile code is printed, will arrive at my doorstep.

Thus, the sender need not know my name and address, and can send me mail regardless but can never find out where I physically live.

If those politicians truly care as much about privacy as they say they do, such a scheme would be implemented decades ago, for it is not expensive nor technologically difficult to do so at all.

That they are not actively searching for mechanisms that allow businesses to function without people having to surrender their location of residence, many of which being rather simple to solve, makes me think they do not care as much as they claim they do. Or rather, as is common, they only care when it concern new and scary technology, but addresses are old, and therefore not scary. When a man utter concern about various dangers, what he is most afraid of, is often simply change.

When ordering online, you don't actually which carrier will be used: all carriers would then need to have access to the database of random codes -> physical addresses... Not much of an improvement, and lots of room for failed deliveries! Better use a PO box, or a parcel drop-off point.

Note that the actual reason businesses legally need a name and address is for invoicing, though.

> When ordering online, you don't actually which carrier will be used: all carriers would then need to have access to the database of random codes -> physical addresses... Not much of an improvement, and lots of room for failed deliveries! Better use a PO box, or a parcel drop-off point.

There is a great deal of improvement if only registered carriers have access opposed to every single party whom one might receive a package from, including simple private citizens.

That I need to tell a man where he might physically locate me, ere he can send me a package, is a problem that need not exist.

> Note that the actual reason businesses legally need a name and address is for invoicing, though.

This too could be solved in many ways.

Governments can easily devise systems where payments can happen without leaking this information, and that the information can only be forced to be surrendered in the case the company has a complaint of non-payment.

I don't think it actually makes that good of an argument against real names. For instance it shares a link to a study that found accounts with feminine names got more malicious messages in IRC rooms [1]. However, the people sending said messages didn't have to use their real name. That doesn't mean a real-names policy would make things worse. It could be that people, when forced to use their real name, are less likely to send harassing messages.

I certainly think there's places for pseudonymous or anonymous discussion. That link talks about how people may face social repercussions for deviant interests: sure I wouldn't expect a real names on e621 and the like. At the same time, real names provide a level of accountability that's beneficial in a lot of contexts.

1. https://phys.org/news/2006-05-female-name-chat-users-malicio...

Contextual accountability is hard.

Real names / pseudonyms tend to be sweeping across a service, particularly large goliaths like Facebook where you could do things like political activism in a group. You either get more exposure than you're comfortable with, or more privacy than other people are comfortable with.

Real name policies also tend to be cultural where usage of real names tends to encourage more usage of real names, even when it might make sense not to use a real name.

Why is what you are registered with in some database in some government database more of a real name than what your friends call you? If I know you under one name and your kids calls you something else, which name is the real one?

People have different roles and behaviors in different situations including being called different names.

This may be inconvenient for states and other large organisations.

For the “affirm the person is the person in the document” problem, I’ve had to use a lot of KYC recently where the solution is to turn on your webcam and hold your doc in various positions while moving your face etc

I imagine it’s possible to get MITM’d in this process (for anything really) but otherwise it seems very hard to fake

The article mentions this solution. It might be pretty secure but hard to automate and currently requires a human on the other side.

As captchas continue to have trouble staying ahead of machine learning while companies/governments realize (and fully invest in) the absurdly high value/power that controlling social media gives them, I think we'll be entering some pretty rough times with respect to Internet identity and anonymity (as if it isn't already a mess).

One of the slightly nicer solutions we may converge on is to verify identities at various layer(s), and then disassociate them with the user afterwards, preferably using many of the tools that modern cryptography gives us to achieve levels of verification and pseudonymity/anonymity at once, depending on what is required. This is nowhere near perfect, but I think it beats having to give your true identity to anyone/everyone to use the Internet.

This is actually extensively use in China, eg. for applying for an ICP licence: upload a copy of your passport (with a lot of extra documents), then you have to record yourself on video, making the moves prompted by an app (close your eyes, open your mouth, tilt your head right/left etc.). I would guess that a lot of this is automated, perhaps with a human check at the end of the process (?). But technical solutions do exist.

Not much new here, the article mostly takes us over well trodden ground. But the second line was an eye opener:

> This time, it is Google’s turn. [0]

I guess my reading of it must be tainted by reading this "real names'' critique first, but ye gods, it seems these people telling Open Source how it must improve its practices have no idea that Open Source has mostly solved the problems it seeks to address. The problem isn't knowing what has to happen. The problem is the people/companies using the output of Open Source simply don't care or don't contribute.

Some illustrations of their suggestions. On the anonymity point first, Google's blog post says:

> Goal: For Critical Software, Owners and Maintainers Cannot be Anonymous. Attackers like to have anonymity. Attackers like to have anonymity. There have been past supply-chain attacks where attackers capitalized on anonymity and worked their way through package communities to become maintainers

Firstly, Debian does insist its developers provide government ID. I'm tempted to start ranting in strong agreeance with the article about how weak that is, but my point is - it's being done. In fact most things they list are done by Debian, and if not by Debian then by other projects. For example:

> Goal: Authentication for Participants in Critical Software

All contributions by a Debian developer must be signed with their gpg public key, minimum length 4096 bits. Or take this one:

> Goal: Changes to Critical Software Require Approval by Two Independent Parties

Debian does this to some extent but the kernel is exemplary in this regard. They insist every patch is signed off. It's no accident git provides a cryptographically secure audit trail of the origin of every line of code.

> Goal: A Federated Model for Identities

Debian has a public ldap database. Other projects use email identities, and open source has public gpg key servers for decades.

> Goal: Trust the Build Process ... Ken Thompson's Turing Award lecture famously demonstrated in 1984 that authentic source code alone is not enough, and recent events have shown this attack is a real threat.

Debian has literally pioneered the solution to this, reproducible builds. They acknowledge reproducible builds (but not Debian), go on to say "but are harder to achieve due to ephemeral data (such as timestamps) ending up in the release artefact". Apparently not so hard, because Debian has got around 80% of its archive to build reproducibly and open sourced how to do it. The open source project F-Droid is doing the same work for Google's own product (Android), which is also unacknowledged. [1] [2]

> Goal: Fix the Widely Used Versions ... It’s also important to fix the vulnerability in the older versions,

And that is, with the exception of a few packages that have now become so complex even backporting simple fixes is beyond a team of Debian Developers, is exactly what Debian does. To wit: for the 60,000 packages in it's released versions of software, Debian backports security fixes to the old version rather than moving to the new version. Yes, it’s an immense effort, but it is the right way to do it so it’s what is done.

I could go on addressing the things they raise, but I hope the point is made. Open source knows how to do this stuff. That is not the problem. The last point above illustrates the real problem. Debian is regularly criticised here on HN for being too slow, too conservative. That's a direct consequence of the "backport only" policy, of course. It seems a _lot_ of people aren't prepared to put up with the pain it causes, or perhaps it is they don’t understand how the advantages it brings justifies the pain for many.

The users probably aren’t aware of it, but it causes even more pain for Debian itself. Part of it arises from Debian’s absolute insistence audit trail it insists on: binary in archive -> "the source the human wrote" -> licence -> copyright owner. The original motivation for that was ensuring Debian is truly open source, how it meshes with the security via accountability aspects the Google blog is championing is obvious. Upstream projects that mix sources with lots of licences can make merely writing that trail down for every source file an epic task, eg: [3]

But it’s not just size, some developers go further. They include “non-source forms” of unversioned software in their source, eg a minimised version of some ancient version jquery - or worse, some version they’ve tweak (hack it) a little. The Debian packager then has to go on a whumpus hunt trying to figure out what version, and if they modified it, and if the version in Debian suffice. If it doesn't they can't add another version of jquery to Debian, because doing that for every package would lead to an unmanageable explosion in the backporting work every jquery vulnerability would cause. It's not just npm, if a Python developer says "to use my package, do a pip install" and the package has a pinned dependency like =x.y.z the people who package the software, ie the open source people who have already solved the problems the Google blog is telling us how to solve, get a more grey hairs.

But the thing that has literally forced distro packagers to literally give up on backporting fixes is packages that have grown too complex for a part time person to understand. Firefox is one example. But Mozilla is also a fine upstanding example of how to mitigate the problem: they publish Firefox ESR, which is, ta-da, a version of Firefox _they_ backport fixes to. We love you, Mozilla. You understand how security and reliability arise from change control.

Other examples of huge complex packages Debian can't maintain the way the blog suggests are Kubernetes, and Chromium. They are packages produced by Google, of course. Unlike Mozilla, Google offers no help and makes no concessions to others for maintaining the stability and security of their packages.

And here we have a blog article from Google, telling open source how to make its ecosystems more secure. The irony would be delicious, if it wasn’t so painful.

[0] https://security.googleblog.com/2021/02/know-prevent-fix-fra...

[1] https://wiki.debian.org/ReproducibleBuilds

[2] https://f-droid.org/en/docs/Reproducible_Builds/

[3] https://metadata.ftp-master.debian.org/changelogs//main/c/ch...

Could there be a “KYC” approach where companies are required to verify their users’ identities but also keep them private? This could cut down on fake accounts while protecting the privacy of users who wish to remain anonymous.

Until they get hacked

Keeping (arguably, even temporarily collecting) that data is inherently a violation of the user's privacy.

"There are a couple of hundred different passports issued by a variety of countries and organisations."

Judging from the linked Wikipedia page there are even more. Because at least in the case of Germany what you see is a "Reisepass" that is commonly used for traveling but when you are to prove your identity typically you use your "Personalausweis" which is a small plastic card like a credit card. As far as I know many countries have similar identity cards.

https://en.wikipedia.org/wiki/Identity_document

Dont use the free framework. Fork, or make your own framework.

But this costs money.

Google thinks to themselves: if only we'd had this policy 12 years ago, we could have stopped that evil Satoshi Nakamoto guy!

Reply on news.ycombinator.com