In my experience, this is the path many developers take. I’ve consulted to hundreds of companies over the years, and it’s alarming how often I’ve encountered decisions driven by what someone wanted to learn or work with, rather than what was actually right for the problem.
That happens at every level, from individual developers through to project leads and CTOs.
Consultancies are often no better. Choosing technologies that require substantial or highly specialised skill sets seems almost routine. I’m looking at you, Kubernetes.
I’m not entirely innocent here either. I owe a decent portion of my mortgage to MuleSoft consulting. That said, I don’t think I ever pretended it was always the best solution. Even while working directly for MuleSoft, my recommendation in probably half of the engagements was some variation of: ‘You’re using the wrong technology for this.’
But by then, an executive had usually tied their reputation to the project and the platform, commitments had been made, and changing course had become politically harder than continuing.
And so we persist.
In my experience, the best technology choices are boring ones. There’s still a large area of immature technology you can get creative with (like Backstage or Port for software catalogs and setting up a nice golden path”), but the meat and potatoes of development work should be a boring choice, that follows a well-tread path within a large ecosystem of developers.
There are exceptions, but they’re not for the majority of organisations.
This is what happens when you give people tools that let them achieve an outcome, without necessarily giving them the judgement or expertise to know whether the outcome is any good.
If you asked me to build a house, I could probably assemble something that would stand for a few months. Hopefully. It might even keep the rain out. But it might also fall on my head, because I do not know enough about building houses to be confident that it won’t.
And even if it didn’t fall on my head under normal conditions, I also would not know when I needed to design for earthquakes. Or floods. Or fire. Or wind. Or grandmother-cosplaying wolves with very strong lungs.
But if all I need is shelter for a day, would I necessarily care whether it lasts more than a week?
That is effectively what a website like this is. It is not really a product. People don’t depend on it. Tan’s visitors are probably using MacBooks and iPhones on fast networks, and most of them will never notice how bad it is under the surface.
That does not mean it is good. It means it is good enough for the context.
So, consider this a layman explanation of why this change is bad from someone who spends their time securing end-users.
This change is good for the majority of users, but is actually bad for large enterprise customers and highly-regulated customers. It puts more control and onus of responsibility on to Google, rather than the end-user. So, we will expect to see better enforcement of controls from Google for the lowest-hanging-fruit that some aspects of MV2 exposed.
What's that, you say? MV2 changes? Well there's 3 things.
1. Remote code execution. The ability for someone to just yeet commands into your browser. A little harder to do directly.. Still very possible, just with extra steps.
2. Removing the ability for extensions to access network requests directly, which is what adblockers often relied on. It also means malicious extensions could snoop on your requests. They still can, just with extra steps.
3. Background persistence, an extension could stay alive, maintain state, run timers, keep connections open, and coordinate across tabs. So this shuts off the "background persistence" piece -- but helps with ensuring better isolation. Still possible, but now requires yeeting your data to an external provider instead of keeping the state contained locally.
Those 3 changes are incredibly powerful, and will impact many, many Enterprise security tools. Tools that now instead will result in products like "Island Browser", and "Enterprise Chrome" being rolled out to supplement the functionality that MV2 gave us.
This change goes against the US and Australian government's hardening advice, and reduces the overall efficacy of security controls we're able to implement within our web browsers natively.
Here's the Australian Government's control relating to it:
> Control: ISM-1485; Revision: 1; Updated: Sep-21; Applicable: NC, OS, P, S, TS; Essential 8: ML1, ML2, ML3
> Web browsers do not process web advertisements from the internet.
And if you're wondering about what incentives there are that led to this change, you can read this letter written to the Chairman of the FTC by a US Senator back in 2020. This letter is linked to from the same CISA document I shared earlier.
You should read it in full, and consider what incentives the Senator was referring to -- and how they also apply in this scenario.
Those Enterprise Chrome products I mentioned earlier? Chrome's change has now put some of this functionality which was previously possible with an extension, behind the Enterprise Chrome Premium SKU: https://chromeenterprise.google/products/chrome-enterprise-p...
For tech B2B companies where the founders or executive team hold the majority stake in the organisation, yes. A failure to disclose or respond when there is a public notice on an .onion address, or a sample set of your customer data has been published online, creates tangible, direct commercial impact.
You should expect every deal in your pipeline to stall. Your product and company will be flagged by every GRC team, and every stakeholder trying to purchase your product will suddenly need to go to risk committees, or into meetings with CISOs, CTOs, and founders, to explain why buying from you is worth the risk compared to competitors who have not been breached.
If you have not addressed the issue, it becomes a literal deal-breaker. The sooner you write the press release, notify customers, and deal with the underlying problems, the sooner you can turn the incident into a credible story about how you responded, contained it, and improved.
If you do not respond, or you deny it, your deals are dead.
The reason I prefaced this with companies where the founders or executive team hold a majority stake is that I sincerely do not believe the same incentives do not exist for most other companies. The stock price is not meaningfully impacted by incidents like this; it is more affected by vibes, market conditions, and the general tech economy. There are a hundred things that will move the stock price before cybersecurity and data incidents do.
Operating revenue and profit, however, will be impacted. Executives on a death march for growth, who understand that an incident like this can wipe away a year of progress (and essentially their life's work), are far more likely to take it seriously. They are directly exposed to the commercial consequences.
The companies you see trying to sweep this under the rug, or outright ignore it, are usually one of two things.
1. They are so out of touch with their customers that they would rather listen to a lawyer chasing the “ideal legal-risk outcome” than pursue the best financial, customer and cybersecurity risk outcome. In my experience these are executives who are independently wealthy or already come from wealth, and their priority is simply keeping the status quo.
2. They are simply not incentivised to deal with it properly (carrot, nor stick). That is: they don't lose their bonus, they don't face the axe, and they aren't rewarded for doing anything "well" in response to it. They might say they're "inherently" exposed because if the business is impacted, so are they (stock price, performance bonuses) -- but that's incredibly disingenuous, as it's pretty much always not a material difference to them.
For B2C or B2B doing "traditional" stuff? No. The incentive simply just isn't there.
It makes sense when you have a somewhat fixed core team size. Frankly, in some regards, this is the responsible thing to do.
It means they’ll never grow modules or the codebase beyond what the team can reasonably maintain.
However on the other hand.. What does this mean for the existing team, are maintainers now worth considerably more to the project? What does this mean for the codebase, or the momentum of the project?
It’s an approach I would have expected for the likes of curl, or single-purpose libraries. But this is a mammoth decision for a mammoth project.
What you’re concerned about doesn’t stop at the employer.
Anyone with access to data being processed about you may have incentives that align similarly with your employer’s use case.
Advertisers, Internet service providers, phone manufacturers, social networks, tech platform providers, schools, families, spouses, nosy neighbours, nosy governments.
The scale at which you can build a summary about someone is astonishing.
How they breach policies, how they break laws, how they mishandle sensitive data, how they materially negatively impact customers.
This whole thing is now a litigation nightmare, and frankly I can’t believe Meta is doing this so publicly. They’ve created an incredibly dangerous and lucrative lever in which vexatious and otherwise incentivised individuals and organisations can subpoena and demand evidence which, provided the ample data available, will surely produce enough evidence given the expanse of their employer base. They simply need to have a thread to pull on, so a judge doesn’t deem it a fishing expedition.
Similarly, I worry for democracies with no checks or balances to prevent ruling parties from exploiting or abusing this power. For example, in India, there’s accusations of their equivalent of the NSA being used to spy on the opposition —- under the guise of “keep them honest”. https://www.idsa.in/system/files/book/book_IntellegenceRefor...
In other Western countries whenever this type of work is conducted, it’s usually at Director or Minister-level approval. There’s lawyers involved, it’s heavily documented. What happens when systems, or products, are given the implicit approval of this same function by their very nature?
It's moreso the "AI-isms" that irk me. It's interesting, but I'm not finishing the video because once I notice it -- I can't help but focus on it. Instead, I tl;dr'd the transcript.
People question my use of AI when I double `-` with an iPhone on the internet constantly.[0] I get it, it's annoying.
However, if our barrier for quality is "at it's core, the content of this is interesting", then the quality of this place will fall off a cliff. This is factoid-level interesting. It's not a hacker writing something profound or presenting a breakthrough in garbled grade 8 English. It's a fun fact being presented in an acceptably, inoffensive, reasonably produced format.. Is that the bar?
Such a list will never exist in an organisation of this size, with the amount of delegated management and operations required for these functions. In fact, it’s unlikely such a list is even _allowed_ to exist given the sensitive nature of some areas of the business, being a publicly traded company which works directly with regulated entities and governments.
It’d be interesting to hear a senior old-timer from MS to weigh in on their blog about this, and similar/adjacent problems that arise from working across such a colossal entity.
It’s a wonder they ever release anything new, if I’m being completely honest. The amount of governance, hoops, process and procedure across every aspect of their business must be staggering.
Agree, see the Delve fiasco. But that’s not their job. Their job is literally checkbox. However some audits are so poorly done, or have auditors with zero real world engineering or cyber experience, they’re actively harmful to a product or customer base.
Example: insane, complex password policies and password rotation policies. These are still pushed by auditors rather than trying to build a reasonable exception case with the client.
Sometimes good change comes from compliance. More than once I’ve seen major product resource shift to address major cybersecurity gaps, in response to a compliance led audit.
Compliance is not security, but engineers, especially solo ones tend to have their blinkers on when they’re trying to build something to first work.
No worries, it’s more about finding what the security and compliance teams care about — and making them comfortable. Compliance doesn’t equal security, I’ve onboarded startups with better security than the SOC2 certified, ISO27K Swiss cheese $B unicorn.
Hackers don’t target based on certification. It’s generally convenience and motive. Unknown startups who are laying solid foundations won’t show up on anyone’s radar for the first 2 years without some insanely unlucky event (i.e supply chain breach, an early employee doing something really dumb).
I’ll spend some more time replying to this next week, so circle back to this comment; I’m someone who regularly helps people get past these audits, meet the criteria customers are trying to assess with these certifications, and vet startups who don’t have these certifications or budget.
Then read through it and see what you can address immediately (EDR on your laptop, MFA on your cloud environments, etc), followed by role playing your client; “based on answers to this questionnaire, what would I not accept?”
There will be some items you can’t fix.
You’ll soon find out the majority of customers, including banks, governments, defence contractors, crypto startups — simply do not care. If they want to use your product, they’ll work with you.
It may be single-tenancy, it may require architectural changes, it may mean making it selfhosted with a time-bomb, but you’ll be able to address the requirements of the CISO, compliance monkey or executive.
I’ve yet to meet an industry or individual I can’t convince. Even if the product is a hot mess, half baked and radioactive — we’ll deploy it on a VM running inside of a VDI within the customer’s environment, because slopping together a migration path is _so easy_, and those early, highly regulated clients are worth it.
That happens at every level, from individual developers through to project leads and CTOs.
Consultancies are often no better. Choosing technologies that require substantial or highly specialised skill sets seems almost routine. I’m looking at you, Kubernetes.
I’m not entirely innocent here either. I owe a decent portion of my mortgage to MuleSoft consulting. That said, I don’t think I ever pretended it was always the best solution. Even while working directly for MuleSoft, my recommendation in probably half of the engagements was some variation of: ‘You’re using the wrong technology for this.’
But by then, an executive had usually tied their reputation to the project and the platform, commitments had been made, and changing course had become politically harder than continuing.
And so we persist.
In my experience, the best technology choices are boring ones. There’s still a large area of immature technology you can get creative with (like Backstage or Port for software catalogs and setting up a nice golden path”), but the meat and potatoes of development work should be a boring choice, that follows a well-tread path within a large ecosystem of developers.
There are exceptions, but they’re not for the majority of organisations.