• atk007@lemmy.world
    link
    fedilink
    English
    arrow-up
    7
    ·
    1 day ago

    Why did the app had the government IDs and credit card data to begin with? The app looks like an obvious phishing scam/ Honeypot situation.

    • GreenKnight23@lemmy.worldBanned from community
      link
      fedilink
      English
      arrow-up
      4
      ·
      1 day ago

      that’s a great(terrible) idea for a sex trafficking psyop. just get yourself a female spokesperson and make it a platform that gives a voice to women who have survived abuse. they’ll willingly give you all their information on where to find them and their psych profiles on how to manipulate them.

      fucked up, but really shows how fucked up apps are in general and how much power we give to them over ourselves.

  • pivot_root@lemmy.world
    cake
    link
    fedilink
    English
    arrow-up
    64
    ·
    3 days ago

    Tea was storing its users’ sensitive information on Firebase, a Google-owned backend cloud storage and computing service.

    Every time. With startups, it’s always an unsecured Firebase or S3 bucket.

    • NeilBrü@lemmy.world
      link
      fedilink
      English
      arrow-up
      8
      ·
      edit-2
      2 days ago

      I’m certainly no web security expert, but shouldn’t Tea’s junior network/backend/security developers, let alone seniors, know how to secure said Firebase or S3 buckets with STARTTLS or SSL certificates? Shouldn’t a company like this have some sort of compliance department?

      • GissaMittJobb@lemmy.ml
        link
        fedilink
        English
        arrow-up
        4
        ·
        2 days ago

        SSL is not the tool you need in this case, although you should obviously already be running exclusively on encrypted traffic.

        The problem here is one of access rights - you should not make files default-available for anyone that can figure out the file name to the particular file in the bucket. At the very least, you need to be using signed URLs with a reasonably short expiration, and default all other access to be blocked.

        • NeilBrü@lemmy.world
          link
          fedilink
          English
          arrow-up
          1
          ·
          edit-2
          2 days ago

          As I mentioned in other comments, I am a noob when it comes to web-sec; please forgive what may be dumb questions.

          Is it really just permission rights “over-exposure” issue? Or does one need to also encrypt and then decrypt the data itself that must be sent to a database?

          Also, if you have time, recommend any links to web/cloud/SaaS security best practices “for dummies”?

      • gian
        link
        fedilink
        English
        arrow-up
        6
        arrow-down
        2
        ·
        2 days ago

        I am not sure, but I read somewhere that the developer(s) used vibe coding to create the app so…

        • Canaconda@lemmy.ca
          link
          fedilink
          English
          arrow-up
          2
          ·
          2 days ago

          A lot of people have speculated that.

          According to their statement their code was written in Feb/2024 and predates “vibe coding”

          • gian
            link
            fedilink
            English
            arrow-up
            1
            ·
            1 day ago

            What intrigue me is this:

            I’m confident vibe coding was not to blame in this particular case,

            So they used vibe coding, they are only saying that they think/hope that it is not the cause of the break (and maybe also of the second one)

            And if vvibe coding is not caused then they are even more incompetent.

    • Kalothar@lemmy.ca
      link
      fedilink
      English
      arrow-up
      2
      ·
      2 days ago

      My hey we’re probably using Firestore as their database without authenticating their api calls to firebase functions. Basically leaving their api endpoints open to the public Internet.

      They could have connected service account and used some kind of auth handshake between that and generate a temporary login token based on user credentials and the service account oauth credentials to access the api. but they probably just had everything set to unauthenticated

  • blitzen@lemmy.ca
    link
    fedilink
    English
    arrow-up
    8
    arrow-down
    2
    ·
    2 days ago

    I feel that the app filled a need of women we should not ignore. But the app, both this specific app and also the overall concept, is just too rife with downsides to be workable.

    So we, as men and as society need to reevaluate why women feel the need for such an app, and reinvest in the criminal justice system to hold victimizers more accountable.

    It’s okay to call this app and similar Facebook groups unacceptable. But that’s not enough, we must also call for stronger protections for victims of criminal behavior.

    • jpeps@lemmy.world
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 day ago

      I think there must be a way to deliver on the value of the app without it being the privacy/public exposure nightmare it sounds like. Speaking naively, perhaps a setup where you can only speak about a person with those who have actually matched with them.

      • blitzen@lemmy.ca
        link
        fedilink
        English
        arrow-up
        1
        ·
        1 day ago

        There’s no “matching” on this app, because men aren’t allowed. By its very design, you can’t avoid the unilateral one-sidedness.

        • jpeps@lemmy.world
          link
          fedilink
          English
          arrow-up
          2
          ·
          1 day ago

          Sorry, I do understand that, I was just thinking of an improvement that might help. I thought having the same phone number might work too but that gets dodgier.