3 ms·
Not defending him, but he does state that unlike the other mobile providers he's worked with, this K-Pop company's backend system would lock _any_ phone number,
by treesknees 5y ago
Not defending him, but he does state that unlike the other mobile providers he's worked with, this K-Pop company's backend system would lock _any_ phone number, not just the ones they're responsible for. Perhaps he didn't know this. I bet normally he'd generate random numbers not associated with the provider, check they show up as "locked" in the database, under the assumption that the backend actually doing the locking signal would reject the numbers due to them being under control of another operator.
It's similar to our networking lab where we generate bogus traffic using random src/dst IP addresses under the assumption that our null routes and firewall will block them from the real Internet. In this case, the provider just decided no firewall was needed. We can't use "fake" IP addresses (yes there are IP ranges for internal use but that doesn't work for certain testing scenarios.)
- polartx 5y agoThe fact that he was running production code and not writing the result to any kind of log file, which would only take a couple more lines of code, one more dependency (if he wanted to skip some time rolling his own), and a couple of megs of storage, is so absurdly irresponsible, I’m surprised he wrote this post up at all—most would be too embarrassed.