Hacker Newsnew | past | comments | ask | show | jobs | submit | Mindwipe's commentslogin

The fact this letter takes aim at something the paper doesn't say is pretty damning. The paper alledges that a series of high entropy identifying metadata about the users system is passed to a very large amount of third parties, including the site being visited, and that has potential to link the real identity of the user to the site they are verifying with.

Yoti's letter then gets angry that "face" data is not passed to third parties. That is not what is alleged.

Not to mention the repeated veiled threats about how they "could" sue academics investigating their systems.

It is absolutely incredibly sus as a letter.


Hey Mindwipe, 100% agree the paper doesn't say that face data is passed to third parties, but then the techexplore article from those universities DOES. That article is the one that this whole thread started on, strangely you are ignoring that.

What's pretty damning is that you make it appear like you know the paper but you claim things that the paper doesn't claim. In the exact same style of those who wrote the article, interesting.

You claim that "The paper alledges that a series of high entropy identifying metadata about the users system is passed to a very large amount of third parties"

That is FALSE, the paper doesn't say that, it actually says that the high entropy metadata is sent to Yoti servers, actually encrypted with client side keys on top of TLS which makes it impossible for any third party to even read it.

Reporting here extract from the paper: --- Once the user’s face is properly aligned, the SCM collects and processes a significant amount of data that is sent to Yoti’s servers. In particular, it collects the photo captured from the user’s camera and telemetry, including significant high-entropy browser and device metadata (see Table 2). It also includes data about the camera’s properties, the FPS of the camera stream, and metrics about download and processing times.

The SCM uses some cryptography, which we briefly describe here before returning to its implications in Section 5.5.3. If the image encryption setting is enabled (as it is by default), the SCM encrypts the captured image using AES-GCM with a key and initialization vector (IV) derived in the browser. Similarly, the telemetry and metadata collected is also encrypted under AES-GCM in the browser. ---

Then you claim "including the site being visited, and that has potential to link the real identity of the user to the site they are verifying with."

Which perfectly highlights the issue, as it seems like you might have gotten that from the Abstract section of the paper.

The great thing is that the paper itself disproves all of that when you read all the details. And anyone can find out that the key section where there is actual sharing of data with third parties (not the visiting site) is when the credit card check method is used for example. Which is pretty inevitable, to do a credit card check you need to use a payment provider which will have to process the data necessary to do that.


TBH, even LinkedIn seemed to provide me with posts advertising events that happened two weeks ago a bit less pre-acquisition.


Individual self employed photographers successfully use the DMCA to get significant payouts from large publishers and news organisations every single day.

Like literally hundreds of thousands, every day.


That report wasn't suppressed. It wasn't published because the methodology had a 44% margin of error, and subsequently it was totally useless.

(https://arstechnica.com/gaming/2017/09/eu-study-finds-piracy...)

It doesn't provide data suggesting that piracy doesn't hurt sales. It literally doesn't provide any data at all.


The evidence for this supposed performance hit is basically zero.


False. There's lots of side-by-side recordings of Denuvo and non-Denuvo versions of games on YouTube clearly showing that Denuvo does impact performance.


No there aren't, because having identical builds of games with Denuvo actually removed and present is vanishingly rare.

If you compare a game that's had significant performance patches over a period of years and had Denuvo removed to the launch version (as so many of these videos are) then no shit you see performance differences, but it doesn't tell you anything.


https://www.youtube.com/watch?v=07NMuobVVwQ

This channel has many comparison videos like this one.

Loading times and 1% or 0.1% low FPS are usually hit the hardest and those stutters are the most immersion-breaking.


Should be noted that even scene cracks don't fully remove denuvo and all the performance intense checks so the impact should be even larger on actually denuvo free versions.


That's worrying, because Apple Mpas is still a borderline useless hot mess.


> The point of this is that you can use the credentials on your phone to prove that you are an adult to a website using zero-knowledge proofs to avoid disclosing your identity to anybody.

No it isn't.

Literally that is not the scope document, and such a solution would not be permitted by the EU as compliant with the legislation.

The app isn't zero knowledge. A prototype workflow has been designed for a one way transfer to sites that is zero knowledge, but it doesn't actually deliver zero knowledge because it you have to verify your age with an external provider to get the credential (which is not zero knowledge), the app has to be secured with either Apple or Google's attestation services (which are not zero knowledge), and the site has to be able to check with the original external provider that the credential hasn't been revoked (which is in no way zero knowledge).


Zero knowledge proofs are when the prover can prove the statement is true to the verifier without disclosing more information beyond the statement. It doesn’t mean the prover cannot talk to other systems to produce the statement.


That only works in the context of when the sender isn't the adversary, which isn't the case in an age verification system - it very much does treat the sender as the enemy and untrusted. And again, the revocation chain on the backend is not zero proof.


That's only an issue if getting the proof involves somehow identifying the service you are sending it to. If it's a generic 'send me a proof' it's not necessarily a problem, though of course it would be better if you could just generate your own proof.


The goal would be that neither the verification service nor the service you are verifying with can link the connection: the verification service can't tell which service you are connecting to, and the service you are verifying your age to can't determine your ID. The first two issues you mention don't necessarily seem to kill that (though I agree they are both suboptimal: once you are verified you should be able to generate your own verification keys without connecting to the verification service, and any requirement for attestation is just an unncessary restriction), though the revocation check does seem like it might be a problem.

The issue is that a lot of these services wave around a lot of words that _might_ mean that they are reasonably private, but it's damn hard to actually detemine if it is actually working like that in practice (the eIDAS standard seems to suggest the ZKP stuff is entirely optional, for example).


Twitter only supported 2FA using a mobile number for several years, so they quite possibly have that.

People are not always good at infosec for convenience, and Twitter's design for this was incompetent even before Musk's acquisition.


Given how on fire the rest of MacOS currently is I think incompetent management simply not caring about regression testing is more likely.


> The EU has zero knowledge proof age verification systems

No, they don't. And they can't.


Why can't they?


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: