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

I can write my own authenticator implementation in a few hours by hand, maybe 5 minutes vibe coded. https://www.rfc-editor.org/info/rfc6238/

Even if you throw your phone into a volcano and buy a new one, you can still receive SMS verification.


KeePassXC supports passkeys

If you are blanket accepting permissions passkeys do nothing to fix the attack you describe (on device phishing).

Passkeys are not about securing things.

The entire value proposition, and the reason big sites are pushing them, is they take the user out of the loop of authentication. You are no longer authenticating the user, you're authenticating the users device.

For websites you don't have to worry about cookie theft and dealing with the support load of users needing their accounts reset or dealing with fraud. You can also do some level of attestation to hardware which makes automated account creation more difficult.

For the user it offers no additional benefits. You still have something secret that gets presented to a website to login. Password managers solved this problem. But now for some reason you can't log in when you buy a new laptop.


Warren Buffet made the largest single tax payment in US history last year. He doesn't play any games.

Telemetry is used to push service, which is the big money maker for dealerships. Roadside assistance, maps subscriptions, driving data for market research.

Selling it is pure icing on top.


I spent about an hour looking at the code and found some glaring issues that should be fixed before trusting it with real money.

- Yahoo News is introduced twice (sentiment and news analysis) which double weights it

- Sentiment analysis prompt primes the model to be bullish on Nvidia.

- In the self learning loop there is a complex parsing bug that results in hallucinated memories when agents return truncated responses

- You can completely control sentiment analysis of a subreddit by simply maintaining a majority of the 5 most recently posted messages, regardless of any quality metric

- The reflection prompt states the agent must cite alpha, which in a market wide downturn causes it to think correctly placed calls were losses


> Sentiment analysis prompt primes the model to be bullish on

Eeh, yeah? At that point I'd stop reading the code and just leave the project behind. How exactly is the prompt doing this right now?


To be fair, these are not prompted as has been described here. These are actually "few shot" examples in the sentiment prompt. It is presented as an example under "distinguish opinion from event" but not as "do-this" evidence. Still, hard-coded positive Nvidia/NVDA examples in a generic prompt are unnecessary prompt contamination. At best this a real bias risk, but not a strong deterministic bug.


There is also problem with underlying models. There was a study, where they always repest the same investing/management strategy: trust strangers, be open minded/adopt to new unproven ideas, prefer cooperation... Basically they were trained on disney-boomer bull(shit) market of last 15 years.

They have zero guards against market manioulations, and will get wiped without bull market!


DNSSEC support is an anti-feature, it is dead/dying and the faster we can unburden ourselves from it the faster we can move on to better solutions.

https://sockpuppet.org/blog/2015/01/15/against-dnssec/



That rebuttal held water 10 years ago, but fortunately we have made a lot of advancements since then.

DNSSEC was a solution trying to solve the problem of DNS security while still maintaining transparency for DNS operators to spy on queries. At the time, passive DNS was one of the tent poles of tracking malware and responding to security incidents.

We have since committed entirely to transport security in the form of DoH and friends. It solves the vast majority of problems we actually have.


DoH only secures the connection between the DoH provider and the client, not the response from the authoritative DNS server. It also isn't sufficient for DANE or similar. So DoH doesn't completely solve the problems DNSSEC tried to.


Exactly. And now there's <https://datatracker.ietf.org/doc/html/rfc9539> that allows encrypted DNS between authoritative and recursive servers as well.


That provides privacy, but not authentication.


Authentication was never the problem, transport security was.

This is why we pushed to deploy TLS everywhere instead of focusing on a scheme to PGP sign every webpage on the internet.


Authentication is precisely the problem DNSSEC is supposed to solve. And authentication is part of transport security.

TLS usually does provide authentication. The certificate is signed by a chain that leads up to a trusted CA, and content of the stream is authenticated using an AEAD encryption algorithm. But RFC 9539 specifically doesn't require the certificate to be signed by a CA (and recommends using a self signed cert) or the client to verify the authenticity of the certificate used by the server.

This means that an active MitM could return whatever it wanted to the recursive resolver. Pulling that off is admittedly more difficult than a MitM on a public wifi network at a coffee shop, but it's still a gap in security.

And no, you can't just use Web PKI to verify connections to authoritative DNS servers, because Web PKI relies on DNS to confirm domain ownership.


The rebuttal is old because the criticism is old. If you give more up-to-date criticism, then more modern rebuttals are available.

”DNS security” can mean many things, but DNSSEC was meant to solve the problem of verification of DNS data, while still allowing for offline signing and secondary DNS servers serving pre-signed zones, without distributing the key everywhere. DoH/DoT do not solve this; they solve different problems.


You don't seem to be sharing any of the modern rebuttals. I think it's telling that the old criticisms still basically stand.


You don’t seem to be giving any up-to-date criticism. I think it’s telling that the old rebuttals still basically stand.

Which of the criticisms in that article don't stand? What's changed? Adoption of DNSSEC has barely budged since I wrote it.

> Which of the criticisms in that article don't stand? What's changed?

Which of the rebuttals in the link I gave don’t stand?

> Adoption of DNSSEC has barely budged since I wrote it.

According to this graph, DNSSEC adoption seems to now be roughly 16×, i.e. 1600%, of what it was when you wrote it:

https://www.verisign.com/resources/dnssec-tools/dnssec-score...


See the comment from 'dsl upthread.

As for stats: https://dnssecmenot.fly.dev/

It is not surprising that European registrars have added millions of new names nobody is ever going to visit, all of them signed by default at their registrars. That's not meaningful.


> See the comment from 'dsl upthread.

That comment has recieved appropriate and adequate rebuttals, so I see no need to add anything further.

> As for stats: https://dnssecmenot.fly.dev/

You said “Adoption of DNSSEC has barely budged”, and that is what the graph which I linked shows to be hilarously false. I remember that you often used to link the same graph – until it stopped showing what you wanted, that is. Now you come peddling a different, explicitly biased, graph, which only shows what the top 1% is doing, but I really don’t care about what the top %1:ers are doing. Most people are concerned with popularity in general, not what Google and Amazon are doing. Most people are not Google and Amazon, and consequently should take no lessons from them concerning their own systems.


You mean like this one? https://rick.eng.br/dnssecstat/

I cite the DNSSECMeNot thing now for two reasons:

(1) I wrote it.

(2) It's live: everything in the Tranco Top 1000 gets checked several times a day. I can tell you every site in that last that has changed DNSSEC status (turned it on or off) in the last year. Spoiler: you can count them on the fingers of two hands.

I don't know why you push on this statistics argument! It's really rough for you. If I was in your shoes I'd be trying to decrease their salience, not increase them.


> You mean like this one? https://rick.eng.br/dnssecstat/

What is this graph a reply to? Those graphs are for how many resolvers validating DNSSEC, not domains using DNSSEC. And here, your frequent pointing to Google and other large operators works against you, since all of them already validate DNSSEC!

Also, I find it highly questionable of you to link to a graph as part of an argument, without disclosing that you also made the software which makes the graph. (But the graph also wears its bias openly, so it’s at least honest about not being biased.)

> I don't know why you push on this statistics argument!

Notably, I did not bring it up. You brought it up, when you wrote “Adoption of DNSSEC has barely budged since [2015].” Which the graph from Verisign – which you also used to link to – shows to be utterly false.

The argument about DNSSEC with you always goes in circles. You claim that DNSSEC adoption is not rising. But the Verisign statistics show that more domains are DNSSEC signed than ever before, every day, both by numbers and percentage. Then you claim that the large masses of domains don’t count, but only the top 1% of 1% of popular domains, which are, notably, with some exceptions, not commonly DNSSEC signed. But those domains are used by Google and other infinitely large and alien actors, which have very different security models and threat models than most people with a domain name. Then you try to argue against the Verisign graph by posting a link to other graphs which claim to show “DNSSEC adoption”. But the graph you link to is not about domains, but about resolvers. However, the large and most popular resolvers are from Google, Cloudflare and the like, and all of those have done DNSSEC validation for a long time.


At this point I think if you want to keep talking you should just email me, because we're the only two people reading this. I don't understand either of your arguments here.

I don’t see why I should email you; you haven’t given any new arguments here in this thread, why should I expect any better by email?

My arguments can be summarizes as follows: 1. The usage of DNSSEC is, contrary to your claim, going up, steadily. By number of domains signed, percentage of domains signed, and usage of DNSSEC-verifying resolvers. 2. Your argument seems to be that a) The increasing number and ratio of DNSSEC signed domains do not count, only big-name domains like Google are important (since many of those are still not DNSSEC signed), but b) big-name resolvers like Google are simultaneously not important, since those all do verify DNSSEC signatures. This argument is inconsistent. 3. Linking to, and trying to prove an argument by, your own biased graph using your own software, without disclosing that it is your graph and software, is scummy.


> Had DNSSEC been deployed 5 years ago, Muammar Gaddafi would have controlled BIT.LY’s TLS keys. Yupp. Which is why using bit.ly is a terrible idea unless you live in Lybia


Such as? And do those solve the same thing? The post lists 8 headlines why it should be abolished.


So DNS should be open to MITM attackers?


Even with DNSSEC, it still is. Example: https://blog.cloudflare.com/de-tld-outage-dnssec/


Did you read the article? It's saying that DNSSEC as an implementation to prevent MITM is flawed; other solutions that protect against MITM are proposed.


I think the comment you replied to was referring to the fact that when Twitter was taken over the entire Trust and Safety team was done away with. This has allowed child sexual abuse material to flourish on the platform.


It was referring to the feature they added where you could give a picture of a child to an AI module and ask it to undress it and it would comply, and millions of people did just that.


The child abuse material problem was much worse before Twitter was taken over.


This. They ALLOWED it to exist. Now it's clamped down on where seen, personally I've zeen zero having used X every day since the liberation.


In naive implementations like Grok that is exactly what happens.


Does Grok not have native models? What are you saying precisely


> but are they functionally useful or helpful to anyone currently?

I've been building a SaaS that deals with data that can't be distributed to third parties. Some of the useful AI stuff I can add is not time sensitive and can run overnight. Things like this allow me to use higher quality models without selling my house for GPUs.


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

Search: