Disclaimer: I work at Density (https://www.density.io) building an anonymous people counter.
MAC address tracking is a good simple way to get an approximate number of people: it's very easy to install, it requires only a WiFi antenna, and the data is easy to translate into a count. However, there are privacy and legal concerns which have prompted phone vendors to obfuscate this data. And there can easily be zero (or more than one) broadcasted MAC address per human, even when filtering by OUI.
Retailers have been using specialized "people count" technology like infrared break-beams, thermal cameras, and CCTV+CV systems for a long time. CCTV is the most accurate by far, but it's also commonly considered to be an invasive level of surveillance (and rightly so). It's also not particularly accurate in adverse situations. At Density, we looked at (and tried) many of these technologies - but ultimately found them lacking because they were either too invasive or too inaccurate. The device we've built uses a lower-resolution depth-only sensor because it can return extremely accurate results, without having the capability for facial recognition or other analysis techniques that are harmful to privacy. So far the technology is working very well - with an algorithm based on a deep-learning "human classifier" we're seeing accuracy above 99% in many of our deployments.
Here's a cool (and in-progress, excuse our dust) summary of some issues that the technology has to navigate: https://faq.density.io/algo/
The concerns you raise are true in corner cases, but the general use case should be good enough. Your solution also seems to require mounting one of your devices at the entryway of every room for which you wish to monitor occupancy. Seems like it could be costly, especially if doing so requires wiring power up to it.
That is the other side of our approach, yes. Active depth sensing and on-device deep learning means non-trivial power and speed requirements, so the hardware isn't as cheap as we'd like it to be. I'm not up to date with the latest developments on the hardware team, but they're working aggressively on our BOM and we're hoping to take advantage of cheaper and lower-power SIMD/GPU chips in the future. Our current-gen model works with Power over Ethernet, and right now we're most often selling to customers with large/valuable real-estate portfolios because they can get a higher ROI from accurate count data.
We've switched from a mobile phone MAC address based location analytics people counter system(I believe founded by someone who worked on Google Analytics) to a stereo camera based system(bellwether).
We switched as our original provider's business model shifted(I believe in part due to the change in MAC addressing by telecom providers?).
We believe strongly in personal freedom and personal data security.
But we are scratching our head as far as what we can do to ethically and affordably better understand and serve our customers in an integrated(digital & meatspace) way.
I'm not sure if our product would be able to meet your needs right away, but reach out to sales@density.io if you'd like more information about what we have.
Without knowing what specific depth sensor you're using, most of them are essentially B/W IR cameras so it seems a bit disingenuous to say that is better for privacy.
The depth map you provide doesn't contain the full output of the sensor, but how is that any different than using cameras but not passing the data up any higher?
If you look at this video:
https://www.youtube.com/watch?v=YOKMx7EDVys you can see the kind of image that Density has access to, though their depth map they show is only what's on the left side.
No part of our system uses amplitude data, not even on the local device. We only rely on phase offset/depth data. However you're correct that simply choosing a particular technology cannot automatically "solve" privacy, and it has to remain a priority indefinitely.
Looks cool!
I’m wondering how you would deal with cumulative errors. Lets say you have a meeting room with one door with one sensor, and the sensors has a 99% accuracy. If 100+ people walk through the door, the sensor could still report 1 or 2 persona in meeting room, while nobody is there.
Do you have work arounds for this problem?
Yes, we have active R&D projects focused on addressing this kind of drift. In smaller rooms where the environment is favorable, we will usually see the device count for a whole day without any mistakes. But in general there are diminishing returns with that strategy, and there are lots of possible ways to correct drift error. I'm not sure how much more I can say right now.
I work on the software side, so I can't really comment with authority, but this looks like it could be an interesting lower-frequency/lower-power approach to active sensing. From the preview site, it seems like the "resolution" of this model may be too low to separate and count a crowd of people. However I'll forward this on to the hardware team just in case, thanks!
Isn't Soli more for natural user interface (NUI) detection via radar wave disruptions? I'm not sure it would provide very granular detection and he'd have a lot of false positives.
I was thinking more in terms of lidar tracking of people. It's been around for nearly a decade and works quite well.
Right, Soli is built for NUI. However, it does seem like it might fit this use case as well:
Distance - I'd imagine that the distance from the top of a door frame to the top of the head of the average shopper is roughly equivalent to the distance from the Soli device to someone's hands.
Software - The Soli hardware streams radar contacts to software trained to separate and classify them, not too unlike the approach that Density is already using.
Benefits over a CV approach might come in power usage and lower complexity in the contact classification software.
Unfortunately, as far as I know LIDAR is still prohibitively expensive for this. Someone did invent a solid-state LIDAR system recently, which seems like a good sign.
Fair point. I was solely thinking from a technical solution not the practicality around deployment. My employer has biased my bubble on thought process. "Oh, yes, this is easy to solve, and I see it on campus (Disney - imagineering office).
Really interesting. What sort of limits/constraints do you have? For example, I've seen older methods have trouble maintaining tracking accurately at 12-24+ people in an room size area.
Since the sensor has a certain operating power, it does not work as well on very high doorways (>10ft) or in direct sunlight. Also the field of view cannot cover a very wide doorway (>8ft). Obstructions, reflections, and odd room geometry are common problems, but they can often be solved in software/configuration.
Within spec, the algorithm does well tracking 8+ people at a time, and even when a line of people extends through a doorway we usually don't have to track more than that.
The hard thing about that approach might be handling conflicting signals and determining a "source of truth" in adverse situations. Generally speaking, there are variables in the real world that will trip up any given strategy (even if you were to station a human at each doorway with a hand counter). And while nothing can count perfectly 100% of the time, the difficulty is in finding an affordable strategy that will be really close or perfect most of the time.
Here's a neat demo of a multi-sensing device (not ours) which combines many signals to guess the activity taking place in a room: https://www.youtube.com/watch?v=aqbKrrru2co
guscost correctly describes the limitations of MAC address tracking. In my experience building Aura Vision [1], we've also discovered MAC tracking is no longer GDPR compliant, because an identifier about a person is stored indefinitely. This gives retailers the ability to measure the same identifier returning. The same goes for Bluetooth/BLE tracking.
We are a CCTV/deep learning system that uses existing infrastructure (think old school grainy security cameras), and we're are also able to capture additional information like age and gender of a person. Unlike other invasive/HD CCTV systems, we don't use facial recognition, and we also work over very wide areas, not just over restricted doorways.
It's commonly used by some retail and shopping malls to "estimate" traffic and conversion. It's great for determining peak times and visit duration. This kind of technology has been commercialized for some time now.
People counters for retail stores or airports are commonplace, true. Recently, humanitarian aid organisations began to show interest in using them, as well. They could use them for instance to manage refugee camps better or to understand migration routes.
So we built a tool for the NGOs in this sector, with a very similar technology used by OP as basis:
One key difference is that each Aileen box is a client, which will upload its findings to a server, so that NGO management staff can review it.
Now that the basis is there (and being piloted), we hope to make it into a product tailored to the humanitarian aid sector. One key aspect is taking privacy seriously, others will drill down into the features that refugee camp managers tell us they'd need (for instance alerts if populations seem to be on a rapid move).
My wife manages a retail store and they use this tech to track sales conversions by the hour. Gross sales / Number of people walking in the store broken out by hour. Each conversion rate for each hour is tied back to the manager on duty for that hour so they can see how effectively the store is managed. They also take weather into account since that has a strong effect on foot traffic for an outdoor mall.
I'm now considering building a battery powered RasPi device that'll rapidly switch the MAC address on the WiFi adaptor and masquerade as extremely busy periods as I walk through a shopping mall...
> Pry-Fi comes with a War mode, which when enabled tries to make your Android device appear like dozens of people. Just wandering around an area under Wi-Fi location surveillance for a few minutes can ruin the tracking data for the period of your stay.
>rapidly switch the MAC address on the WiFi adaptor //
Seems like you wouldn't need to do that, just do something akin to a DoS where the traffic is spoofed to contain a different MAC? I guess you'd need driver level access to the adaptor though.
Or, maybe you can just send data whilst flipping random bits in the MAC address memory address location?
Forgive me, but that sounds awful. Does she like this system? Genuinely curious if it works or if it just results in a pushy manager trying to get her numbers up?
Metric-driven automated employee tracking is everywhere. If you're a software engineer or similar at a tech company, be aware that you have a very cushy, unmonitored job by most comparisons.
It isn't "just" Amazon warehouse employees and other low-paid folks.
One thing that most people don't realize at big tech companies is how much your time actually is monitored.
The amount of tickets you close out, the amount of code reviews you publish, how many code reviews of other employees you're doing. There's a lot of metrics that are not openly discussed but are being tracked and watched to make sure you're performing at the same level as your peers.
You don't want to get caught transmitting on cellular bands.
You can do this with just receive though. A $10 USB TV Tuner and a Raspberry Pi will listen in to most cellular bands, and pull enough out of the over-the-air machine to machine chatter to do a similarly accurate job of counting cellphones...
The cellular transmitters (can)_ run with a lot more power than Wi-Fi, and are on lower frequencies, so the range at which you'll detect them is significantly longer, which might make localised device counting less useable.
If you buy carefully you can usually get 1800 on a TV Tuner with the right chipset. You can get to 2.4GHz with a satellite downconverter if you haven't by then bought in enough to buy a (way) more expensive SDR.
E400 goes to around 1.7 GHz, R820T to about 1.85 GHz, which doesn't cover the full LTE band, so yes it's pretty shit at the higher frequencies, 10$ won't get you anywhere there.
It's a great example of the breakdown in understanding of a system. People envision WiFi as a wireless pipe or cable whereas in reality you're broadcasting in every direction out to infinity.
When reality doesn't match peoples' expectations they legislate a 'fix' (making listening illegal) rather than fixing the fundamental technical issue (with encryption, randomized IDs, etc).
I think that's argued a little differently. Rain you collect from your roof is water removed from a watershed which has an impact on everything living in that environment. You aren't allowed to burn your trash in your yard and pollute the 'public' air either, for example.
> It may be illegal to monitor networks for MAC addresses
I use promiscuous mode to monitor and send alerts about everybody with a wifi active phone that comes onto my property. I also have cameras and motion sensors. It's not illegal and if it's made illegal I'll keep doing it because I have an intrinsic fundamental human right to protect my property.
Our research group also had a similar idea to this back in 2006, though looking at laptops (since this was before smartphones really took off). This was also before MAC randomization, as many other posters have pointed out. Here's our research paper if you're interested:
http://cmuchimps.org/uploads/publication/paper/86/putting_pe...
Two ideas to consider for next steps, if you're interested. One is to crowdsource the data, to build out a map of places and how busy those places are. You would need to add in a lot of privacy mechanisms though, e.g. only sharing data of mostly public places vs homes. You could also build out a map of interesting places based on this (e.g. we used foursquare data in our past research to build out clusters of places, see http://livehoods.org/)
Another is to estimate how busy a place really is based on traffic, in terms of #people, and #seats or #tables available. This could be especially useful for campuses (where is a good place to study?) or cafes. You might need some crowd-based approach to label ground truth, and it's unclear what the incentive would be.
We did consider commercialization back in the day, but never came up with a plausible business model. It's not clear why business owners would want this, and they might even have an incentive to cheat. Though I would definitely say that cities would be interested in this data, e.g. urban planners or depts of public works. They have so little data about what is actually going on in a city. For example, we spoke with people who wanted to know the effects of closing a bridge or closing off a street.
My university still has people count by hand twice a shift, a dozen floors of tables. It's hard to beat the benefits of how cheap it is to hand a minimum wage undergrad a $5 mechanical counter and have them get a more precise count in the 20 minutes it takes to do a lap of the building, especially when said undergrad would just be idling at the front desk, on their phone, and still on the clock for those 20 minutes anyway.
> Another is to estimate how busy a place really is based on traffic, in terms of #people, and #seats or #tables available. This could be especially useful for campuses (where is a good place to study?) or cafes. You might need some crowd-based approach to label ground truth, and it's unclear what the incentive would be.
Google Maps does that. Search for a popular cafe on your area and you should see the "Popular times" graph with live data.
"Project Beacon is designed to improve the performance of location-related features in Google products for your venue, such as popular times, reviews etc. The beacon itself is configured for just this purpose, and isn't re-configurable by the user. If you would like to obtain a beacon to use with our developer platform, you can find a list of manufacturers at g.co/beacons"
I assume they do that by tracking how many Androids are at a given location; so that doesn't count those who are using iOS. Given Android's dominance though, not counting iOS devices might not be even skew the results significantly.
The pervasiveness of Android would mitigate random errors. It alone can not, however, mitigate systematic errors. Apple Stores (and, employing stereotypes for maximum effect, art galleries and organic food stores) would be undercounted.
But, wait: Google only gives you relative data over time, where that error is irrelevant. Never mind.
I'd bet that any iOS device running Google Maps is probably listening for those beacons too and calling home to tell them. (And Google Maps is likely snitching on you via your own GPS as well, in the absence of Bluetooth beacons.)
i've seen twitch streamers get swatted and their viewers start their lights/play "fuck the police" via alexa via paid donation TTS software. this just removes one step in the process
I did something similar for macOS, my aim was to see how effective deauthing a router is (turns out it's incredibly effective, the readme has more details) and as a side effect the app shows a list of all WiFi traffic. It was a pretty fun project.
I find this interesting, because my old Apple Time Capsule was doing just fine for well over a year, especially when I changed settings to use only 5GHz and eschew all backwards compatibility. But a few months ago, I started having to occasionally reconnect machines on wifi. My wife's machine on the wired network isn't subject to this, either. I wonder if people in my apartment are experimenting with this.
Thought about this too a while back. If I remember correctly the "issue" (actually I consider it a feature) with most modern smartphones is that they will randomly change their MAC address in order to prevent exactly this kind of tracking.
Do you have any idea how often they change? Like if you were only looking counts of distinct MAC addresses, could you shorten the listening window so that an individual phone would have the same address?
On probe requests this can be very often(< second or within 50 frames), especially in the case of IOS. On Android MAC randomisation is implemented only on a handful of specific devices and some vendors dont at all.
Mac randomisation is flawed at the least and can still be used to identify an individual in some cases.
The paper below lists techniques explored by the US Navy published in 2017.
https://arxiv.org/pdf/1703.02874.pdf
It's 48bits, so a space or around 2.8 million billion possibilities, so you'd need a over a million billion devices to have a 50% chance of collision. _If_ everything was statistically randomly distributed across the entire address space. But they aren't. There's a few kinds of structure in MAC address formats that reduce that but potentially a _lot_...
Theoretical worst care, a MAC address has 24bit of organisation identifier and 24 bits of device identifier. So If an organisation/manufacturer only makes one model of device, they'd "only" need to build ~16.7 million (24bits) of them before they repeated a device identifier (if they chose not to use up any of their organisation bits to reflect that rollover). Again, maybe half that if they just randomly choose a device ID each time instead of enumerate the space.
(Also, many Wi-Fi adaptors have easily changeable MAC addresses. Back in the day when cafes used to charge for Wi-Fi access, it wasn't uncommon to sniff the network for a "paid up" MAC address, and either wait til they left and use it, or de-auth them and do a hostile takeover of their paid-for internet access. Apologies to anyone who used to pay for "unreliable" Wi-Fi at Atlas Cafe on Alabama St back in the late 90s/early 2000s...)
Yep - the chance of any collisions at all, vs the chance of a collision with _your_ specific device/MAC.
That does though drop the chance of any collision at all (aka the birthday paradox) of devices discriminated solely by the 24 bit device identifier down to sort(2^24) which is only 4096. A significantly smaller number than I expected...
I think another question to ask is: do they randomize across all possible MAC addresses, or just within the block of addresses assigned to the type of device. My experience suggests it’s the latter.
They do retain the mac for scanning networks that they have previously connected to AFAIK. This is what allows the correlation of mac approved (ie paid or bound mac networks).
However, if your wifi is on and not connected to an AP, then you will broadcast mgmt frame pings with the correct MAC for all the networks you've been connected to.
An enterprising hacker could submit those to wigle and figure out not only uniques, but also tell what geographical part of the world you're from.
Nicer hackers share this for public knowledge on HN :-D
(edit: really? -1'ed? How is this wrong? Would love to hear from detractors, as this technique is how malls and supermarkets track individual users.)
iOS has sadly made it more difficult to disable WiFi in Control Center (turns back on after fixed time). I wonder if iOS12 Shortcuts could perform geofencing of WiFi.
I thought I remembered schollz (the GitHub user that this is under) from something else, and sure enough, I did! They did another interesting thing with wifi that I believe I discovered from hackernews years ago (appears to have evolved somewhat since then):
I did something similar using my jobs open network, a raspberry and nmap. I was able to correlate devices to people, and depending on which floor they were on they had different DHCP IP ranges. I then made a webpage out of it that let me see who was where. People changed devices too often and I was lazy, but if I could have figured out how to get people's hostnames I could probably make the process a lot simpler.
I know, I know. To my defence it was more to see if it could be done than anything else. I have actually used the very same nmap technique in an argument with a "I have nothing to hide" coworker.
It is a great example of how a simple concept like "I can see other devices connected to the network" can be transformed into "I can log who is at work when". This could be done with a $45 device. With $500 I could make something much more nefarious with regular arduinos.
Several devices,camera at the entrance, Bluetooth LE, not having to do obvious network monitoring. We have loads of good places to hide them, and I suspect they would go unnoticed for years
I did something similar[1] in C++ (on Windows - I know, I know...) but I feared that the rate of the scan requests could inadvertently cause me to be "interesting": even though I was only storing the IDs in memory - due to GDPR - which, from the wording of another comment[2], sounds like could still land me in trouble.
It's interesting (and a bit frightening) to see just how many devices (e.g.: APs, mobile phones, dash cams, etc.) there are discoverable out in the wild.
I wonder if there are any studies on how reliable this is, especially in a crowd. This can be very useful, but I see many ways how the assumption of "MAC addresses" = "people" can be broken:
* As stated in the docs, not everyone has a phone, they estimate it being 70%, but I wonder how accurate this is in different regions for different crowd sizes and applications (cafe visitors vs a parade)
* As stated in the comments, some individuals carry multiple WiFi capable devices and it can be much more than 1 per person
* How large can a crowd get, before signals get jammed to a point this method stops being useful?
* Many people prefer mobile data and sometimes even don't turn WiFi on
So, I mean, it obviously can be used practically, but I struggle to estimate, how much should I believe what the device reads w/o actually seeing the crowd.
I've been researching and working with this for some years now. There's a lot of stuff that can interfere with the quality/accuracy of the numbers (e.g. MAC randomization). I found out that there's also various ways to circumvent and improve upon those problems.
The arpa-e SENSOR [1] program is working on several technologies for people counting for sake of doing Demand Controlled Ventilation (DCV)[2]. People counting is part of the ASHRAE 62.1 calculation [3] for demand controlled ventilation. Also, simple N>0 occupancy counting is useful for home HVAC system setbacks.
I sat in an ASHRAE technical session presentation the other day about the program. All of the technology goals intend for the people count results to be anonymous, and for the technology to be "open source."
Cost goals are <$0.06/ft^2 for residential and <0.08$/ft^2 for commercial systems.
I've long been curious why McDonalds (and the like) don't have automated license plate readers, similar in concept to people counters (though more invasive I suppose) on their drive-throughs.
I'd think they could very quickly & automatically begin collecting data about income, repeat vs new customer, even streamlining the order process by recalling past orders or upselling, etc.
It seems like an area that is incredibly ripe for data collection & analysis; I almost wonder if there isn't a business in here, selling this feature-set as as B2B service.
For the record, I prefer not to be 'tracked' -- I don't know that I can realistically say it would actually impact my fast-food selections though. The concept does intrigue me nonetheless.
Many people are apprehensive about being linked to their plates, even going as far as blacking them out in selfies etc. Given this apprehension (founded or unfounded), I doubt the increase in business would be worth the trade off in negative PR. I can't begin to imagine what the Wendy's twitter timeline would look like if the news broke that McD was storing your license plate in a database and correlating it with your income.
Many of the ideas you suggested (recalling past orders, upselling) can easily be accomplished with existing smartphone technology. I've never used the McD app so I don't know if they utilize location tracking but if they do I can almost guarantee they are already checking to see which locations you visit the most, what you order, when you usually come in, whether you use the drive thru or not, etc. Even without location tracking they can still do all of that if you order online.
tl;dr In my opinion they don't do this because they can already collect the data through less invasive means.
Thats cool. I wanted to do something similar with ESP-8266 to track visitors in a tourist attraction I worked for. But as it turned out it was illegal by law because a law forbids to track people through "electromagnetism". As it turned out it the reason for the law was to not make it possible to track people in their apartments by registering wherever they where watching TV and similar stuff.
We never wanted to track an individual person and would have hashed the MAC, nor did we want to get any data from them (phone brand or whatever). We wanted to be sure to not have more than 1000 people in the building (another law) and for security reasons we did not have turnstiles at the exit.
At the end we had to use cameras that counted heads...
It would be worthwhile to also scan bluetooth discoverable devices and try to normalize the two for cases where:
* you usually see entry and exits of both and can start to map them as "one" user.
* you see only wifi entries and exists without corresponding bluetooth (maybe user usually has bluetooth turned off or is out of range of BT capture).
* You see only BT with no corresponding wifi (user has discoverable bt but wifi off).
The normalization is complicated as wifi/bt range are pretty different (unless you have hardware to extend the pickup for bt) -- but if you deal with a time window slide (and repeat event correlations) it should be possible.
To avoid the privacy issues around MAC addresses, etc, is there any way to simply count the number of "variations" of signal in the area? So rather than having to process any data, you base your count on things like signal strength and other indicators of a "unique" signal?
Does this get around MAC anonymization done by iOs and Android? Researchers have shown it can be defeated, but curious if this takes it into consideration
Although there is a remark about the potential legal issues in the US, it should also be noted that capturing and storing MAC addresses without explicit consent is not GDPR compliant, and not legal in Europe.
Not legal in Europe? That's a bold claim, can you cite any documentation please? I'm in Europe and I know of many local shops, plus at least two pub chains that do this right now.
The pub chains are registered with our Information Commissioners office and I am struggling to understand how every one of those people (including the ICO!) could have missed this.
I note Bluetooth also uses MAC addresses, so this issue is not limited to WiFi. Spoofing your WiFi MAC on a mobile phone with Bluetooth may not be making you as anonymous as you hope to be.
> A business uses Wi-Fi analytics data to count the number of visitors per hour across different retail
outlets. It is not necessary to know whether an individual has visited an individual store (or multiple
stores) before.
> This involves the business processing the Media Access Control (MAC) addresses of mobile devices
that broadcast probe requests to its public Wi-Fi hotspots. MAC addresses are intended to be unique
to the device (although they can be modified or spoofed using software).
> If an individual can be identified from that MAC address, or other information in the possession of
the network operator (the business, in this example), then the data is personal data.
Indeed, collecting unique MAC addresses, potentially from multiple endpoints, can reveal a lot of personal, sensitive, information (location, trips, time you go to the coffee shop or which hospital you visit, etc.).
The only ways to properly collect and store MAC addresses are either using privacy-protecting methods (e.g. cutting the last bits of the MAC address, potentially using bloom filters) or immediately aggregating the collected MAC addresses.
Couldn't almost any WiFi router, and thus the user of that router, then be in violation of GDPR simply by logging which MAC addresses attempt to connect to that router? Even connections by accident (selecting the wrong SSID).
I know my Netgear router has a history of basically any connection attempts and their MAC address; it does this by default, not sure I can even turn it off.
And how would you even present a GDPR notice to the user prior to logging that kind of information?
No. Wifi router needs the MAC address in order to provide a service to the user, thus it is allowed to collect the MAC. GDPR allows collecting personally identifying information if it is necessary for providing the service.
Interesting. What if I own a shop and I want to use this technique to graph the number of people near my shop over time? Would I be in the clear if I hash the MAC addresses?
Operations before storage don't avoid any legal issues around the collection, but they certainly can obviate legal issues with storing the data. For example, if you 'hashed' them with an algorithm that always yield 0, you'd surely be in the clear as far as the storage goes. Probably you'd still be fine if the output of the hash was 1 bit. I don't know whether you'd still be in the clear for more common hash algorithms.
Would you mind explaining that? I'm pretty certain doing this would get you in trouble with a range of other legislation around the EU and put you in line with similar PR nightmares in the past but I don't really see how MAC addresses alone would be covered by the GDPR (at least not in the text/precedence I'm aware of).
MAC address tracking is a good simple way to get an approximate number of people: it's very easy to install, it requires only a WiFi antenna, and the data is easy to translate into a count. However, there are privacy and legal concerns which have prompted phone vendors to obfuscate this data. And there can easily be zero (or more than one) broadcasted MAC address per human, even when filtering by OUI.
Retailers have been using specialized "people count" technology like infrared break-beams, thermal cameras, and CCTV+CV systems for a long time. CCTV is the most accurate by far, but it's also commonly considered to be an invasive level of surveillance (and rightly so). It's also not particularly accurate in adverse situations. At Density, we looked at (and tried) many of these technologies - but ultimately found them lacking because they were either too invasive or too inaccurate. The device we've built uses a lower-resolution depth-only sensor because it can return extremely accurate results, without having the capability for facial recognition or other analysis techniques that are harmful to privacy. So far the technology is working very well - with an algorithm based on a deep-learning "human classifier" we're seeing accuracy above 99% in many of our deployments.
Here's a cool (and in-progress, excuse our dust) summary of some issues that the technology has to navigate: https://faq.density.io/algo/