I think we are about to enter a world where security compromises occur at least an order of magnitude more often due to AI. The fact that AI is sometimes wrong benefits the attacker because they can just automate attacking with agents until they breach a system and the failed attempts don't matter.
Nicholas Carlini has a good talk about the risks on his homepage https://nicholas.carlini.com/ (can't link to the talk directly for some reason)
The corollary is that service access will become increasingly penalized, authenticated, and finicky as the most general first line defense against automated "informed brute force" attackers will be to slow or ban access that looks like them.
If you've got a lot of roving bandits with fancy lockpicks, you're village needs to harden the walls, reduce the number of entry points, identify and document entrants more universally, check under more carriages and inside more trunks for stowaways, etc. And with all that comes delays, imprivacy, accusations, false positives.
The low trust world that we're headed towards isn't going to be nearly as fun.
Building on your analogy: Currently we spend a lot of time and effort making sure our walls appear nice and inviting, with lots of convenient entry points where advertisements can be placed. In the future we will build ugly walls with a few well guarded entrances.
What I mean is, look at how much time and effort we spend on making software services beautiful and branded, and so little time spent on security. In the future we'll probably have fewer webpages and more hardened text-based APIs that end users interact with via their AI agents.
SRI only really works if the 3rd-party script never changes, in which case why is it a third-party script?
If it changes and the hash no longer matches perhaps due customer changing config then the site is faced with the challenge of either the browser refusing to load the script (with potential breakage) or reporting the change which then is probably ignored
It's not really a simple fix for the way the web is built today
usually scripts have versions, this protects you from compromised cdns as well where you publish assets in a different location compared to where your frontend is served.
If a library serves a script and your site manages user funds you should probably avoid using it or use a cdn that does.
I am not quite sure, but there's also other integrity mechanisms that gurantee that a file was signed by the library developer via a served header with the signature of the file.
For 50 years, computer security has largely been built on the theory that most targets aren't worth the relatively high effort to compromise, so it's not worth it to spend the money on security. We're now reaching a point where the effort to compromise is dropping close to 0, which means we've got 50 years of insecure software to reckon for.
The advice today is the same as it has ever been, though. Always assume that any networked computer is or may become compromised. Do not do anything critical on a networked computer, because it is or may become compromised. You can still use computers, but assume that a bad actor may take control at any time, and plan for that eventuality.
For example, if you are hooking up a networked computer to your town's water supply system, ask yourself "what would happen if Iran got complete control of this system?" If you're putting your school system's students' mental health data into a networked computer, ask yourself "what would happen if all of this data became public?"
A better framing is that security has largely been built on theory that most targets aren't worth the effort to target, so security spending is focused on preventing/mitigating untargeted spray-and-pray attacks.
Computer security has largely been built on the “not enough bears” theory.
Every target is worth attacking, but there are not enough bears to eat everybody. Sure, the bears are breeding, but exponential growth does not look threatening until it suddenly is.
I don't think the "breeding rate" was the limiting factor.
It reminds me of a bit from the book Lying For Money [0], where the author notes that you can often find multiple layers of scams attached to other scams, just like meta-parasite in biology.
My new security through obscurity is to collect esoteric modern LLM written software, like this sweet gem of a terminal editor written in fortran: https://shithub.sh/fortrangoingonforty/facsimile
> The advice today is the same as it has ever been, though. Always assume that any networked computer is or may become compromised. Do not do anything critical on a networked computer, because it is or may become compromised.
This is completely unrealistic advice that 0% of people follow.
I agree it's rarely followed. I don't think it's unrealistic. No one needed to connect water infrastructure or student data into the Internet, but we did, and the obvious thing happened.
Friend of mine, who's been treated as the unlucky one as an inside joke, made a binance account - after avoiding crypto for years - just hours before the hack happened, it's now official lore that this whole chain of security incidents is entirely his fault.
Due to similar bad timing I got my first Playstation right before the hack in the early 2010s that took down the Playstation network for a whole month. When they offered a make-good to their customers I didn't qualify because my account was too new. I never bought another Sony product again.
This is the same style of attack that took 1.5B from Bybit ~1yr ago.
Fundamentally: There is no way to lock webapps to reproducible builds.
Except: IPFS could do it but IPFS has been very very poorly maintained.
I published IPFS-boot ~1yr ago and its a simple idea:
1. deploy a webapp bootloader using something immutable like IPFS
2. bootloader is basically react hot reloading except user agrees what to load
3. bootloader polls a mutable list of app updates and user agree or disagree each update
Now the bootloader has a static content addressable URI but it can also do updates. TBH I think IPFS may be a lost cause but something needs to take its place and this idea is transferable to whatever that is. https://github.com/rhodey/IPFS-boot
You’re right, but the risk here could be reduced significantly by not loading dozens of third party marketing, analytics, and tracking scripts; one of which was supply chain compromised in this case.
Of course, that goes against commercial interests.
About a month and a half I made a Polymarket account with my Google login. I never traded anything. My account got hacked and they started draining my bank account. Polymarket support was completely non responsive. My bank reversed the charges. About 5 days later I got a text from Polymarket support telling me that it looked like I was having trouble making a deposit and they could help me out. I sent them screenshots of them not responding to my support requests and then never heard back.
My Google account was not compromised. I wouldn't touch Polymarket ever again. There is some kind of massive scam happening here.
gnabgib | 18 hours ago
Wired's coverage (25 points) https://news.ycombinator.com/item?id=50296328
WSJ's coverage (20 points) https://news.ycombinator.com/item?id=50294287
trio8453 | 17 hours ago
mcmcmc | 17 hours ago
n_u | 17 hours ago
Nicholas Carlini has a good talk about the risks on his homepage https://nicholas.carlini.com/ (can't link to the talk directly for some reason)
swatcoder | 17 hours ago
If you've got a lot of roving bandits with fancy lockpicks, you're village needs to harden the walls, reduce the number of entry points, identify and document entrants more universally, check under more carriages and inside more trunks for stowaways, etc. And with all that comes delays, imprivacy, accusations, false positives.
The low trust world that we're headed towards isn't going to be nearly as fun.
Buttons840 | 14 hours ago
What I mean is, look at how much time and effort we spend on making software services beautiful and branded, and so little time spent on security. In the future we'll probably have fewer webpages and more hardened text-based APIs that end users interact with via their AI agents.
himata4113 | 17 hours ago
For now most of these appear to be related to supply chain attacks which can be avoided with basic discipline and using features that browsers had for years: https://developer.mozilla.org/en-US/docs/Web/Security/Defens...
youngtaff | 16 hours ago
If it changes and the hash no longer matches perhaps due customer changing config then the site is faced with the challenge of either the browser refusing to load the script (with potential breakage) or reporting the change which then is probably ignored
It's not really a simple fix for the way the web is built today
himata4113 | 16 hours ago
If a library serves a script and your site manages user funds you should probably avoid using it or use a cdn that does.
I am not quite sure, but there's also other integrity mechanisms that gurantee that a file was signed by the library developer via a served header with the signature of the file.
youngtaff | 14 minutes ago
skinfaxi | 15 hours ago
youngtaff | 13 minutes ago
Integrity reporting can detect when the script changes
coldpie | 17 hours ago
The advice today is the same as it has ever been, though. Always assume that any networked computer is or may become compromised. Do not do anything critical on a networked computer, because it is or may become compromised. You can still use computers, but assume that a bad actor may take control at any time, and plan for that eventuality.
For example, if you are hooking up a networked computer to your town's water supply system, ask yourself "what would happen if Iran got complete control of this system?" If you're putting your school system's students' mental health data into a networked computer, ask yourself "what would happen if all of this data became public?"
pdpi | 16 hours ago
Veserv | 16 hours ago
Every target is worth attacking, but there are not enough bears to eat everybody. Sure, the bears are breeding, but exponential growth does not look threatening until it suddenly is.
Terr_ | 16 hours ago
I don't think the "breeding rate" was the limiting factor.
It reminds me of a bit from the book Lying For Money [0], where the author notes that you can often find multiple layers of scams attached to other scams, just like meta-parasite in biology.
[0] https://www.simonandschuster.com/books/Lying-for-Money/Dan-D...
bongofizzbuzz | 16 hours ago
sellmesoap | 16 hours ago
specproc | 15 hours ago
What would happen if America got complete control of this system?
Oh wait. Oops.
yrjrjjrjjtjjr | 14 hours ago
This is completely unrealistic advice that 0% of people follow.
buildbot | 14 hours ago
coldpie | 13 hours ago
https://www.bbc.com/news/articles/c934dq95zpgo
https://duckduckgo.com/?t=fpas&q=public+schools+ransomware&i...
ProllyInfamous | 11 hours ago
...with a hint of sarcasm, but the percentage is definitely a non-zero number.
no-name-here | 5 hours ago
It seems like the only “safe” option is a PC (+storage) that never attaches to a network, but that extremely limits its usefulness.
direwolf20 | 14 hours ago
aucisson_masque | 10 hours ago
no-name-here | 5 hours ago
ciupicri | 16 hours ago
chistev | 16 hours ago
HolyLampshade | 16 hours ago
mvc | 17 hours ago
charlieyu1 | 17 hours ago
dumberquestions | 17 hours ago
gdulli | 15 hours ago
jareklupinski | 12 hours ago
rhodey | 15 hours ago
Fundamentally: There is no way to lock webapps to reproducible builds.
Except: IPFS could do it but IPFS has been very very poorly maintained.
I published IPFS-boot ~1yr ago and its a simple idea:
1. deploy a webapp bootloader using something immutable like IPFS
2. bootloader is basically react hot reloading except user agrees what to load
3. bootloader polls a mutable list of app updates and user agree or disagree each update
Now the bootloader has a static content addressable URI but it can also do updates. TBH I think IPFS may be a lost cause but something needs to take its place and this idea is transferable to whatever that is. https://github.com/rhodey/IPFS-boot
amluto | 14 hours ago
One could absolutely use subresource integrity to lock one’s reference to a vendor’s subresource to a specific version. That’s what it’s there for.
dinosaurdynasty | 14 hours ago
There is no way to, for instance, only allow updates to a PWA from files signed by an offline key.
rhodey | 13 hours ago
lxgr | 14 hours ago
How are you going to verify your thousands of dependencies, some of them obfuscated/closed source? And if you can’t, what does integrity buy you?
rhodey | 13 hours ago
dannyw | 8 hours ago
Of course, that goes against commercial interests.
bcvvvy | 14 hours ago
sroerick | 14 hours ago
My Google account was not compromised. I wouldn't touch Polymarket ever again. There is some kind of massive scam happening here.
VCFundedGenYer | 13 hours ago