[HN Gopher] Surveilling the masses with wi-fi-based positioning ...
___________________________________________________________________
Surveilling the masses with wi-fi-based positioning systems
Author : belter
Score : 412 points
Date : 2024-05-27 16:25 UTC (1 days ago)
(HTM) web link (arxiv.org)
(TXT) w3m dump (arxiv.org)
| spr-alex wrote:
| I work at Supernetworks where we're building secure by default
| Wi-Fi routers. Our software had the ability to assign MACs to
| interfaces for a little while now, and as a response to this
| study we've now also added MAC randomization, now in the dev
| branch, and generally available in our next release
| (https://github.com/spr-networks/super). Many cards which support
| WDS//AP-VLAN have no trouble with updating the BSSID.
|
| For use as a travel router the UI makes it simple to randomize
| both the AP BSSID/MAC as well as interfaces working as WiFi
| client stations for internet uplink.
| canadiantim wrote:
| So is bringing your own travel router while traveling the
| current best practice for securely connecting to public wifi's?
| transpute wrote:
| https://news.ycombinator.com/item?id=40494994
| SSIDName_optout_nomap
| sambazi wrote:
| pretty please don't fall for that crap
| canadiantim wrote:
| What's wrong about it?
| staplers wrote:
| If you had a nice enclosure for these routers you could take a
| large share of the prosumer market and be a "privacy" version
| of unifi.
|
| As an average home user, I would love something like this
| (interface and features) but with a nicer looking hardware
| (wife tax).
| spr-alex wrote:
| Yes, We have some prototypes and will have some nice
| enclosures coming soon that we'll make available via our
| website at https://www.supernetworks.org
| mrbluecoat wrote:
| In addition, some parental controls would be nice (feature
| parity with, say, Gryphon). I see your subscription tier
| offers some of that (schedules and domain logging).
| throw0101d wrote:
| > _Our software had the ability to assign MACs to interfaces
| for a little while now, and as a response to this study we 've
| now also added MAC randomization, now in the dev branch_ [...]
|
| Will it follow what the IEEE is proposing?
|
| * 802.11bh: Enhanced service with randomized MAC addresses
|
| * 802.11bi: Enhanced service with Data Privacy Protection
|
| * https://standards.ieee.org/beyond-standards/data-privacy-
| and...
| spr-alex wrote:
| These amendments might not apply to BSSIDs/Access Points but
| refer to enhanced privacy features to stop the fingerprinting
| of stations as well as providing ways for APs to identify
| stations under randomization, across a complicated network.
| transpute wrote:
| Note the privacy-impaired 802.11bf: WLAN Sensing,
| https://www.ieee802.org/11/Reports/tgbf_update.htm &
| https://www.technologyreview.com/2024/02/27/1088154/wifi-
| sen...
|
| _> Someone outside your home could potentially tell when
| it's vacant, or see what you are doing inside. Consider all
| the reasons someone might want to secretly track someone
| else's movements. Wi-Fi sensing has the potential to make
| many of those uses possible.. it could be used by
| corporations to monitor consumers, workers, and union
| organizers; by stalkers or domestic abusers to harass their
| victims; and by other nefarious actors to commit a variety of
| crimes. The fact that people cannot currently tell they are
| being monitored adds to the risk. "We need both legal and
| technical guardrails "..
|
| > At least 30 million homes already have some kind of Wi-Fi
| sensing available.. When the new standard comes out in 2025,
| it will allow "every Wi-Fi device to easily and reliably
| extract the signal measurements".. With Wi-Fi 7.., "the
| sensing capability can improve by one order of magnitude"..
| The committee did discuss privacy and security.. But they
| decided that while those concerns do need to be addressed,
| they are not within the committee's mandate.. Wi-Fi sensing
| is more concerning than cameras, because it can be completely
| invisible._
|
| IEEE standards are a minimum starting point for
| interoperability. Security and privacy improvements can be
| implemented in open-source code, to inform future revisions
| of IEEE standards.
| throw0101d wrote:
| Privacy has been discussed with .11bf; see "SSV.D Security
| and Privacy" of the following:
|
| * https://arxiv.org/abs/2207.04859
|
| Of course Wifi sensing is already a thing with existing
| signals:
|
| * https://web.ece.ucsb.edu/~ymostofi/WiFiReadingThroughWall
|
| * https://interestingengineering.com/innovation/scientists-
| tra...
| transpute wrote:
| _> Privacy has been discussed_
|
| Discussion is a good start. That section of the paper
| states: Although there are already
| various ways to improve security and privacy, IEEE
| 802.11bf is still discussing which solution to add.
|
| Hopefully the scheduled 2025 launch of 802.11bf will be
| gated upon _implementation_ of security and privacy.
|
| _> Of course Wifi sensing is already a thing with
| existing signals_
|
| Several orders of magnitude exist between researchers and
| commercial devices in the hands of millions of consumers.
| judge2020 wrote:
| > Several orders of magnitude exist between researchers
| and commercial devices in the hands of millions of
| consumers.
|
| Well, between nation state actors and consumers
| transpute wrote:
| fight_club.jpg
| transpute wrote:
| _> we 're building secure by default Wi-Fi routers_
|
| In addition to RPi hardware, it would be helpful to support
| Rockchip RK3399 and RK3588 SoCs that have minimal binary blobs,
| since these can used with open-source Arm Trusted Firmware
| (TF-A) for secure boot, to ensure that only owner-authorized OS
| and firmware are running on the device.
|
| _> Many cards which support WDS //AP-VLAN have no trouble with
| updating the BSSID._
|
| Do these M.2 WiFi cards support AP/VLAN and BSSID updates?
| Qualcomm Atheros QCA6174 Wi-Fi 5 Qualcomm Atheros
| QCNFA765 Wi-Fi 6
| karma_pharmer wrote:
| _Rockchip RK3399 and RK3588 SoCs_
|
| Just so people don't get confused, there is a huge world of
| difference between these two chips. They are not in the same
| category.
|
| Rockchip RK3399 is 100% blobless. You even control the EL3
| Trustzone Secure World! This is True Root.
|
| Rockchip RK3588 _still_ needs blobs in EL3, the highest
| privilege level. We 've been hearing rumors for years now
| about "oh they'll open source it next month for sure" and
| it.... just. never. happens. Please stop spreading this
| rumor. Source or GTFO, Rockchip.
| transpute wrote:
| Feb 2024, https://news.ycombinator.com/item?id=39490540 &
| https://review.trustedfirmware.org/c/TF-A/trusted-
| firmware-a...
|
| _> Rockchip have sent a few patches to the TF-A project
| here to support [RK3588].. From TF-A we can now build a
| complete working BL31 and replace the closed binary blob
| with an open-source binary that we can compile ourselves..
| There are still some missing parts and the most important
| that is remaining right now is the DDR training blob, which
| is still closed source._
| karma_pharmer wrote:
| Like I said: blobs in EL3, the highest privilege level.
|
| We've been getting these "almost there" announcements
| quarterly for multiple years at this point.
| transpute wrote:
| In decreasing order of preference: OSS
| TF-A at EL3 + OSS DDR training (RK3399) OSS TF-A at
| EL3 + closed DDR training (RK3588) OSS uboot +
| closed TF-A closed uboot + closed TF-A
|
| Those who need the features of RK3588 can compare it to
| competitors which are less open.
|
| Those who don't need the features of RK3588 can use the
| older and fully open RK3399.
| karma_pharmer wrote:
| > OSS TF-A at EL3 + closed DDR training (RK3588)
|
| That should be "blob which does stuff, including DDR
| training, _at EL3_ ".
|
| That blob certainly does DDR training. Maybe it does
| other stuff. But all of it is done at EL3.
|
| > In decreasing order of preference
|
| "Warning! Diagram is not drawn to scale."
| transpute wrote:
| _> That blob certainly does DDR training. Maybe it does
| other stuff. But all of it is done at EL3._
|
| If someone wants to find out, they can load it in
| IDA/Ghidra?
| karma_pharmer wrote:
| If it was that easy we'd have a cleanroom FOSS
| implementation by now. It's been more than two years!
|
| https://wiki.raptorcs.com/wiki/Project_Ortega
| transpute wrote:
| Cleanroom reverse engineering for the purpose of
| publishing new driver code, to avoid legal/IP minefields,
| is super-expensive. It should be a much narrower scope to
| determine whether a binary blob's actions are limited to
| memory training, since there is no requirement to publish
| reusable source code.
|
| Looks like Collabora is already monitoring the blob, so
| it's not entirely a mystery: At the
| moment of writing this article, we have identified a few
| differences from the binary blob previously used, which
| we can highlight as following: Binary BL31
| contains some unknown code to get HDMI-RX PHY access
| working. The cpufreq support in binary BL31 is
| different from TF-A. There could be more
| issues that are unknown at the moment and users should be
| aware of it.
| karma_pharmer wrote:
| > Cleanroom reverse engineering for the purpose of
| publishing new driver code, to avoid legal/IP minefields,
| is super-expensive
|
| Project Ortega did it to an entire gigabit ethernet
| controller for the princely sum of zero dollars:
|
| https://media.ccc.de/v/37c3-11781-adventures_in_reverse_e
| ngi...
|
| https://wiki.raptorcs.com/wiki/Project_Ortega
|
| > Binary BL31 contains some unknown code to get HDMI-RX
| PHY access working.
|
| That doesn't sound like DDR training to me. Maybe now you
| see the problem?
| transpute wrote:
| _> That doesn 't sound like DDR training to me. Maybe now
| you see the problem?_
|
| It is absolutely a problem, but it's bounded by the
| ability to inspect and question code/behavior outside the
| officially claimed rationale. We can prefer open systems
| and also shine a bright light on the behavior of closed
| systems.
| spr-alex wrote:
| SPR can run about anywhere docker can run. So if you have a
| linux system running docker with these, you should be good to
| go. We provide the OS images as one path to running SPR.
|
| We are currently looking at banana pi over rockchip but we
| are very happy to assist if someone has this gear.
|
| I don't have access to Qualcomm information but if you have
| those chips it will be under the output of 'iw dev'.
| nox101 wrote:
| This sounds very cool and IIUC could replace my
| EdgeRouterX($60) I currently use.
|
| Suggestion, your site is not understandable to me. At the top
| it says you make routers. Under products it lists a a PI5 HAT.
| Is that a router? It sounds like it's a Wifi card for a
| Raspberry PI?? PI5 Pod, Is that a router? It says "bundled with
| PI5 Router" ??? "CM4 Capsule" is that a router?
|
| Is this site only for people who already know these terms?
|
| It also claims all this runs locally but then says you have a
| subscription... ?!
| transpute wrote:
| _> It also claims all this runs locally but then says you
| have a subscription... ?!_
|
| Looks like the subscription is for those who want to help
| fund the project.
|
| Not many functional differences, maybe those are handled in
| the config GUI?
| karma_pharmer wrote:
| Most wifi baseband firmware "helpfully" leaks the true eeprom-
| written MAC address in places like management frames and
| beacons:
|
| https://news.ycombinator.com/item?id=13839540
|
| As of 2017 the authors of the paper above found MAC leaks in a
| shocking 96% of all android phones. And the remaining 4% aren't
| proven to be leak-free -- they simply hadn't noticed any leaks
| by the time they wrote the paper.
|
| Unless you have fully open-source firmware on your baseband,
| like ath9k_htc, there's really no way to prevent this leakage.
| Or even be sure if it's happening.
|
| https://wiki.debian.org/ath9k_htc/open_firmware
|
| With open source baseband firmware you can guarantee that the
| baseband never even has access to the hardware MAC address. You
| can even reflash the MAC address eeprom (on every boot if you
| like!)
| spr-alex wrote:
| We actually have an intern researcher working on a path
| towards an open source implementation of 802.11 for wifi 6
| cards but do not have an ETA when our first proof of concept
| will be released.
|
| We've also reported mac leaks to vendors -- we found stations
| would transmit packets with their non randomized state in
| certain scenarios, we'll blog about it when vendors release
| their fixes.
|
| But more importantly I also want to say that I do not expect
| the MAC leaks are happening in most beacons & probe
| responses, which is what Apple and Google and others collect
| for their positional database with wi-fi SSIDs and BSSIDs.
| There's still ways to fingerprint, from digital fingerprints,
| to signal fingerprints unique to the radio and antennas and
| board, where machine learning can cluster and classify
| devices that are going to be very hard to anonymize for
| privacy.
|
| Projects like https://www.nzyme.org/ actually apply
| fingerprinting techniques for defense to detect Rogue APs
| that could manifest in an actively attacked environment. They
| can pick up wifi implants as well as the Rogue AP attacks.
| karma_pharmer wrote:
| _an open source implementation of 802.11 for wifi 6 cards_
|
| For which baseband chip, specifically?
|
| I mean this would be great, but I have a very hard time
| believing any baseband vendor gave you enough documentation
| to achieve that -- especially not without an OSS-
| prohibitive NDA. Would love to be wrong about that. It
| happened once, but that was back when Atheros was an
| independent company -- before they were Qualcommized.
|
| Also, aren't all the wifi 6 baseband firmwares
| cryptographically signed? Best case it'll be as "open
| source" as Tivo was.
|
| _We 've also reported mac leaks to vendors_
|
| That's good, but I don't think the whack-a-mole approach
| inspires much confidence. There have been _so many_ of
| these problems that at this point we really need to take
| the car keys away from the drunkard and have the baseband
| chip and the MAC-bearing eeprom be separate devices which
| can only communicate via the CPU. Or just have the CPU
| derive the MAC from the CPU 's own serial number. Or maybe
| just not have hardware MAC addresses at all.
| spr-alex wrote:
| Not all are cryptographically signed, no. We have no
| special documentation but we are also not directly
| modifying closed firmware either. We are working with
| mediatek cards and will post more updates this summer. We
| last posted about our approach 6 months ago,
| https://www.supernetworks.org/pages/blog/barely-ap-
| surfaces.
|
| So the randomization bugs we have reported are
| specifically about stations, namely: mobile smart phone
| devices failing to randomize their WiFi MAC address.
|
| As for the study this thread's topic concerns, I do not
| have reason to believe that there are bugs with MAC
| randomization in cards running as APs that would make the
| randomization of BSSIDs fail.
|
| The probe responses and beacon contents appear to
| consistently use their randomized MAC address in the
| cards we have tested. There could be underlying actively
| triggered bugs an active attacker could uncover, to get
| the non randomized address, but I do not expect such bugs
| would affect the BSSID + Positional databases of this
| study.
| devjab wrote:
| I'm not sure if I understand your project correctly, but can
| this fix the issue with tracking people by location from their
| phones? Either way it's a cool project.
|
| I'm Danish, I think the only way to really prevent mass
| surveillance through WiFi is through laws and legislation. It
| used to be legal to track people here, but thankfully it's not
| anymore. I still remember when there was an outcry from smaller
| municipalities when they could no longer track people on their
| "walking streets". I'm not sure if you have those in other
| countries but they are basically the "central" street with a
| lot of shops that are only for pedestrians. Virtually every
| Danish city has one, larger cities have multiple. Anyway,
| smaller cities used to track people to see which parts of those
| streets were popular and which weren't.
|
| Now they didn't exactly do it for sinister reasons as such. Our
| smaller cities have issues with what is called "city death"
| where their "waking streets" lose shops because people go to
| larger malls. Then they might add a play ground or other
| cultural things, or even help shops with rents in order to
| increase an even popularity in their "waking streets".
|
| Despite their good intention it was still mass scale
| surveillance.
| wolvesechoes wrote:
| > It used to be legal to track people here, but thankfully
| it's not anymore.
|
| It not legal anymore, except when you are big enough or you
| are the one that decides what is legal or not.
| yardstick wrote:
| From your site: " Why should your vacuum be able talk to your
| doorbell? Inadequate network isolation makes breaches worse."
|
| Just got to say- that would be awesome for my vacuum to stop
| making a loud noise when someone pushed the doorbell, so I
| wouldn't miss the person! (But I do completely get the
| underlying sentiment)
| transpute wrote:
| An untrusted vacuum and doorbell can each talk to trusted
| HomeAssistant for coordination, while isolated from each
| other.
| m463 wrote:
| I think phones should have location-based wifi (and maybe
| bluetooth).
|
| Meaning, if your location is home, turn on wifi, else turn it
| off.
|
| Unfortunately apple/google/carriers have a vested interest in
| making our devices very promiscuous. (location services,
| advertising/surveillance, offload cellular, etc)
| balderdash wrote:
| That would be a great feature the only places I use WiFi
| besides home/work is the airport/plane, hotels, and
| occasionally other offices or people's homes. There is no need
| to be broadcasting driving/walking around etc.
| gruez wrote:
| This paper is about surveilling locations of APs (ie.
| hotspots), not the devices that connect to them. Thanks to MAC
| address randomization the latter is basically a non-issue.
|
| >I think phones should have location-based wifi (and maybe
| bluetooth).
|
| >Unfortunately apple/google/carriers have a vested interest in
| making our devices very promiscuous. (location services, [...]
|
| You don't see the contradiction here? You want your phones to
| have location-aware features, but right afterwards say that you
| don't want it because it makes your device "very promiscuous".
| yjftsjthsd-h wrote:
| >> Unfortunately apple/google/carriers have a vested interest
| in making our devices very promiscuous. (location services,
| [...]
|
| > You don't see the contradiction here? You want your phones
| to have location-aware features, but right afterwards say
| that you don't want it because it makes your device "very
| promiscuous".
|
| I don't think it's a contradiction. You can have a phone that
| knows its own location without telling Google/Apple where it
| is, and that uses that information to toggle features. (I'm
| kind of skipping the cell carriers because you _do_ have to
| give them coarse location by virtue of how cell network
| work.) A device can get location by purely passive GPS
| without involving _any_ external services, but that 's a
| pretty sucky experience (slow lock, low precision)... I
| _think_ you can do AGPS without telling anyone where you are,
| though. Anyways, my point is that there is a world of
| difference between _you_ having your information /location
| and anyone else having it.
| m463 wrote:
| If your phone has wifi enabled, it will collect AP
| name+location for apple/google and upload it. The same thing
| happens for bluetooth + ibeacons/edison beacons, airtags,
| etc.
| fallingsquirrel wrote:
| You can set that up pretty easily with something like Automate.
| https://llamalab.com/automate/
| transpute wrote:
| This could likely be automated by tapping an NFC proximity tag
| (e.g. discarded transit card) at your door for entry/exit.
|
| NFC avoids dependency on network-based location positioning.
| KeplerBoy wrote:
| You can also automate this by simply querying your gps
| coordinates and setting up geo-fences around your home.
|
| This was possible 10 years ago using tasker on android.
| hnburnsy wrote:
| Samsung has this on some phones called intelligent wi-fi...
|
| https://docs.samsungknox.com/admin/knox-platform-for-enterpr...
|
| >Intelligent Wi-Fi provides four features that aim to improve
| consumers' Wi-Fi experience:
|
| Network Bearer Switching
|
| Auto Wi-Fi
|
| Suspicious Hotspot Detection
|
| Enhanced Power Saving
|
| >Intelligent Wi-Fi is the new brand name of the existing
| "Adaptive Wi-Fi" which had been applied to models older than
| Galaxy S10 (e.g. Galaxy S9 or older models). It has been
| improved by adding a new feature such as Suspicious Network
| Detection and also enhancing existing features such as Network
| Bearer Switching.
|
| >Auto Wi-Fi >People use Wi-Fi differently based on their
| location. In places where Wi-Fi is available, we turn on Wi-Fi
| to avoid being charged for mobile data. On the other hand, if
| Wi-Fi is always on, we are subjected to frequent, unwanted
| connections and higher power consumption. To solve this
| problem, we have introduced Auto Wi-Fi, which turns Wi-Fi on
| and off depending on your location. Auto Wi-Fi addresses these
| connectivity-related pain points.
|
| >Auto Wi-Fi pays close attention to your connection patterns
| and remembers your favorite networks. It turns your Wi-Fi on
| when a favorite network is available. When you leave the area
| and the network becomes unavailable, Auto Wi-Fi will
| automatically turn off your Wi-Fi.
| red369 wrote:
| This can be set up in iOS using Automation in Apple's Shortcuts
| app, e.g:
|
| When: I arrive home
|
| Do: Set WIFI On
| roelschroeven wrote:
| For that to work you need to have location enabled, so you're
| now leaking your location anyway. Doesn't that defeat the whole
| purpose?
| juunpp wrote:
| > We find what appear to be personal devices being brought by
| military personnel into war zones, exposing pre-deployment sites
| and military positions.
|
| Is this verified? Does the military not ban Apple/Google personal
| trackers?
| lelandfe wrote:
| One would hope after
| https://amp.theguardian.com/world/2018/jan/28/fitness-tracki...
| gruez wrote:
| Basically any sort of Android/iOS device by default will report
| back the location of nearby APs. Given how important phones are
| (eg. for entertainment or keeping in touch), it's basically
| impossible to ban them.
| eximius wrote:
| Feels like the theatre of war where opsec literally means
| life or death _to yourself_ , you'd be willing to leave your
| device at base or faraday it or something.
| karma_pharmer wrote:
| Yeah but then millennials came along.
| yellow_postit wrote:
| Multiple militaries have had locations disclosed via Strava.
| BYOD is everywhere.
| ezconnect wrote:
| That is a known fact and widely reported to have caused
| security issues. Even in the Ukraine conflict if the Russian
| army doesn't follow protocol of NOT BRINGING your phone to
| deployment they get targeted instantly by US missiles. SIGINT
| can map phone signals showing large group of people in certain
| areas just by having your phone on and all this privacy thing
| turned off.
| croes wrote:
| Original source
|
| https://news.ycombinator.com/item?id=40454706
|
| Related article
|
| https://news.ycombinator.com/item?id=40464184
| karmakaze wrote:
| On my Android 12 phone, I have the following things disabled:
| - [ ] Location - Improve location accuracy [ ]
| Wi-Fi scanning [ ] Bluetooth scanning - [ ]
| Google location accuracy - [ ] Google location history
| - [ ] Google location sharing - App-level permissions
| - Allowed all the time: None - Allowed only while using
| app: Maps, Lyft, Uber, Uber Eats
|
| What's funny is when searching "location" in settings is that the
| "Google ..." ones aren't listed and have to be hunted down
| manually under Location/Location services.
|
| I sometimes temporarily enable Location, but most often I'll just
| enter addresses manually into the apps and dismiss any requests
| for location access.
|
| Of course anything with internet access can still guess location
| based on the public IP address used to connect to any server.
| Maybe a VPN could help, but then you have to trust that party
| too.
| blueflow wrote:
| Be 100% sure by leaving your smartphone at home. Checking
| WhatsApp & Co once daily is enough.
| dannyw wrote:
| This just isn't practical for anyone with kids, etc.
| dark-star wrote:
| I wonder how people checked in on their kids in the 90s,
| before smartphones were a thing?
|
| /s
| cornflake23 wrote:
| Tried it, alas, without success -Two big factors: 1. the
| infrastructure that made this possible in the 90s isn't
| there anymore (at least in my part of the world). 2. The
| surrounding world requires information exchange at
| physical boundaries. These too have now been "digitized".
|
| Where might we turn to?
| amatecha wrote:
| The family could all get their amateur radio
| certification/license and communicate over great
| distances, for free, without any subscription fees,
| tracking, etc. :) Sounds like I'm joking but honestly
| with the presence of repeaters everywhere around any
| metropolitan area, establishing communication would be
| trivially easy (especially with agreed-upon "time
| windows" during which to listen for each other and/or to
| check in).
| Aurornis wrote:
| I grew up in the 90s. If plans deviated from what we
| decided before I left the house, it was a huge chore to
| communicate with parents. It involved finding a pay
| phone, then calling a list of different numbers to try to
| catch parents at the office or home or wherever they
| might be. And it sucked.
|
| It's weird to think that anyone would hold this up as an
| example of the good old days. Rose colored glasses in
| effect.
|
| Notably, pay phones don't exist anymore, so you couldn't
| actually replicate the 90s era communication if you
| wanted to.
| SapporoChris wrote:
| Pay phones are not prevalent in the USA, but they do
| exist. https://www.payphone-project.com/numbers/usa/
|
| Some countries actually support pay phones. They're
| amazingly useful during disasters when mobile networks
| may not be functioning.
|
| Example: Japan, but they're contemplating reduction.
| "city areas are required to have a public pay phone
| installed every 500 square meters, with non-city areas
| every kilometer. "
| https://japantoday.com/category/features/lifestyle/the-
| end-o...
|
| If your local region doesn't have a lot of pay phones
| perhaps it is time to consult the local government.
| Change can start at the bottom.
| judge2020 wrote:
| OP was almost certainly saying "don't exist anymore" to
| indicate that you can't rely on them to be at every
| corner gas station (or similar) anymore, thus making them
| obsolete for such a purpose as checking in with
| relatives. Their obscurity means you'll be unlikely to
| find them unless you're close enough to something like a
| full-service truck stop, which I've observed tend to
| still have payphones.
| sambazi wrote:
| also grew up in the 90s and plans usually didn't deviate
| from the plan because there was no way to communicate.
|
| ppl just showed up, or didn't
| yjftsjthsd-h wrote:
| > Checking WhatsApp & Co once daily is enough.
|
| That is _strongly_ dependent on your social circles, and is
| also a rather small subset of what smartphones are used for.
| kingnothing wrote:
| Regardless of all of that, your phone provider is selling your
| location data derived from triangulated cell tower positioning.
|
| https://krebsonsecurity.com/2024/04/fcc-fines-major-u-s-wire...
| aunty_helen wrote:
| I don't see enough talk about this. I thought someone would
| have hacked up a solution to this by now.
| pwagland wrote:
| But a solution is basically not possible, short of running
| your own cellular network. By definition the the carrier
| has to know where to send the data that your handset wants,
| and once they know which tower you are going out of, they
| know your location to within a small degree.
| Karawebnetwork wrote:
| No SIM card in your main phone (now only a "pocket
| computer"), burner phone for calls.
| threecheese wrote:
| How does this work for eSIM?
| toomuchtodo wrote:
| American Privacy Rights Act of 2024 is a potential
| solution.
|
| https://www.commerce.senate.gov/2024/4/committee-chairs-
| cant...
|
| https://www.commerce.senate.gov/services/files/3F5EEA76-5B1
| 8...
| fsflover wrote:
| Have a loot at Purism AweSIM service.
| spr-alex wrote:
| Also see https://en.wikipedia.org/wiki/Simjacker which was
| being exploited by bounty hunters and all kinds of
| adversaries
| pests wrote:
| > anything with internet access can still guess location based
| on the public IP address used to connect to any server.
|
| Not to mention Chrome & friends will gladly provide wifi-based
| location lookup to any site that asks for location. You can
| have GPS off, using a VPN, and still the website will know
| where you are. Turn it off, sure, then the site can block you.
|
| Tried to get around my states online casino restrictions a few
| months back. Not a fun time.
| judge2020 wrote:
| > Turn it off, sure, then the site can block you.
|
| Yes? Is this a problem?
|
| > Tried to get around my states online casino restrictions a
| few months back. Not a fun time.
|
| How is any casino both (A) following state restrictions and
| (B) not validating based on both your geo location and the
| address you must validate via some KYC document? Or are you
| also entering a fake address somehow?
| pests wrote:
| > Yes? Is this a problem?
|
| Yes, because I am trying to use the site. If they block me,
| I can't use it.
|
| They validate, usually via a backend SSN lookup or via an
| identity document like ID or passport, but only on
| registration. Sometimes they make you take a selfie with
| your ID. Sometimes you get flagged and have to identify
| again.
|
| In Michigan you are allowed to use the site from any
| location, there are restricted actions which must be
| location verified. Sports wagering and any casino gambling
| obviously, but I think deposits or withdraws might be
| location limited as well.
|
| The location verification is accomplished via both a
| dedicated program you must install on your device + giving
| location permission in the web browser, which uses GPS +
| Cellular + Wi-FI triangulation.
|
| > Or are you also entering a fake address somehow?
|
| You are allowed to use the online casino's with an out-of-
| state ID or address. You must simply be in the state for
| location verification. There is a little industry of people
| taking road or train trips to travel through all the online
| gambling states in order to sign up for the free promotion
| money.
| pests wrote:
| For anyone wanting to know what I tried and how it ended:
|
| This was on a laptop with no built-in GPS and no
| cellular.
|
| Paid VPN - nope, they probably have a list of all the VPN
| providers IP addresses.
|
| Self-VPN in cloud - no, again they probably have an IP
| list
|
| Self-VPN in target state on residential IP - nope,
| something else causing the fail
|
| Spoofing WiFi names & IDs in the environment of the
| residential IP above, both from online databases and
| having someone there do a scan - nope, I think the
| problem here was the networks in range of the laptop were
| lowering the confidence of the location check
|
| Finding a browser that doesn't incorporate WIFI
| triangulation - none that I could find, including all the
| privacy-focused browsers like Brave. They let you turn
| off location, but none let you disable the wifi
| component.
|
| At this point my thoughts were that I would have to
| find/write a custom driver or find some other way to get
| the wireless card to lie about which networks are
| nearby.... or find a way to crack the casino location
| service executable AND patch a browser not to rat on me.
|
| There is no other sources of leaks from what I could
| tell. No other signals being detected by my laptop, no
| DNS or VPN leaks, it had to be the Wi-Fi triangulation.
|
| I didn't want to do all that so instead just left a PC at
| home hooked up to a PiKVM and it worked perfectly.
|
| edit: Forgot to mention you must have Wifi on the device
| or else it will block and ask you to enable it.
| aftbit wrote:
| Did you try on a laptop without wifi enabled?
| pests wrote:
| I added an edit at the bottom, not sure if you caught
| that on your page load. Wifi off or disabled is insta
| blocked.
| aftbit wrote:
| Oh yeah I missed that. So a desktop computer can't play?
| Lame.
| pests wrote:
| Ya know what, I didn't actually test that but I would
| assume. I've been on a laptop for awhile and all my
| desktops have either a wifi card or its build into the
| motherboard.
|
| I did disable the driver and tried to make my laptop act
| as if it didnt have WIFI at all, but I don't see how they
| could protect a desktop from what I was attempted above
| without WiFi access.
| gruez wrote:
| >Self-VPN in target state on residential IP - nope,
| something else causing the fail
|
| might be caused by the VPN connection reducing the MTU,
| and the server detecting that.
| hnburnsy wrote:
| Can you run the betting app in an Android emulator, and
| then control all aspects of the environment?
| microflash wrote:
| I've done the same. It is extremely annoying that there's no
| concept of graceful fallback in modern operating systems. For
| example, Google Pay on Android can work without location
| enabled but whenever you start the app, it is the first thing
| that it prompts you for (even before asking fingerprint or
| passcode unlock that you've set on it)
| bcye wrote:
| You're still giving it away by which merchant you're
| transacting with.
| 3abiton wrote:
| To be fair, apple has a similar approach, you can't fully turn
| off Bluetooth or wifi if you press on their corresponding
| widgets (they only become inactive), you have to go to the
| settings to turn them off. As for location, you can't even do
| so without going to the settings.
| dirkmakerhafen wrote:
| Wait what, this was not public knowledge?
|
| I have been using apple geolocation api for the last 6-7 years to
| regularly download a snapshot of all access points in the world.
|
| https://github.com/dirk-makerhafen/apple-bssid (the basic request
| code, not the mass downloader part)
| ipsum2 wrote:
| Does this still work or did Apples mitigations stop this from
| working?
| sambazi wrote:
| it's a public api and public cloud exists, how would they
| stop scraping?
| gruez wrote:
| Authentication via remote attestation?
| sambazi wrote:
| it's not a public api anymore if you have to auth, but i
| guess you're right
| IshKebab wrote:
| No, I'm pretty sure Google (or Skyhook?) fixed this issue in
| like 2012. I assumed Apple had done the same.
| sambazi wrote:
| what issue are you referring to?
| IshKebab wrote:
| They used to have an API that would let you submit a single
| ssid and get its location. I believe their fix was that you
| needed to submit at least 2 (maybe more) ssids and it would
| only return the location if they were in close proximity.
|
| Seems like Apple didn't get the message.
| inasio wrote:
| Nitpick: Figure 2 should have been loglog, rather than semilog-y,
| I would love to see more details rather than the near vertical
| line (graph is Cumulative geo-located BSSIDs as a function of the
| number of API queries)
| datahack wrote:
| Has nobody ever heard of Google sidewalk or what?
| _trampeltier wrote:
| There is, since ever, a website with wifi routers and location
|
| https://www.wigle.net/
| sambazi wrote:
| pls don't discriminate against ppl that lived in a world before
| wifi was a thing
| benopal64 wrote:
| thank u for doing gods work. wifi-less people have been
| around for centuries.
| sambazi wrote:
| and discrimination against us has absolutely soared in the
| last decades
| lgats wrote:
| https://www.reddit.com/r/WritingPrompts/comments/6vpej2/wp_y.
| ..
| transpute wrote:
| "Why Your Wi-Fi Router Doubles as an Apple AirTag", 100 comments,
| https://news.ycombinator.com/item?id=40430603
|
| _> In late March 2024, Apple quietly updated its website to note
| that anyone can opt out of having the location of their wireless
| access points collected and shared by Apple -- by appending
| "_nomap" to the end of the Wi-Fi access point's name (SSID).
| Adding "_nomap" to your Wi-Fi network name also blocks Google
| from indexing its location..
|
| > "You may not have Apple products, but if you have an access
| point and someone near you owns an Apple device, your BSSID will
| be in [Apple's] database," he said. "What's important to note
| here is that every access point is being tracked, without opting
| in, whether they run an Apple device or not.. Commonly used
| travel routers compound the potential privacy risks..
|
| > The Google/Apple opt out (_nomap) needs to be at the end of
| SSID name. Whereas the Microsoft opt out (_optout) can be
| anywhere in the SSID name. Therefore, to opt out of both, it
| would be in this order: SSIDName_optout_nomap_
| canadiantim wrote:
| Very very useful info, thank you
| chevman wrote:
| My guess is the opt out (versus opt in) nature of this could be
| the seed of a massive class action lawsuit should the right
| folks get involved :)
| transpute wrote:
| _> Asked about the changes, Apple said they have respected
| the "_nomap" flag on SSIDs for some time, but that this was
| only called out in a support article earlier this year._
|
| If an SSID flag falls in the forest and no one is told to
| read it, does it opt out?
|
| https://en.wikipedia.org/wiki/If_a_tree_falls_in_a_forest_an.
| ..
| nerdponx wrote:
| IMO the intrusive nature of the opt-out should be considered
| as well. It basically requires you to broadcast to your
| neighbors, friends, family, guests, etc. your personal
| beliefs about data privacy, and then of course makes you
| identifiable as a data privacy person by anyone interested in
| targeting ads at you.
| salawat wrote:
| Yep. That's the poison pill. Oh, you don't want to be
| tracked? Oh well, you have to let us track you so we can
| treat you "different".
|
| The change we should be pushing for is tracking must be
| opt-in by default. The way God intended.
|
| Thou shalt ask for consent before doing shit with another's
| boxen.
| rsync wrote:
| I know of a better response...
|
| List of ssids in some popular location and then duplicate
| it, place-shifted.
|
| I've been meaning to run this experiment for a while
| now... Can I broadcast a set of ssids that make, for
| instance, the mall of America appear on the Golden Gate
| Bridge?
|
| It surprises me that so much investment and dependency is
| built on leveraging lists of ssids When they are so
| easily spoofed...
| sambazi wrote:
| whatever you have been smoking, i want some
|
| PS: you'd also have to spoof the mac addresses and get a
| lot of clients to report it, but it could cause some
| confusion
| sambazi wrote:
| please don't submit to this nonsense.
|
| future you will thank you
| transpute wrote:
| _> this nonsense_
|
| Because the flags are: (a) not honored by
| M/G/A for removal from public db? (b) ignored by other
| parties? (c) treated like telemarketing/spam opt-out
| lists? (d) ...?
| acheong08 wrote:
| I've been experimenting with this over the past few days:
| https://github.com/acheong08/apple-corelocation-experiments
|
| Found some interesting things and still working on recording more
| MITM from my iPhone to see what else is sent.
| edward1 wrote:
| Here is a good summary of that PDF
| https://learnlater.com/content/1778/Surveilling%20the%20Mass...
| nbzso wrote:
| Call me paranoid, but I have a habit to use a Faraday Bag. Saving
| a lot of battery and knowing when and where to activate. Welcome
| to the future. :)
| clort wrote:
| How does a faraday bag save battery? Normally I find that in
| areas of poor mobile signal, the phone ramps up the power to
| keep contacting towers and burns through the charge much
| quicker..
| mrbluecoat wrote:
| Same. Airplane mode works better for me in these scenarios.
| fsflover wrote:
| Only if you trust that it does what it says.
| Eduard wrote:
| I find this paper's title "surveilling the masses ..." not
| fitting for the (nevertheless important) findings in this paper.
| While "mass surveillance" is an ambiguous term, it invokes images
| of "this method allows wiretapping/reading society's private
| conversations, and/or pinpointing everybody's precise location in
| real-time".
|
| But actually, the findings are:
|
| "this method can be leveraged as an additional statistical proxy
| for population movement and infrastructure outages/destruction;
|
| By taking several assumptions (e.g. BSSID not spoofed; BSSID is
| seen by some smartphone; BSSID of to-be-surveilled target is
| known; BSSID is actually used by target and not sold/handed to
| someone else; target is close to BSSID; BSSID is on; etc.), an
| individual's historical and possibly current whereabouts may be
| revealed".
| whatupmiked wrote:
| You seem to be attacking a strawman.
|
| "The central goal of the attacker we consider is to gather
| location and movement data about a large number of devices,
| either globally or pertaining to a specific region of
| interest."
| Eduard wrote:
| My critique is not about the paper _content_, it is about the
| paper _title_, which currently (arXiv:2405.14975v1 ) verbatim
| is: "Surveilling the Masses with Wi-Fi-Based Positioning
| Systems".
|
| Understand it as a minor pet peeve on my side that I would
| prefer a less sensational, better disambiguated title in
| order for the paper to express its content and significance.
| After all, it's arxiv.org, and possibly a preprint open for
| feedback.
| nonameiguess wrote:
| It remains to be seen to me what information is really being
| gathered here that wasn't already available. If you want to
| know where people are, geographic population demographics and
| residential density data is generally publicly available in
| most places. If you want to know where they're moving to,
| vehicular traffic, bus and train ridership, and airline
| ticket sales are also public knowledge.
|
| This is simply providing another way to say "humans who
| connect to WiFi networks exist here, here, and here, and move
| to here, here, and here." Without knowing who actually owns
| and uses each device, it's hard to see how you can really
| call this mass surveillance, which typically implies the
| leakage of information that people expected to be private.
| The fact that my residential address has a WiFi access point
| in it does not seem to me to be private information. I can
| readily guess with at least 99% accuracy that every
| residential and business address in existence with visible
| furnishing, decoration, regular cleaning, trash outside, or
| any other sign of human occupancy, has a WiFi access point
| attached to it.
|
| The threat they mention of intimate partner abuse and
| stalking whereby an attacker knows a specific person's MAC
| address and is able to track them if they move but retain the
| same device is a more obviously real concern, but easily
| mitigated by simply not retaining the same WiFi access point
| when you move to a new residential address.
| pontifier wrote:
| I was thinking recently about the inverse of this attack. I have
| many thieves coming to my warehouse, and was thinking I could
| broadcast bunch of local ssids to try to see which ones their
| phones try to autoconnect to.
|
| I could then use that info to figure out where they are likely to
| hang out, and either give it to police or take matters into my
| own hands.
| p3rls wrote:
| How much have you had stolen in monetary value just out of
| curiosity? I went schizo myself for a few months after having
| like $60k worth of stuff stolen from me when the cops did
| nothing. But you sound like this is just happening continually
| -- having this daily stress that's gonna get you or someone
| else killed -- and you probably don't deserve the prison time.
| hellojesus wrote:
| At some loss value it seems like hiring off duty cops is ev+.
| p3rls wrote:
| Yeah I think everyone tells this guy that, and it'd
| probably be a good start to try and get himself back in the
| good graces of Pine Bluff's political types, but for
| whatever reason it doesn't look like an option and he posts
| on twitter that he's still getting bulgarized on something
| like a weekly basis... From my experience I know there's
| nothing more frustrating than these useless government
| bureaucrats that can't be bothered to do their jobs until
| something or someone explodes.
| Hikikomori wrote:
| Beacons take up a fair bit of radio space so if you're going to
| have a lot then have it on a channel you're not using yourself.
| heartbreak wrote:
| Their phones search for known WiFi networks whenever they're
| not currently connected to WiFi. You can monitor and log this
| traffic. Many (most?) modern smartphones randomize their MAC
| address when not connected, but a few years ago you could look
| for repeat visitors this way, too.
| gruez wrote:
| Suppose you found that they auto connected to mcdonald's wifi.
| Now what? Are you going to stake out the local mcdonald's on
| the off chance that the thieves hangs out there? Given how long
| people keep their phones (years) and never clear their wifi
| network lists, all this would tell you is that they visited the
| given business at some point in time. It doesn't tell you
| whether they frequent that place.
| calvinmorrison wrote:
| No but you may sell that location data to send them Fast Food
| eDream on their Tesla AI VR Crypto Quantum Unit
| ajsnigrutin wrote:
| Offtopic, I know, but still...
|
| > Wi-Fi-based Positioning Systems (WPSes) are....
|
| Why does every articl have to invent some acronym, and even worse
| in this case, an acronym that already exists in the wifi context
| (wifi protected setup - WPS).
| calebm wrote:
| I published an open-source tool several years ago which helps map
| out the wifi world:
| https://github.com/calebmadrigal/trackerjacker.
| ACV001 wrote:
| wow this is huge
|
| "Russia-Ukraine War First, we use Apple's WPS to ana- lyze device
| movements into and out of Ukraine and Russia, gaining insights
| into their ongoing war that, to the best of our knowledge, have
| yet to be made public. We find what appear to be personal devices
| being brought by military personnel into war zones, exposing pre-
| deployment sites and military positions. Our results also show
| individuals who have left Ukraine to a wide range of countries,
| validating public reports of where Ukrainian refugees have
| resettled."
| jessenaser wrote:
| On top of that, some networks like Spectrum already report all
| the MAC addresses that are connected to it remotely to the
| Spectrum database, instead of just on your network panel locally
| (because there isn't a Spectrum network panel anymore, only the
| app). This means that a nation state (USA) can see real time
| minute by minute who is on that network, and recent devices on
| that network because Spectrum designed this in their firmware.
|
| You can check yourself from the app:
|
| Services > Devices on Network > Manage
|
| And it will show all of the MAC addresses connected, and recently
| connected. Even remotely if you are not logged into your network.
|
| You also can see the *plaintext* password to your router from
| this app.
|
| Services > Your WiFi Network
|
| Which means a nation state also can remotely login to your
| network without you knowing, and otherwise is bad for security if
| passwords for millions of homes are plaintext.
|
| ---
|
| Moral of the story is that even if Apple eventually fixes this,
| the other side of the tracking that nation states could do could
| be done at the ISP firmware level. To solve this kind of attack,
| either allowing open firmware or new legislation is the only to
| stop this. (Which when has privacy legislation ever happened...
| is another question for another day).
| sandworm101 wrote:
| >> To solve this kind of attack, either allowing open firmware
| or new legislation is the only to stop this.
|
| Or just randomize every MAC at the client level, blinding
| everyone up the chain and no doubt causing many false reports
| as randomized macs collide.
| jessenaser wrote:
| Yes this helps the MAC concern, but this means we need wide
| scale device manufactures to enable this by default, because
| users won't. Similar level of consensus.
|
| Also why is some devices don't support this randomization, or
| even if they do, the first connection is not supported. When
| you first activate an iPhone or use a Windows computer, it
| still does not expose all the settings to randomize the MAC
| address until you setup the device, so the first connection
| exposes the actual address to the network. Yet again we need
| deeper levels of change to fix this.
___________________________________________________________________
(page generated 2024-05-28 23:01 UTC)