5 ms·

Practical problems in real name policies

42 points by edent 6y ago

teddyh 6y ago
Better argument against “Real Names”: https://geekfeminism.wikia.org/wiki/Who_is_harmed_by_a_%22Real_Names%22_policy%3F https://geekfeminism.wikia.org/wiki/Who_is_harmed_by_a_%22Re...
- myWindoonn 6y ago
  Even better, a technical argument: http://habitatchronicles.com/2017/05/what-are-capabilities/ http://habitatchronicles.com/2017/05/what-are-capabilities/
  - SAI_Peregrinus 6y ago
    Did you link the wrong essay? That one is about Capabilities and access control, not real name policies.
    - zrm 6y ago
      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.
      - 3np 6y ago
        Yup. Or, worded differently: you do not need authentication to achieve authorization. So many people conflate the two.
    - myWindoonn 6y ago
      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."
- Blikkentrekker 6y ago
  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.
  - asplake 6y ago
    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.
    - Blikkentrekker 6y ago
      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.
- manfredo 6y ago
  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-malicious-messages.html https://phys.org/news/2006-05-female-name-chat-users-malicio...
  - buisi 6y ago
    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.
divbzero 6y ago
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.
- sathackr 6y ago
  Until they get hacked
- fuzxi 6y ago
  Keeping (arguably, even temporarily collecting) that data is inherently a violation of the user's privacy.
rvba 6y ago
Dont use the free framework. Fork, or make your own framework. But this costs money.
- tedjdziuba 6y ago
  In the wake of Parler, etc., "If you don't like it, build your own X" is no longer a valid argument.
rtpg 6y ago
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
- ofrzeta 6y ago
  The article mentions this solution. It might be pretty secure but hard to automate and currently requires a human on the other side.
KirillPanov 6y ago
Google thinks to themselves: if only we'd had this policy 12 years ago, we could have stopped that evil Satoshi Nakamoto guy!
ofrzeta 6y ago
"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 https://en.wikipedia.org/wiki/Identity_document
ve55 6y ago
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.
tomjen3 6y ago
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.
rstuart4133 6y ago
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-framework-for-shifting.html https://security.googleblog.com/2021/02/know-prevent-fix-fra... [1] https://wiki.debian.org/ReproducibleBuilds https://wiki.debian.org/ReproducibleBuilds [2] https://f-droid.org/en/docs/Reproducible_Builds/ https://f-droid.org/en/docs/Reproducible_Builds/ [3] https://metadata.ftp-master.debian.org/changelogs//main/c/chromium/chromium_87.0.4280.141-0.1~deb10u1_copyright https://metadata.ftp-master.debian.org/changelogs//main/c/ch...
throwaway744678 6y ago
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.

42 points by edent 6y ago

Better argument against “Real Names”: https://geekfeminism.wikia.org/wiki/Who_is_harmed_by_a_%22Real_Names%22_policy%3F https://geekfeminism.wikia.org/wiki/Who_is_harmed_by_a_%22Re...

myWindoonn 6y ago
Even better, a technical argument: http://habitatchronicles.com/2017/05/what-are-capabilities/ http://habitatchronicles.com/2017/05/what-are-capabilities/
- SAI_Peregrinus 6y ago
  Did you link the wrong essay? That one is about Capabilities and access control, not real name policies.
  - zrm 6y ago
    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.
    - 3np 6y ago
      Yup. Or, worded differently: you do not need authentication to achieve authorization. So many people conflate the two.
  - myWindoonn 6y ago
    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."
Blikkentrekker 6y ago
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.
- asplake 6y ago
  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.
  - Blikkentrekker 6y ago
    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.
manfredo 6y ago
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-malicious-messages.html https://phys.org/news/2006-05-female-name-chat-users-malicio...
- buisi 6y ago
  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.

divbzero 6y ago

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.

sathackr 6y ago
Until they get hacked
fuzxi 6y ago
Keeping (arguably, even temporarily collecting) that data is inherently a violation of the user's privacy.

rvba 6y ago

Dont use the free framework. Fork, or make your own framework. But this costs money.

tedjdziuba 6y ago
In the wake of Parler, etc., "If you don't like it, build your own X" is no longer a valid argument.

rtpg 6y ago

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

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

KirillPanov 6y ago

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

ofrzeta 6y ago

"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 https://en.wikipedia.org/wiki/Identity_document

ve55 6y ago

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.

tomjen3 6y ago

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.

rstuart4133 6y ago

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-framework-for-shifting.html https://security.googleblog.com/2021/02/know-prevent-fix-fra... [1] https://wiki.debian.org/ReproducibleBuilds https://wiki.debian.org/ReproducibleBuilds [2] https://f-droid.org/en/docs/Reproducible_Builds/ https://f-droid.org/en/docs/Reproducible_Builds/ [3] https://metadata.ftp-master.debian.org/changelogs//main/c/chromium/chromium_87.0.4280.141-0.1~deb10u1_copyright https://metadata.ftp-master.debian.org/changelogs//main/c/ch...

throwaway744678 6y ago

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.