kevin_nisbet

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.

Not exactly acoustic but reminds me of a high school science project we had one year, something along the lines of put out a candle with a contraption. My partner and I rigged up a balloon to be popped by the candle, and the balloon pop blows out the candle. Probably not an original idea, but I don't think any other group in the class tried a similar approach. Worked like a charm.

I've seen this point in a few different places and I don't know that it's understood as widely as it should be.

So just to expand on why that's the case. As a net producer of energy right now, the US produces more than it consumes. This is why it get's pointed out, that as a net producer, the trade deficit with Canada is also a surplus (or reduction in deficit) on the other side with other countries. Yes it may not be the same physical barrel that is exported vs consumed, but in a fungible way they're commodities. If you separate out that portion, we (Canada) then buy more goods from the US then we sell. And that's also just the goods trade, not including services which the US also sells more of to Canada than the other way around.

Just in case any of the authors read HN, I'm getting a pretty crazy rendering bug on this page, where a bunch of the contents are redrawing up and down by a few pixels. It seemed to go away with resizing the width a few times, but I didn't look into it too hard. My page width was probably small on first draw. Incredibly distracting though and hard to read with the text moving. Using latest chrome, and it occurred on more than one page refresh. I didn't dig in beyond that though.

Sorry, I didn't mean to imply tariff's were the exclusive cause, just a reminder that an additional factor is large tax increases.

>It's basically, because everything else has gotten more expensive. Labor + fuel + wear and tear on equipment + raw materials.

Don't forget taxes (tariffs) have also increased substantially. Even if a supplier isn't paying tariff's, if their competitors are they can often just raise their prices, or their prices go up due to the supply/demand shift.

> The strict academic definition hasn’t followed the colloquial usage for a long time. Maybe ever:

This is my understanding as well, and as I recall the results of the research were also more nuanced than most people seem to indicate. So not only were the novices with a wider range of self-estimates, the average result of those perceived scores was still below the experts. So it was never that low performers thought they were experts (although this may show up in the raw results with some portion of the population tests), just that on average they perceived their performance to be better than it actually was. And the high competence group while overestimating their results, still thought they'd do better than the low performers.

2am in Ontario

Good ol proxy arp, also ~20 years ago I took out all cellular internet access in Canada. Luckily it was in the maintenance window and I acted pretty quick, so hopefully no one noticed the couple minutes of outage at 2AM.

And even if there are new ETFs like this, will ETF customers bother to move at enough scale. It's like the old quote for buying IBM, no one get's fired for returning the benchmark, so if it's the benchmark adjusting the way they do things there is lots of inertia.

And to try and expand on why an index would include a waiting period in it's rules, my limited understanding is it's to give the public markets time to follow the company and review several quarters of financial results to stabilize the valuation in relation to those results before getting included in the index.

I'm a little bit more on the fence with the work sample interviews having designed them and also interviewed through them. I've also done my fair share of "traditional" tech interviews, all at startups, never FAANG.

As an interviewer, I much prefer the signals generated through a work-sample interview. I'm much more confident in the hiring recommendation than I get from a 1 hour zoom session. However, if I look at teams that were built through the work-sample and zoom interviews, I'm not sure the outcomes were that noticeably better.

As an interviewee, I think I understand the frustration being on the other side has. With an in-person interview, I often have a good sense that I bombed the interview or something to improve on or replay in my head, less surprising outcomes. On the work samples it's harder to know whether you're making mistakes, or are being out-competed by someone putting in 4 times the effort to polish the solution beyond what their regular work product would be. Although I had one really good outcome where the work-sample interview really flagged the internal dysfunction of a company.

And then with both interview processes, I still think there is a really big unknown on what the false no-hire rate is, how much effort is getting wasted rejecting candidates that would actually fit the team.

So having to choose a process as an interviewer, I'm with you and would always choose a work-sample interview. On whether it should be considered the "gold standard", I'm much more hesitant, I think there are some limitations that are still hard to control for.

I do wish Starfighter/Stockfighter model had gained more traction, would've been interesting to see a recruiting company specialize in this and then seeding the interview results to multiple companies model work out.

And the way they verify you are doing what you say you are doing is by asking you to provide evidence, which is usually pretty easy to demonstrate that a policy was followed once or twice, a lot harder for them to pick up consistency issues or exceptions.

Yup, I thought it was great. Although one concern I always had in the back of my mind was where is the line drawn. Such as if an adversary gains access to one of my orgs accounts and does something similar, do we get 100% taken out.

>That’s assuming your vendor was pentesting AWS systems. If you meant you hired a vendor to pentest your own systems on AWS, that’s of course a totally different matter.

Sorry for being unclear, the vendor was attacking our organization only, and any other company was expressly forbidden in the contract. As I recall it was a fake SSO sign-in page to collect credentials that they would try and social engineer our employees with.

Do they?

The only anecdotal thing I've seen is we hired a vendor to do a pentest a few years ago, and they setup some stuff in an AWS account and that account got totally yeeted out of existence by AWS if memory serves.

singleflight and sync.Once handle slightly different use cases.

sync.Once - Run exactly once, only the first call is invoked.

singleflight - Merge concurrent requests into one request and return the response to all the callers.

Where I tend to use both, is sync.Once tends to get used for lazy init code, the first caller does any client initializations, and subsequent callers wait, and then the lazy init is done and never done again in the lifetime of the application.

For singleflight, it tends to be on merging relatively expensive requests together. Like retrieving and parsing a JSON object from a server in concurrent requests. Merging those requests together, doing the expensive work once and distributing the results to each concurrent caller type of idea. With the results becoming invalid over time so a later set of requests need to do it all over again.

Sometimes it's mostly about taking an interest, reading or understand the legislation, and making a really good case and argument to the government.

I don't think I can claim credit because I'm sure I wasn't the only one, but it took 3 or 4 emails to a couple of legislator offices to get some policy changes. In my case it might've just been small enough (no news coverage, basically only a small number of people were aware of a regulatory memo), the first time or two they just kicked the can down the road deferring the implementation, until ultimately they reversed course. And my part was just laying out a very strong case for why the particular situation was unfair, how many people would be impacted (voters), etc. Nothing confrontational, just laying out the argument.

I'm not an expert on the baseband implementations, but I have the same impression as the parent, that in the 3GPP protocols the devices location can be requested and it's processed without any OS level interaction.

How that maps into the hardware I don't know.

Absolutely, I just don't know that this can be achieved over the Diameter/SS7 network between carriers, which the report was alleging access to the RAC/TAI and Cell ID's. So if the threat actor has different level of access to an individual network, we're talking a completely different analysis.

Sorry if I was unclear about that.

Yup, sorry I didn't bring this side up because the article was mainly talking from the perspective of pulling the LAC/TAI from generating messages in the SS7/Diameter networks. If we want to include what a carrier can do or what lawful intercept can do it's a different story.