Hacker News Reader

Comment by wyc | Hacker News Reader

login.gov is open source! They also encrypt user data in a way that they can't access it without the user's password, precluding the formation of a national registry that could be used towards nefarious and anti-democratic purposes. As a result, account recovery looks a lot like re-registration, which I think is a great thing.

https://github.com/18F/identity-idp

It's built on Rails, and I'm really impressed at the engineering decisions that were made here, from choice of technologies to level of transparency. I wish all public sector projects could exhibit the same leadership and competence demonstrated for login.gov--the interface is even a pleasure to use, which is hard to say for most government online services outside of the UK and parts of Canada in my experience. Bravo!

View on HN

Their 2FA was broken in a way that required me to delete my account, which is a pain as now I have to redo my resume for applying to federal jobs. I had an old account which worked fine but when trying to access it again it always said my 2FA code was incorrect.

Still I do prefer this to ID.me which I needed to use for CA unemployment.

Perhaps true user-friendliness is achieved not when the user can no longer have any bad experiences, but rather when the user's bad experiences are still superior to the alternative...?

That's an easy way to start a race to the bottom :)

It looks great, though afaik they still encrypt on the server side, which means they handle unencrypted data, so it seems to protect more against data leaks, rather than surveillance. To be honest, this is federal government and they already have most of the data anyway.

The major problem with login.gov from the IRS' perspective is that it doesn't provide identity verification which is absolutely needed. We will see how they work around that, but they still may have to outsource that to someone like id.me.

Don't they? https://www.login.gov/help/verify-your-identity/overview/

> login.gov is open source! They also encrypt user data in a way that they can't access it without the user's password, precluding the formation of a national registry that could be used towards nefarious and anti-democratic purposes

The website is still full of Google trackers, so it looks like it's already handing some user data over to private for-profit 3rd parties. Not a great sign, but I guess we can be happy we're not being forced to give them face-scans, fingerprints, or DNA I guess.

Do you expect the government to host their own analytics? Should they maintain data centers, CDNs, and serve from their own AZ as well?

> Do you expect the government to host their own analytics?

Yes. I do. There are alternatives to Google that work just fine (assuming they genuinely _need_ analytics in the first place). There's no reason using a government service should involve you handing data over to Google (or any private for-profit company).

>Do you expect the government to host their own analytics?

No analyzing your citizens behavior on a government site (that you paid) should be done by private company's (to make money out of your data)...what a question....

That's assuming what's in the repo is the same code that is deployed.

You can make similar counterproductive claims about everything. How can you assume that your senses and all humans are not gaslighting you?

If you want to go down that rabbit hole, you may want to (re)read Ken Thompson's Reflections on Trusting Trust at https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...

How does encrypting user data preclude nefarious and anti-democratic purposes?

If disabling your login.gov account locks you out of you bank account, the ability to travel, your library account, your email account, your social media accounts, your school, your children's school, your mortgage, your ability to pay your rent and utilities, your ability to seek employment, vote...

When your life is consolidated to SSO, your life is controlled by those who control the SSO service. The fact that they encrypt your data doesn't change that reality.

> They also encrypt user data in a way that they can't access it without the user's password

I love how low our standards for government sites have gotten where this is seen as a plus and not something that's expected

Isn't the US corporate standard even lower? Outside of maybe Google, Facebook, or HIPAA-covered entities.

Corporate customer databases I've seen have rarely even been need-to-know access limited, much less actually encrypted to internal users.

I don't even think a HIPAA-covered entity could hold their data to the standard of zero-knowledge encryption... since, you know, they have to be able to use patient data.

in theory they could but I doubt most patients want to have to remotely authorize their provider any time someone wants to access their record.

They could authorize an agent to authorize provider usage. The agent could apply provider-specific policies, and potentially monitor record requests to try to identify fraud, waste, or abuse, and so forth. The patient regularly reviews a report of actions taken by the agent to adjust configuration or revoke authorization. Could be an interesting approach!

All of the access audit information exists, afaik, albeit in non-standardized form. Because the law distinguishes between wilful and inadvertent releases, and assesses penalties on the basis of count and type, covered entities darn well better be able to produce an audit trail when asked.

It also needs to be a system that is workable when you scrape an unconscious person off the street with no next-of-kin available. It's not possible to have the patient or their agent hold the sole key for data that is created before the patient/agent is first available. Really, the best you can do in that situation is exactly what HIPAA requires.

Good point, implied consent does make such a system unworkable.

Agent should not be individual it should be an third party service or organization( could even by governmental) which shouldn't have uptime concerns. The policy setup would be complex to do without expert assistance anyway.

Maybe so, but that's a different thing than the zero-knowledge encryption that this branch of the comment thread was originally about.

Agent only handles the policy and access, they don't have access to the data itself It is still zero knowledge ?

In a healthcare context, the patient often may not physically be able to.

Absolutely. People do what they need, no more.

It’s getting better as people shift to cloud and inherit better controls, or implement better controls for cost avoidance reasons.

My country lets me use Google's SSO (arguably should probably also support Apple and have better 2FA options) - why wouldn't yours?

If someone wants to use facial recognition - why not? If someone wants to use insecure username/password and risk a compromise - let them do it.

FWIW big tech has probably 99.99% of people's faces, I'd guess at least 90% is tied to an identity.

I'd say the bigger issue isn't being allowed to use a third-party SSO, the issue is having the option to not use the third-party's SSO. We see enough horror stories about the impact of being locked out of a Google account.

Reply on news.ycombinator.com