In a world where node based editors and code are also equivalent to LLMs, it's not super clear to me that the future will not be nicely visualized and understandable nodes (generated by the LLM to explain things to me and to get guidence) kept in sync with the codebase.
Which has led to every game needing a central server running, forcing centralization where p2p used to work great. Also how Skype was able to scale on a budget, something now blocked, forcing you to raise money for more ideas than before. Running a matrix(?) node should be as simple as clicking install and it's just there, next time you're with your friends, nfc tap or whatever and your servers talk to each other directly forever going forward. But nope, there always is a gatekeeper now and they need money and that poisons everything.
I don’t think VOIP was a major factor in game centralization. The big one was selling cosmetics (easily unlock able server-side in community servers), and to some extent being able to police voice chat more. Major game publishers didn’t want to be in the news about the game with the most slurs or child grooming or what not.
Central servers are useful for more than just NAT hole-punching. They’re also great as a centralized database of records and statistics as well as a host for anti-cheating services and community standards enforcement.
Peer to Peer games with no central authority would be so rife with cheating that you’d only ever want to play with friends, not strangers. That sucks!
> Peer to Peer games with no central authority would be so rife with cheating that you’d only ever want to play with friends, not strangers. That sucks!
Back in the the day RtCW had a server anyone could run and you could give out the address:
If you can run your own server then that's still a central server. That still lets a community of people work with a central authority. It's just a different authority from the game's publisher.
In that sense, Mastodon is a centralized service because it's on someone's computer. That's not really what people mean by central. They mean we're increasingly reliant on game companies for networking infrastructure.
Is that all IPV4s fault? I don't think so. But it complicates things
I think you're muddling things up more than they need to be. A peer-to-peer game is one in which players connect directly to each other but neither is the host and there is no dedicated server. Game state is maintained separately on each player's computer and kept in sync by the netcode. Since there is no single source of truth for the game-state, so players are free to cheat by modifying the game's code to lie on their behalf. There is also the side issue of bugs in the game code causing the game-states to become irreparably desynchronized.
All of these issues are solved by having a central server for both players to connect to. Whether that server is owned by the game's publisher or by an open-source community is irrelevant from a technology standpoint. However, the prevalence of IPv4 networks and stateful NAT firewalls is relevant because it privileges those central servers over true peer-to-peer connections.
Don't put words into my mouth! I never said I didn't care about peer to peer networking and peer to peer gaming. I said it sucks if your only option to avoid cheating is to play with friends.
If you only care about gaming with friends, then peer to peer is an excellent way to do that (assuming the game doesn't have any synchronization issues, which some peer to peer games do).
So we acknowledge v4 and CG-NAT are a problem but don't want to use the already available solution because game developers took it upon themselves to DEFEAT NAT :)
That just reminded me of a peer protocol I worked on a long time ago that used other hosts to try to figure out which hosts were getting translated. Kind of like a reverse TOR. If that was detected, the better peering hosts would send them each other's local and public addresses so they could start sending UDP packets to each other, because the NAT devices wouldn't expect the TCP handshake first and so while the first few rounds didn't make it through, it caused the NAT device(s) to create the table entries for itself.
Was it Hamachi that was the old IPX-over-IP tunneling? I'm fairly sure it used similar tricks. IPX-over-IP is also done on DOSBOX, which incidentally made it possible to play Master of Orion 2 with friends in other continents.
> That just reminded me of a peer protocol I worked on a long time ago that used other hosts to try to figure out which hosts were getting translated. Kind of like a reverse TOR. If that was detected, the better peering hosts would send them each other's local and public addresses so they could start sending UDP packets to each other,
If that's the VOIP thing, yes, lots of people came to similar methods. That particular thing was for exchanging state, not VOIP or tunneling, so as long as participant groups overlapped it didn't really need a fixed server to be the middle which was handy for our purposes, although long network interruptions could make reconvergence take a while.
Does make me chuckle that so many people had to be working around NAT for so long and then people are like "NAT is way better than the thing that makes us not have to deal with the problem at all." Just had a bit of NAT PTSD remembering an unrelated, but livid argument between some network teams about how a tool defeating their NAT policies was malware. They had overlapping 10.x.y.z blocks, because of course they did :)
Nat hole punching works... most of the time. There are many edge cases and weird/broken networks which you just can't work around in standard ways. You get to see all kinds of broken setups if you work at VoIP providers. That's why everyone will use a central proxy server as the last resource - you'll mostly notice it only because of a higher ping.
I have to say it's just lovely seeing such a nicely crafted and written technical essay. It's so obvious that this is crafted by hand, and reading it just reemphasises how much we've lost because technical bloggers are too ready to hand the keys over to LLMs.
There is not enough information in pasted code for a language server to indent pasted in python code. Try copy pasting a random stackoverflow snippet into deeply indented python code.
What’s the pragmatic solution to ipv6 allowing everybody in my household to be trivially and stably mapped to a unique subnet? I like the accidental semi-randomization that ipv4 and ISP NAT offered and I don’t see anything like it short of putting my entire home net on a VPN (it’s expensive and can’t keep up with my ISP’s bandwidth)
Each device gets directly addressable from WAN with v6 but it also gets a randomised privacy IP that rotates very frequently so each individual device is just as "hidden" as it was with v4+NAT.
Your v6 subnet prefix is no different than whatever WAN-side v4 your NAT had. "Accidental semi-randomization" of the WAN side IP is not something one could reliably count on. Many ISPs just hand over a static-like IP, that is, even when it's supposed to be random the pool of IPs is so constrained that it's usually the same simply through the IP lease surviving power cycling. And that was before CGNAT.
If your concern is being identifiable through your IP then counting on whatever v4 artifact is the wrong move. Use a VPN with randomised exit nodes.
It's true that you won't get CGNAT without having CGNAT. Depending on your concern, it is possible to NAT66 to make your entire network appear as one IP.
I’d love to pay my ISP to rotate my ipv6 subnet every week. It’s not an option. My comcast IP changes every so often and that’s of some value.
It’s very unclear to me why people should be able to deterministic reach out to a specific device on my network. It has no value to me unless I run a service.
Then the value is clear, isn't it? The value is that it gives you the ability to run a service. Maybe you don't want to do that today, which is fine -- you can simply not make use of the ability. If you ever change your mind, it's available and you can use it.
Also... the ability for people to deterministically reach out to a specific device on your network is the exact same ability you use to deterministically reach out to specific devices on their networks, just viewed from the opposite side. If the Internet wasn't a place where people could decide to run services on their networks and connect to services that other people ran on their networks, what would the point even be?
IPv6 supports customer-controlled prefix rotation. You can select how often it happens by configuring your router to periodically change its DUID. Of course, your ISP can ignore this signal and always assign the same prefix anyway, but you can hardly blame that on IPv6.
There are lots of ways to run services without IPV6 transparently linking your service to every single other internet call that your household has ever made! I do it right now and have a little separability from my IPv4.
Everybody in your household is already mapped to a single IPv4 address that rarely changes with most ISPs. Mine hasn't changed in over 3 years. My IPv6 /56 prefix delegation hasn't changed, either.
It’s a little different, but you can use ULAs to have a static subnet with static device addresses.
One of the biggest changes from IPv4 when I enabled IPv6 a while back was that it’s fine and normal to have multiple addresses per interface now. ULAs are not globally routable, so I think of them as LAN addresses. Another option that comes to mind is mDNS, but I think support for that is not as widely accepted.
Global addresses can change, just as your home dynamic IPv4 probably did from time to time.
I'm a little frustrated with articles like this that scattershot their critique by conflating genuine failures with problems that even FAANGs struggle with.
In particular, I don't love it when an article attacks a best practice as a cheap gotcha:
"and this time it was super easy! After some basic reversing of the Tapo Android app, I found out that TP-Link have their entire firmware repository in an open S3 bucket. No authentication required. So, you can list and download every version of every firmware they’ve ever released for any device they ever produced"
That is a good thing - don't encourage security through obscurity! The impact of an article like this is as likely to get management to prescribe a ham-handed mandate to lock down firmware as it is to get them to properly upgrade their security practices.
Doesn't matter really, keeping blobs hidden doesn't actually do anything except make it slightly harder to analyze the software. Making all blobs easily and readily available is exactly what I want the vendor to do. Black boxes don't make things secure.
This blog post is pretty readable, but it's still obviously written with the help of an LLM.
A common trend is that LLMs lack the nuance and write everything with the same enthusiasm. So in a blogpost it'll infer things are novel or good/bad that are actually neutral.
Not a bad blogpost because of this, but you need to be careful reading. I've noticed most of the article on the HN front page are written with AI assistance.
I think maybe you’re reading this wrong. Reverse-engineering blog posts like this are just a fun and instructive way of telling the story of how someone did a thing. Having written and read a bunch of these in the past myself, I found this one to be a great read!
Edit: just want to add, the “how I got the firmware” part of this is also the least interesting part of this particular story.
Yes, heavily, because of the use of adjectives and repeating the points.
Here, I'll emphasize the words that elicit the tone:
> After some basic reversing of the Tapo Android app, I found out that TP-Link have their entire firmware repository in an open S3 bucket. No authentication required. So, you can list and download every version of every firmware they’ve ever released for any device they ever produced: [command elided] The entire output is here, for the curious. This provides access to the firmware image of every TP-Link device - routers, cameras, smart plugs, you name it. A reverse engineer’s candy store.
Highlighting (repeatedly) the ease and breadth of access is a basic writing technique to illustrate the weakness of a security system.
To me the phrasing seems objective. Making your binaries available to the public is good (though source would be better).
Replace [firmware] with [random popular GitHub repo] and nobody would blink. Replace [firmware] with [customer email address] and it would be a legal case. Differentiating here is important.
I think it fails to be objective because of the repetition. It's an open S3 bucket. No need to state that no authentication was required, it's already open. It's not about economy of writing but the repetition emphasizes the point, elevating the perceived significance to the author or that the author wants the reader to take away.
Furthermore, the repeated use of every when discussing the breadth of access seems like it would easily fall into the "absolutes are absolutely wrong" way of thinking. At least without some careful auditing it seems like another narrative flourish to marvel at this treasure trove (candy store) of firmware images that has been left without adequate protection. But it seems like most here agree that such protection is without merit, so why does it warrant this emphasis? I'm only left with the possible thought that the author considered it significant.
An 'open S3 bucket' sounds really bad. If it were posted on an HTTPS site without authentication, like the firmware for most devices, it wouldn't sound so bad.
Sure an open bucket is bad, if it's stuff you weren't planning on sharing with the whole world anyway.
Since firmware is supposed to be accessible to users worldwide, making it easier to get it is good.
But how is an open, read-only S3 bucket worse than a read-only HTTPS site hosting exactly the same data?
The only thing I can see is that it is much easier to make it writeable by accident (for HTTPS web site or API, you need quite some implementation effort).
Full blown production SPAs are served straight from public access S3 buckets. The only hard requirement is that the S3 bucket enforces read-only access through HTTPS. That's it.
Let's flip it the other way around and make it a thought experiment: what requirement do you think you're fulfilling by enforcing any sort of access restriction?
When you feel compelled to shit on a design trait, the very least you should do is spend a couple of minutes thinking about what problem it solves and what are the constraints.
No I agree with you. I think it is bad framing as "S3 open bucket" when people would totally understand an open website :)
I'm not shitting on anything except the wording in the article.
I guess I didn't word it clearly.
In our company we don't really serve directly from open buckets but through cloudfront. Though this is more because we are afraid of buckets marked open by mistake so they are generally not allowed. But I agree there's nothing bad about it. I just meant it sounds much worse (at least to someone in cybersec like me) and I don't like the effect used as such in the article.
No, it clearly has a gloating tone to it. 'A reverse engineer's candy store' is clearly meant as a slur.
When in fact TP-Link is doing the right thing with keeping older versions available. So this risks some higher up there thinking 'fuck it, we can't win, might as well close it all off'.
I just meant that it was very convenient to have the firmware images there on S3, nothing else :D Many vendors make the process of even just obtaining a copy of the firmware much harder than that, so for once I was glad it has been much easier. Also being able to bindiff two adjacent versions of the same firmware is great ... all in all I was just expressing my happiness :D
> Highlighting (repeatedly) the ease and breadth of access is a basic writing technique to illustrate the weakness of a security system.
It's a firmware distribution system. It's read-only access to a public storage account designed to provide open access to software deployment packages that the company wishes to broadcast to all products. Of course there is no auth requirement at all. The system is designed to allow everyone in the world to install updates. What compells anyone to believe the system would be designed to prevent public access?
> Maybe listing shouldn't be enabled even if all the files are public.
I don't see why. Support for firmware upgrades literally involve querying available packages and downloading the latest ones (i.e., apply upgrades). Either you use something like the S3 interface, or you waste your time implementing a clone of what S3 already supports.
Sometimes simple is good, specially when critics can't even provide any concrete criticism.
It's not a necessary interface. Do the clients actually use S3 listing to determine what the latest firmware is? Personally I would put a service in the middle that takes in the model number, region, etc and then returned the most recent firmware URL. There's no reason to have historical versions be easily listable by curious people.
Why not? The firmware was already public at one point. If people are analyzing your app to find an S3 bucket full of firmware, I'd assume they'd have a pretty good reason to go through the effort.
Or to illustrate the convenience to the point of the article, being reverse engineering; not necessarily to critique their security practices here. Being easy to reverse engineer is not necessarily a weakness of security (as the inverse would simply be obscurity).
I think this kind of critique often leans too hard on “security through obscurity” as a cheap punchline, without acknowledging that real systems are layered, pragmatic, and operated by humans with varying skill levels. An open firmware repository, by itself, is not a failure. In many cases it is the opposite: transparency that allows scrutiny, reproducibility, and faster remediation. The real risk is not that attackers can see firmware, but that defenders assume secrecy is doing work that proper controls should be doing anyway.
What worries me more is security through herd mentality, where everyone copies the same patterns, tooling, and assumptions. When one breaks, they all break. Some obscurity, used deliberately, can raise the bar against casual incompetence and lazy attacks, which, frankly, account for far more incidents than sophisticated adversaries. We should absolutely design systems that are easy to operate safely, but there is a difference between “simple to use” and “safe to run critical infrastructure.” Not every button should be green, and not every role should be interchangeable. If an approach only works when no one understands it, that is bad security. But if it fails because operators cannot grasp basic layered defenses, that is a staffing and governance problem, not a philosophy one.
I’m beginning to think maybe I’m the only one that read this whole thing. The firmware storage isn’t the security through obscurity problem being talked about here. The hardcoded TLS private key definitely is though. And yes, it deserves shaming… terrible practice leads to terrible outcomes. Nobody is surprised that this is coming from tp-link at this point though.
GitHub already has a program to scan for keys, since publishing Discord tokens by mistake used to get the token immediately revoked and a DM from the system account saying why
I thought there were many first and third party services looking for this kind of thing (AWS, Github, GWS, crypto, etc tokens). Seems weird that a F500 company repo was not receiving the regular, let alone extra deep scanning which could have trivially found these.
There was a recent post from someone who made the realization that most of these scanning services only investigate the main branch. Extra gold in them hills if you also consider development branches.
For things pushed to github, github has quite sophisticated secret scanning. They have a huge list of providers where they will automatically verify if a potential key is real and revoke it automatically [2], and a smaller list of generic patters they try to match if you enable the matching of "non-provider patterns".
This seems to be a case of someone accidentally publishing their github token somewhere else. I'm not sure how github would cheaply and easily prevent that. Though there are third party tools that scan your web presence for secrets, including trying wordlists of common files or directories
GitHub wants to sell a service. Keys are convenient. Better alternatives in authorization and authentication exist, and GitHub is very aware of them. They even offer and facilitate them. For example, see OIDC. But many users either want keys because they're used to them or GitHub is sure they do, so they continue to offer them to avoid friction. The alternatives require more parameters, thought, and coordination between services.
GitHub has deprecated classic tokens, but the new tokens are not backwards compatible. The deprecated tokens have also continued to be available for some time. Real security professionals will tell you flatly "tokens are bad", and they're right. They're leakable attack vectors. The tokens are the problem and discontinuation is the solution. Scanning is simply symptom treating, and given what I know about Microsoft culture, I doubt that's going to change soon or quickly.
They do scan but they miss a lot. The frequency decreased after Github started scanning all repositories but I still report leaked secrets to bug bounty programs pretty often.
Unfortunately Home Depot don't have a bug bounty program so I don't scan them.
They at least scan GitHub for all kind of exposed tokens in public repositories, and even have partnerships with the companies where you can connect with those tokens (SaaS, PaaS...) to verify they're valid and even revoke them automatically if necessary.
I think there are crawlers that do that. Somehow I accidentally had a commit with an openai key in it, and when I published an open source repo with that commit within ~20 seconds I got an email from openai someone had retired my exposed key.
The article doesn’t say where the Home Depot token was published. Almost certainly not on GitHub or it would have been invalidated. But AFAIK GitHub doesn’t crawl other sites looking for GitHub tokens. I suppose Microsoft could provide GitHub a feed of GitHub tokens found by their Bing crawlers.
They definitely do have automation to scan for this already. I've seen plenty of alerts (fortunately all false positives that triggered on example keys that weren't real). I don't know how comprehensive it is, but it does exist.
I've got friends who tell me they'd never consider applying for YC because they are on a classic H1B with a tech company. What typically happens with folks on a H1B who make it into YC?
That makes sense ... is there a typical path? Basically - are they right in thinking it's a high risk thing for them or should I encourage them to take a shot?
My understanding is that their time spent on the company before YC accepts them is the biggest risk factor?
The general rule about computer fans is that the bigger they are the the quieter they are (i.e. 140mm > 120mm etc.) It's a wierd market gap that large "commercial" air moving fans are so loud.
reply