Do one thing, and do it well.
The unix philosophy prevails!
425 karma · joined January 12, 2022
The unix philosophy prevails!
You know, the companies that say security is their number one priority, or companies that scream “developers, developers, developers”. How Google and Apple didn’t come up with something together eludes me, but then again, we have entire ecosystems and categories deployed in the areas they don’t service (auth, application control, etc).
I think the SaaS is dead meme is really just a “SaaS can’t be lazy anymore”. The days of offering a product that technically does something, but is incredibly poorly designed, or not well integrated, or unsupported — are over.
If your SaaS doesn’t support both Google and Microsoft; macOS and Windows; iOS and Android; automated provisioning, complex/fine-grained RBAC, customisable onboarding.. You’re dead in the water.
The moat of features has evaporated, and your only defence is good UX, stability and TCO.
AI isn’t eating SaaS. It’s eating shitty businesses.
Password Manager SaaS that have been breached are dead.
Auth providers that scale their pricing model to their investors growth expectations are dead.
Platforms and technical products that did something a script could do, with little support for real business software, ecosystems and environments are dead.
You think we’d have Carmack’s DOOM with “best practice”? Hell no.
I’ve worked for incredibly talented people who choose the wrong technology, approach and design for problems they could have predicted or anticipated, had they seen it or a similar problem before, or had context about the organisation, customer or size of team managing the proposed solution. But they don’t.
AI is great at giving textbook and “Enterprise grade” solutions; but as code production cost reduces — I think the value of simple, digestible solutions will grow. TDD et al can also be helpful, but at a certain point it becomes too abstracted, too complicated, too hard for any one person to grasp.
At that point I think test managers who understand user journeys will be worth their weight in gold, and the real value in any solution becomes good, represented testing.
But this is only stuff I can run locally, or it’s a cloud model.
So.. This is good for right now!
https://huggingface.co/zeropointnine/Darwin-TTS-1.7B-Cross-Q...
Added it to my blind TTS model comparison leaderboard. So far Darwin TTS is the open model leading the pack, ElevenLabs is at the lead.
i.e. retail investor → brokerage platform → clearing/execution infrastructure → Jane Street → payment back toward the brokerage side of the chain.
Who captures the economic value created by retail order flow?
Jane Street.
In an ideal market, this product line shouldn't exist. Institutional investors should not be making money on the activity of retail investors.
What incentives determine where that flow is sent, and would investors receive better execution if their orders were exposed to genuinely competitive price formation rather than privately internalised by a concentrated group of wholesalers?
The regulators should be squashing any HFT related or retail order flow, but it's so opaque _by design_ that getting policymakers, or the general public, to understand that retail investors are paying some portion of tax on their $20T USD annual trades to these companies.
Granted, these order flows _sometimes_ work the other way -- and retail users get a better deal on a trade.. But would you really expect the market to be worth what it is, if that was the case less more often than not?
There is a clear and obvious conflict: the broker is supposed to seek the best execution for the customer while potentially being paid by the firm receiving that customer’s order. How can that be, when the broker's in bed with the liquidity providers?
Cmd+Option+I > Console > 'allow pasting'
const onboarding = document.querySelector('#onboarding'); const app = document.querySelector('#app'); onboarding.style.setProperty('display', 'none', 'important'); app.inert = false; app.removeAttribute('aria-hidden'); document.querySelector('#prompt')?.focus();
Also, warning:
# Share chats with Bullet — helps us improve model routing and answer quality
Enabled by default.
That's a 90% uplift since the original pricing, in a market that is already showing signs of seizing.
With Apple offering leasing options, CXMT knee-capping Samsung, all of the big tech players on a run to outspend on CapEx by the end of the year..
We're at a point where local models are exceptionally capable, model-on-silicon dies like Taalas (recently acquired by AMD) may be cutting inference cost substantially for the 90% of work we do day-to-day (similarly Alibaba's T-Head division with open-model-forward inference chips being produced domestically in China).
If we shifted all of the design/planning to cloud models like Fable 5/Sol 5.6 Ultra, and day-to-day operational inference to these chips -- it's quite likely we'll squash usage to single-digit percentages of what we're currently using. But we should also expect the model providers to take a similar approach.
In any case -- I'm keen on demand destruction, both as a consumer and someone without skin in the game.
If you act in good faith, communicate clearly, and conduct yourself reasonably, most companies will work with you — even when you've technically wandered outside the neat boundaries of their risk-appropriate, regulatory-reviewed policy.
That isn't protection, of course. Eventually you'll encounter a bounty program run primarily by lawyers, procurement, or someone optimising a graph trend-line.
And we know what tends to happen next.
Those programs, and organisations, develop reputations. Researchers talk. Companies get discussed at conferences, in private groups and across the community, and some become informally blacklisted.
Microsoft is a useful recent example: researchers have publicly walked away from five-figure bounties to make a point. There are excellent people working there, but organisationally Microsoft has repeatedly struggled to engage with the security community in a way that feels collaborative, rather than adversarial. Unless you're one of their paid partners, intermingled in their ecosystem.
A lot of that seems to come down to incentives: somebody, somewhere, wants the numbers to look better.
That doesn't work particularly well in an industry that, like most industries, ultimately runs on relationships, trust and specialisation.
If a company marks something critical as informational, sometimes the most effective response is a CVSS parameter argument. It's a snarky comment:
"Okay — so if I find a way to abuse your own infrastructure to message your customers, trigger a major incident and create regulatory problems for your clients, you'd prefer I treat that as informational too, and instead just report it to regulators?"
Surprisingly often, that gets the issue reconsidered.
Have you annoyed an analyst? Maybe. Does it matter? Probably not. Neither of you will remember the exchange a week later, but you might have corrected a bad risk decision on their side and you'll see a positive outcome on your side. Mistakes happen.
I generally advise companies and hackers alike to follow Kiwicon's #1 rule.
Most of my research starts with: _There is absolutely no way this works_. Then it works.
I've been thinking that a lot more lately.
Companies and hackers are both heavily incentivised to reduce the friction involved in vulnerability disclosure, particularly for large organisations. The platforms are good enough now. They're email in 2007: imperfect, occasionally frustrating, but substantially better than what came before.
They make SLAs possible. They provide structure and administration. Things still go wrong — companies stop responding, analysts drop the ball, hackers can be idiots — but the model basically works.
Decentralising disclosure again would make life significantly harder for individual hackers. We'd end up back on email, probably building email-powered bounty CRMs that consume a small country's worth of tokens just to keep track of everything.
For smaller organisations, though, I wouldn't touch a public bounty platform with a 10-foot pole. Run a private program first (through the platform). Having been on the receiving end of beg bounties, automated scanner output and increasingly AI-generated slop, most smaller security teams simply cannot scale to absorb the noise.
The more interesting way to think about these platforms is that they're becoming the LinkedIn of hacking.
For hackers, the path is fairly straightforward: build a rep through useful -- but oftentimes unsolicited disclosures, get invited onto private programs, and gradually establish a profile with a strong signal-to-noise ratio.
For companies, they're increasingly a recruiting and relationship-building tool.
And for the platforms, I think there's a much larger opportunity for them in community.
They should be significantly better at understanding hackers: what they're good at, what technologies interest them, which industries they understand, and where they're located. Today, that profiling is laughably poor, to the point the questionnaires on areas by these large platforms are out of date by several years.
Then use the data.
Run small, highly targeted events: state- or city-based meetups, lunch-and-learns, product launches, bounty program launches and technical briefings. They don't need huge sponsorship budgets or prize pools. They need the actual community involved. Pay for dinner, sponsor a talk.
A lot of existing events seem to start with companies, sponsorship packages and monetary amounts, then work backwards. I think that's backwards.
As a weekend hacker, I'm far more likely to spend time on a program because something about it is interesting: you're launching an AI feature, handling financial data in a new way, using Node/GCP/a TI-82 calculator, or exposing some weird technical surface I want to understand.
And I'm far more likely to build a useful relationship with a company if I can actually meet the people behind the program. Hackers can provide much better feedback than a semi-generated report, and companies can explain far more than a stale domain list and scope document — which, realistically, we'll be ignoring 99.99% of the time anyway.. Unless it's government. I quite like my freedom.
Intel/Barefoot Tofino 2, VHDL/SystemVerilog, FPGA, QSFP28 (100GbE networking), P4 programming.
Their buyers don’t have customer stories. They don’t sell to SaaS companies.
I actually recall the lead engineers in my department coming into work on their last day with a harddrive. The same people who had access to national databases, and production systems that impacted the majority of the country’s population. That simply wouldn’t happen today.
Although I’m not someone who’s dealing with PCB schematics or bleeding edge IP.
This is definitely being done with private models by HFT/quant firms, data processing agencies/orgs (large intelligence agencies, _every_ data analytics org, etc).
I think back to the questionable things _I've_ done that _don't_ amount to data theft, but _should have_ caused someone to probably kick off an incident/investigation.. But they didn't.
- git cloning every repository in the company (who am I kidding, I do this in _every_ company
- airdropping stuff to my personal phone (my profile photo, but it could have been the aforementioned git repos)
- using sharedrop/similar services (to copy my RSS/news feeds, favourites bars) from my work laptop
- enumerated staff/ops dashboards/tooling to get shit done (think: enumerating the CRM before Lazarus and Lap$u$ made it cool)
GTX 1080 in 2016: 8 GB of GDDR5X, with 320 GB/s.
RTX 5090 in 2026: 32 GB of GDDR7, with 1.792 TB/s.
This is fun, what's next?!
PCI 8.0 is breaking 1TB/s, GDDR7 is 1TB/s.
With just the _current_ timeline, things are looking like they'll compress once we get over this initial lump.
1080 GTX in 2016. Cutting-edge, an insanely powerful consumer card for the time. Theoretically around 8.87 to 8.9 TFLOPS.
5090 RTX in 2026. Cutting-edge, an insanely powerful consumer card for today. Theoretically around 104.8 TFLOPS.
In the same timeframe mobile processor CPU's went from 0.001 TFLOPS, to today's Apple's A19 Pro chip which delivers 2.074 TFLOPS.
That's _without_ getting into ASIC's, or purpose-built hardware like Taalas's model on silicon HC1, or generic AI dies like what they're planning with HC2 or Cerebras, which will massively compress the timeline.
70mm IMAX, as Nolan intended, is the ideal setup.
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.
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.
Most people also tolerated the hilarious gigabyte JSON parsing bug in Grand Theft Auto for years, until a hacker patched it and cut GTA Online loading times by around 70%: https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times...
It was good enough, even if people noticed how bad it was.
Business applications, and typical software really doesn’t have to be super tuned or perform fast. It just needs to work.
At least until your product category has been commoditized, and _then_ you’re competing on experience.
This is true of any LLM-generated quiz.
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.
CISA's own guidance on this is pretty straightforward (aptly named Securing Web Browsers and Defending Against Malvertising for Federal Agencies): https://www.cisa.gov/sites/default/files/2023-09/CISA%20CEG%...
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.
https://www.wyden.senate.gov/imo/media/doc/011420%20Wyden%20...
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...
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.
GDPR, CCPA, whatever, hasn't moved the dial.
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.
I guess we’ll just have to see.