[HN Gopher] Covert Web-to-App Tracking via Localhost on Android
___________________________________________________________________
Covert Web-to-App Tracking via Localhost on Android
Author : sebastian_z
Score : 245 points
Date : 2025-06-03 12:12 UTC (10 hours ago)
(HTM) web link (localmess.github.io)
(TXT) w3m dump (localmess.github.io)
| rvnx wrote:
| Not surprising, it's legal, but only if you are a multi-billion
| dollars company.
| orbital-decay wrote:
| Actual report: https://localmess.github.io/
|
| >Google says it's investigating the abuse
|
| That's a bit ironic, considering how they're using any side
| channel they could lay their hands on (e.g. Wi-Fi AP names) to
| track everyone. Basically every large app vendor with multiple
| apps does something similar to circumvent OS restrictions as
| well.
| voidUpdate wrote:
| I wish we could just ban advertising and tracking on the
| internet. I feel like so much crap these days has come out of it,
| all so that CEOs can afford an extra yacht
| crowcroft wrote:
| The question is how do you ban it, and then how do you prove
| that people are breaking those rules?
| fsflover wrote:
| https://news.ycombinator.com/item?id=43595269
| crowcroft wrote:
| I like the idea, but where do you draw the line on what
| advertising is.
|
| Is affiliate marketing still allowed? Are influencers
| allowed to take payment? Can people be a spokesperson for a
| company? Can newspapers run commentary about businesses?
| Can companies pay to be vendors at a conference?
|
| No matter where you end up drawing the line you're just
| shifting the problems somewhere else. Look at the amount of
| money Meta and Google make, the incentive is just too
| large.
| voidUpdate wrote:
| I know. It's wishful thinking that will never become a
| reality. I pray for a solarpunk future in the same way
| numpad0 wrote:
| By defining the $thing, banning the $thing per definition by
| law, and then tasking FBI-like organization enforce the law?
| It won't completely go away but it will subside, like how
| gambling on Internet is divided binary and confined into
| lootbox games without cashing features and straight up scam
| underground casinos.
|
| Personally I think we should start from separating good old
| ads(that existed before _I_ was 15) and Internet "ads". The
| old ads were still somewhat heavily targeted, but less than
| it is now. There probably would be an agreeable line up to
| which level advertisement efforts can be perverted.
| the_sleaze_ wrote:
| Yes - although I disagree on one point.
|
| All we need to do is define the $thing and mandate that
| lawsuits can be effective.
|
| No agency enforces that potato chips need to fill up 92% of
| the bag or whatever, or that McDonalds cannot show pictures
| of apple fritters with more apples than they actually come
| with (this happened).
|
| You just incentivize a cottage industry of legal that can
| squeeze a profit out of suing peanut butter companies for
| labelling incorrectly, or advertising dishonestly and it
| sort of takes care of itself.
| crowcroft wrote:
| I mean the comparison of 'old' ads vs new ads is
| interesting in itself, old ads already abide by far more
| regulation and are far more auditable. Simply bringing
| digital ads in line would be a big step forward.
|
| Some examples:
|
| In most countries it's illegal to 'target minors' and
| there's restrictions on what ads can run on after school
| hours. Meta has always allowed age targeting down to 13 and
| has no time of day restrictions.
|
| In parts of New Zealand you can't advertise alcohol between
| 10PM and 9AM... unless you do it on Meta or Google.
|
| Most countries have regulation about promoting casinos (or
| the inability to) unless they're digital casinos being
| promoted in digital ads.
|
| Or just look at the deepfake finance and crypto ads that
| run on Meta and X. Meta requires 24 strikes against an
| advertiser before they pull them down, if a TV network ran
| just one ad like that it would be a scandal.
|
| Audit-ability is the biggest issue imo. If a TV ad runs we
| can all see it at the same time and know it ran. That is
| simply impossible with digital ads, and even when Meta
| releases some tools for auditing the caveat is that you
| still have to trust what they're releasing. Similarly with
| data protection there's no way to truly audit what they're
| doing unless you install government agencies in the
| companies to provide oversight, and I don't see how you
| could really make that work.
| voidUpdate wrote:
| It would be nice if they also couldn't target us with
| more information than what we consent to give them. Like,
| fine, if you want to target facebook ads at people using
| details they've filled in, I can see that being
| acceptable, but trying to scrape every single byte of
| data about us and using that to throw targeted ads at us
| feels icky.
|
| Better moderation of crappy AI-generated image ads that
| are just scamming you would be nice as well.
| lucianbr wrote:
| I think the main problem is lots of money are made from it,
| and money influences politics hugely. The technical
| difficulties are low on the list of reasons this is not
| happening.
| pseudocomposer wrote:
| The deprecation of third-party cookies, that _all browsers were
| at one point on track to implement_ , was pretty much the most
| realistic first step to that. Which is why Google killed it
| last year by leveraging their control over Chrome.
|
| While not technically a crime, it was a disgusting, unethical
| market manipulation move that never really got the public
| outrage it deserved.
|
| Google execs' initial support for it was also telling:
| leadership at Google must literally thought they would find
| another way to stay as profitable as they are without third-
| party cookies. Put another way: Google leadership didn't
| understand cookies as well as someone who's taken a single
| undergrad web dev class. (Or they were lying all along, and
| always planned to "renege" on third-party cookie deprecation.)
| crawsome wrote:
| Insidiously calling it "Privacy sandbox", and now setting
| everything opt-in every time I login to Chrome is really not
| Googly.
| IggleSniggle wrote:
| I don't think that's quite what happened. Google got in anti-
| trust trouble because they have an unfair advantage in user-
| tracking, given logged in Chrome accounts. Removing third-
| party cookies hurts other privacy-invading companies without
| substantially affecting Google. It was still somewhat on
| track to be removed from Chrome until they lost their
| antitrust battle, and Chrome was required to be spun off.
| With Chrome's new future, and Google's new legal constraints,
| there's less incentive to try and make Privacy Sandbox work.
| At least, that was my understanding; I didn't follow it all
| that closely.
| skybrian wrote:
| 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.
| threecheese wrote:
| 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)
| Workaccount2 wrote:
| >all so that CEOs can afford an extra yacht
|
| ...and so consumers can use services/products without having to
| fork over money.
|
| People _love_ the ad-model. Given the option to pay or use the
| "ad-supported" option, the ad-supported one wins 10 to 1. This
| means in many cases it doesn't even make sense to have a paid
| option, because the ad option is just so much more popular.
|
| As bad as crypto is, with all the negative things attached to
| it, BAT was probably one of the smartest things to be invented.
| A browser token that automatically dispenses micropayments to
| websites you visit. Forget all the details to get snagged on,
| the basic premise is solid: Pay for what you use. You become
| the customer, not the advertisers.
|
| Also a note about ad-blocking - it only makes the problem
| worse. It is not a "stick it to the man" protest. You protest
| things by boycotting them, or paying their competitors, not by
| using them without compensating them.
| rkomorn wrote:
| I really liked the concept of BAT but the reality left me
| wanting.
|
| Things like "we'll hang on to the tokens of sites that don't
| use BAT yet for them until they join" gave negative vibes.
|
| It all felt a little underbaked. I swing back to Brave once
| in a blue moon and then remember I've got at least $20's
| worth of BAT lost forever somewhere.
| Workaccount2 wrote:
| I'm not a big fan of it or anything, it's just the only
| crypto I know that was targeting that idea.
|
| I'd love if there was another one that was totally open and
| just a browser extension away. But I do not think it would
| ever get off the ground because...
|
| People love the ad model and hate paying for things.
| SecretDreams wrote:
| Yes, we need ads for a free internet, today. And, as a
| result, we also have our privacy eroded - eroded in ways we
| may not care about today, but will probably regret tomorrow.
|
| If we must pay for the internet, give me an option to pay to
| use it where I see no ads and my privacy is preserved. Let me
| know what that cost is and I'll decide what I want to do.
|
| Right now, the actual pricing is obscured so we just "accept"
| that the internet in its current form is how it needs to be.
| account42 wrote:
| There is no such thing as a free lunch. Consumers on average
| are forking over the money. Otherwise no one would pay for
| advertising. And they are paying more than they would have
| otherwise since this dystopian tracking apparatus isn't free
| either.
| fuzzfactor wrote:
| This type of thing is pure greed, completely distinct from a
| highly aggressive pursuit of far more lucrative opportunities
| that average businessmen have been able to accomplish in the
| extreme interest of their shareholders.
|
| Those true leaders are the traditional examples who have shown
| success over the centuries, without letting any greed
| whatsoever become a dominant force, recognizing and moving in
| the opposite direction from those driven by overblown self-
| interest, who naturally have little else to offer. It can be
| really disgraceful these days but people don't seem to care any
| more.
|
| That's one thing that made them _average_ businessmen though.
|
| Now if you're below-average I understand, but most companies'
| shareholders would be better off with a non-greedy CEO, who
| outperforms by steering away from underhanded low-class
| behavior instead.
|
| Now if greed is the only thing on the table, and somebody like
| a CEO or decision-making executive hammers away using his only
| little tool with admirable perseverance long enough, it does
| seem to have a likelihood of bringing in money that would not
| have otherwise come in.
|
| This can be leveraged too, by sometimes even greedier forces.
|
| All you can do is laugh, those shareholders might be satisfied,
| but just imagine what an _average_ person could do with that
| kind of resources. It would put the greedy cretins to shame on
| their own terms.
|
| And if you could find an honest above-average CEO, woo hoo !
| Hilift wrote:
| Reddit has fairly extensive device fingerprinting. And they are
| selling data for training AI models. It's only a matter of time
| before there is some premium phone app that monetizes data that
| otherwise isn't available/for sale.
| lostmsu wrote:
| This just reinforced the use of uMatrix. Governments should
| mandate browser vendors to implement any standards gorhill might
| come up with.
| pabs3 wrote:
| If only uMatrix was still developed/supported.
| pmontra wrote:
| It still works very well. I'm using it on both Linux and
| Android. The UI is far better than its replacement inside
| uBO.
| fc417fc802 wrote:
| The uBO functionality isn't a legitimate replacement. I
| don't understand how that came to pass.
| k4rli wrote:
| Unfortunately in modern web uMatrix is just incredibly
| annoying. Nearly every site breaks for various reasons and
| often allowing everything in uMatrix still doesn't fix the
| issue.
|
| Card payments, especially with 3D secure that use iframes, are
| one of the biggest problems. This often leads to creating new
| order several times since allowing something + reloading loses
| the entire flow.
|
| Captchas are also massive pain, probably because they can't
| fingerprint as well as normally?
|
| Life after having disabled uMatrix completely has been better.
| Xiol32 wrote:
| Crap like this is why I haven't had the Facebook or Instagram
| apps installed for years. I still have accounts, but I only visit
| them via the browser.
| codedokode wrote:
| I am not going to register with FB because they now require a
| 3D face scan to use it.
| bravesoul2 wrote:
| It just wants to make me bin my phone tbh. Thank God for RMS
| and Linus that at least you can run GNU and Linux on a laptop
| as there is little left outside the panopticon.
| qwertox wrote:
| "UPDATE: As of June 3rd 7:45 CEST, Meta/Facebook Pixel script is
| no longer sending any packets or requests to localhost. The code
| responsible for sending the _fbp cookie has been almost
| completely removed."
|
| I'm surprised they're allowed to listen on UDP ports, IIRC this
| requires special permissions?
|
| > The Meta (Facebook) Pixel JavaScript, when loaded in an Android
| mobile web browser, transmits the first-party _fbp cookie using
| WebRTC to UDP ports 12580-12585 to any app on the device that is
| listening on those ports.
|
| Borders on criminal behavior.
|
| Apparently this was a European team of researchers, which would
| mean that Meta very likely breached the GDPR and ePrivacy
| Directive. Let's hope this gets very expensive for Meta.
| fluidcruft wrote:
| Nothing quite like an instant panicked coverup to confirm guilt
| and intent.
|
| Hopefully not too late to make it into the lawsuit. Assholes.
| reaperducer wrote:
| _Hopefully not too late to make it into the lawsuit.
| Assholes._
|
| I sure hope there's a lawsuit. Over the last ten years, I've
| gotten over $2,000 in lawsuit settlement checks from Meta,
| alone.
|
| I have a savings account at one of my banks that I use just
| for these settlement checks. Sometimes they're just $5.
| Sometimes they're a lot more. I think the most I ever got was
| around $500.
|
| It's a little bit here, and a little bit there, but at the
| rate it's going, in another five years, I'll be able to buy a
| car with privacy violation money.
| IncreasePosts wrote:
| 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.
| crtasm wrote:
| It seems incredibly unlikely a low level programmer could
| come up with this method then get the necessary code into
| both the tracking pixel served to third party sites _and_
| Meta 's android apps without some higher ups knowing about
| it.
| lesuorac wrote:
| Or at the very least, a low level programmer not claiming
| credit for it during performance reviews which are
| reviewed by higher people.
| paxys wrote:
| These companies have demonstrated repeatedly that fines are
| just the cost of doing business. Doesn't matter if you charge
| them $1 million or $1 billion. They have still made
| significantly more than that from the crime.
| bauerd wrote:
| The sum absolutely does matter. All you're saying is the
| fines are too low
| account42 wrote:
| That's why fines should scale up geometrically with repeat
| offenses.
| maeil wrote:
| That's.. quite the contradictory sentence.
| reaperducer wrote:
| _> The Meta (Facebook) Pixel JavaScript, when loaded in an
| Android mobile web browser, transmits the first-party _fbp
| cookie using WebRTC to UDP ports 12580-12585 to any app on the
| device that is listening on those ports._
|
| And people on HN dismiss those who choose to browse with
| Javascript disabled.
|
| There's a reason that the Javascript toggle is listed under the
| Security tab on Safari.
| account42 wrote:
| Worse, people on HN _celebrate_ when websites add anti-bot
| protection that prevent you from accessing the website
| without JS.
| pabs3 wrote:
| I'm surprised browsers don't isolate each of the
| localhost/localnet/internet networks from each other. Are there
| any use-cases for allowing this?
| matthberg wrote:
| If I recall correctly Figma uses it to connect to the locally
| installed app, and Discord definitely uses it to check if its
| desktop app is installed by scanning ports (6463-6472).
|
| I'm aware of two blockers for LAN intrusions from public
| internet domains, uBlock Origin has a filter list called "Block
| Outsider Intrusion into LAN" [0] under the "Privacy" filters,
| and there's a cool Firefox extension called Port Authority
| [1][2] that does pretty much the same thing yet more
| specifically targeted and without the exclusions allowed by the
| uBlock filterlist (stuff like Figma's use is allowed through,
| as you can see in [0]). I've contributed some to Port
| Authority, too :)
|
| 0:
| https://github.com/uBlockOrigin/uAssets/blob/master/filters/...
|
| 1: https://addons.mozilla.org/firefox/addon/port-authority
|
| 2: https://github.com/ACK-J/Port_Authority
| bravesoul2 wrote:
| There are surely other ways to achieve this. If you are
| logged into an app and the site at tbe same time they can use
| the server to communicate. Discord doesn't need to know if
| the app is installed to work. That sounds sketchy.
| Orphis wrote:
| It's just a way to ensure you open the desired context on a
| local Discord instance, not any instance that might be
| logged in to your account. I have a few personal computers
| logged in on Discord on the same account that could be
| active at the same time for example.
| pabs3 wrote:
| The native messaging feature is a much better way to talk to
| native apps, that should be used instead for modern browsers.
| neuroticnews25 wrote:
| To me it's weird that they're willing to misuse browser APIs so
| blatantly for interprocess communication, when, as I understand
| it, server-side correlation using a combination of IP, battery
| level and screen dimensions probably already gets them 95% of the
| surveillance capability.
| dylan604 wrote:
| Why is this weird to you instead of being "of course they are"
| to you?
| Retr0id wrote:
| the invisible hand says they have to chase that last 5%, too
| jeroenhd wrote:
| A quite obvious attack mechanism, I'm surprised browsers
| permitted this in the first place. I can't think of a reason to
| STUN/TURN to localhost. Aside from localhost, trackers can also
| use all other IP addresses available to the browser to bind their
| apps/send traffic to.
|
| Now that the mechanism is known (and widely implemented), one
| could write an app to notify users about attempted tracking. All
| you need to do is to open the listed UDP ports and send a
| notification when UDP traffic comes in.
|
| For shit and giggles I was pondering if it was possible to modify
| Android to hand out a different, temporary IPv6 address to every
| app and segment off any other interface that might be exposed
| just because of shit like this (and use CLAT or some fallback
| mechanism for IPv4 connectivity). I thought this stuff was just a
| theoretical problem because it would be silly to be so blatant
| about tracking, but Facebook proves me wrong once again.
|
| I hope EU regulators take note and start fining the websites that
| load these trackers without consent, but I suspect they won't
| have the capacity to do it.
| fc417fc802 wrote:
| > 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.
|
| Approximately, you'd just need to patch the logic where zygote
| changes the PID to also configure and switch to a network
| namespace.
| jeroenhd wrote:
| 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
| rotated regularly.
|
| Plus, you'd need to reconfigure the sandbox when switching
| between WiFi/5G/ethernet. Not impossible to overcome, but not
| the weekend project I'd hoped it would be.
| candiddevmike wrote:
| > modify Android to hand out a different, temporary IPv6
| address to every app
|
| AFAIK this is on the Android roadmap and one of the key reasons
| they don't want to support DHCPv6. They want each app to have
| their own IP.
| bix6 wrote:
| What happened to all the hackers fighting for personal freedom
| and privacy? Meta paycheck too tasty?
| Agentus wrote:
| at some point yah reach a cross road. either sellout and join
| big brother or join the wandering homeless hordes on the
| streets.
| kstrauser wrote:
| Eh. You can have a very comfortable career doing work that
| still lets you look at yourself in the mirror. You don't
| _have_ to choose to burn the world to pay the rent.
| bix6 wrote:
| I agree with you but I also don't. It's a privilege to have
| the ability to choose which job you work.
| kstrauser wrote:
| Not in this case. If you're qualified to get a job at a
| company who will pay you to sell out your neighbor,
| you're qualified to get a job with a decent boss who'll
| never ask you do to do this kind of thing, pays 90% as
| much, and is still many times the national average
| salary.
|
| The alternatives are not doing evil vs starving. They're
| getting paid well for doing evil, or getting paid well
| for doing good or at least neutral.
| bix6 wrote:
| Ok you've convinced me!
| kstrauser wrote:
| We're still fighting the fight. Turns out shifty assholes also
| figured out how to write code and get hired.
| bix6 wrote:
| Thank you for your service!
| danaris wrote:
| In the early days of the information revolution, when computers
| were new and being nerdy was still seen (almost universally) as
| a bad thing, a very high proportion of computer enthusiasts
| were people already on the fringes of society, for one reason
| or another. For a large number of them, hacking was a way to
| express their preexisting antiestablishment tendencies. For a
| lot of them, they were also your basic angsty adolescents and
| young adults rebelling against The Man as soon as they found
| any way to do so.
|
| As time went on, computers became more mainstream, and lots
| more people started using them as part of daily life. This
| didn't mean that the number of antiestablishment computer users
| or hackers went down--just that they were no longer nearly so
| high a percentage of the total number of computer users.
|
| So the answer to "what happened to all the hackers fighting for
| personal freedom and privacy?" is kinda threefold:
|
| 1) They never went away. They're still here, at places like the
| EFF, fighting for our personal freedom and privacy. They're
| just much less noticeable in a world where _everyone_ uses
| computers...and where many more of the prominent institutions
| actually know how to secure their networks.
|
| 2) They grew up. Captain Crunch, the famous phreaker, is 82
| this year. Steve Wozniak is 74. And while, sure, some people
| reach that age and still maintain not merely a philosophy, but
| a practice, of activism, it's much harder to keep up, and even
| many of those whose principles do not change will shift to
| methods that stay more within the system (eg, supporting
| privacy legislation, or even running for office themselves).
|
| 3) They went to jail, were "scared straight", or died. The most
| prominent example of this group is, of course, Aaron Swartz,
| but many hacktivists will have had run-ins with the law, and of
| those many of them will have turned their back on the lifestyle
| to save themselves (even Captain Crunch was arrested and
| cooperated with the FBI).
| bix6 wrote:
| Thanks for your thoughts! How can we create more hackers? I
| think the fear of punishment has really put a damper on
| things but not sure how that can be avoided.
| kstrauser wrote:
| Hacking isn't about crime. It's about exploration. There
| are lots of people showing "the youths" how interesting it
| is to break a lock or go around it. Basically, any time you
| can make a system do something fun, helpful, or interesting
| that it wasn't intended to do, that's hacking. You can be
| 100% law abiding with no fear of punishment and still get
| the full experience.
| paxys wrote:
| Who do you think found the issue?
| bix6 wrote:
| Touche
| GrantMoyer wrote:
| Would an individual using this technique to collect information
| from someone else's computer possibly face prosecution under the
| Computer Fraud and Abuse act?
| croes wrote:
| Yes
| paxys wrote:
| People have been prosecuted under that act for clicking "view
| source" on their web browser. The crime itself is irrelevant.
| It's more about who you are/what connections you have/who you
| piss off.
| gruez wrote:
| This only works if you control the code on both sides (ie. on
| the website being visited and an app running on the phone).
| It's not some sort of magic hack that allows you to exfiltrate
| arbitrary browser history. Therefore it's unclear how it can be
| construed as "hacking" in any meaningful way. As bad non-
| consensual tracking done by google/meta/whatever are, it's not
| covered under CFAA.
| GrantMoyer wrote:
| I agree it's not hacking, but the Computer Fraud and Abuse
| act seems to have a pretty broad definition of computer fraud
| and abuse. In particular, the technique seems like it might
| (emphasis mine) "knowingly and with intent to defraud,
| accesses a protected computer without authorization, or
| _exceeds authorized access_ , and by means of such conduct
| furthers the intended fraud and obtains anything of value
| ...". Would the other person have a reasonable belief that
| they didn't authorize access to information which their OS
| attempts to prevent access to?
|
| I'm not a lawyer, so my question is genuine.
| threecheese wrote:
| The yandex one uses client/browser-side code to exfiltrate;
| it's within the realm of possibility to abuse this, given a
| user visits a site under your control.
|
| On the FB side, I can see a malicious user potentially
| poisoning a target site visitors's ad profile or even social
| media algorithm with crafted cookies. Fill their feed with
| diaper ads or something.
| merek wrote:
| This is the overall process used by Meta as I understand it,
| taken from https://localmess.github.io/:
|
| 1. User logged into FB or IG app. The app runs in background, and
| listens for incoming traffic on specific ports.
|
| 2. User visits website on the phone's browser, say something-
| embarassing.com, which happens to have a Meta Pixel embedded.
| From the article, Meta Pixel is embedded on over 5.8 million
| websites. Even in In-Cognito mode, they will still get tracked.
|
| 3. Website might ask for user's consent depending on location.
| The article doesn't elaborate, presumably this is the cookie
| banner that many people automatically accept to get on with their
| browsing?
|
| 4. > The Meta Pixel script sends the _fbp cookie (containing
| browsing info) to the native Instagram or Facebook app via WebRTC
| (STUN) SDP Munging.
|
| You won't see this in your browser's dev tools.
|
| 5. Through the logged-in app, Meta can now associate the
| "anonymous" browser activity with the logged-in user. The app
| relays _fbp info and user id info to Meta's servers.
|
| Also noteworthy:
|
| > 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.
|
| > On or around May 17th, Meta Pixel added a new method to their
| script that sends the _fbp cookie using WebRTC TURN instead of
| STUN. The new TURN method avoids SDP Munging, which Chrome
| developers publicly announced to disable following our
| disclosure. As of June 2, 2025, we have not observed the Facebook
| or Instagram applications actively listening on these new ports.
| fluidcruft wrote:
| Not totally following but it sounds like you are saying one of
| the things they have been doing involves abusing mandated GDPR
| cookie notices to secretly track people?
| scott_w wrote:
| Which, on the face of it, sounds like a violation of the
| GDPR...
| fluidcruft wrote:
| The intent of these laws is just so obtuse and unclear! And
| beyond that complying is technically impossible to
| implement but you could only understand that if you were a
| rocket scientist PhD computer science wizkid making $$$$k
| in California which isn't that much in such a high cost of
| living area donchaknow. /sardonic
| gruez wrote:
| >abusing mandated GDPR cookie notices to secretly track
| people?
|
| How does that even work? What can GDPR cookie notices can do
| that the typical tracker can't do?
| threecheese wrote:
| Yes? The cookie in question is First Party, which means
| you've consented to permitting only that party to track you
| using it, and not permitting its use for wider behavioral
| tracking across websites.
|
| However, the locally hosted FB/Yandex listener receives all
| of these first party cookies, from all parties, and the OPs
| implication is (I think) that now these non-correlateable-by-
| consent first party cookies can be or are being used to track
| you across all sites that use them.
| threecheese wrote:
| Not only did you only consent to the one party using it,
| but the browser has robust protections in place to ensure
| that these cookies are only usable by that party. This
| "hack" gets around the restriction completely, leveraging a
| local service to aggregate all the cookies across sites.
| codedokode wrote:
| So main application for WebRTC is de-anonymisation of users
| (for example getting their local IP address). Why it is not
| hidden behind permission I don't understand.
| afavour wrote:
| 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
| able to make an informed choice after reading that?
| codedokode wrote:
| The website wants to connect to another computer|another
| app on your computer.
|
| Most users probably will click "No" and this is a good
| choice.
| afavour wrote:
| But that says nothing about the danger of identifying
| you.
|
| > Most users probably will click "No"
|
| Strong disagree. When I'm loading google.com is my
| computer not connecting to another computer? From a
| layman's perspective this is the basis of the internet
| doing what it does. Not to mention, the vast majority of
| users say yes to pretty much any permission prompt you
| put in front of them.
| gruez wrote:
| >The website wants to connect to another computer|another
| app on your computer.
|
| "website wants to connect to another computer" basically
| describes all websites. Do you really expect the average
| user to understand the difference? The exploit is also
| non-trivial either. SDP and TURN aren't privacy risks in
| and of themselves. They only pose risks when the server
| is set to localhost and with a cooperating app.
| deepsun wrote:
| Let it show "Use WebRTC?".
|
| If users don't understand, they click whatever. If the
| website really needs it to operate, it will explain why
| before requesting, just like apps do now.
|
| Always aim for a little more knowledgeable users than you
| think they are.
| afavour wrote:
| That feels pretty useless. You might as well do what
| happens today: enable it by default and allow
| knowledgable power users to disable it. If it's disabled,
| show a message to the user explaining why it's needed.
| deepsun wrote:
| Today there's no way to disable it, I searched through my
| Firefox Mobile settings. So I'd say it's for very "power"
| users.
|
| And why enable it by default, why not disable by default?
|
| Also, sibling comments say iOS is already asking for the
| permission, why not just copy it?
| btown wrote:
| And specifically, if you're on something-sensitive.com in
| a private browsing session, it would give you the choice
| of giving _no_ optional permissions. That choice is
| better than no choice at all, especially in a world where
| Meta can be subpoenaed for this tracking data by actors
| who may be acting unconstitutionally without sufficient
| oversight.
| account42 wrote:
| TFA list tens of thousands of websites using WebRTC for
| deanonymization. How many websites using it for P2P data
| transfer can you list?
| mindslight wrote:
| Browser functionality needs a hard segmentation into
| disparate categories like "pages" and "apps". For example,
| _Pages_ that you 're merely intending to view don't need
| WebRTC (or really any sort of network access beyond the
| originating site, and even this is questionable). And you'd
| only give something _App_ functionality if it was from a
| trustable source and the intent was to use it as general
| software. This would go a long way to solving the other
| fingerprinting security vulnerabilities, because _Pages_
| don 't need to be using functionality like Canvas, USB,
| etc.
| miloignis wrote:
| The existing killer app for WebRTC is video chat without
| installing an app, which is huge.
|
| Other P2P uses are very cool and interesting as well -
| abusing it for fingerprinting is just that, abusing a user-
| positive feature and twisting it for identification, just
| like a million other browser features.
| account42 wrote:
| You mean just like a million other "user-positive" browser
| features pushed by the biggest tracking company there is.
| consumer451 wrote:
| > something-embarassing.com,
|
| Depending on the country that you or your family lives in, this
| could be far worse than embarrassment.
| hulitu wrote:
| > Meta and Yandex are de-anonymizing Android users' web browsing
| identifiers
|
| Thank god that Microsoft and Google don't do this. Oh, wait... /s
| matthberg wrote:
| A comment I wrote in another HN thread [0] covering this issue:
|
| Web apps talking to LAN resources is an attack vector which is
| surprisingly still left wide open by browsers these days. uBlock
| Origin has a filter list that prevents this called "Block
| Outsider Intrusion into LAN" under the "Privacy" filters [1], but
| it isn't enabled on a fresh install, it has to be opted into
| explicitly. It also has some built-in exemptions (visible in [1])
| for domains like `figma.com` or `pcsupport.lenovo.com`.
|
| There are some semi-legitimate uses, like Discord using it to
| check if the app is installed by scanning some high-number ports
| (6463-6472), but mainly it's used for fingerprinting by malicious
| actors like shown in the article.
|
| Ebay for example uses port-scanning via a LexisNexis script for
| fingerprinting (they did in 2020 at least, unsure if they still
| do), allegedly for fraud prevention reasons [2].
|
| I've contributed some to a cool Firefox extension called Port
| Authority [3][4] that's explicitly for blocking LAN intruding web
| requests that shows the portscan attempts it blocks. You can get
| practically the same results from just the uBlock Origin filter
| list, but I find it interesting to see blocked attempts at a more
| granular level too.
|
| That said, both uBlock and Port Authority use WebExtensions'
| `webRequest` [5] API for filtering HTTP[S]/WS[S] requests. I'm
| unsure as to how the arcane webRTC tricks mentioned specifically
| relate to requests exposed to this API; it's possible they might
| circumvent the reach of available WebExtensions blocking methods,
| which wouldn't be good.
|
| 0: https://news.ycombinator.com/item?id=44170099
|
| 1:
| https://github.com/uBlockOrigin/uAssets/blob/master/filters/...
|
| 2: https://nullsweep.com/why-is-this-website-port-scanning-me/
|
| 3: https://addons.mozilla.org/firefox/addon/port-authority
|
| 4: https://github.com/ACK-J/Port_Authority
|
| 5: https://developer.mozilla.org/en-US/docs/Mozilla/Add-
| ons/Web...
| JimDabell wrote:
| There is a specification for blocking this:
|
| https://wicg.github.io/private-network-access/
|
| It gained support from WebKit:
|
| https://github.com/WebKit/standards-positions/issues/163
|
| ...and Mozilla:
|
| https://github.com/mozilla/standards-positions/issues/143
|
| ...and it was trialled in Blink:
|
| https://developer.chrome.com/blog/private-network-access-upd...
|
| Unfortunately, it's now on hold due to compatibility problems:
|
| https://developer.chrome.com/blog/pna-on-hold
| matthberg wrote:
| Yep! Unfortunately its main method (as far as I remember from
| when I first read the proposal at least, it may do more) is
| adding preflight requests and headers to opt-in, which works
| for most cases yet doesn't block behind-the-lines
| collaborating apps like mentioned in the main article. If
| there's a listening app (like Meta was caught doing) that's
| expecting the requests, this doesn't do much to protect you.
|
| EDIT: Looks like it does mention integrating into the
| permissions system [0], I guess I missed that. Glad they
| covered that consideration, then!
|
| 0: https://wicg.github.io/private-network-
| access/#integration-p...
| bakkoting wrote:
| Both Firefox [0] and Chrome [1] are working on successors
| which rely on permissions prompts instead of preflight
| requests.
|
| [0] https://groups.google.com/a/mozilla.org/g/dev-
| platform/c/B8o...
|
| [1] https://groups.google.com/a/chromium.org/g/blink-
| dev/c/CDy8L...
| account42 wrote:
| > There are some semi-legitimate uses, like Discord using it to
| check if the app is installed by scanning some high-number
| ports (6463-6472)
|
| I would not consider this a legitimate use. Websites have no
| business knowing what apps you have installed.
| robin_reala wrote:
| Zoom got busted for something similar five years ago now:
| https://www.zdnet.com/article/zoom-defends-use-of-local-
| web-...
| matthberg wrote:
| I agree, yet at least you can kind of see where they're
| coming from.
|
| I guess a better example would be the automatic hardware
| detection Lenovo Support offers [0] by pinging a local app
| (with some clear confirmation dialogs first). Asus seems to
| do the same thing.
|
| uBlock Origin has a fair few explicit exceptions made [1] for
| cases like those (and other reasons) in their filter list to
| avoid breakages (notably Intel domains, the official
| Judiciary of Germany [2] (???), `figma.com`,
| `foldingathome.org`, etc).
|
| 0: https://pcsupport.lenovo.com/
|
| 1: https://github.com/uBlockOrigin/uAssets/blob/master/filter
| s/...
|
| 2: https://github.com/uBlockOrigin/uAssets/issues/23388 and
| https://www.bundesjustizamt.de/EN/Home/Home_node.html
| (they're trying to talk to a local identity verification app
| seems like, yet I find it quite funny)
| mschuster91 wrote:
| > the official Judiciary of Germany [2] (???)
|
| That's the e-ID function of our personal ID cards (notably,
| NOT the passports). The user flow is:
|
| 1. a client (e.g. the Deutsche Rentenversicherung,
| Deutschland-ID, Bayern-ID, municipal authorities and a few
| private sector services as well) wishes to get
| cryptographically authenticated data about a person (name
| and address).
|
| 2. the web service redirects to Keycloak or another IDP
| solution
|
| 3. the IDP solution calls the localhost port with some
| details on what exactly is requested, what public key of
| the service is used, and a matching certificate signed by
| the Ministry of Interior.
|
| 4. The locally installed application ("AusweisApp") now
| opens and displays these details to the user. When the user
| wishes to proceed, the user clicks on a "proceed" button,
| and is then prompted to either insert the ID card into a
| NFC reader attached to the computer or a smartphone in the
| same network as the computer that also has the AusweisApp
| attached.
|
| 5. The ID card's chip verifies the certificate as well and
| asks for a PIN from the user
|
| 6. the user enters the PIN
|
| 7. the ID card chip now returns the data stored on it
|
| 8. the AusweisApp submits an encrypted payload back to the
| calling IDP
|
| 9. the IDP decrypts this data using its private key and
| redirects back to the actual application.
|
| There is a bunch of cryptography additionally layered in
| the process that establishes a secure tunnel, but it's too
| complex to explain here.
|
| In the end, it's a highly secure solution that makes sure
| that _only_ with the right configuration and conditions
| being met the ID card actually responds with sensitive
| information - unlike, say, the Croatian ID card that will
| go as far as to deliver the picture on the card in digital
| form to anyone tapping your ID card on their phone. And
| that 's also why it's impossible to implement in any other
| way - maaaaybe WebUSB but you'd need to ship an entire
| PC/SC stack and I'm not sure if WebUSB allows cleaving an
| USB device that already has a driver attached.
|
| In addition, the ID card and the passport also contains an
| ICAO compliant method of obtaining the data in the MRZ, but
| I haven't read through the specs of _that_ enough to
| actually implement this.
| account42 wrote:
| IMO browsers should not just block the request but block the
| whole website with one of those scary giant red banners if
| something like this is attempted. If all websites get for
| trying to work around privacy protections is that their
| attempts might not succeed then there is little incentive not
| to try.
| xrisk wrote:
| Your DNS server not resolving to localhost may also serve as an
| additional line of defense.
| h43z wrote:
| What does this have to do with the issue here? A website can
| just connect to 127.0.0.1 , no DNS needed.
|
| I think what you are thinking of are dns rebinding attacks.
| kriro wrote:
| The EU should set some record breaking fines for this.
|
| Maybe it's time to invent a tax that starts at 0% and goes up
| 1-X% every time your hand is cought in the cookie jar. And add a
| corresponding website where you can clearly see all violations by
| company.
| like_any_other wrote:
| There should _also_ be fines, but individuals have gone to jail
| for less.
| Hilift wrote:
| Meta makes $70 billion net per year, after fines.
| bravesoul2 wrote:
| So Meta apps are spyware. And Zuck agains has got his finger in
| his mouth and a cat on his lap.
| dylan604 wrote:
| All Meta software is spyware. Whether it's an app or a website,
| they are only in existence for you to be pacified to spend as
| much time on them as possible so they can hoover up your data.
| If those apps/websites provide you with anything useful, it is
| just as a ruse to get more data from you.
| dylan604 wrote:
| *: Meta Pixel script was last seen sending via HTTP in Oct 2024,
| but Facebook and Instagram apps still listen on this port today.
| They also listen on port 12388 for HTTP, but we have not found
| any script sending to 12388. **: Meta Pixel script sends
| to these ports, but Meta apps do not listen on them (yet?). We
| speculate that this behavior could be due to slow/gradual app
| rollout.
|
| So, could some other app send data to these ports with a fake
| message? I'm asking for a friend that likes to do things for
| science.
| fshafique wrote:
| Two ways to f#ck with these trackers - either send them nothing
| back, or flood them with lots of fake data.
|
| Somebody also needs to come up with a way to peer to peer share
| advertiser tracking cookies.
| paxys wrote:
| All 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?
| dylan604 wrote:
| Which begs the question why is this specific to Android? Why
| would Meta/Yandex not be doing this on iOS, or why did this
| study not report on iOS?
| mig39 wrote:
| 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.
| paxys wrote:
| In this case it's the web browser connecting to the
| network, so the permission is irrelevant.
| JimDabell wrote:
| > What even is a legitimate use case for an app starting a
| local web server?
|
| There are apps on iOS that act as shared drives that you can
| attach via WebDAV. This requires listening on a port for
| inbound WebDAV (HTTP) requests.
| like_any_other wrote:
| A commenter mentioned [1] that major Russian apps now all ask for
| permission to read a unique device ID to deanonymize users. The
| people that stopped Intel from adding such an ID to their CPUs
| had perfect foresight [2] (too bad later Intel added it anyway).
| But then it's not hard to guess that if you include a feature
| whose purpose is to attack the user, it will be used to attack
| the user.
|
| [1] https://arstechnica.com/security/2025/06/meta-and-yandex-
| are...
|
| [2]
| https://en.wikipedia.org/wiki/Pentium_III#Controversy_about_...
| gruez wrote:
| >A commenter mentioned [1] that major Russian apps now all ask
| for permission to read a unique device ID to deanonymize users.
|
| To be fair it's not really limited to Russian apps. Many
| popular apps on play store have it as well:
|
| https://play.google.com/store/apps/details?id=org.telegram.m...
|
| https://play.google.com/store/apps/details?id=com.microsoft....
|
| https://play.google.com/store/apps/details?id=com.pinterest&...
| lachlan_gray wrote:
| Is there a similar thing on iOS? I always wonder when a random
| app asks to "find devices on my network"
| JimDabell wrote:
| This is answered on the page.
| pacifika wrote:
| > That said, similar data sharing between iOS browsers and
| native apps is technically possible.
| cosmic_cheese wrote:
| Possible, but potentially not as practical due to the iOS'
| restrictive background process model. There, background tasks
| are generally expected to quickly do whatever it is they need
| to and exit and generally can't run indefinitely. Periodic
| tasks are scheduled by the OS, with scheduling requests from
| apps being more likely to be honored if their processes are
| well-behaved (quick, low resource, don't crash, and don't run
| too frequently) with badly-behaved processes getting run less
| often.
|
| Apps that keep themselves open by reporting that they're
| playing audio might be able to work around this, but it'd still
| be spotty since users frequently play media which would
| suspended those backgrounded apps and eventually bump them out
| of memory.
| cluckindan wrote:
| It's probably easier to buy that data directly from Apple.
|
| Google's core business is built on tracking data, so they would
| be reluctant to sell, necessitating covert collection.
| bravesoul2 wrote:
| Can this cross profiles? That would be a big security issue for
| corps.
|
| Quick test and if I serve on 8080 on the Userland app it can be
| accessed from both profiles. So probably yes.
|
| This means an infected app on your personal profile could
| exchange data with a site visited from a second profile.
| lxgr wrote:
| Only if that site specifically communicates with an
| (unauthenticated) service bound to a local port though, right?
| btown wrote:
| Which, per the OP, the site would be doing by merely
| including the Meta pixel, which practically every e-commerce
| and news site does to track its campaigns and organic
| traffic.
|
| The takeaway is that for all intents and purposes, anything
| you did in a private session or secondary profile on an
| Android device with any Meta app installed, was fully
| connected to your identity in that app for an unknown amount
| of time. And even with the tracking code deactivated, cookies
| may still persist on those secondary profiles that still
| allow for linking future activity.
| lxgr wrote:
| Yes, but if the concern is not mixing business and personal
| compartment of the phone, business sites would hopefully
| not embed a Meta tracking pixel.
|
| > The takeaway is that for all intents and purposes,
| anything you did in a private session or secondary profile
| on an Android device with any Meta app installed, was fully
| connected to your identity
|
| Definitely, and that's a huge problem. I just don't think
| Android business profiles are a particular concern here;
| leaking app state to random websites in _any_ profile is
| the problem.
|
| Or do Android "business profiles" also include browser
| sessions? Then this would be indeed a cross-compartment
| leak. I'm not too familiar with Android's compartment
| model; iOS unfortunately doesn't offer sandboxing between
| environments that way.
| d4mi3n wrote:
| While I agree with your reasoning, in my experience any
| statement where I prepend "hopefully" usually ends up
| being the worst possible interpretation in practice.
| lxgr wrote:
| What I mean is: If a corporate internal website regularly
| connects to unauthenticated local ports and _leaks
| sensitive data out_ , that's fully on them.
|
| If they are trying to fingerprint the "private
| compartment" of a BYOB device, that seems roughly as bad
| as a non-corporate side doing the same.
| d4mi3n wrote:
| 100% agree, and fingerprinting BYOB devices would be
| problematic in a lot of ways.
|
| I'm generally against BYOD programs. They're convenient
| but usually come from a place of allowing employees
| access to things without the willingness to take on the
| cost (both in corp devices and inconvenience of a second
| phone/tablet/whatever) to run them with a high level of
| assurance.
|
| Much better in my opinion to use something like PagerDuty
| or text/push notifications to prompt folks to check a
| corp device if they have alerts/new emails/whatever.
| bravesoul2 wrote:
| You can easily click a link e.g. to a blog post on Chrome
| inside your profile.
|
| E.g. a Jira ticket links to a post on how to do something
| concurrency related in Python.
|
| I get your point thought that maybe this is no worse than
| if they visit the site on the personal side.
|
| However I wouldn't trust out lack of imagination on how
| to exploit this to be happy about the security gap!
| glennpratt wrote:
| > do Android "business profiles" also include browser
| sessions
|
| I believe that is typical.
|
| My business profile has it's own instance of Chrome.
| Mostly used for internal and external sites that require
| corporate SSO or client certificates. Of course it could
| be used to browse anything.
| lgats wrote:
| I built a little lan tool https://router.fyi that tries to get
| LAN data for a sort of online-nmap. depending on your browser,
| it's sometimes capable of finding wifi printers and a couple
| other smart home devices i've manually added.
| barbazoo wrote:
| Probably hard to do for many but the solution seems be not to
| have their apps installed. It's crazy to me that people tolerate
| FB et al on their devices where you have absolutely no control
| over what they're doing.
| threecheese wrote:
| I agree wrt Facebook, but there's a long tail of useful apps-
| that-should-be-websites; 1 click for an app versus 45 seconds
| searching through tabs and re-logging in (etc) can be
| meaningful, especially when there are fifty of them.
|
| My healthcare provider recently yanked the mobile version of
| their portal website, and forces users to download their app.
| Personally, I see the security angle, but still feel like it's
| a punch in the face and so I just went back to paper billing
| and using a PC for healthcare stuff. More of this is coming, I
| suspect.
| Hilift wrote:
| Reddit has fairly intense device fingerprinting. And they sell
| data for AI training.
| username135 wrote:
| Simple question: would disabling apps from running in the
| background prevent this? Or, more simply, not staying logged into
| an app on your phone?
| robin_reala wrote:
| Can you imagine the mental hoops you'd need to jump through as a
| developer to persuade yourself that this is a valid thing to
| implement?
| fanatic2pope wrote:
| My experience is that most developers just do as they are told.
| robin_reala wrote:
| Another reason why AI is so fascinatingly horrible: it'll
| never question the moral impact of what you're trying to do.
| ambicapter wrote:
| Not many? You've never met a developer with a god complex?
| edoceo wrote:
| Get paid - it's one hoop.
| kube-system wrote:
| Zero. People who work on ad-tech build ad-tech all day long,
| that's the entire job.
|
| Seriously, why do you think all of the unquestionable things
| humanity has built have been built? It's because it's all just
| part of the job, for somebody.
|
| People working at ad-tech question the things they're building
| just like the people at McDonalds flipping a burger are
| questioning the cholesterol levels of their customers. They're
| not.
| dylan604 wrote:
| I mean, it is kind of a cool work around. There's a lot of
| motivation in telling someone they can't do something where
| "hide and watch" is a pretty typical response. The creative
| thinking that comes up with ideas like this is not something to
| discourage. It is a shame that the effort is for such a shit
| purpose, but these "people" are not stupid, and not many other
| areas offer these kind of challenges.
| paxys wrote:
| If you are even mildly technical you NEED to have a Pihole +
| Tailscale setup on your home network and all devices. Block all
| this malware at the root.
| aembleton wrote:
| Or change your DNS to use nextDns
| aembleton wrote:
| Sounds like blocking these tracking scripts using uBlockOrigin
| probably prevents this. Another reason to use uBlockOrigin.
| dmantis wrote:
| Does that work across profiles? I have to use some apps from such
| spyware oriented companies and usually put them in isolated
| profile with shelter.
|
| I wonder whether local ports opened in isolated "work" android
| profile are accessible by main profile.
| Aissen wrote:
| Love the url slug: headline-to-come. It now redirects to a more
| boring one though.
| bnpxft wrote:
| Another reason not to install big tech's apps and only use their
| websites if you must.
|
| Not only our their websites painful which discourages use,
| websites are more sandboxed.
| danieldk wrote:
| I am not sure which Meta apps open ports, but e.g. Samsung
| phones come with a bunch of Meta apps pre-shipped. IIRC just
| removing the Facebook app is is not enough, there is another
| service installed that is not visible as an app
| (com.facebook.services etc.), which you can only uninstall from
| the data partition with something like ADB/UAD.
|
| Or buy an iPhone or a Pixel.
| jmm5 wrote:
| The Pixel "Private Space" feature should prevent Meta apps
| from running in the background. It also prevents you from
| getting notifications.
| johnisgood wrote:
| I tend to buy stock Android, e.g. Motorola moto g30, etc. It
| still has lots of Google stuff, but you can get rid of them,
| and I have a work profile specifically designed for Google-
| related stuff, and my personal profile is de-Googled as much
| as possible.
| danieldk wrote:
| I would recommend everyone who wants a clean Android to
| look into Google Pixel phones. Aside from being mostly
| bloat-free (and most bloat can be uninstalled), it is one
| of the few phones that supports unlocking/relocking and a
| secure open source alternative (GrapheneOS).
| captn3m0 wrote:
| Another 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/item?id=43518866 , 482
| comments)
| maeil wrote:
| Incredible that this was locked.
| bossyTeacher wrote:
| dang likely got told not to upset the benefactors
| maeil wrote:
| On 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.
| aucisson_masque wrote:
| 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.
| hofrogs wrote:
| Doing something like this should result in Meta and such being
| legally annihilated. But nothing will happen, as usual.
| OsrsNeedsf2P wrote:
| What's the crime?
| hofrogs wrote:
| Spying on users, connecting their real life identities to
| their browsing history without their consent or knowledge?
| kennywinker wrote:
| Tracking users without their consent. This is a crime in the
| EU. It's a crime that it's not a crime in the US.
| autoexec wrote:
| stalking? Maybe even something in the ECPA
| lucianbr wrote:
| Unauthorized access to a computer system. I'm sure if I
| connected to some port on a computer belonging to Meta
| without them wanting it, that would be the crime I would be
| charged with. But somehow if Meta connects to a port on my
| phone without me agreeing to it, it's not a crime?
| nickphx wrote:
| Yes.. and that listening service is their software that you
| installed on your device... So caveat emptor.
| genewitch wrote:
| Software that came preloaded with what sounds
| suspiciously like a rootkit to keep the background
| service running on some phones.
|
| Please don't "don't that phone then" because it's the
| same all the way down to rotary telephones.
|
| I still didn't consent to meta tracking me on my
| telephone. I understand the shadow profiles and tracking
| pixels and whatnot, but cmon.
|
| Next year "actually meta was listening to conversations
| captured by android devices and using it to target ads"
|
| Don't use a cellphone? Meta and Google track desktop web
| use. Don't use a computer? Okay, that's cool.
| jurgenkesker wrote:
| Ah yes, and every small Android dev is banned from Play and Admob
| for tiny unknown reasons, with no recourse or way to communicate
| with Google. But Meta here probably won't get any problems at
| all. They should be temporarily banned!
| qwertox wrote:
| I wonder if companies like Wetter Online (from whom we know that
| they're selling the location data to brokers [0]) or ad service
| providers which offer libraries do the same.
|
| If it were so, Google should be knowingly be allowing this to
| happen and be a co-conspirator. I mean, they surveil our devices
| as if it were their home. Impossible that they're not aware.
|
| [0] https://netzpolitik-org.translate.goog/2025/databroker-
| files...
| josephcsible wrote:
| Why don't all browsers, desktop and mobile, just block all cross-
| origin access to localhost?
| easterncalculus wrote:
| For one I think it would break all those "update your BIOS via
| your motherboard website" apps that probably shouldn't exist
| anyways.
|
| There probably are some legitimate uses, but I'm straining to
| come up with them.
| arunkant wrote:
| Maybe just ask for confirmation
| chedabob wrote:
| I thought they did for resources and JS, which is why Meta have
| to use WebRTC instead?
|
| I think the Yandex one slips through because CORS does a naive
| check against just what's in the header, not what it resolves
| to?
| chedabob wrote:
| Does the Yandex HTTPS one mean they're shipping the private key
| for their cert in the app, therefore anything running on
| localhost (or on a network with poisoned DNS) can spoof the
| yandexmetrica site?
|
| There is a cert for it in the logs:
| https://crt.sh/?q=yandexmetrica.com
| worik wrote:
| This is yet another reason for installing very few apps
| ethbr1 wrote:
| The reason to install very few mobile apps is directly
| proportional to the effort companies exert to get you to do so.
|
| And they push _REALLY_ hard.
| neilv wrote:
| Of course the ID was easy to abuse, and I assume Google knew
| this, and also knew they'd need to have rules against abuse...
| and that they'd need to back up the rules with penalties, like
| Play Store permaban, legal action for damages, and maybe even
| referral for criminal investigation (CFAA violation?).
|
| Unfortunately, even if they did have such rules, in this case,
| Meta is a too-big-to-deplatform tech company.
|
| (Also, even if it wasn't Meta, sketchy behavior of tech might
| have the secret endorsement of IC and/or LE. So, making the
| sketchiness stop could be difficult, and also difficult to talk
| about.)
| ogurechny wrote:
| Google and Apple are owning their whole operating systems. They
| can do tracking directly in 50 different ways. Other
| corporations routinely renegotiate deals on sharing the user
| surveillance data with them, for big big money. So it all has
| already been paid for, and authorised. The only problem is that
| some stupid serfs are still making a fuss over it.
| tomhow wrote:
| We changed the URL from
| https://arstechnica.com/security/2025/06/meta-and-yandex-are...
| which is a report about this disclosure.
| ugh123 wrote:
| No doubt, whatever "vulnerability" is found, you have already to
| agreed to it in some buried TOS.
___________________________________________________________________
(page generated 2025-06-03 23:01 UTC)