If you’re working with them I’d like to highlight that if they have a messaging platform with children on they are going to have to take safety extremely seriously. I know the laws in the uk are not popular here but the checklists of risk assessments are worthwhile doing - cases where people can privately message children are really high risk because you’ll get a bunch of people who really want to message children. If users can send images you’ll have CSAM to deal with.
That "job offer" tells me everything I need to know about this guy. Cheerfully dictating what you're going to do as if it's a great opportunity for you, with an obvious ulterior motive. Just "you will start tonight!", without so much as a mention of pay or availability, and oh by the way take your post down. Lol.
I used to meet clowns like this all the time when I freelanced years ago. Back then they called themselves "ideas guys" and liked to make you sign an NDA for the privilege of hearing their braindead overplayed product idea. Scumbags and users, every one of them, always looking for a shortcut to personal gain.
> The developer has been given responsible disclosure and I have been informed that steps are being taken to address the security concerns.
There is still no timeline or other information about the events, which is unfortunate; I'd expect the author to document and report this in such a situation.
Valid security issues buried under unnecessary smugness and basic 'techniques' like demonstrating the unzip command. The condescending tone undermines what could have been constructive disclosure. This reads like a high schooler dunking on a first grader, I'm just glad we all learned from the technical prowess of extracting an archive. The underlying problems with exposed API keys and unrestricted database access are serious, but your arrogant presentation does a disservice to responsible disclosure.
I read it as an incredulous and increasingly pissed off person absolutely dunking on a smug person's attitude and success who has done so in a fashion they find completely unacceptable.
Both sides can be wrong. This isn't the first HN article investigating security issues where the researcher has this exact smug, exasperated, "oh, how can the dev be so stupid" attitude. I can say that in business communication, this kind of insufferable smugness never helps, even if the subject person really is stupid/incompetent.
I never said the app's issues should be absolved, the security problems are obviously serious. But the author claims he did responsible disclosure and got no response, yet somehow skipped the obvious next step of contacting Apple directly. Instead he chose to publish a detailed technical writeup that essentially creates a how-to guide for exploiting these vulnerabilities.
Now because of this post, these children are arguably at greater risk than before, since anyone can follow his step-by-step instructions. If he actually cared about user safety over HN karma, he would have escalated to Apple's App Store channel rather than publishing exploitation details.
The smugness isn't the only problem, it's the irresponsible disclosure wrapped in performative outrage.
You can criticize terrible security practices without creating a ready to replay tutorial for bad actors.
Are you really going to be pedantic now and accuse me of deception? OP said: "Developer doesn't seem keen on changing things." Which I can rightly interpret as the developer didn't respond meaningfully or at all. Knowing the nature of OP, he would have surely published the developer's responses if he did. And if he did respond, what I said is semantically valid in that OP did not receive the response he or we would expect: the developer actually doing something about these vulnerabilities.
Apple absolutely should be contacted here: they have App Store Review Guidelines that this app clearly violates. Apps in the kids category and apps intended for kids cannot include third-party advertising or analytics software and may not transmit data to third parties. This app is transmitting children's location data to third parties through unsecured APIs, which directly violates Apple's kids category guidelines.
But you're completely ignoring the main point: by publishing this detailed technical writeup instead of escalating to Apple, the author has now made these children MORE vulnerable.
Perhaps, but let's not pretend his claim to responsible disclosure holds up when he skipped this obvious step. That being said, because the app violates their App Store guidelines with regards to data collection related to minors, it's a channel that should have absolutely been explored.
If you want to bring Apple and app store guidelines into this, then why aren't you calling them out for allowing this app on the market in the first place? Without that failure (which they're also making 30% on, let's not forget) we wouldn't even be having this conversation.
Interesting, does https://178.156.176.158/ serving the main/actual site, mean that requests are going straight to the dx serve process with no Caddy or Nginx in front? I'm always curious how people set stuff up.. if rp in front I would think that the naked IP wouldn't pass a likely host-based proxy rule..
Nope! The entire thing is behind nginx! And I'm not using dx serve either! I'm statically building each page server-side so I can ship zero WASM/JS (barring analytics) and then each page is served as plain HTML through Rocket. Rocket is bound to the loopback adapter which is proxied by nginx.
I really suggest not removing them as they are a great way to estimate the length of the article (which was the first thing I tried to do on your page and had to spend a good minute first looking for a scroll bar, and then holding Page Down key).
