I haven't found this to be the case. I check both regularly and much of the "science" that has engagement on Bluesky is thinly-veiled political slop earning engagement as a form of tacit "resistance". It's paper thin (and even the comments here on HN demonstrate a bit of this effect).
X downranks links in general, unfortunately, so unless the research is reformatted for X (rare) it won't get much engagement.
The fact that you can't actually see the passkey is absurd. I understand it's a "feature" prevent phishing — victims have a lot less to share — but it constrains more sophisticated storage and use of passwords.
Their spec doesn't dictate that you shouldn't be able to see it. It's just dumb implementations that do it (mostly for lock-in purposes). There are ones where you can see it just fine.
It's not for lock in, it's for anti phishing purposes. Passkey managers are designed so that grandma on the phone to a scammer can't physically dump and email her entire passkey vault. It's impossible to get phished by a fake login page with Passkeys and it's impossible to send your private keys to someone on the mainstream Passkey managers.
Portability between Passkey managers is still an issue though. Last I checked there were in draft specs for migrating between managers but nothing ready yet.
Not being able to see it all can't be justified with "for phishing purposes". You can put a big warning there that exposing your private key is a risk, but user should be able to see it with needed effort. Not being able to see it at all is a problem, like anything that moves away control from the user to some external entity.
Of course they'll happily justify it with security reasons, but that doesn't remove the problem.
The person on the phone will just instruct grandma to ignore the warning and that it's important she continue and send the private key over to secure her account.
Considering there isn't really anything you can do with the private key other than logging in to a website, making phishing impossible is a higher priority than letting people view the keys. There are alternative open source passkey managers which do let you view them. But it seems pretty obvious the average person is much better off not having this.
The person on the phone will walk grandma through installing remote desktop, make gradma login to the account, show a fake Windows update picture fullscreen, and do whatever they like.
It's not reasonable to remove all agency from users because they sometimes click through warnings. Scammers will do the exact same refund scam script that they do today, and at no point will a passkey stop someone from doing a sketchy money transfer, or letting the scammer control their computer.
It just doesn't make sense to impose these extreme restrictions on exporting passkeys that won't stop the most common phone scams sctipts at all.
Well, I'm talking about definition of the spec and principle here. If they start dictating impossibility of looking at your own private keys by design of the spec, it should be strongly pushed back against. There is enough of abuse in taking away control from the user with all kind of opaque stuff.
And what you can do or want to do with your private key is really up to you. Copy it and import into another password manager could be a reasonable use case, besides simple curiosity. Basically, slapping on it some kind of DRM-like restrictions in the name of security isn't right.
You can make it non trivial to make it more clear that it has risks, but not prevent users from accessing it if they insist.
So there is a portability spec in progress for copying your passkeys between password managers, it's just seemingly not ready yet.
You can also use KeepassX which lets you export the keys in plain text which would be the power user option. Passkeys as a tech doesn't stop you doing this, only the mainstream Passkey managers.
> I've already heard rumblings that KeepassXC is likely to be featured in a few industry presentations that highlight security challenges with passkey providers, the need for functional and security certification, and the lack of identifying passkey provider attestation (which would allow RPs to block you, and something that I have previously rallied against but rethinking as of late because of these situations).
Or in less patronizing terms: "do what we want or we're blacklisting you."
keepassxc is good, yeah. The point I'm making is that it shouldn't become mandatory to always force this DRM stuff. So far it didn't happen, but it always can.
They're probably just trying to not get their implementation blackballed with the attestation feature like one of the FIDO devs immediately threatened to do to keepass: https://github.com/keepassxreboot/keepassxc/issues/10407
I think the dance is all for naught though, they'll end up locked out as non-standard once uptake is high enough IMO.
For the last 20 years that has been the mantra. Some X "solves" all the problems.
Except it doesn't. It just creates another X that is popular for a while, and doesn't somehow retroactively "fix" all the chaotic projects that are a nightmare to install and upgrade. Yes, I understand people like Python. Yes, I understand the LLM bros love it. But in a real production environment, for real applications, you still want to avoid it because it isn't particularly easy to create robust systems for industrial use. You may survive if you can contain the madness in a datacenter somewhere and have people babysit it.
Solving it at least involves the Python maintainers making a choice, integrating it into the Python binary and sticking to it. At least. But that requires possibly annoying some people until a) whatever solution becomes mature and b) people get over it.
I've ignored the trends and just used the bog standard requirements.txt with pip and a virtualenv and have had no problems in the past 10+ years. Either way, you always want to catch production deploys if something breaks.
That is only true if you never reexamine the universality of your statement. I promise that it is possible to "solve" the mess that was Python's ecosystem, that uv has largely done so, and that your preconceptions are holding you back from taking advantage of it.
Here's the thing: there has never been a lack of people who have declared this problem as solved in the 20 or so years since Python started Poking its way into my professional life. (And for about 12-13 years before that I could gladly ignore it since nobody did much of anything in it). People have said this since the days of the Blackberry.
Multiple times people have explained why they think whatever they are madly in love with now is the definitive solution. And none of those times, over those couple of decades did it turn out to be true.
I understand that you are enthusiastic about things. I get it. But perhaps you might understand that some people actually need to see things stick before they declare a winner? I'm not big on wishful thinking.
I would take a look at uv adoption. That's what makes it different. It nails everything that all the other tools have done and it does it fast. So it's been what people have been using for a while now. Even poetry never seemed to get this ubiquitous of support.
I'm not saying uv isn't catching on. I'm saying most Python software still doesn't use it and for meaningfully complete adoption to happen, a solution has to be the default solution, preferably included in the standard distributions of the language.
Every single language enthusiast says that some of the biggest codebases in the world are whatever their favorite major language is. And here's the thing: it is completely irrelevant whether the codebase is small or large. What counts is what it is like to use and maintain programs.
Python isn't the only language that has poor tooling. C/C++ is even bigger than Python in terms of established code base, and its tooling is nothing short of atrocious.
What helps is people realizing where tooling and production readiness should be. They can learn a lot from Rust and Go.
The it's big so therefore it must be right argument is nonsense. Worse yet: it is nonsense that excuses lack of real improvement.
> But in a real production environment, for real applications, you still want to avoid it because it isn't particularly easy to create robust systems for industrial use.
This is silly and seems to discount the massive Python codebases found in "real production environment"s throughout the tech industry and beyond, some of which are singlehandedly the codebases behind $1B+ ventures and, I'd wager, many of which are "robust" and fit for "industrial use" without babysitting just because they're Python.
(I get not liking a given language or its ecosystem, but I suspect I could rewrite the same reply for just about any of the top 10-ish most commonly used languages today.)
I can get that Pythons not for everyone, it certainly has its flaws and maybe uv is just another transient solution which will come and go and others have. I might disagree, but I can accept that. What I can't accept is the idea that it should be avoided for real production environments, which is frankly a bit ridiculous considering all the real applications and real production environments running on Python.
There’s still 20 years of projects using everything that became before uv. They didn’t upgrade the moment uv came into existence. Data science-land still uses other rubbish too.
> They didn’t upgrade the moment uv came into existence.
There's also projects that can't use `uv` because it doesn't like their current `requirements.txt`[0] and I have no bandwidth to try and figure out how to work around it.
[0] We have an install from `git+https` in there and it objects strongly for some reason. Internet searches have not revealed anything helpful.
Unrelated to uv but the problem with having a git ref in requirements.txt is that pip will treat it as a fixed version so it will strictly narrow the other dependencies it can resolve, which gets exceptionally difficult to reason about once that packages also loads a package from another git ref. Throwing everything into codeartifact (or equivalent on other clouds) is better longterm.
I have personally found Marc's takes refreshing and vital. HN, like many sites, has become more cynical and even self-loathing. There are so many in here who hate tech and even progress and growth.
Marc's descriptions in the link are validated even just by the comments here. It's incredible.
>There are so many in here who hate tech and even progress and growth.
I think you are confusing skeptics of currently fashionable development roadmaps for popular technology with luddites.
As an example, I am a strong proponent of efforts to establish a multi-planetary society and at the same time believe that the future of humanity should have as many humans 'in the loop' as possible. This makes the technology underlying self-driving vehicles beneficial but the push to automate everyday human transport anathema. Other examples are collaborative robotics versus black-box manufacturing technology or global/system wide communications networks. Collaborative robotics allow for advanced manufacturing but can allow humans to retain their mastery of a craft and keep a hand in the process, enhancing rather than replacing. Communication networks, indispensable as they are, need not be a vehicle for exploiting weaknesses in the human psyche to hijack the human experience.
Perhaps I speak only for myself but I think there are quite a few members of this forum who hold similar opinions despite having deep knowledge of the subject matter and appreciating the technology at the core of the 'cutting edge'.
Just curious -- which takes? That immigrants are destroying life for people from Wisconsin? That universities are anti progress and should pay a price? That the Trump administration is the only way to save progress and growth in America? Am I just misunderstanding what Marc is saying, and these are not his views at all?
Marc decided to support Trump when the Biden admin told him that he shouldn't start AI companies because they were committed to an oligarchy of AI companies and they would classify math if they had to. Now the left is turning all their propaganda firepower on him.
I’m so grateful that hacker news isn’t swayed too much politically - people in general are willing to consider any novel argument on its merits in search of deeper understanding. As opposed to say Reddit where if you don’t agree with the hivemind it’s instant downvotes.
The honest truth is that you (like many; I say this blamelessly) have been swept left, whereas Marc has not. He has remained utterly loyal to technological progress, which is under assault right now politically.
Ask yourself honestly if you are still as optimistic about technology and the intellectual freedom (and chaos, "unfettered conversations") as you may have been in the past. I have asked many friends this and the answer is "no".
Cars have killed millions of people. Add to that the consequences of electricity, industrialization, urbanization, and even capitalism itself. But billions and billions of people are not only better off -- living lives of outrageous luxury when measured against recent history -- but they wouldn't have existed at all.
Everything good comes with tradeoffs. AI will likely also kill millions but will create and support and improve the lives of billions (if not trillions on a long enough time scale).
That's one vision of how things play out. But I do think it's possible that AI ends up killing every last person, in which case I think "everything good comes with tradeoffs" is a bit too much of an understatement.
Even if AI doesn't kill every last person, I think it will almost certainly increase the wealth gap. I agree that the tradeoffs will most likely not be worth it.
It usually does, just with a time delay and a strict condition that the firm you work at can actually commercialize your productivity. Apply your systems thinking skills to compensation and it will all make sense.
X downranks links in general, unfortunately, so unless the research is reformatted for X (rare) it won't get much engagement.