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.
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.
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.
> 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.
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
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.
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
My Google account was not compromised. I wouldn't touch Polymarket ever again. There is some kind of massive scam happening here.
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?"
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.
[0] https://www.simonandschuster.com/books/Lying-for-Money/Dan-D...
This is completely unrealistic advice that 0% of people follow.
https://www.bbc.com/news/articles/c934dq95zpgo
https://duckduckgo.com/?t=fpas&q=public+schools+ransomware&i...
What would happen if America got complete control of this system?
Oh wait. Oops.
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)
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.
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.
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...
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
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.
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
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?
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.
There is no way to, for instance, only allow updates to a PWA from files signed by an offline key.
Wired's coverage (25 points) https://news.ycombinator.com/item?id=50296328
WSJ's coverage (20 points) https://news.ycombinator.com/item?id=50294287