If folks do this; I'd love for them to also be in the habit of shipping their prompts + harness configuration too. If we are moving to another code abstraction, then that becomes the source code to modify, adapt and extend.
I mean -- compilers used to annoy developers who knew how to hand-roll machine code, with bad outputs and inefficient algorithms, till the compilers got better than most of them...
I don't quite agree with the Assembly => Compilers => LLMs as some sort of "stages of evolution" argument tbh.
LLMs are an additional way to generate code, but it's not like code generation or "low-code" tools are a new thing that made compilers and programming languages obsolete.
LLMs "just" allow to provide the code generation input directly in human language. But whether providing such a specification in "sloppy" human language instead of a precise specification language is actually a good thing for long term projects is still arguable (as convenient as it is).
Mathematicians and engineers invented their own precise "DSLs" (e.g. math notation and blueprints) for exactly this reason, and high-level programming languages are nothing else than "specification languages" that don't leave room for the ambiguities of "natural languages", and it's still not clear to me how having both a natural language specification and a precise specification in form of source code side by side can be considered a good thing. It's easy to say of course that the "natural language specification" is the single source of truth and the source code is a throwaway output artifact, but then you're back at having a specification written in a language that's useless for expressing precise intent.
(and this is also the fundamental difference between compilers and LLMs and why I believe that comparing LLMs to compilers is wrong: determinism. The output artifacts of a compiler are literally throw away. Nobody in their right mind would commit object files into version control, while nobody in their right mind would not commit the source files generated by LLMs into version control, because creating the source files from scratch would yield different results on each run).
Releasing the harness as part of LLM-generated projects still makes sense of course :)
Yet, the Apple + Google implementations will sync passkeys between your devices. "Securely", of course. (I've seen first hand how Apple implements this, and it seems.... sound)
Sites can request hardware-bound tokens, which would block any software based password managers. It's an option in the protocol but one not yet widely utilized.
FIDO authenticator attestation is dead for consumer-facing RPs. Apple made the right call and simply refuses to support it outside of MDM environments.
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.
It is playing nice to criticize things. It's not just "different priorities", passkeys have intentional trade offs which cause them to be "more secure" but in ways that users do not want because it negatively affects them. The intentional trade off made in the name of "more security" makes them wildly inconvenient and risks causing massive lockout. Like removing all the staircases from people's homes and replacing them with climbing walls all in the name of "security". You can't just diffuse that by say "well we want banks to be more secure, we have different priorities."
I am already seeing my "normie" friends getting locked out of accounts due to not understanding passkeys. If they don't have their phone, or it's dead, or it breaks, or is stolen, they just can't access their account anymore. They have no idea how they work or what they're trading off, nor do they understand that they should have prepared for this scenario ahead of time somehow. Upon telling them "yeah you have to use your phone now that you have a passkey" they all universally say "wtf, that's stupid, I never want to have that happen again, I will never use a passkey again."
Passkeys should never have been built for general audiences, they are a huge mistake, I hope they cease to be relevant and die due to everyday folks realizing they're inconvenient and the "more secure" gains ain't worth it for the usability nightmares.
"I am already seeing my "normie" friends getting locked out of accounts due to not understanding passkeys."
In a weird way this is good news for us. If people are losing passkeys, getting locked out, and incurring non-trivial support costs as a result to the relevant companies, then there's no way those companies will crank down even harder by requiring hardware keys.
As an option, I don't mind it existing for situations like a work environment. Work environments are so much easier because there is a clear line to get my credentials reset, from scratch if necessary, even if I lose everything. The problem is that the consumer authentication case is even harder because it lacks that clear line without also creating a backdoor.
So I insist on centralizing my passkeys into a password manager. I have no passkeys outside of my password manager and will continue to reject them. If it's important enough to slap authentication on, it's important enough for me to not lose it because I couldn't choose where to stick it, which is in a basket that I protect very, very carefully.
Honestly I just don't see how something like Amazon could ever turn on the "require hardware key" feature without blowing their own foot off, or really any consumer-facing service. Everyone loses keys. To a first approximation nobody is going to buy three keys and correctly manage setting up all of them to work with every service. Even if we magically stipulate that all sites support it and they all have some integrated unified approach so that there's no software-side friction at all to register all three at once everywhere, you just get too many people who stuck all three keys on one keychain, people whose houses burned down, people who so successfully stored both backups "securely" that they have no memory of where they are anymore or how to get them back, an endless parade of lost keys. The consumer as a whole is not capable of managing hardware keys.
Given how often my household loses its second car keys for extended periods of time I am not exempting myself from this. My work key lives a much simpler life... it just sits in one place, doing work things. My family would hardly last a month if everyone had to carry around physical keys to log in to things.
Why should I recognize that as valid interest, when it's straight out hostile to me? I know why they are doing that. It doesn't oblige me to accommodate their selfish interests.
I'd absolutely never trust Google to manage passwords/passkeys for me, with their habit of irrevocably auto-banning accounts. Apple seems... better? But that's today. That could change, and then you'd be screwed.
You're not limited to a single passkey by the spec or 99% of sites that support them. The limit is arbitrary and typically when a limit exists it's no fewer than 3 (very rarely 1, but I've only seen that once that I can recall).
I generally add three, one for Bitwarden (my actual password manager), and then the OS passkey store (Android/Chrome password manager or iOS/Apple Passwords depending on the device).
I'm not qualified to say yes or no; but I will say that Apple's tends to make design decisions that try to empower the user as much as they can while still being easy to use, and have more or less maintained that position.where as Google, on the other hand, started as "open" and "you can do it all on our platform" to "we're taking away your control and choice little by little, in order to 'protect' you". Oh, and you hear more about Google perma-banning your account for no clear reasons, than Apple...
The most reliable way to permanently silence the cellular modem is to pull the relevant fuse. In the above case, this also disables the microphone, which I think is a positive. Unplugging the DCM entirely, however, seems to disable to right speaker, which is wired through the DCM for some reason.
>Unplugging the DCM entirely, however, seems to disable to right speaker, which is wired through the DCM for some reason.
I'm cynical, but unnecessarily coupling the ability to send telemetry with some feature people definitely want seems like exactly the sort of thing that would be done intentionally.
>right speaker, which is wired through the DCM for some reason
This is to provide cell phone audio during calls – if you're already inside your dashboard to remove the DCM (modem), there is an easy pin-out to restore the right speaker's music audio (which varies across Toyota models, but usually is as simple as placing a jumper across two pins of the unplugged wiring harness.
It varies by car. For my Honda, I believe disconnecting the antenna is enough. I looked at a Toyota and the antenna is shared. To disable the phone-home you had to disconnect a box … but that’s difficult. The box is also designed to call 911 or 999 emergency services and is connected to the microphone and one of the speakers. You have to rewire those if you want to use the microphone with your cellphone or play any stereo sound. Do your research before buying or disconnecting things.
Exactly, the harmed party is not subject to binding arbitration. The harmed party isn't going to bring someone to court for their bad devices - nobody has enough assets to be worth suing (other than perhaps to compel them cooperate with the discovery process) . However the company that made those devices is worth suing.
Alibaba is an interesting question though - if the device is from China (or some such) it isn't clear what the courts can do...
Do all modern compilers do tree-shaking at this point? Unless you use compiler-based flags, If you hard code them into your code, the dead code paths may still be in the shipped binary. Depending on what you are doing, the security issues mentioned in the article are still present, or you may prematurely reveal an upcoming feature.
Location: Northern RI (in between Boston + Providence, commuting okay!)
Remote: Yes, can do hybrid, or in person full time
Willing to relocate: No
Technologies: Perl (20+ years), MySQL, Postgres, everything Linux(Bash, iptables, containers, podman, Debian, Wireguard, OpenVPN, etc), Consul, Cloud Management & Migration (AWS Focused), Kubernetes (AWS EKS + on-prem k3s, ArgoCD, CI/CD, Longhorn, GitOps), on-prem hardware management (IPMI, iDrac, PXE, DHCP, DNS, BGP, networking, etc), JavaScript (frontend/backend), exploring LLM/Agentic development
Résumé/CV: Happy to share upon request
Email: jobs at jjayr.com
I've been the primary tech designing, implementing and operating our systems
for the last 25 years, and new ownership came with their existing stack, and
made my position unnecessary. I'm looking for a new challenge as a trusted
partner and team member overseeing, designing, implementing technology systems,
and being an advisor figuring out the best ways to cost effectively implement
and serve web-based and other technology systems.
At another ongoing gig, I've worked independently implementing barcode driven work order tracking in a small manufacturing firm, in operation for nearly 15 years. I have the drive and focus to implement ideas as an independent single contributor, or as part of a team. I'd love to connect!
Perhaps the AI then figures out how to read/write the PCI bus or memory controller or whatever to leak just enough RF to speak Bluetooth to the next closest device to proxy through that?
There is also the giant "Tax Incentives" being given to these projects under the guise of them being "job creators". Unfortunately, data center's only need a bunch of jobs at the initial construction + installation of hardware. Once it's operational, it'd need about a dozen staff to maintain round-the-clock on premise supervision.
reply