The biggest problem I have seen with AI scrapping is that they blindly try every possible combination of URLs once they find your site and blast it 100 times per second for each page they can find.
They don’t respect robots.txt, they don’t care about your sitemap, they don’t bother caching, just mindlessly churning away effectively a DDOS.
Google at least played nice.
And so that is why things like anubis exist, why people flock to cloudflare and all the other tried and true methods to block bots.
Threads is a one way view into the fediverse and opt in too boot. Only Threads users who turn it on are visible to the wider fediverse and many instances on Mastodon de-federate from Threads anyway.
I can follow Hank Green on Threads but the interoperability basically ends there.
1. Passkey prompts asking if I want to use a phone or security key when I only have one (or neither!) registered. The UI for this gets in the way and should only ever present itself if I happen to have both kinds of devices registered.
2. Passkeys should have had the portability and flexibility that ssh keys have from the start. Making it so your grandparents can use public key cryptography and gain a significant advantage in securing their accounts in a user friendly manner should have been the priority. Seems like vendor lock-in was the goal from the start.
>The UI for this gets in the way and should only ever present itself if I happen to have both kinds of devices registered.
I disagree. It is very annoying when some service fails to show an option on the grounds that I can't use it. It makes it difficult to resolve problems. If the option is just missing, I have no way to tell whether the company doesn't provide the option, whether the company made some sort of mistake (they can't provide an email option because they lost my email), whether I made a mistake, or whether the company just has a bad UI that tries to hide the option. And don't forget the situation where I tried to google online for some help in using the UI, I found a 6 month old Reddit post showing the option, and I can't figure out if the company changed the UI in the past six months.
They should show it greyed out with a note "no key of this type registered".
That’s fair. I just meant that during logon, it is annoying to have to click through an additional prompt that doesn’t apply. But I can see where if there was an issue showing what all the options could be and if they are enabled or unavailable or you want to set it up, would be more beneficial than not.
On Mac with the security key you can just press the button on the security key before choosing a path. It only looks like a required extra step but in practice it is optional.
> Seems like vendor lock-in was the goal from the start.
Exactly. The passkey vendors state that the goal was to make phishing not just difficult but impossible. This means plaintext access to your credentials is forbidden forever, regardless of your level of expertise, and regardless of the complexity of the process to export/import them. The purpose of the so-called "secure credential exchange" is once again to prevent you from directly accessing your credentials. You can go from one passkey vendor to another, but you're always locked in to one passkey vendor or another.
Any credential system that makes it impossible to write something down on a piece of paper, take it to a new computer, and login to a website is just a gateway to vendor lock-in. You can manually manage your own ssh keys but for some reason not your passkeys.
As an Apple Mac user, what annoys me the most is that the use of passkeys in Safari requires iCloud Keychain, which of course requires iCloud and an Apple Account. [EDIT: Obviously I'm talking about built-in support. I'm well aware of third-party software, so everyone can stop replying to this now, please!] You can't do local-only passkeys, not even if you take responsibility for backing up your own Mac.
The passkey vendors took some good theoretical ideas, such as site-specific credentials and public-key cryptography, and totally mangled the implementation, making it hostile to everyone except themselves.
This is not true - browsers including Safari support passkeys managed by third-party password managers.
I'm using 1Password with browser extensions for Safari and Chrome on macOS and iOS and it works seamlessly with my passkeys, which are not stored in iCloud Keychain.
> you're always locked in to one passkey vendor or another.
> This is not true - Safari also supports passkeys managed by third-party password managers.
I think you know what I meant and are just being pedantic here for no good reason.
Do you think I'm unaware of 1Password? I don't want to use 1Password any more than I want to use iCloud Keychain.
Technically, pendantically, Safari "supports" anything that third-party Safari extensions support. I'm a Safari extension developer myself. But this is totally different from how Safari supports the use of passwords, which is all built in, requires no third-party software, can be local-only, allows plaintext export/import, etc.
Reading the cfx spec [1], the raw private key is exported as a base64 encoded der. I don't understand what your concern is here. It appears that any cfx export file is not tied to a specific service to service import path, but can be imported into anything, or just used locally with self written tools.
This is merely the exchange format between credential providers, which is encrypted and gatekeeped by the credential providers. None of this is exported to users.
OK I see what you mean. Having the ability to switch between vendors but not the ability to export your data locally (e.g. as plaintext keys) is a new meaning of "vendor lock-in" I hadn't considered before.
Yes. User freedom is not all-or-nothing. There are degrees, and the tech companies are coming up with fiendish new ways to lock away your data from you. So in the case of passkeys, you can technically move your data between vendors, though that can be quite inconvenient as the submitted article mentions, but nonetheless every vendor locks away your data from you, and most vendors have a financial incentive to keep your data away from you, so that you have to pay for the services.
Once "secure credential exchange" becomes supported by commercial credential managers, what's to stop someone implementing an open source password manager that implements the standard and allows local export in plaintext?
Passkeys relying parties can block providers. Tim Cappalli threatened the KeypassXC developers so.[1] The restrictions demanded now do not restrict user freedom significantly arguably. But the incentives and capabilities are clear.
OK but you'd still be able to use the open source "password manager" to export the keys - which solves the issue lapcat raised in this thread - even if relying parties blocked it for authentication, which would be a separate issue.
Someone could develop a "passkey export tool" purely for the purpose of doing credential exchange then local export.
Or are you saying the credential exchange process itself could block providers?
You misunderstood lapcat I think. They wanted Passkeys stored locally exclusively. And they wanted to be able to use them. The issues are not separate.
Not sure how stating that my (an individual) opinions on a topic are evolving is interpreted as "threatened the KeypassXC developers".
If you've been following along, you'll have seen that I am actually one of the biggest advocates of the open passkey ecosystem, and have been working really hard to make sure all credential managers have a level playing field.
Always happy to chat directly if you have concerns!
The threat you relayed was more serious than the threat you made. But it is a threat when a person with influence suggests they may support a punishment.
The biggest advocates of an open ecosystem say attestation should be removed and no one should adopt Passkeys before. Is this your position now?
The concerns were clear I thought. I would be happy to discuss this publicly.
Not really. The attestation model defined for workforce (enterprise) credential managers/authenticators doesn't really work in practice for consumer credential managers.
Avoid weasel words please. Is it possible in theory to use attestation or any other Passkeys feature ever to prevent a user to use any software they chose with any service they chose?
In theory any code could be written at any time that does something good or bad. Sure.
But in reality, the people who actually work on these standards within the FIDO alliance do not want a world where every website/service makes arbitrary decisions on which password managers are allowed. That would be a nightmare.
This is obviously kicking the can down the road, but I "solve" this problem by storing passkeys in a third-party credential manager that supports them. That way I can use them on any device that I've installed the client app or browser extension on. I have this working on Fedora, macOS, Windows, and iOS.
> The passkey vendors state that the goal was to make phishing not just difficult but impossible. This means plaintext access to your credentials is forbidden forever, regardless of your level of expertise, and regardless of the complexity of the process to export/import them.
Care to cite this statement?
> As an Apple Mac user, what annoys me the most is that the use of passkeys in Safari requires iCloud Keychain, which of course requires iCloud and an Apple Account. You can't do local-only passkeys, not even if you take responsibility for backing up your own Mac.
You can use any credential manager you choose. You don't have to use Apple Passwords / iCloud Keychain.
Yes, literally from you: "Passkeys should never be allowed to be exported in clear text." https://github.com/keepassxreboot/keepassxc/issues/10407 Also, "You absolutely should be preventing users from being able to copy a private key!"
> You can use any credential manager you choose. You don't have to use Apple Passwords / iCloud Keychain.
But I want to use Apple Passwords. And I do use Apple Passwords for passwords.
What you're saying, in contrast, is that in order to use passkeys, I would be forced to change how I currently store credentials, which is not in iCloud. "You can choose any method you like, except the one you currently like" is a pernicious interpretation of "choice".
You're quoting the first post of a long discussion, where the importance of protecting your data on disk was highlighted, and a proposal was made that at minimum, the default should be encrypting the backup with a user selected secret or key.
> But I want to use Apple Passwords.
You're choosing to use an app that doesn't meet your needs, when there are numerous apps out there that do meet your needs. I'm not sure how anyone is supposed to solve that for you.
> At minimum, a credential manager distributed for wide use should encrypt exported/copied keys with a user selected secret or user generated key.
It feels like this stated minimum is not your actual minimum.
Consider for example a macOS user keychain. The keychain is encrypted on disk with a user-selected password. But once you unlock the keychain with the password, you can copy and paste passwords in clear text. The keychain is not a black hole where nothing ever escapes. And I have no objection to this setup; in fact it's my current setup.
So when you say copy and paste of passkeys in clear text is not a good idea, there's nothing inherent to encrypting credentials with a user key that prevents such copy and paste. There would have to be some additional restriction.
> This is currently being defined and is almost complete.
>> no signed stamp of approval from on high
> see above. Once certification and attestation goes live, there will be a minimum functional and security bar for providers.
Will I always be able to use any credential manager of my choice? Any naturally also includes software that I might have written myself. And would you be in support of an ecosystem where RPs might block my implementation based on my AAGUID?
Unclear how this quoted comment relates to what I was replying to (which was about exporting / backing up your credentials).
But I'll respond.
> Will I always be able to use any credential manager of my choice? Any naturally also includes software that I might have written myself. And would you be in support of an ecosystem where RPs might block my implementation based on my AAGUID?
If a website were to block your custom software's AAGUID for some reason, you can change your AAGUID.
AAGUIDs in the consumer passkey ecosystem are used to name your credential manager in account settings so you remember where you saved your passkey.
Which I would be careful with. I can use any authenticator that the RP accepts. I could totally see a future where banks only allow certain authenticators (Apple/Google) and enforce this through AAGUID or even attStmt. Similar to the Google Play Protect situation.
At that point, those banks/services would enforce vendor lock-in on me. The reality would be: I can use iOS or Android, but not a FOSS implementation. This restriction is not possible with old-school passwords.
> The purpose of the so-called "secure credential exchange" is once again to prevent you from directly accessing your credentials.
I’ll accept that the attestation parts of the protocol may have had some ulterior motives (though I’m skeptical), but not having to reveal your credential to the verifying party is the entire benefit of passkeys and hugely important to stop phishing. I think it’s disingenuous to argue that this is somehow unnecessary.
> not having to reveal your credential to the verifying party is the entire benefit of passkeys
I think you misunderstood what I was talking about. The credential exchange protocol is for exporting passkeys from one credentials manager and importing them into another credentials manager. It has nothing to do with the relying party.
It's an open protocol, you don't need to use any of the vendors. My Yubikey is a "passkey", so is my Flipper Zero. Keepass provides passkey support.
For the general public, they already rely on either Google or Apple for pretty much all of their digital life. Nothing wrong with extending this to passkeys, it's convenient and makes sense for them.
> It's an open protocol, you don't need to use any of the vendors. My Yubikey is a "passkey", so is my Flipper Zero. Keepass provides passkey support.
I don't want to use a Yubikey. It's a pain in the butt. I just want to use my Mac, with no more damn dongles.
Keepass is a vendor, and one who doesn't even have a Safari extension.
> Nothing wrong with extending this to passkeys, it's convenient and makes sense for them.
I didn't say there was anything wrong with extending this to passkeys. The problem is the lock-in, e.g., Safari requires iCloud keychain for passkeys, but not for passwords. And there is no plaintext export/import, unlike with passwords.
Nobody can convince me that passkeys are good when I buy a Mac and use the built-in Safari but can't even use passkeys to log in to websites unless I give my passkeys to a cloud sync service or have to install some third-party "solution" (for a problem that should not exist in the first place). That experience is so much worse than passwords.
All of the 3rd party credential managers I’ve used that support passkeys work with safari, and through the APIs that Apple offers the credential managers you can even pick your default CM and never think about iCloud again…
Passkeys seem to be the best solution for users whose technical chops cannot be trusted, and who are also gullible enough to be a scam / social engineering target. Which, to my mind, describes a large enough chunk of audience of most popular services.
A tech-savvy relative of such a user should help them generate rescue codes, write them on a piece of paper, and store them along with all other important documents. Ideally the paper should also read: "Call me before using any of these codes! <phone number>."
A "user agent", I suppose. The agent could identify you to online services, and it does. Remembering and typing a passphrase is often too hard (or "too hard") for some users. A passkey is better than a password like 123456 or name + year of birth, or other such "easy to remember" passwords people invent to avoid remembering a passphrase. Especially if you have a hundred logins.
A passkey basically offloads user identification to the OS (especially a mobile OS). It should not be the only way to identify though.
An ssh-style key + password is fine. A username + password + TOTP should also be fine. But 99.9% of passwords should be in a password manager anyway.
Rescue codes should always be generated and written down when activating a passkey or similar, but this requires certain discipline, some feeling of importance. And many web sites that require registration don't seem important for users, especially one-time users. What makes sense for your Google account, or your bank account, feels like too much ceremony for a low-stakes login like a random online store; losing a login to it does not feel like a big loss to many people.
I haven’t really followed things in great detail, but something that has stood out to be is the apparent linchpin that was pulled in this whole affair. Like it or not, TikTok is an American company with American employees and even running on American infrastructure and oversight that was established years ago now; not somehow the cabal in our government has simply eschewed rule of law and their own ideals, to basically strong-arm this deal because there was too much free speech, a fundamental right of Americans, which the government is legally prohibited from violating and doing so is as much of a capitol offense as it can get, violating not only the law of the Constitution, but also the rights enshrined in the Declaration of Independence.
I don’t see how a competent legal team could not shred this whole effort at disowning TikTok and at the very least make it extremely expensive politically and even to the core foundation of legitimacy of the current government in what is for some reason still called the USA in spite of gross patterns of consistent material violations of all the terms.
While technically true, these articles give context about the level of decision-making control and data access from ByteDance, as of the time of their publication.
What's changed in 2025 is that the Trump administration has illegally postponed the ban passed by Congress four times, despite the fact that the law does not allow the President to extend the ban. And, naturally, the fact that this is to facilitate purchase by a coalition of political allies.
This has less to do with anti china hawks and more to do with anti Israel content on TikTok. And information control in the US. They are openly buying out all US mainstream media and from the looks of it will probably take Warner brothers from Netflix as well.
I'm the first to say they should have been shut down the day the original deadline ran out, and if new leadership comes to the WH they should aggressively prosecute all the platforms that broke the law under promises of the corrupt DOJ (Google, Apple et al). But that's between your joke of a constitution and political leadership, it hardly sways the case one way or another.
> TikTok is an American company with American employees
Those American employees are required to basically uphold the interests of the CCP. This is done as part of an agreement around their stock grants apparently. From https://dailycallernewsfoundation.org/2025/01/14/exclusive-d... there are details on what executives of TikTok have to agree to in writing:
> “You shall comply with applicable laws and guidelines and abide by public order and good customs, the socialist system, national interests, legal rights of other citizens, and information authenticity requirements,” the purported Douyin agreement reviewed by the DCNF states.
> The document also lists a number of prohibited activities for employees, including “overthrowing the socialist system,” “inciting secession,” “undermining national religious policies, or promoting cults and superstitions,” as well as injunctions against “meaningless information or deliberate use of character combinations to avoid technical censorship.”
And in fact, they’re required to report to a ByteDance management team in China, and acknowledge that they’re employees of ByteDance (and therefore NOT the American company):
> TikTok executives also sign agreements with ByteDance consenting to digital surveillance and report to China-based leadership, according to other documents and audio recordings supporting Puris’ lawsuit.
> Other documents also seem to indicate TikTok ultimately considered Puris to be a ByteDance employee.
> While onboarding in 2019, Puris was allegedly required to sign one hiring document reviewed by the DCNF affirming: “I am a director, executive officer or general partner of ByteDance LTD.”
You wrote "All tiktok code is written by ByteDance engineers in china." While historically that might have been true in the old codebase, it isn't anymore. There is a significant TikTok office presence in South Bay, with many job listings open.
I find all this very interesting from a historical perspective because we are ramming into the control matrix that has been constructed around America for around 150 years now at minimum, the notion of universal equality; and it is causing the inevitable and predictable collapses that are caused by its inherent contradictions.
We wanted diversity and equality because it served a narcissistic ethnic group, and now that they’ve started realizing that their whole short sighted, self-serving system is turning on them, they’re blowing huge holes in it and getting ever more draconian… as is typical of narcissists, especially malicious and grandiose types of extreme narcissists.
You will not be able to convince these toes of people with things like facts, because what they promote or support is an emotional level conviction similar to a religious one. The whole China ruse itself is just a lie and the ones who used and deployed that lie for strategic ends know this. All those who promote it are just the worthless foot soldiers on a battlefield of and over the mind.
> To be clear, I’m not advocating for AI in real learning. AI is only useful right now as a stress test as it reveals how hollow adolescent work has become. If it pushes schools toward offering work with relevance, impact, and agency and away from hopeless busywork (“When will I ever use this?”), that is a win.
But how will they ever know that if they don’t go through the process? I am not saying the current way of teaching is perfect but you can’t tell what is and isn’t bullshit without some experience at some point.
We had a mandatory home economics class that taught how to balance a check book, cook, do laundry, and even how taxes worked. Yet people still thought that class was bullshit and a waste of time. Many classes such as health, gym, shop, a/v, typing, all had people blowing it off as useless stuff they will never need to know. ChatGPT turning every class into that is a nightmare future for the youth of the world. People will grow up entirely unable to think.
> We had a mandatory home economics class that taught how to balance a check book, cook, do laundry, and even how taxes worked. Yet people still thought that class was bullshit and a waste of time.
Sounds about right. This author is talking about whether the kids think the material is important as if kids have good judgement and can be trusted. But that obviously is not the case. Kids are overconfident and ignorant and have no basis at all to determine what is and isn't good learning for them.
Given that I worked with people well before the advent of LLMs who had no idea how marginal tax rates worked, it seems like we should be more aggressively pursuing this as an educational goal.
Zerossl is integrated with Caddy by default and there’s no indication from Caddy that you would only be able to renew the cert twice before needing to cough up some money.
It would be cool if the output that that the LLM made (commands it ran to harden, the iptables, MPTCP config, etc.) was included in the post.
It seems incredulous that this didn’t take dozens of back and forth prompts and fixes. It was able to one-shot deploying a digital ocean droplet and configure wireguard?
> It was able to one-shot deploying a digital ocean droplet and configure wireguard?
Yes, that part was pretty easy - but the whole thing wasn't one shot. The parts I struggled with were:
- getting automated SSH installed on the $130 router, once you have that the LLM can drive things
- during security hardening, I got fully locked out and had to recreate a new VM. But it was able to automatically recreate everything in a few minutes.
Thanks for sharing. Just looking over this it seems to spend some time creating ufw rules and then deletes them all and disables ufw. Is that accurate or is this just the output and you had to copy and paste in?
I am assuming all the missing steps is just the information you censored.
Yeah but if I program a drone swarm to automate this process it’s for the greater good — more apples for everyone!
And I only charge a tiny subscription for access to all my drone-managed orchards, you can eat as many apples as you want. But don’t steal any and start your own orchard or I sue.
All the people who care for the trees and pick the apples have lost their job while an apple became nearly worthless, but without a job it‘s still unaffordable.
Replace your drones with China or India and you have the current situation in the US.
Apple farmers go out of business so you lose the people who create new varieties.
> but I use those 1,000 apples to start my own orchard
Steal cuttings, not the fruit, if you plan to start an orchard. From 1000 apples you'll get ~10 000 seeds, statistically you won't even end up with one good tree.
> An output of three cultivars from around 50.000 seeds means that 17.000 seeds were needed to get one cultivar. Only one out of around 9.000 scab resistant seedlings showed the appropriate quality to become a cultivar. This proportion underlines the enormous effort which is necessary to develop a new cultivar.
They don’t respect robots.txt, they don’t care about your sitemap, they don’t bother caching, just mindlessly churning away effectively a DDOS.
Google at least played nice.
And so that is why things like anubis exist, why people flock to cloudflare and all the other tried and true methods to block bots.
reply