136
Another way to leak traffic on Android has been discovered (mullvad.net)
submitted 1 day ago* by to c/android@lemmy.world
9 comments fedilink hide all child comments
 

The leak involves telling Android to create a keep-alive UDP connection that is offloaded to the hardware Wi-Fi or cellular chip.

GOS fix in progress. Google has reportedly declined the bug report/bounty.

you are viewing a single comment's thread
view the rest of the comments
[–] 59 points 1 day ago* (6 children)

Google sure seems to not care about VPN leak bugs that easily enable user apps to track real-world IP addresses without any kind of special permissions, even while the user thinks they're safe in 'lock traffic to VPN only mode'.

I wonder why..

Via Graphene issue tracker.

Author: ArminShupuk

@thestinger As I see that you, Daniel, have picked this one up, I want to add that I was just in touch with Yusuf, who found the registerQuicConnectionClosePayload VPN leak. He informed me today that they didn't pay him and closed the report as "won't fix." He had no success with his appeal. Mine seems to be "won't fix" too, with no success reasoning with them either.

So there are currently already two arbitrary ways for any user app with internet permission to leak the IP address in VPN lockdown mode that won't be fixed upstream.

Side note, the main GrapheneOS dev being his usual abrasive self (this is his only contribution to the thread).

Author: thestinger

That's not the spelling of my name.

  • permalink
  • fedilink
  • source
  • hideshow 6 child comments
    •
  • [–] 5 points 21 hours ago* (2 children)

    I don't see that comment in the linked issue. I do see them triaging and assigning it, though.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 3 points 18 hours ago (1 child)

    Lol wtf he deleted it. Maybe he lurks here.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 6 hours ago

    The original comment called him "Danielle" and then edited to fix it to "Daniel". Given that it's the feminine version of the name, I think asking for a correction is reasonable, and deleting that request when it is fixed is also reasonable.

    That being said, he could have been more polite about it. Everyone in that thread comes across to me at grumpy, though.

  • permalink
  • fedilink
  • source
  • parent
  • [–] -1 points 20 hours ago (1 child)

    I enjoy his abrasiveness.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 2 points 10 hours ago

    You do you (no downvote for me), but abrasiveness doesn't help build community support in general, and context matters a lot.

    In the context of some random user demanding a niche feature be added to a free project to suit their needs: abrasiveness warranted.

    In the context here, of a security researcher very politely notifying them of a bug critical to the focus of their project (security and privacy), attempting private channels first, providijg deep details of the issue, adding discussion notes regarding upstream provider being unlikely to fix, and even including code to fix the problem for them - abrasiveness is counter-productive.

  • permalink
  • fedilink
  • source
  • parent