Comments URL: https://news.ycombinator.com/item?id=48692330

Points: 4

# Comments: 0

I don't quite buy this in either direction (although they are both couched as possibilities, which makes it a pretty safe statement). Humans might notice, but years of annual mandated phishing trainings has led me to believe that humans as a whole are generally not great at noticing.

AI agents OTOH mostly do as they are prompted. If the human prompting them tells them to check these things, they will likely check much more consistently than any human. If the prompt doesn't say to check, the agent won't. But that again falls back to what the human might or might not think about.

Frameworks like React that add structure to the data flow, component encapsulation, and a huge repertoire of patterns to train on, plus Typescript for immediate compile-time feedback loops… those are what LLMs thrive on.

Authors do it because it supposedly leads to better engagement, shows up bigger on social media, and breaks up the text. But generally, unless the visual content meaningfully adds to the text content, users will largely ignore it.

I haven't come across the Email Verification Protocol yet, will take a look! At a glance, the flow seems almost identical to BrowserID. I'm curious how the UX looks.

For bespoke projects, a lot of the privacy concerns go away once I’m using my own authentication in the first place (I control the full stack). So then the value would come more from federation (which is hard to bootstrap) or developer experience. I do still think BrowserID has something going for it there, potentially.

I do wonder if I’ll miss the centralized session management, though. I’m building this IdP to be modular, so I could try a different protocol on top of the user management core down the road.

Thanks for sharing!

And the second reason is that I don’t want to try to be Mozilla Persona. The fallback IdP is a great idea, but y’all have no reason to trust me to be the one to run it. I can sidestep that issue for my own needs today, avoid the complexity of sending emails, and if for some reason this project does pick up any steam we can figure out whether/how to add that functionality down the road.

3rd party cookie blocking makes this worse, since it’s difficult to silently refresh your session by checking with the IdP behind the scenes. I believe Auth0 uses a hidden iframe for this, which uses 3rd party cookies and looks a lot like a tracking pixel. Without that refresh mechanism, though, relying parties are pushed to have longer lived sessions, which makes the lack of a global revocation worse.

Comments URL: https://news.ycombinator.com/item?id=47906770

Points: 31

# Comments: 13

To the extent that Flock is only storing the data on behalf of their customers, I'd understand they wouldn't be required to delete it. But to the extent that they are indexing it, deriving from it, aggregating it across customers, and sharing it via their platform, it seems they should be required to remove that data from those services.

But then again, I am not a lawyer!

Comments URL: https://news.ycombinator.com/item?id=47575644

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47003542

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=46980975

Points: 3

# Comments: 0