Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
Privacy Android Security Slashdot.org

Meta and Yandex Are De-Anonymizing Android Users' Web Browsing Identifiers (github.io) 77

Posted by BeauHD from the PSA dept.
"It appears as though Meta (aka: Facebook's parent company) and Yandex have found a way to sidestep the Android Sandbox," writes Slashdot reader TheWho79. Researchers disclose the novel tracking method in a report: We found that native Android apps -- including Facebook, Instagram, and several Yandex apps including Maps and Browser -- silently listen on fixed local ports for tracking purposes.

These native Android apps receive browsers' metadata, cookies and commands from the Meta Pixel and Yandex Metrica scripts embedded on thousands of web sites. These JavaScripts load on users' mobile browsers and silently connect with native apps running on the same device through localhost sockets. As native apps access programmatically device identifiers like the Android Advertising ID (AAID) or handle user identities as in the case of Meta apps, this method effectively allows these organizations to link mobile browsing sessions and web cookies to user identities, hence de-anonymizing users' visiting sites embedding their scripts.

This web-to-app ID sharing method bypasses typical privacy protections such as clearing cookies, Incognito Mode and Android's permission controls. Worse, it opens the door for potentially malicious apps eavesdropping on users' web activity.

While there are subtle differences in the way Meta and Yandex bridge web and mobile contexts and identifiers, both of them essentially misuse the unvetted access to localhost sockets. The Android OS allows any installed app with the INTERNET permission to open a listening socket on the loopback interface (127.0.0.1). Browsers running on the same device also access this interface without user consent or platform mediation. This allows JavaScript embedded on web pages to communicate with native Android apps and share identifiers and browsing habits, bridging ephemeral web identifiers to long-lived mobile app IDs using standard Web APIs. This technique circumvents privacy protections like Incognito Mode, cookie deletion, and Android's permission model, with Meta Pixel and Yandex Metrica scripts silently communicating with apps across over 6 million websites combined.

Following public disclosure, Meta ceased using this method on June 3, 2025. Browser vendors like Chrome, Brave, Firefox, and DuckDuckGo have implemented or are developing mitigations, but a full resolution may require OS-level changes and stricter enforcement of platform policies to prevent further abuse.
This discussion has been archived. No new comments can be posted.

Meta and Yandex Are De-Anonymizing Android Users' Web Browsing Identifiers More

Meta and Yandex Are De-Anonymizing Android Users' Web Browsing Identifiers

Comments Filter:

  • Class action? (Score:1)

    by Anonymous Coward
    I am expected a class action lawsuit against Meta for violation of privacy in three...two...one...

  • Big Brother is watching (Score:3)

    by FudRucker ( 866063 ) on Tuesday June 03, 2025 @05:03PM (#65425487)
    Question is who watches the watchers?

  • Android Advertising ID (Score:3)

    by fahrbot-bot ( 874524 ) on Tuesday June 03, 2025 @05:13PM (#65425513)

    As native apps access programmatically device identifiers like the Android Advertising ID (AAID)

    Another reason to routinely change/reset this manually.
    (Don't know if deleting it would be better...)

    • Re: (Score:2)

      by allo ( 1728082 )

      An app can say "I have ID X and had previously ID Y" and all other apps and websites can add the IDs as aliases for each other in their database.
      Changing only disconnects uninstalled apps, as all still installed apps see the same change. They would need to use one Ad-ID per App instead of a global one.

      • Re: (Score:2)

        by unrtst ( 777550 )

        AFAICT, an easier alternative is to NOT install the apps. Use the website to access those services instead, then there is no local app logged in as you for the webpage to poke.

        I'm a bit surprised the browsers allow those localhost connections without any approval. If you look up "javascript based network scanners", they all use really ugly kludges to get around protections that are supposed to prevent such things. I'm pretty sure there should be stuff that ensures a webpage can't scan all locally open ports

        • Re: (Score:2)

          by allo ( 1728082 )

          I think the old noscript extension prevented it explicitely. I do not know if the new version does. But with Noscript/uMatrix you can restrict connections even when they may not blacklist localhost by default.

    • There used to be a setting in Android to do this automatically on every reboot - I had it set in 2020 for a while - but I failed to find it when looking a couple of weeks ago. The Facebook app is not a problem for me (I placed it in "Forced Stop" on day 1 with my new phone) and Instagram is not installed, but I use WhatsApp. As for Yandox, not on a bet.

    • Wouldn't do anything. AAID is like a browser cookie in this case. It's not the primary key for you being tracked, that's Meta's profile on you.

  • Prison time? (Score:5, Interesting)

    by olddoc ( 152678 ) on Tuesday June 03, 2025 @05:14PM (#65425517)
    German courts sent people to prison for the fraud in Dieselgate: https://apnews.com/article/vol... [apnews.com] Forget class actions, send Facebook executives to prison for computer fraud! It's time that sleazy business practice like this lands the engineers and corporate management that approved it in prison.

    • They haven't touched the person ultimately responsible, Martin Winterkorn, just as they won't touch Zuck.

      • Except the question is whether he was ultimately responsible. For that you'd need to prove he know / signed off on this practice. If anything you can accuse him of running a company with a really shitty corporate culture, but to send someone to prison you need to directly and beyond any reasonable doubt prove fraud.

        • VW was smart enough not to keep any records of when Winterkorn was informed of the problem and allowed it to continue:

          https://www.houstonchronicle.c... [houstonchronicle.com]
          https://www.theguardian.com/bu... [theguardian.com]

          I also remember reading around the time that the scandal broke that Martin Winterkorn was smart enough to not be too specific when he instructed engineers to find a way to make the cars pass emissions within budget or they'd be fired, and that he didn't care how they did it.

          Interesting story, I also heard from an engineer at G

    • Re: (Score:2)

      by taustin ( 171655 )

      VW execs went to prison for lying to the government. These assholes aren't even lying to their customers, they're lying to their product.

    • The problem is that this isn't fraud. If anything it is programmatically bypassing an API. The question is whether this is a GDPR violation, and chances are someone could prove it's not.

  • Do not have Apps for Facebook, Amazon, Google, Microsoft, Twitter/X, etc etc etc.
    I use some of these services in a "privacy" window with Ad blockers, etc and delete all cookies afterwards.

    Their Apps are in now way equal compensation for my loss of privacy and data harvesting.

    Fuck them.

    • >"Do not have Apps for Facebook, Amazon, Google, Microsoft, Twitter/X, etc etc etc. I use some of these services in a "privacy" window with Ad blockers, etc and delete all cookies afterwards.""

      I will do you one better. I don't even have accounts on any of them, never have, and don't use any social media (unless you count Slashdot and a few forums as "social media" (I don't )). And I survive just fine. I do have an Amazon account, I don't consider that the same thing at all, however.

      >"Fuck them."

      In

  • Don't install those apps (Score:4, Interesting)

    by ukoda ( 537183 ) on Tuesday June 03, 2025 @05:20PM (#65425545) Homepage
    If I understand what they are doing right it seems like the easy fix is to not install the related native apps. Many years ago I looked at installing the Facebook app. That was back in the days when Android would list all the individual permissions the program required before doing the install. Back then I was shocked at the massive overreach of permission they were demanding so aborted the install and have never used social media apps on my phone, leaving that for Firefox on the desktop.

    Now days it comes as no surprise. It also comes as not surprise that most people, especially the younger ones, just don't care and will happy give any company any info they want so they can keep endlessly scrolling through dross.

    • If I understand what they are doing right it seems like the easy fix is to not install the related native apps.

      I wouldn't count on this. I have noticed that a lots of web sites connect to localhost. I always assumed it had some semi-malicious reason. Even now I notice that slashdot is connecting to 1248321188.rsc.cdn77.org. I'd assume that this is basically the same idea.

      • Re: (Score:3)

        by ukoda ( 537183 )
        My take on it is the localhost connection requires a local running service to receive that connection and report it to the offending privacy abusing company. If you have never installed any app from the offending privacy abusing company then there will be nothing running for that local connection attempt to actually connect to. Hence my advice not to install their apps if you value your privacy.

  • Time for some fucking privacy laws... (Score:3)

    by sdinfoserv ( 1793266 ) on Tuesday June 03, 2025 @05:23PM (#65425561)
    In the "freest" country on the planet... .
    But then profit "trumps" rights, so we're back to getting fucked by the oligarchs who actually run the country.

    • Re: (Score:3)

      by mysidia ( 191772 )

      The US government is not ignorant to privacy issues at all, but actually actually part of the problem, since agencies routinely buy personal information on citizens from private companies; AKA Data brokers; in order to circumvent our constitutional rights.

      Privacy laws would thwart their shenanigans, so there are powerful forces that impede progress.

    • In the "freest" country on the planet... . But then profit "trumps" rights, so we're back to getting fucked by the oligarchs who actually run the country.

      Freedom is now based on a scorecard. That scorecard is essentially net worth. Those with more have more freedom. Those with less have less freedom. If you are high enough on the freedom scale, you're free to do anything you want to those under you on the freedom scale. America, land of the elite, and those who are their subjects and slaves.

    • You say that like you think there is a contradiction, which suggest that you think freedom and privacy are the same, or at least deeply connected. Are they? Or are they sometimes related but often in opposition?

  • It's even funnier in Russia (Score:5, Informative)

    by Artem S. Tashkinov ( 764309 ) on Tuesday June 03, 2025 @05:26PM (#65425565) Homepage

    There's a spicy thing that looks like a state-mandated program that's been going on in Russia for a couple of years now, since 2023 or something: it turns out [vc.ru] a bunch of major Russian Android apps -- Sber, VK, Wildberries, even AliExpress Russia -- quietly request the READ_GSERVICES permission. This lets them grab your Google Services Framework ID, a persistent device ID that survives app reinstalls and SIM swaps. Translation: perfect for long-term tracking.

    The punchline? The international AliExpress app doesn't need this permission -- only the Russian one does. So either the Russian dev team's just really curious, or someone upstream wants tighter user traceability. ;-) It's like digital surveillance on hard mode: no GPS, no drama -- just one stable ID and a dash of plausible deniability.

    • quietly request the READ_GSERVICES permission. This lets them grab your Google Services Framework ID, a persistent device ID that survives app reinstalls and SIM swaps. Translation: perfect for long-term tracking.

      Given how critical that permission is, how are they even able to request it quietly? I would think Android would be screaming at the top of its lungs if that permission were requested.

      • Re: (Score:2)

        by znrt ( 2424692 )

        Given how critical that permission is,

        it isn't.

        how are they even able to request it quietly?

        they don't. they probably use a package (which maybe uses a package ...) that declares this obsolete permission. this permission was intended for google signed apps only and its authorization is taken for granted, never requested to the user.

    • Re: (Score:2)

      by znrt ( 2424692 )

      read_gservices is a signature level permission (only granted to google signed apps, which is why the user will never be asked to give it to any app, nor can any other app really use it) and is btw deprecated.

      aliexpress has a specific app version for russia because of sanctions and restricted access to google play so they might be working around that using older modules and dependencies that still use it.

      btw, gsf ids are only really persistent on google servers as they represent the combination of a google a

  • The described method could be blocked if HTTPS was required by default, and HTTP only allowed for a user-controlled whitelist.

    • Re:Workaround (Score:4, Interesting)

      by mysidia ( 191772 ) on Tuesday June 03, 2025 @05:59PM (#65425627)

      The problem would be best fixed by preventing scripts in a browser from being able to connect to random ports on localhost that they shouldn't have been able to do in the first place. Why is it the case that they can, anyways?

      I'm pretty sure Chrome on a PC doesn't have the same opening. Websites are generally bound by the same origin policy. A script should only be able to connect to resources at the same hostname as the website; for example connecting a websocket to a port on 127.0.0.1 should only be allowed if the website was actually hosted on 127.0.0.1. Navigating the local browser to http://localhost/ [localhost] URLs at non-standard port numbers by script should also be blocked, and an Android phone ought not to be allowing random apps to bind to port 80 if that were the case.

      • Re: (Score:2)

        by Luthair ( 847766 )
        The same origin policy is irrelevant here because the server is part of the malicious behaviour - it can respond with a CORS header which allows sites to read the response.

        • Re: (Score:3)

          by mysidia ( 191772 )

          - it can respond with a CORS header which allows sites to read the response.

          CORS headers are a recent innovation, And the addition of any headers that can allow a server to make the client relax restrictions may be an extremely bad idea. At least at a fundamental level CORS headers that permit any localhost URL or URL referring to local LAN IP addresses (except for the IP address that script is hosted on) should be blocked by the browser. I believe this is always the case on Desktop browsers.. a ma

      • Re: (Score:2)

        by allo ( 1728082 )

        "Why is it the case that they can, anyways?"

        Have some app that opens a port and try to connect to it with the browser. You can use stuff that uses web interfaces on mobile devices.

        • Re: (Score:2)

          by mysidia ( 191772 )

          Have some app that opens a port and try to connect to it with the browser.

          That's not a valid reason for the browser to enable a page on "facebook.com" to connect to 127.0.0.1.

          In theory that could be a rare reason to allow localhost traffic If the whole browser window is navigated to a page served from 127.0.0.1. But as far as I know Apps don't need to run a own web server to accomplish a local UI, and the Android OS provides such facilities to allow an app to show a HTML page in the browser.

      • I'm pretty sure Chrome on a PC doesn't have the same opening. Websites are generally bound by the same origin policy

        This policy is site controlled, defaults do nothing to prevent collusion.

      • Re: (Score:2)

        by TheBAFH ( 68624 )
        Isn't what Port Authority Firefox plugin [github.com] does?

        "Blocks websites from using javascript to port scan your computer/network and dynamically blocks all LexisNexis endpoints from running their invasive data collection scripts. "

        • Re: (Score:3)

          by mysidia ( 191772 )

          I would say that's a different issue. Websites can "scan" the local network by script-creating IMG tags that reference local IP addresses. Even though a script cannot "connect" to random local addresses; it can send a Tag that directs loading an image from a local resource, And then the script can time how long it takes loading to fail in order to test between the conditions whether the port is closed or doesn't exist, and condition where the port is open - which affect how much time it takes t

    • Re: (Score:2)

      by alcmena ( 312085 )
      Not really. Because it's not hard to get a cert for "*.mycompany.com" and then create a DNS entry for "local.mycompany.com" that maps to localhost. Have the webserver serve up the cert and you have a localhost HTTPS setup that's fully "certified".

    • Re: (Score:2)

      by allo ( 1728082 )

      Facebook can easily bundle a TLS-Key with their app. A certificate also works on localhost. There is no requirement that a HTTPS server must be reachable from outside.

  • Ban them (Score:1)

    by Anonymous Coward
    Other developers get booted from Google Play Store for far less. Yes, I know. These megacorps don't have to obey the Developer Distribution Agreement.
  • "Fixed" local ports but are actually not fixed, just modified in a broken way.
  • This is why I avoided software that used an advertising Id.: There's only one purpose in any Id. number and it's in the name: To identify the device and thus, track it.

    I avoided advertising in general: Because it's an explicit hole in the device's isolation from malicious devices. If a developer wants money he can sell his software. Hell, for $5, he can issue a new product every year and demand another $5. That's much cheaper than modern in-the-cloud products demanding $20/month.

    • Re: (Score:2)

      by HiThere ( 15173 )

      Do you really think that paying for software keeps them from doing this?

      • ... paying for software ...

        I'm not tolerating advertizing in paid applets, either.

        I'm saying I'm willing to pay $3-5 dollars every year. I hope (other users will do the same and) that payment-model will incentivize a few developers to move away from adware/spyware funded applets.

        • Re: (Score:2)

          by allo ( 1728082 )

          "I'm not tolerating advertizing in paid applets, either."

          Use a Firewall app and be surprised what paid apps do. They contact the same servers as the app with ads, they only don't show the ads. The tracking is all the same for most of them.

  • Exceeding Authorized Access is a crime (Score:4, Interesting)

    by laughingskeptic ( 1004414 ) on Tuesday June 03, 2025 @06:12PM (#65425665)
    And when it comes to every scenario involving their computers, the government has taken the point of view if you weren't authorized to do something on their computer and you did it, then you exceeded authorized access. https://www.justice.gov/jm/jm-... [justice.gov] . There was no way for a cellphone owner to authorize this, so it was unauthorized and therefore a crime.

  • Firefox plugins to avoid this? (Score:4, Interesting)

    by PhantomHarlock ( 189617 ) on Tuesday June 03, 2025 @06:43PM (#65425727)

    Would a plugin that blocks tracking pixels fix the problem? I use firefox for android with Ublock Origin installed when I browse on the phone. I do use the facebook app when I access it on the phone, as they have made the mobile browser experience fairly terrible in comparison (on purpose.)

    • No, this is not really fixable at user level unless you uninstall all meta yanfex apps including meta app that shows up only under 'system apps' even if u dont have Facebook whatsapp installed

      Meta has already stopped it as per the article. Maybe replaced with something worse.

      Don't worry social media will all implode on its own, like every new tech that starts overdoing stuff, in a few years. Bigger problems IRL will take up all your focus n efforts, if that's any comfort

      • I'd bet money that they have a huge list of fallback options, all kept secret of course. As soon as one gets uncovered, just issue a pretend apology while switching to the next fallback in the list.

      • Browsers should not allow websites loaded from the WAN to make connections to LAN or localhost addresses without permission.

    • Re: (Score:2)

      by allo ( 1728082 )

      uMatrix and not whitelisting 127.0.0.1 can probably help. Firewall-Apps that allow to filter IPs may also help. If you have iptables access you can also drop packets that are going to the port of the listening app. It could be worth a try to start another app that listens on that port before starting the Facebook app.

  • I need to have an option to set my local advertising ID to "nil", I know why it's there, it's google after all, but I should also be able to turn that off in a definitive way on my own.

  • Thanks for sharing (Score:3)

    by dskoll ( 99328 ) on Tuesday June 03, 2025 @09:35PM (#65426039) Homepage

    I have updated my page on the shittiness of Meta [skoll.ca] with this new information.

  • Browsers already blocked access to file:// by websites, they will jus treat local or LAN addresses the same way. You'll need to have a compatible origin as the top-level address to access. Should be an easy fix, no legitimate site should be doing this. Any sites that are should be using a custom protocol to invoke some action on the user's device with their permission instead.
  • There is no reason for any application to become an unrestricted web server for the local browser or any other app. It's an obvious hole which should have showed up in a threat modeling of the app access schemes (does Android do any, or it is a free-for-all, whatever gets me the fanciest demo type project). Any apps trying to communicate via any listening sockets should require explicit user permissions. There should also be check in the browsers which disallow localhost access embedded in external pages -

    • Re: (Score:1)

      by Anonymous Coward

      "There is no reason for any application to become an unrestricted web server for the local browser or any other app."

      There are many applications that use web-interfaces as primary interface that you can install on Android.

  • Sincere question. Would this be something that doesn't work on an iPhone now, but could work if they do what the EU has demanded?

Slashdot Top Deals

Any circuit design must contain at least one part which is obsolete, two parts which are unobtainable, and three parts which are still under development.

Close