I think the best answer lies somewhere in compartmentalization and fine-grained permissions. In this case: run it in some kind of secure container which has access to read browser history, and write to its database, but definitely does not have network access.
Unfortunately there's no one-size-fits-all solution for this yet, but there are a lot of groups attacking it from different angles: Qubes, GrapheneOS, Firejail, Bubblewrap, Android/iOS app permissions, Landlock, App Sandbox, etc.
> ...run it in some kind of secure container which has access to read browser history, and write to its database, but definitely does not have network access.
We should be doing this with all software, regardless of provenance, anyway. Least privilege applies to servers just as much as it does to users. Even if the software isn't untrustworthy you can be it has vulnerabilities.
My first go-to is network segmentation because I spend most of my time doing networking work. For every vendor who has shit-talked me to Customers ("Wah, wah! Your networking vendor is making this so much harder because they want us to enumerate our traffic!") I have concrete examples I can cite when attacks were stopped by network segmentation (preventing shellcode from downloading a payload, preventing C2 communication, firing off alerts when unexpected network traffic starts coming out of a host, etc).
Beyond network segmentation, I am very suspicious of software that needs to run as a privileged user. So many attacks get easier when privilege escalation in the host OS is already done for you.
Google/Forrest rushed to embrace AI/Dan, and completely forgot about News/boat, which kept chugging along with no one at the controls until it degraded/crashed.
TDD is done in a tight loop (minutes) while coding. For every little micro-feature/fix, you write a test for the new behavior you want, implement the minimal ugly fix to get the test to pass, then rely on the tests so you don't regress as you clean up.
LLMs struggle with TDD. They want to generate a bunch of code and tests in large passes. You can instruct them to do red/green TDD, but the results aren't great.
SDD starts before implementation, and formalizes intent and high-level design. LLMs eat it up. The humans can easily reinvent the worst parts of waterfall if they're not careful.
You can do better: cut to 0%, let the needle fall, go back to 100% for a moment to catch the needle as it approaches the bottom of the scale. If you want to be fancy, add some quick sinusoidal ramps to smooth out the derivative.
The interest is BECAUSE it's well explored territory. The concept is proven and works fine.
On the low end where RISC-V currently lives, simplicity is a virtue.
On the high end, RISC isn't inherently bad; it just couldn't keep up on with the massive R&D investment on the x86 side. It can go fast if you sink some money into it like Apple, Qualcomm, etc have done with ARM.
> Do you think Apple spends more money than Intel on chip design?
Absolutely. Apple's R&D budget for 2025 was 34 Billion to Intel's ~18 Billion (and the majority of Intel's R&D budget goes to architecture, while for Apple, that is all TSMC R&D and Apple pays TSMC another ~$20 billion a year, of which, something like 8 billion is probably TSMC R&D that goes into apple's chips).
Sure not all of Apple's 34B is CPU R&D, but on a like-for-like basis, Apple probably has at least 50% more chip design budget (and they only make ~10-20 different chips a year compared to Intel who make ~100-200)
Correct, ARM does not dominate x86 in desktop and servers. Just everywhere else.
Apple is top 5 for laptop and desktop market share. So, pretty sure Apple RISC Silicon has a presence in those markets. Very recently, Qualcomm has entered as well. And of course Chromebooks are primarily ARM.
ARM has only recently entered the server market. Already it is having some success, especially with hyperscalers.
RISC-V is about to enter all those markets. I mean, RISC-V silicon is in use in the cloud. But it is still an experiment at this stage. And you can buy a RISC-V laptop. But they are only for devs.
As a kid I took a lot of classes at the Lawrence Hall of Science in Berkeley, which was paradise for fledgling nerds. On the last day they would have a little closing ceremony with some cute little science experiment. One of my favorites was "Going Out With A Bang".
The instructors would bring out a helium balloon and a candle on a meter stick. The balloon goes pop, huzzah.
Then the twist. "Hey, wanna do it again?" All the kids would be like "meh, I guess?" They would then bring out a balloon full of hydrogen (maybe some oxygen too?). It would look identical to the first one, floating there tethered to the lab bench.
When the candle hit the second one, it made a white flash and a really sharp BANG. It was an order of magnitude louder, and you could hear the transient bouncing off the walls and echoing in the halls. It made an impression.
If you have a herd of systems - prod environments, VMs for CI, lots of dev workstations, and especially if your product is an appliance VM: you might want to run your own apt mirror, creating known-good snapshots of your packages. I use https://www.aptly.info/
There's a technical reason for it: the voltage sags when the battery is discharged quickly. Ah is relatively constant, but Wh decreases significantly with faster discharge rates, so it can't specified as a single figure.
That's a bit cursed mental model tbf... The voltages of batteries, in the first place, is function of state of charge. 100% = 4.2V, 0% = ~2.7V, 50% is 3.7V(by volume or something. 2.7 is also technical absolute minimums, cutoff voltage is usually more like 3.2V. Please don't abuse the battery in the ranges between 3.2 to 2.7V, let alone below).
Charge/discharge current capacity is constant throughout, at least so battery manufacturers say, at 1-20x the amp-hour capacity depending on the cell. Usually 5x or less.
Since energy = voltage x current, instantaneous W capacity is higher at first, reducing as it becomes supply side limited rather than load side limited.
But all those is irrelevant to why everyone uses mAh, it's because products with biggest numbers sell fastest. Marking capacity in Wh is noble, but it's a clearance worthy sin if you ask the shelves.
Unfortunately there's no one-size-fits-all solution for this yet, but there are a lot of groups attacking it from different angles: Qubes, GrapheneOS, Firejail, Bubblewrap, Android/iOS app permissions, Landlock, App Sandbox, etc.
reply