@davidwalton will probably be able to confirm, but I believe both platforms work the same way here. They don’t need location access to collect your coarse location via other means.
I don’t think there’d even be a way for Apple/Google to prevent that sort of detection, or force it behind an opt in pop-up. They don’t need system level access for it.
They aren’t taking your ‘location data’ (your GPS data), that’s not what Gravy worked with. Gravy used other information that apps gather like what WiFi networks are local to you to work out where you were.
This feels nightmarish . An SDK barely associated with the company that runs the app I’ve downloaded sends information off to a third party that has no relationship at all with said company.
It’s good to know about I guess, but feels impossible to counter.
1 Like
phildawson
(Sorry, I will have to escalate this.)
106
What I’m saying is on Android you have the following classes that give access to WiFi name but you require the end user to explicitly select Precise Location.
I think it’s part of the reason behind privacy nutritional labels. They expose a lot of this stuff, like with MKBHD’s wallpaper app.
I think a lot of times, developers just don’t know or aren’t sure what they collect because of reliance on third parties, so wind up listing things just in case.
When I’m writing a GDPR-compliant privacy and cookies policy, the vast amount what goes into it pertains to what some implemented third party is up to, rather than me or the client. It’s a minefield when there’s lots involved, like with this advertising partner (probably one of these SDKs that are the culprit here), that analytics platform, your services provider, the cookies and tracking associated with the platform licensing you your favourite font, etc.