kevin_nisbet

I tried the skill as an experiment, and while it did give a suggestion that had poor support, it also suggested the library version as fallback (using Temporal). So if that's universally applied it might not be so unreasonable, but I don't do much frontend dev to know whether it's worth the risk or not.

The post is hard to read AI slop, but if there is anything to the claims it sounds like a real issue.

Unless I'm missing something I'd expect Payments Canada to have similar issues for you, since it'll still be the banks that you interact with. What changes is the settlement and messaging system between the banks.

Possibly. But some manufacturers may not have the full set of roots, use a private authority, or do certificate pinning.

Purely anecdotal but earlier this year I had presentations from a couple of installers for industrial control systems for buildings and I was thoroughly disappointed.

TLDR multiple of the installers just wanted to have a public static IP address, and just drop the control systems directly on the internet. None of them knew who was responsible for device updates or CVE's. One of them had an optional proprietary yubikey type thing with no idea how it actually worked. One companies security assurances was basically they always do this and have never had a problem before.

Don't get me wrong, I'm all for beyond-corp, but none of the companies we talked to seemed knowledgeable enough to risk it.

Just some insight into how the rest of the world operates, I would expect bigger companies to have more resources, but this is an example of what happens when you're small and dealing with "experts".

I was confused at first but it seems like the site lists for google products only, doesn't seem to list some of the regions google cloud is available in (such as nothing in shown in Canada). But scrolling down it has a link to Google cloud regions.

I sort of started skimming when the article was saying industry solved the problem with text messages and TOTP. I think there are several arguable problems with Passkeys as implemented, but to argue TOTP is equivalent is going to leave lots of people vulnerable.

The protections against MITM you mentioned is probably the biggest one, but the other one in the back of my mind is TOTP is a shared secret. So a compromise of the server side allows impersonation of users undetected, which can be a big problem. Maybe I'm over reacting because no company has ever lost a copy of it's database and they're all super secure. But, imagine trying to argue as a user I didn't do a thing when there is an audit log saying we challenged the user for TOTP and it was provided, was definitely the users fault.

Agreed, with an ACL that blocks any device to device communication within the network.

I really like Edison's ethos as well, although I do worry they make some of the classic startup mistakes of getting a bit distracted on things that aren't important.

The post seems to be in line with some of my own direct observations. I've been pondering recently whether for many devs the use of AI is the death of the mental model.

We all interact with systems through mental models, but if many devs are just prompting claude when something doesn't work, they might read what claude found, but lose out on the exploration, debugging, and work that builds and reinforces the correct mental model and discourages the wrong one. And if devs are missing out on the mental models, will they actually be capable of driving efficient solutions to problems as the mental models get worse.

Not for cars, but Edison Motors in Canada seems to be going this route right now for their heavy duty trucks and heavy-duty pickup truck conversions.

Disclosure: I have a small investment in them.

Lots of folks are commenting on the internal dynamics, but the other part that didn't resonate with me was actually the what happens next part. This may be an overreaction on my part, stemming from watching lots of engineers suggest expensive solutions to relatively minor issues. And it's a mistake I've made myself before as well, I started in telecom with very strict standards for availability, so it's hard to beat out of me the desire to look through the most minor alarm for a potential problem brewing or get to a root cause of the most minor incidents.

And maybe this is just a part that the article dodges, but for something described as non-catastrophic, I would suggest that there shouldn't be a presumption of changes. In my view there should be an assessment of the risk of re-occurrence, and if it was a near miss, what is the risk had it not been a near miss. And then even should changes be part of the outcomes, how expensive are those to implement compared to whatever the issue was, and if they're too expensive compared to the risk, don't put resources into it.

Part of my maturing with getting older in addition to the above is that luck is a larger factor than most people are willing to admit. So I'm with you that GTM is just as important as engineering, but execution on all fronts is what tilts the luck factor. And with luck you get exceptions which is why you can get companies that seem to succeed despite themselves.

These tools are very common in non-nefarious ways for troubleshooting networking, and while vendors set up to serve this space solely as troubleshooting tools, I've also built my own that can sit on a network link and monitor for problems.

In my case it was for mobile wireless signaling traffic (all the coordination for creating a mobile internet connection, handing the connection off between towers, etc), and I'd credit it as one of the reasons you're mobile internet connection is so stable. When LTE first came out, myself and many others solved all sorts of bugs in the equipment and protocols by using or building these sorts of tools.