tldr; The native Facebook apps run a local web server on your phone. When you visit a site in your phone's web browser that has Facebook code on it (for example if they show their Facebook...
tldr; The native Facebook apps run a local web server on your phone. When you visit a site in your phone's web browser that has Facebook code on it (for example if they show their Facebook follower count or have a thumbs-up button), the Facebook code makes a request directly to the native Facebook app on your phone telling it which site you're on--so now, assuming you're logged into the native Facebook app on your phone, Meta knows what site you just visited, even if you took every precaution to prevent that from happening (deleting all browser cookies, running in incognito mode, using a VPN, none of that hides your identity or the fact that you just visited that website from Meta).
Meaning it wouldn’t have affected (exclusive) users of the web over the natively installed app version, which 1) good for them for other reasons as well! 2) is likely to be an overwhelming...
Meaning it wouldn’t have affected (exclusive) users of the web over the natively installed app version, which 1) good for them for other reasons as well! 2) is likely to be an overwhelming minority… making this trick a very effective one once again. It’s kinda nuts what they manage to come up with, but at this point basically the majority of their (closed-source) code should be viewed as malicious or helping to enable user-hostile goals.
I’m one of those people haha I only ever log on to Facebook on my desktop pc on a normal browser. I find that just not installing apps on my phone actually gets me like 99% privacy.
I’m one of those people haha
I only ever log on to Facebook on my desktop pc on a normal browser.
I find that just not installing apps on my phone actually gets me like 99% privacy.
“Ask app to not track” IIRC is more or less honor system. The impact of this tracking method on iOS is pretty limited anyway though because iOS doesn’t let apps keep processes like web servers...
“Ask app to not track” IIRC is more or less honor system. The impact of this tracking method on iOS is pretty limited anyway though because iOS doesn’t let apps keep processes like web servers running in the background indefinitely.
The apps themselves get suspended after being backgrounded for a short period and background processes are run when the system decides to regardless of schedule the developer requests.
I'm a little curious why Android would allow this. It seems to me that a local server is only useful as a way to communicate between apps on your device. I can't think of a good reason for a...
I'm a little curious why Android would allow this. It seems to me that a local server is only useful as a way to communicate between apps on your device. I can't think of a good reason for a website to talk to localhost. If it's to get information from an app, I would expect a more sophisticated design where the app responds to requests for information by sending it to a hosted service, not simply giving it to to whatever happens to connect to it. That would be a lot more transparent and easier to audit and block. The other half would need to be browsers honoring incognito and such when asked to initiate such a request to the app.
I'm surprised that websites even can connect to localhost without enabling some kind of developer flag. It seems like any use case for a localhost service talking to something outside of the app hosting it should be better solved (if it isn't already, not an Android developer) by system architecture for safe communication between apps or apps and the web. Something that would honor various no-track settings.
Working in an offline/air gapped environment, I do actually have to leverage these aspects of Android. However, the use case that I work in is so far removed that a special flag to enable it...
Working in an offline/air gapped environment, I do actually have to leverage these aspects of Android. However, the use case that I work in is so far removed that a special flag to enable it really does sound like the best option.
The DNT header sent to web servers is pretty toothless (and according to Wikipedia it's deprecated entirely)--it's 100% up to Meta whether they decide to take any action upon receiving it or not....
The DNT header sent to web servers is pretty toothless (and according to Wikipedia it's deprecated entirely)--it's 100% up to Meta whether they decide to take any action upon receiving it or not. I'm guessing since they're already willing to pull obviously malicious stunts like this to bypass other mechanisms to avoid tracking, it's highly unlikely that they give two poops about the user asking them to please not track them in a request header.
That’s something different. NoblePath is talking about an iOS setting that caused quite a stir when it was released because a tiny minority of users, when asked in pop-up if they would like to...
That’s something different. NoblePath is talking about an iOS setting that caused quite a stir when it was released because a tiny minority of users, when asked in pop-up if they would like to allow an app to track them, would say “yes.” Data harvesters were up in arms that so many users were opting out. IIRC that actually did have some teeth, because Apple can kick any app out of the App Store if they circumvent it.
Whether they would actually go that far with Facebook is another question. Though we have seen them play hardball with Epic, sho who knows.
So... this is straight-up malware, right? Specifically bypassing strict security features to secretly gather information on the user. I have no Meta apps on my phone, luckily, but this is pushing...
So... this is straight-up malware, right? Specifically bypassing strict security features to secretly gather information on the user. I have no Meta apps on my phone, luckily, but this is pushing me further towards just deleting my Instagram/whatsapp account, even if I only access it on my laptop.
All things considered it's simultaneously a pretty clever and disgusting way to track the user. I didn't think android allowed that, but in hindsight, it makes sense. I wonder how secure that...
All things considered it's simultaneously a pretty clever and disgusting way to track the user. I didn't think android allowed that, but in hindsight, it makes sense.
I wonder how secure that localhost service is and whether a malicious page could use it as an attack vector...
A malicious actor acting independently of Facebook probably can't do much. The listening app (FB, IG) is designed and controlled by Meta, so it couldn't, say, send data to an arbitrary host or IP...
A malicious actor acting independently of Facebook probably can't do much. The listening app (FB, IG) is designed and controlled by Meta, so it couldn't, say, send data to an arbitrary host or IP (controlled by the malicious actor). Now, this doesn't preclude the possibility that Meta is offering a service to malicious actors to let them receive juicy data from Meta via this whole mechanism.
I'm grateful for the reminder that, however the company's appearance may change, Meta still beats with Zuckerberg's smug and indifferent heart. Keep as much distance as possible.
I'm grateful for the reminder that, however the company's appearance may change, Meta still beats with Zuckerberg's smug and indifferent heart. Keep as much distance as possible.
This is VW levels of disregard for the law. I doubt they’ll get a serious fine sadly but even if they do jail time seems appropriate for this level of malicious workaround. I’m guessing there’s no...
This is VW levels of disregard for the law. I doubt they’ll get a serious fine sadly but even if they do jail time seems appropriate for this level of malicious workaround. I’m guessing there’s no provision for that under the current laws but this is so egregious.
Sadly I expect people to still continue to use their apps. I get why someone might feel stuck with Wells Fargo if they need to send money around, but god the number of tech people I know who still use anything meta blows my mind. It’s often “oh well family/friends” but so much of it boils down you doom scrolling
Curious, is all scrolling these days called doom scrolling? I thought doom scrolling was a pandemic thing but it sounds like any time someone is using an infinite scroll app they say they’re doom...
Curious, is all scrolling these days called doom scrolling? I thought doom scrolling was a pandemic thing but it sounds like any time someone is using an infinite scroll app they say they’re doom scrolling.
I would assume not, given WhatsApp accounts are not fully integrated into the Meta ecosystem- as they're primarily attached to only a phone number- but I wouldn't bet any money on WhatsApp being...
I would assume not, given WhatsApp accounts are not fully integrated into the Meta ecosystem- as they're primarily attached to only a phone number- but I wouldn't bet any money on WhatsApp being safe. I would assume, however, that the "Meta pixel", or whatever other tracking scripts are used, are exactly the sort of content blocked by uBlock Origin and NoScript-type addons.
If you wonder what's a "peaceful use" of this technology - I recently rolled out Okta FastPass to my work. FastPass use a client app deployed to end devices. From the perspective of the end user,...
If you wonder what's a "peaceful use" of this technology - I recently rolled out Okta FastPass to my work.
FastPass use a client app deployed to end devices. From the perspective of the end user, they visit an app that requires sign in, they click "Sign in with Okta FastPass", the app show up, they approve it, use fingerprint/Windows Hello or PIN, then they're in. This is quite similar to The Passkey Experience but with corporate-mandated password manager. Users only need to use provide biometric and not username, passwords or pull out their phone. And it is two factor authentication - your device's TPM is the first factor, and biometric/pin is the second factor.
Internally, during sign on, the sign in widget connects to the Okta application with various methods, including localhost binding. Localhost binding works with all browsers, and it can be used to silently detect that the application is installed, so that the sign-in widget hides the FastPass button if it's unavailable. The application verify the incoming socket property that should comes from a valid web browser executable (they say that for now they don't block any browsers, but in the future it may generate alerts instead of blocks), then look at the Origin header to ensure it was called from a real Okta website. It then collect device signals and report it to Okta when the user approve the sign in. So, administrators can also block devices that are rooted, running outdated OS, have no firewalls, has no MDM, etc. It enforces corporate policy along with protecting against phishing
Vile. Though it's a pretty hardcore design error to allow any kind of non-localhost webpage to communicate with localhost. I recall browsers being pretty judicious about that. I guess WebRTC was a...
Vile. Though it's a pretty hardcore design error to allow any kind of non-localhost webpage to communicate with localhost. I recall browsers being pretty judicious about that. I guess WebRTC was a loophole.
As stated in the article Yandex has been doing this for much longer. I assume a few other companies are doing it, but Android will probably get an update soon to require consent when a site...
As stated in the article Yandex has been doing this for much longer. I assume a few other companies are doing it, but Android will probably get an update soon to require consent when a site connects to an app.
My question upon reading this was whether Meta was inserting the Pixel cookie/tracker themselves and then sending it back to the mother ship, or did the website have to participate and serve that...
My question upon reading this was whether Meta was inserting the Pixel cookie/tracker themselves and then sending it back to the mother ship, or did the website have to participate and serve that tracker first and Meta was listening for it?
The website would have to participate, but participation could involve something as innocuous as copy/pasting a Facebook-provided code snippet to add a like button to their page or show their...
The website would have to participate, but participation could involve something as innocuous as copy/pasting a Facebook-provided code snippet to add a like button to their page or show their follower count. Meta probably also provides code for other services like site analytics which would also undoubtedly include the pixel tracker.
I assume it comes along for the ride when you integrate almost anything FB-related on your website, possibly including SSO ("log in with your Facebook account").
I assume it comes along for the ride when you integrate almost anything FB-related on your website, possibly including SSO ("log in with your Facebook account").
I've had my FB account deactivated the past couple months, testing if I'd actually miss it. This is enough of a final push for me to fully delete my FB and kill the apps.
I've had my FB account deactivated the past couple months, testing if I'd actually miss it. This is enough of a final push for me to fully delete my FB and kill the apps.
I haven't researched this, but wouldn't having any sort of domain based tracker blocker prevent this from working? I'm thinking things like uBlock, pi-hole, privacy badger, ghostery, etc....
I haven't researched this, but wouldn't having any sort of domain based tracker blocker prevent this from working? I'm thinking things like uBlock, pi-hole, privacy badger, ghostery, etc.
According to the article it requires "Meta Pixel", but if that's some external script (like a Facebook button), it'd have to download the real script from Meta. If that initial script can't be downloaded, then it won't try to connect to the hidden server running on Facebook/Instagram.
If you block the tracking pixel and related javascript from ever loading in your web browser (which may or may not be the case using DNS-based ad blocking, it depends on whether the domain that...
If you block the tracking pixel and related javascript from ever loading in your web browser (which may or may not be the case using DNS-based ad blocking, it depends on whether the domain that the pixel is being loaded from is on your blocklist), then this technique by Meta would not work--as you say it requires their code to load and execute in your browser in order to communicate with the native app's web server running in the background on your phone. Presumably they could load the pixel directly from a facebook.com or meta.com url, in which case if you're not blocking all of facebook or meta then this technique could still track you.
The tin foil hat answer is that Google was doing this too. Sure they could try scrape the data out of the browser directly, which would be a lot more data, but there are lots of eyes looking at...
The tin foil hat answer is that Google was doing this too. Sure they could try scrape the data out of the browser directly, which would be a lot more data, but there are lots of eyes looking at the Chrome code base. So obviously the solution is to just not fix this to exploit it from closed-source apps that way it's less visible.
In case it wasn't clear enough from my first few words: this is a thing I just made up with no evidence or any reason to believe is true. Conspiracy theories can just be fun sometimes.
tldr; The native Facebook apps run a local web server on your phone. When you visit a site in your phone's web browser that has Facebook code on it (for example if they show their Facebook follower count or have a thumbs-up button), the Facebook code makes a request directly to the native Facebook app on your phone telling it which site you're on--so now, assuming you're logged into the native Facebook app on your phone, Meta knows what site you just visited, even if you took every precaution to prevent that from happening (deleting all browser cookies, running in incognito mode, using a VPN, none of that hides your identity or the fact that you just visited that website from Meta).
Meaning it wouldn’t have affected (exclusive) users of the web over the natively installed app version, which 1) good for them for other reasons as well! 2) is likely to be an overwhelming minority… making this trick a very effective one once again. It’s kinda nuts what they manage to come up with, but at this point basically the majority of their (closed-source) code should be viewed as malicious or helping to enable user-hostile goals.
I’m one of those people haha
I only ever log on to Facebook on my desktop pc on a normal browser.
I find that just not installing apps on my phone actually gets me like 99% privacy.
I wonder does “ask app not to track” prevent this on iphone?
“Ask app to not track” IIRC is more or less honor system. The impact of this tracking method on iOS is pretty limited anyway though because iOS doesn’t let apps keep processes like web servers running in the background indefinitely.
The apps themselves get suspended after being backgrounded for a short period and background processes are run when the system decides to regardless of schedule the developer requests.
I'm a little curious why Android would allow this. It seems to me that a local server is only useful as a way to communicate between apps on your device. I can't think of a good reason for a website to talk to localhost. If it's to get information from an app, I would expect a more sophisticated design where the app responds to requests for information by sending it to a hosted service, not simply giving it to to whatever happens to connect to it. That would be a lot more transparent and easier to audit and block. The other half would need to be browsers honoring incognito and such when asked to initiate such a request to the app.
I'm surprised that websites even can connect to localhost without enabling some kind of developer flag. It seems like any use case for a localhost service talking to something outside of the app hosting it should be better solved (if it isn't already, not an Android developer) by system architecture for safe communication between apps or apps and the web. Something that would honor various no-track settings.
Working in an offline/air gapped environment, I do actually have to leverage these aspects of Android. However, the use case that I work in is so far removed that a special flag to enable it really does sound like the best option.
The DNT header sent to web servers is pretty toothless (and according to Wikipedia it's deprecated entirely)--it's 100% up to Meta whether they decide to take any action upon receiving it or not. I'm guessing since they're already willing to pull obviously malicious stunts like this to bypass other mechanisms to avoid tracking, it's highly unlikely that they give two poops about the user asking them to please not track them in a request header.
That’s something different. NoblePath is talking about an iOS setting that caused quite a stir when it was released because a tiny minority of users, when asked in pop-up if they would like to allow an app to track them, would say “yes.” Data harvesters were up in arms that so many users were opting out. IIRC that actually did have some teeth, because Apple can kick any app out of the App Store if they circumvent it.
Whether they would actually go that far with Facebook is another question. Though we have seen them play hardball with Epic, sho who knows.
So... this is straight-up malware, right? Specifically bypassing strict security features to secretly gather information on the user. I have no Meta apps on my phone, luckily, but this is pushing me further towards just deleting my Instagram/whatsapp account, even if I only access it on my laptop.
Who knows what other shit they're hiding?
All things considered it's simultaneously a pretty clever and disgusting way to track the user. I didn't think android allowed that, but in hindsight, it makes sense.
I wonder how secure that localhost service is and whether a malicious page could use it as an attack vector...
A malicious actor acting independently of Facebook probably can't do much. The listening app (FB, IG) is designed and controlled by Meta, so it couldn't, say, send data to an arbitrary host or IP (controlled by the malicious actor). Now, this doesn't preclude the possibility that Meta is offering a service to malicious actors to let them receive juicy data from Meta via this whole mechanism.
I'm grateful for the reminder that, however the company's appearance may change, Meta still beats with Zuckerberg's smug and indifferent heart. Keep as much distance as possible.
This is VW levels of disregard for the law. I doubt they’ll get a serious fine sadly but even if they do jail time seems appropriate for this level of malicious workaround. I’m guessing there’s no provision for that under the current laws but this is so egregious.
Sadly I expect people to still continue to use their apps. I get why someone might feel stuck with Wells Fargo if they need to send money around, but god the number of tech people I know who still use anything meta blows my mind. It’s often “oh well family/friends” but so much of it boils down you doom scrolling
Curious, is all scrolling these days called doom scrolling? I thought doom scrolling was a pandemic thing but it sounds like any time someone is using an infinite scroll app they say they’re doom scrolling.
Imo doom scrolling refers to any endless scrolling through bad news or negative posts. I never connected it with the pandemic specifically personally.
I personally use it when I feel they're just scrolling infinitely looking for things to be worried/offended/upset about.
I wonder, does WhatsApp by any chance also do the same?
I would assume not, given WhatsApp accounts are not fully integrated into the Meta ecosystem- as they're primarily attached to only a phone number- but I wouldn't bet any money on WhatsApp being safe. I would assume, however, that the "Meta pixel", or whatever other tracking scripts are used, are exactly the sort of content blocked by uBlock Origin and NoScript-type addons.
If you wonder what's a "peaceful use" of this technology - I recently rolled out Okta FastPass to my work.
FastPass use a client app deployed to end devices. From the perspective of the end user, they visit an app that requires sign in, they click "Sign in with Okta FastPass", the app show up, they approve it, use fingerprint/Windows Hello or PIN, then they're in. This is quite similar to The Passkey Experience but with corporate-mandated password manager. Users only need to use provide biometric and not username, passwords or pull out their phone. And it is two factor authentication - your device's TPM is the first factor, and biometric/pin is the second factor.
Internally, during sign on, the sign in widget connects to the Okta application with various methods, including localhost binding. Localhost binding works with all browsers, and it can be used to silently detect that the application is installed, so that the sign-in widget hides the FastPass button if it's unavailable. The application verify the incoming socket property that should comes from a valid web browser executable (they say that for now they don't block any browsers, but in the future it may generate alerts instead of blocks), then look at the Origin header to ensure it was called from a real Okta website. It then collect device signals and report it to Okta when the user approve the sign in. So, administrators can also block devices that are rooted, running outdated OS, have no firewalls, has no MDM, etc. It enforces corporate policy along with protecting against phishing
Vile. Though it's a pretty hardcore design error to allow any kind of non-localhost webpage to communicate with localhost. I recall browsers being pretty judicious about that. I guess WebRTC was a loophole.
Question: if I uninstall meta apps today can I stop further tracking?
Based on my understanding of what they're doing, yes. If you don't have their apps installed they can't be running the local web server.
Okay awesome thank you for confirming.
Addendum question: is there a possibility other apps/companies are using a similar trick to track their users.
As stated in the article Yandex has been doing this for much longer. I assume a few other companies are doing it, but Android will probably get an update soon to require consent when a site connects to an app.
My question upon reading this was whether Meta was inserting the Pixel cookie/tracker themselves and then sending it back to the mother ship, or did the website have to participate and serve that tracker first and Meta was listening for it?
The website would have to participate, but participation could involve something as innocuous as copy/pasting a Facebook-provided code snippet to add a like button to their page or show their follower count. Meta probably also provides code for other services like site analytics which would also undoubtedly include the pixel tracker.
I assume it comes along for the ride when you integrate almost anything FB-related on your website, possibly including SSO ("log in with your Facebook account").
Yes, websites have to participate by being part of facebook’s marketing network.
Oh god damnit. I have Threads installed.
I've had my FB account deactivated the past couple months, testing if I'd actually miss it. This is enough of a final push for me to fully delete my FB and kill the apps.
I haven't researched this, but wouldn't having any sort of domain based tracker blocker prevent this from working? I'm thinking things like uBlock, pi-hole, privacy badger, ghostery, etc.
According to the article it requires "Meta Pixel", but if that's some external script (like a Facebook button), it'd have to download the real script from Meta. If that initial script can't be downloaded, then it won't try to connect to the hidden server running on Facebook/Instagram.
If you block the tracking pixel and related javascript from ever loading in your web browser (which may or may not be the case using DNS-based ad blocking, it depends on whether the domain that the pixel is being loaded from is on your blocklist), then this technique by Meta would not work--as you say it requires their code to load and execute in your browser in order to communicate with the native app's web server running in the background on your phone. Presumably they could load the pixel directly from a
facebook.comormeta.comurl, in which case if you're not blocking all of facebook or meta then this technique could still track you.The "Block Outsider Intrusion into LAN" filter list in uBlock Origin supposedly prevents this.
Yeah I'm alarmed that this isn't built into browsers. If any website can just XHR to localhost that's kind of a nightmare
The tin foil hat answer is that Google was doing this too. Sure they could try scrape the data out of the browser directly, which would be a lot more data, but there are lots of eyes looking at the Chrome code base. So obviously the solution is to just not fix this to exploit it from closed-source apps that way it's less visible.
In case it wasn't clear enough from my first few words: this is a thing I just made up with no evidence or any reason to believe is true. Conspiracy theories can just be fun sometimes.