[HN Gopher] CVE-2024-9956 - PassKey Account Takeover in All Mobi...
___________________________________________________________________
CVE-2024-9956 - PassKey Account Takeover in All Mobile Browsers
Author : rbanffy
Score : 175 points
Date : 2025-03-19 06:07 UTC (16 hours ago)
(HTM) web link (mastersplinter.work)
(TXT) w3m dump (mastersplinter.work)
| vlovich123 wrote:
| since not stated in the article and I started to get worried,
| this was reported last year.
|
| Safari: fixed in 18.3 (Jan 2025)
|
| Firefox: fixed in 136 (March 2025)
|
| Chrome: fixed in 130.0.6723.58/.59 (Oct 2024)
|
| Wow - only Google seemed to really prioritize fixing this / had
| the processes and manpower to get a fix out quickly.
|
| Mozilla's bug report is still locked down but Google's is open:
| https://issues.chromium.org/issues/370482421
| protimewaster wrote:
| > Wow - only Google seemed to really prioritize fixing this /
| had the processes and manpower to get a fix out quickly.
|
| I would have guessed they'd be the quickest, but I wouldn't
| have guessed they'd be months ahead of the others.
| jbverschoor wrote:
| Perhaps they had the info before it was disclosed to the
| others?
| crtasm wrote:
| https://www.mozilla.org/en-
| US/security/advisories/mfsa2025-1... links the bug
| https://bugzilla.mozilla.org/show_bug.cgi?id=1922357
|
| but it's not public, perhaps someone can tell us when it
| was opened.
| jbverschoor wrote:
| The next issue,
| https://bugzilla.mozilla.org/show_bug.cgi?id=1922358 is
| from October 2nd 2024
| gavinsyancey wrote:
| Reading through the Chromium bug report, it looks like the
| reporter wasn't able to get in contact with Mozilla until
| February, so after they were aware it only took a month to
| fix the bug in Firefox. It's unclear when they started
| trying, and who's fault the delay is.
| mastersplinter wrote:
| I can't speak to the prioritization differences between the
| different browser teams, Chrome was definitely the best which
| isn't surprising considering their resources. Apple was also
| quite swift but I imagine it took them some time to decide
| where to deliver the fix, I myself wasn't sure if this is
| something that should be blocked at the OS level (the
| Authentication checking the intent origin) or browser.
| Mozilla is usually the slowest out of the three but they were
| still very professional.
| bflesch wrote:
| The involved engineers are most likely running around with a
| blushed-red face to this day, claiming "phishing resistance" in
| all the marketing materials but then having such a bug. I'd say
| the cover-your-ass (CYA) reflex was a big incentive for google
| engineers to fix it quickly.
| lxgr wrote:
| Phishing resistance isn't a binary property, it's a spectrum,
| and even with this vulnerability, that of passkeys is orders
| of magnitude higher than that of most other alternatives
| (including passwords, SMS OTP, TOTP etc.)
| acdha wrote:
| This attack requires physical presence and visiting an
| attacker-controlled page. It's absolutely a real threat and
| great work, but there are multiple orders of magnitude more
| people getting phished using weak MFA than by an attacker
| with control of a BLE device in their home or office.
| verst wrote:
| Microsoft Edge had a release based on the relevant Chromium
| version on Oct 17, 2024. That is release 130.0.2849.46:
|
| https://learn.microsoft.com/en-us/deployedge/microsoft-edge-...
|
| https://msrc.microsoft.com/update-guide/en-US/vulnerability/...
| programmarchy wrote:
| I'm missing something. If WebAuthn is "ssh for the web" then why
| would it matter if Bob was phished and logged into the fake
| crypto portal running on the raspberry pi? It's not like the
| attacker now knows his private key. Is the danger that Bob also
| would share his crypto wallet keys with the fake site or
| something?
| chc4 wrote:
| The attacker controlled proxy is the one that logged in, and so
| captured a valid session for the user account that they can use
| afaik
| vlovich123 wrote:
| The attacker has access to whatever the passkey was protecting.
| It's like asking who cares about password phishing. And FWIW a
| crypto portal in front of something like Coinbase can obviously
| do a lot of damage since most people do not keep their crypto
| in their own personal cold storage.
| garaetjjte wrote:
| Attacker is now logged in on the real crypto portal as Bob. SSH
| equivalent would be like connecting to malicious server with
| SSH agent forwarding enabled.
| lxgr wrote:
| By the analogy of SSH, this vulnerability is more of an
| exposed/incorrectly permissioned SSH agent Unix domain socket
| than a private key compromise.
|
| Whether that's catastrophic or not will vary case by case and
| depends on what exactly you're securing with the key.
| chc4 wrote:
| I don't use BLE PassKeys, but wouldn't the user also have to be
| paired with the attacker controlled BlueTooth device to get the
| connection request? Does the "The victim's Authenticator connects
| to the attacker's Client" step's authorization include pairing to
| a new device and not only allow a log-in with an already
| connected one?
| lxgr wrote:
| The QR code initiates pairing (at the FIDO level; I believe at
| the Bluetooth level there is actually no pairing required
| here).
| chc4 wrote:
| The diagram in the post has the user device talking to the
| attacker device over Bluetooth, and the bug description
| explicitly says "An attacker within bluetooth range" - which
| heavily implies to me your device actually is pairing with
| the attacker device somehow! If already being paired with the
| attacker Bluetooth device is a prerequisite for this attack
| that's much less of a concern imo.
| lxgr wrote:
| As far as I can tell, no pairing (or indeed any kind of
| logical Bluetooth connection) is required in the protocol
| used. The (device containing the) authenticator broadcasts
| a Bluetooth LE advertisement, and the "client platform"
| (i.e. usually the browser) has to be able to receive its
| contents to prove physical proximity.
|
| Such a (by definition unidirectional) Bluetooth LE
| advertisement can easily be received and relayed over
| arbitrary distances.
| warp wrote:
| IIRC caBLE ("cloud assisted bluetooth low energy")
| sidesteps the usual bluetooth pairing process by using out-
| of-band channels (QR codes, NFC) to exchange initial
| pairing information.
| resfirestar wrote:
| The subheading "Phishing PassKeys credentials using browser
| intents" is inaccurate. The attacker does not get a credential,
| only a session.
| vlovich123 wrote:
| Which can be used to register your own passkey credentials
| obtaining an account takeover?
| resfirestar wrote:
| Sure, if you assume the session is scoped to allow
| registering a new passkey. Depends on how the application is
| configured. Regardless, getting the credential is different
| from getting a session.
| lxgr wrote:
| Arguably, "phishing a credential" doesn't necessarily have to
| mean full compromise of the credential itself.
|
| For example, in the case of SMS-OTP, the credential is (access
| to) the registered phone number, yet I'd still call an attack
| that successfully intercepts one OTP in time to use it a
| successful phishing attack.
| mastersplinter wrote:
| Author of the blog here, I actually agree with you the
| subheading is quite misleading, any tips on what would be more
| appropriate? "Phishing PassKeys sessions using browser intents"
| doesn't make much sense to me
| gradientsrneat wrote:
| This would be a nice ublock origin filter for Firefox Android. I
| installed one that blocks sites requesting localhost addresses,
| after I noticed some websites portscanning my localhost for
| "security".
| GTP wrote:
| Interesting, can you share which kind of websites you noticed
| doing this?
| Scoundreller wrote:
| https://www.bleepingcomputer.com/news/security/ebay-port-
| sca...
| lxgr wrote:
| I wonder why browsers even allow cross-origin access to
| localhost in that way, given all the risks involved.
| ghxst wrote:
| Localhost is typically uniquely trusted, generally
| speaking, even when loading a localhost page on HTTP it
| behaves like a page served over HTTPS would (in terms of
| the browser APIs you have access to for example). Also
| for a port scan it's not all that unusual since you can
| do it without loading any resources, so CORS alone
| wouldn't protect you from it. Maybe an extension that
| injects / modifies CSP rules could protect from this but
| it might also end up breaking websites.
| lxgr wrote:
| > it might also end up breaking websites
|
| That's what I was trying to get at: Are any websites
| using this legitimately to communicate with local
| applications? If so, isn't that a pretty big
| fingerprinting and attack vector (how are websites
| authenticating themselves to these local applications and
| vice versa)?
| 0x457 wrote:
| > Localhost is typically uniquely trusted, generally
| speaking,
|
| Sure, but that trust is about me, an owner of this
| particular localhost, interacting with it, not trust
| some.website.on.web to have an unchecked communication
| with it.
| saint_yossarian wrote:
| For reference, uBO has a filter list called "Block Outsider
| Intrusion into LAN" which you can enable. That blocks all
| cross-site requests to local IP addresses, "localhost", and
| some other well-known locally-resolved hostnames.
|
| Another attack vector is public DNS names that resolve to local
| IPs as well, like "lvh.me". I block these with a local dnsmasq
| instance and the "stop-dns-rebind" setting.
|
| Still not sure if this catches everything, probably not. I
| really wish browsers would just block all of this by default
| and ask for permission.
| teeray wrote:
| I wonder if this will enable creating a Firesheep-equivalent.
| lxgr wrote:
| This attack is very active, in contrast to Firesheep. The
| attacker needs somebody physically close to their Bluetooth
| device to additionally visit a site they control.
|
| Definitely not impossible, but still a very different threat
| level.
| bflesch wrote:
| Nice find.
|
| To me it seems that WebauthN/PassKey was a significant project
| where all of the clever and highly paid engineers from the big
| corporations took part.
|
| How can they overlook such an attack vector? Especially when the
| main selling point for the new technology is "resistance against
| phishing"?
|
| Even MS has in their FAQ: Are "Q: passkeys phishing resistant? A:
| Yes, passkeys are phishing resistant" [1]
|
| [1] https://support.microsoft.com/en-us/windows/passkeys-
| frequen...
| lxgr wrote:
| Security engineers aren't infallible. This is a really clever
| channel confusion attack that presumably just nobody
| considered. It happens, unfortunately.
| bflesch wrote:
| Clever attack indeed - wouldn't have expected for this to be
| possible. I trusted the claims of Webauthn / Passkey being
| "phishing proof" without much consideration, because these
| claims came from highly respected companies. Unfortunately
| this is yet another example for "trust, but verify".
| sunshowers wrote:
| I'm curious if folks tried to use a model checker. Seems like
| a model checker might be able to identify cases in the spec
| where invariants are violated.
| lxgr wrote:
| I don't think that that would have helped here: The
| invariant ("URLs purportedly resulting from a QR code scan
| must only result from an actual QR code scan") essentially
| follows directly from a specific threat scenario that was
| missed.
| sunshowers wrote:
| Yeah, you're right, that does seem to be very specific.
| 3np wrote:
| Any professional should know this. Claiming any credential
| scheme is unphishable is not honest. Leading wider marketing
| with "phishing-resistant" is not far from that, knowing that
| the subtlety is lost on the public.
| ajross wrote:
| > How can they overlook such an attack vector?
|
| Because secure engineering is extremely hard? That's two really
| quite uncharitable replies from you in this topic now, and IMHO
| it's really unwarranted. One of the _worst_ smells for secure
| engineering is the insistence of the people involved that they
| 'd never make a dumb mistake like "that other" group did.
|
| Basically nowhere is humility more of an asset than in this
| world.
| bflesch wrote:
| I totally agree with you. That's why claiming your technology
| is "phishing proof" reflects badly on the people involved who
| are all supposedly experts in their field, and well-
| compensated on top.
| lxgr wrote:
| The protocol is; the implementations weren't, in this case.
| (To be fair, the specification didn't explicitly say
| "validate the origin of the pairing secret to actually be a
| QR code scanner", but that's still more of a missing
| (important!) implementation warning than a protocol design
| flaw.)
|
| Compare this with passwords, where the protocol is
| fundamentally phishable, with partial mitigations requiring
| user discipline (e.g. only ever using password manager
| auto-fill) and a lack of local or remote vulnerabilities.
| WorldMaker wrote:
| Most claims about Passkeys are "phishing resistant" not
| "phishing proof". This scenario is still more "resistant"
| than passwords: it requires a believable MITM proxy _for a
| specific website_ that is also physically in someone 's
| near-area network/personal-area network to pick up
| intentionally low powered Bluetooth LTE packets, and to
| click through a login flow that on most of these
| OSes/browser combos _looks decidedly different_ ( "remote
| login" instead of "real login"). Obviously that's still a
| threat model to consider, just as one should generally
| worry about logging into _anything_ on a public Wifi, but
| the number of "ingredients" to get right on this phish
| attack is much higher than anything password related, and
| is much harder to scale (spearphish) because as amusing as
| it sounds to try to build a fleet of Raspberry Pis to
| blanket a public space it starts to get physically
| impractical.
|
| This is a "I'm going to phish a very specific person's
| wallet in meatspace" attack, not a "I'm going to remotely
| phish anyone on the internet's wallet".
|
| (It's also an attack we've already got mitigations rolled
| out in major browsers and more planned.)
| 0xbadcafebee wrote:
| The way things like this are developed is not by "clever and
| highly paid engineers". They're developed by a cabal of
| businesses led by a standards body to try and wrangle all the
| competing interests into one solution for everyone's problems
| (lol jk, it's to solve the problems of the most influential
| organizations involved).
|
| Because the whole process is design-by-committee on crack, the
| solutions don't tend to be technically very good. But they
| don't need to be, because they're not trying to solve a
| technical problem, they're trying to solve a business problem.
|
| The solutions they come up with are always ugly and broken at
| first, and don't account for all the needs of everyone
| (remember, only the most important's needs get met first), so
| they eventually churn out a fixed version and that becomes the
| version everyone ends up using long term.
|
| WebAuthn/Passkeys/FIDO/etc aren't even one solution or
| standard. They're a cobbled together patchwork of different
| pre-existing standards with some extra pixie dust mixed in.
| Almost everyone agrees that the users and implementers are who
| loses out when these things are pushed. But a couple giant
| businesses have an easier time solving _their_ problems, which
| are large-scale security problems. And all the rest of us use
| it, because we tend to defer to large powerful authority
| figures, and we don 't know what the hell else to do.
|
| Whatever universal solution is pushed will continue to suck
| balls, because there are too many different use cases, and no
| single solution will ever work well for all of them.
|
| What has worked, is working, and will continue to work, is to
| simply support a variety of different security mechanisms
| independently, and allow users to install a password manager
| which wrangles it all for them, across different use cases,
| sites, applications, devices, organizations, etc.
| everybodyknows wrote:
| I'd also ask: Why can't MS explain them coherently? From just
| the first two FAQ items:
|
| > Passkeys are like digital keys ...
|
| But Joe User doesn't yet know what a "digital key" is, not yet
| anyway, so this is at best a forward reference.
|
| > The public key is registered with the website or application.
|
| Joe has no idea what "registered" means in this context.
| ziddoap wrote:
| > _Even MS has in their FAQ: Are "Q: passkeys phishing
| resistant? A: Yes, passkeys are phishing resistant" [1]_
|
| Phishing resistant is different than phishing proof.
|
| Passkeys remain phishing resistant, even in light of such an
| attack.
| wkat4242 wrote:
| They say phishing resistant. They don't say phishing proof. And
| this is not an easy thing to exploit.
| amluto wrote:
| What prevents essentially the same attack from being done by
| making a (desktop / tablet or even wall-mounted-display) web page
| that shows a QR code that, when scanned by a victim device,
| triggers the authentication flow?
| charcircuit wrote:
| The fix blocks fido links from anywhere, including QR code
| scans.
|
| https://chromium-review.googlesource.com/c/chromium/src/+/59...
|
| Edit: QR code scans are actually allowed to open such links.
| amluto wrote:
| Is there some handshake over BLE that allows a browser that
| speaks BLE and shows a QR code to trigger the FIDO flow but
| does not allow a QR code by itself to do so? If so, how?
| Remember, the attacker is presumed to control a BLE device in
| range of the victim's authenticator.
| charcircuit wrote:
| I was mistaken. I'm not sure what would prevent a proxied
| QR code + proxied Bluetooth signal.
| lxgr wrote:
| Nothing, by definition. If an attacker can successfully
| proxy all channels designed to frustrate proxying
| attacks, it's game over, at least without a distance
| bounding protocol being used (and I don't think Bluetooth
| has one).
| WorldMaker wrote:
| Signal Power affects readable distance (signal to noise
| radius) and the specs for this do suggest the lowest
| power Bluetooth LTE packets for the shortest "personal
| area network" distance we can get for these FIDO
| requests.
|
| (It doesn't entirely solve it, you can be extremely
| unlucky with a radio bounce or a surprisingly quiet
| Bluetooth radio band at transmission time. Surprising
| because Bluetooth is somewhat intentionally in one of the
| noisiest radio bands we've allowed to be extremely
| noisy.)
| lxgr wrote:
| GP mentioned Bluetooth proxying (i.e. using two devices
| forwarding protocol messages bidirectionally to create a
| "Bluetooth wormhole"), which doesn't have any obvious
| inherent distance bound in this protocol, as as far as I
| can tell.
| 0x457 wrote:
| I guess it's possible to reduce radius where that attack
| is executable with signal level.
| lxgr wrote:
| Unless there is an API to actively limit the broadcasting
| signal strength via BLE that authenticator
| implementations could leverage, I don't see how.
|
| And even then you'll quickly run into problems when the
| attacker's receiver has better antennas in better
| locations than e.g. the user's laptop.
| rcxdude wrote:
| Indeed. That attack is a little more involved (requires having
| a BLE device in proximity and tricking the user into scanning a
| QR code outside of the normal browser flow), but it seems like
| the main issue is that there's no way for the authenticator to
| validate that the device that's actually being authenticated is
| the device that the user actually intends to authenticate.
| lxgr wrote:
| The device being authenticated is the one that I scan the QR
| code off of, isn't it?
|
| The problem here seems to be that implementations don't check
| whether a QR code has, in fact, been legitimately scanned at
| all.
| rcxdude wrote:
| That's what the user intends, but there's no way for the
| authenticator to know whether the QR code it's scanning is
| actually from a webauth session on the device it's scanned
| it from, or simply proxied from another device: ultimately
| the QR code is just a bunch of pixels, and a web page can
| display arbitrary pixels.
|
| Basically, there would need to be some device-specific
| private key included in the QR code which the authenticator
| could check somehow, but that trust needs to be established
| first somehow
|
| One potential mitigation I could imagine is browsers
| actively trying to prevent FIDO QR codes from being
| rendered in web pages, but that's pretty difficult to stop
|
| This is, of course, something that an attentive user can
| likely detect, as the browser can prevent web pages from
| mimicking the QR code workflow exactly, but a) webauthn is
| supposed to prevent this from happening, as the 'line of
| death' has proven to be a poor barrier, and b) there's no
| good way for the authenticator scanning the QR code to
| identify this line of death reliably.
|
| https://textslashplain.com/2017/01/14/the-line-of-death/
|
| (And, of course, the designers of this interface knew this
| could be an issue, which is why BLE is involved at all: so
| that this kind of attack can't just be done entirely
| remotely. But BLE is a bad way of identifying a particular
| device compared to, say, plugging in a USB port. Especially
| also imagine compromised IoT devices...)
| lxgr wrote:
| But here, no pixels have been scanned at all.
|
| At least that much seems reasonable to detect (e.g. by
| blocking FIDO URLs from being opened in browser, but also
| by the FIDO URL handler verifying whether the caller is a
| camera application or a browser).
| WorldMaker wrote:
| Though mitigations on this are that the QR codes in BLE
| authentication are inside browser/OS dialogs, _not_ a
| part of the webpages. Obviously a web page can still put
| a lot of work into pretending to _be_ browser /OS
| dialogs, but there are some mitigations in place of "does
| this look like the right prompt for this style of login?"
| already. Also, obviously some of that is a training
| problem of "don't just scan random QR codes, look for the
| ones specifically framed in browser dialogs" and given
| how hard it can be in general to train people to be
| skeptical of random QR codes there will always be human
| failures in that space.
|
| One of the tricks is going to be avoiding Bluetooth
| logins in the long run. Microsoft has mentioned interest
| in finding better ways to better flow keys cross-
| platform. Also, BLE logins should be rare in general if
| handled well (BLE login _once and only once_ on a
| different platform to add a key for that platform
| directly to the site) and we shouldn 't be training users
| to expect "login via QR code" as the "norm". (Of course,
| yes, that's also a training situation with a lot of human
| failure modes.)
| rvz wrote:
| What an excellent write up. Adding a Web Bluetooth API to the
| browser to then be later used for "secure" actions like passkeys
| or logins never made any sense to begin with.
|
| How much was this bounty if there was any? Looks like a 7.8
| severity CVE [0].
|
| [0] https://nvd.nist.gov/vuln/detail/CVE-2024-9956
| lxgr wrote:
| FIDO is explicitly blocked in Web Bluetooth for exactly that
| reason:
| https://github.com/WebBluetoothCG/registries/blob/master/gat...
|
| This is similar to how you can't access HID (and by extension
| CTAP2 or U2F) or CCID (and by extension smart cards such as
| OpenPGP cards) over Web USB.
| rcxdude wrote:
| This issue is mostly seperate from Web Bluetooth: it'd be an
| issue even if that API didn't exist at all (though, of course,
| these APIs make it a little harder to use those interfaces for
| validating anything, though thankfully not that much harder
| because it's fairly easy to add some 'hey, this is really a
| browser and not a web page making this request' signal, as
| opposed to with QR codes, which are ultimately just a
| collection of pixels and it's the very-hard-to-evaluate context
| in which it appears on the device's screen which makes for that
| seperation.)
| mastersplinter wrote:
| So grad you enjoyed it! Chrome awarded 6000 USD, very grateful
| for it and will fuel some more security research for a while :)
| lxgr wrote:
| If I understand it correctly (I had some trouble wrapping my head
| around the exact attack vector):
|
| The problem here is that browsers allow redirecting users to the
| installed passkey implementation/"backend" in the same way that
| camera and dedicated QR scanner apps legitimately use to initiate
| cross-device authentication via (what used to be called) caBLE,
| right?
|
| In other words, the attacker primes the user for an upcoming
| authentication _on-device authentication_ , but in reality
| initiates an _off-device authentication to their own device_.
|
| And the fix is presumably to not accept off-device authentication
| intents over anything that's not a QR scan, or at least filter
| them out in the browser?
| tadfisher wrote:
| Correct, the Chrome fix at least was to block fido:/ URL
| navigation, so the victim can't get redirected to their passkey
| application with the phished URL.
| greatgib wrote:
| I think that we can easily say that it is a huge "epic fail" for
| the whole ecosystem of people that pushed for "Passkey" with the
| argument that "this was more safe than password that need to be
| deprecated"...
| jiveturkey wrote:
| I wouldn't dance on the grave yet.
| lxgr wrote:
| It's worth keeping in mind that if you enter your password in
| an attacker-controlled website, you lose your entire
| credential, not just one malicious authentication/signature
| using it such as here.
|
| Also, this vulnerability is very patchable; password phishing
| is incredibly hard to prevent.
| otterley wrote:
| And, in fact, has already been patched in all major browsers.
| mastersplinter wrote:
| Although this is an attack that can be carried out in practice,
| it is not quite as scalable as phishing passwords of
| potentially millions of users across the world. Passkeys are
| still in general more phish-proof than passwords.
| lostmsu wrote:
| How can I disable Passkeys over Bluetooth? Given the severity of
| vulnerability and the "fix" just plugging one hole of potentially
| many more, I'd rather have it permanently disabled.
| burnte wrote:
| Everything I hear about passkeys makes me glad I've stuck to
| strong passwords in a password manager and 2fa via tokens.
| shepherdjerred wrote:
| I've had a _really_ good experience with passkeys + 1Password.
| I vastly prefer it over a password + TOTP 2FA.
|
| It was a little rough at first, but support is pretty good now.
| The only real concern is I don't know how to export passkeys
| out of 1Password if that were needed.
| autoexec wrote:
| This is just one more reason to keep bluetooth disabled on mobile
| devices. There have been other vulnerabilities with bluetooth
| itself, and bluetooth is constantly used to track people. What's
| the point of leaving it on all the time when most of the time
| it's just going to drain your battery and open you up to being
| tracked or exploited.
| latentcall wrote:
| I have BT headphones in all the time and my phone doesn't have
| a headphone jack.
| lxgr wrote:
| > bluetooth is constantly used to track people
|
| How so? Unless you grant Bluetooth permissions to apps (that
| then start broadcasting identifiers) or explicitly make your
| device discoverable, this shouldn't really be a thing.
|
| > What's the point of leaving it on all the time when most of
| the time it's just going to drain your battery and open you up
| to being tracked or exploited.
|
| Just people with a wearable have at least one Bluetooth device
| connected to their phone at all times. Bluetooth headphones are
| also very popular.
|
| We need hardened and privacy-protecting Bluetooth stacks, not
| blaming people for using their phones as designed and
| advertised.
| dharmab wrote:
| Over ten years ago retailers were already tracking customer's
| cell phones as they walked around the store to see what
| sections people walked through. Your phone constantly sends
| radio waves out that are identifiable to the individual
| device.
|
| https://www.nytimes.com/2013/07/15/business/attention-
| shoppe...
| lxgr wrote:
| Could you be more specific?
|
| In what way is a modern Bluetooth device (let's assume both
| classic and LE) uniquely identifiable, other than for the
| caveats mentioned above? 2013 was indeed over a decade ago.
___________________________________________________________________
(page generated 2025-03-19 23:01 UTC)