No doubt, whatever "vulnerability" is found, you have already to agreed to it in some buried TOS.
Covert web-to-app tracking via localhost on Android
201–210 of 356 posts
Re: Covert web-to-app tracking via localhost on Android
#202Another similar tracking vector that lets any app detect all installed apps by using android.intent.action.MAIN Query: https://support.google.com/googleplay/android-developer/thre... without the QUERY_ALL_PACKAGES permission. No response from Google. Being used by dozens of apps in the wild. Edit: Original Research link: https://peabee.substack.com/p/everyone-knows-what-apps-you-u... (HN: https://news.ycombinator.com…
Incredible that this was locked.
dang likely got told not to upset the benefactors
Re: Covert web-to-app tracking via localhost on Android
#203On many threads here regarding EU fines, I see the sentiment "The EU only fines US tech to make a quick buck!". It could be an idea to, you know, stop doing these things. Would be great to see another few $billion fine for this one.
The us could fine US tech too.
I bet that most Americans would be ok with that, more privacy, more money for the state and less to the greedy bastards.
EU doesn’t have to be the cop of US technology, in fact it’s a bit pathetic to have another country policy your industry.
Re: Covert web-to-app tracking via localhost on Android
#204Firefox about:config toggle media.peerconnection.enabled from true to false
Further, Netguard plus Nebulo in non-VPN mode can stop unwanted connections to Meta servers
Re: Covert web-to-app tracking via localhost on Android
#205Earlier quoted context omitted.
> hand out a different, temporary IPv6 address to every app and segment off any other interface that might be expose Yes, but (AFAIK) not out of the box (unless one of the security focused ROMs already supports this). The kernel supports network namespaces and there's plenty of documentation available explaining how to make use of those. However I don't know if typical android ROMs ship with the necessary tooling. Ap…
I've looked into network namespaces a bit but from what I can tell you need to do a lot of manual routing and other weird stuff to actually make IPv6 addresses reachable through them. In theory all you need to do is have zygote constrain the app further with a network namespaces, and run a CLAT daemon for legacy networks, but in practice I'm not sure if that approach works well with 200 apps that each need their IPs…
I don't follow? Your system is either routing packets or not. IPv6 vs IPv4 should not be a notable difference here.
I've never tested network namespace scalability on a mobile device but I doubt a few hundred of them should break anything (famous last words).
In the primary namespace you will need to configure some very basic routing. You will also need a solution for assigning IP addresses. That solution needs to be able to rotate IP assignments when the external IP block changes. That's pretty standard DHCP stuff. On a desktop distro doing the equivalent with systemd-networkd is possible out of the box with only a handful of lines in a config file.
Honestly a lot of Docker network setups are much more complicated than this. The difficult part here is not the networking but rather patching the zygote logic and authoring a custom build of android that incorporates the changes.
Re: Covert web-to-app tracking via localhost on Android
#206Earlier quoted context omitted.
The main application for WebRTC is peer to peer data transfer. I think you can make the argument that it should be behind a permission prompt these days but it's difficult. What would the permission prompt actually say, in easy to understand layman's terms? "This web site would like to transfer data from your computer to another computer in a way that could potentially identify you"? How many users are going to be ab…
TFA list tens of thousands of websites using WebRTC for deanonymization. How many websites using it for P2P data transfer can you list?
Any Jitsi deployment?
Let's be clear here. Meta/other sites are abusing the technology TURN/WebRTC for a purpose it was never intended for, way beyond the comfortable confines of innocent hackery, and we all know it.
That's asshole behavior, and worth naming, shaming, and ostracizing over.
Re: Covert web-to-app tracking via localhost on Android
#207Earlier quoted context omitted.
Doesn't iOS prompt you to give apps permission to connect to your local network? "App would like to find and connect to devices on your local network" or something along those lines. I always hit the "no thanks" button.
In this case it's the web browser connecting to the network, so the permission is irrelevant.
[deleted]
Re: Covert web-to-app tracking via localhost on Android
#208All apps + the web browser being able to communicate freely over a shared localhost interface is such a glaring security hole that I'm surprised both iOS and Android allow it. What even is a legitimate use case for an app starting a local web server?
I expose a LAN accessible status board from an app via HTTP. The app runs completely offline, thus I can't rely on something hosted on the public internet.
My last electron app did effectively the same thing. I took the hosted version of my app and bundled in electron for offline usage with the bundled app being just a normal web application started by electron.
Re: Covert web-to-app tracking via localhost on Android
#209Earlier quoted context omitted.
Most commenters on Hacker News hated Google’s plan and hoped it would fail. Were they wrong? It seems like damned-if-you-do, damned-if-you-don’t.
That stemmed from “dammit Google now every SaaS developer has to work nights to meet your arbitrary deadline”; here we’re caring more about the impact as consumers. It’s ok to think about things in two ways. source: a developer who actually did have to do this (and did it, and now didn’t have to, but it’s done)
Didn't have to? Don't you need to support users on Firefox and Safari?
Re: Covert web-to-app tracking via localhost on Android
#210Earlier quoted context omitted.
Nothing quite like an instant panicked coverup to confirm guilt and intent. Hopefully not too late to make it into the lawsuit. Assholes.
As someone who works for a similar large org, it's just as likely that some low level programmer put it in without much thought, and then this got surfaces to higher up people who didn't know about it and told them to remove it immediately.
You claim some low-level programmer created a feature that opens a new network connection between two separate applications?
Just some guy working at facebook was able to ship network code in not just one but two code-bases without any senior or higher engineers in the loop?
That's the claim? If that was true (it's not) it would be even worse than high level executives being involved.