My first eye-opening moment working within the government was with team of herpetologists at the state conservation agency. They had a pretty slick public education campaign around protecting Gopher Tortoise habitats and a grand call-to-action "let the agency know where and when they see their nests". The whole thing fell apart because they were getting tons of earnestly-submitted junk data from earnestly-engaged citizens. Turns out the application was just a form that they asked people to fill out. I suggested they ask for user photos and scrape the EXIF data or ask them to opt-into sending their location and got laughed out of the room. Turns out that they discovered users immediately nope out of government websites that ask for their location! What a shame.
A colleague of mine tried doing this after a large sturgeon die off in the San Francisco Bay a few years ago. Citizens were asked to upload photos of dead sturgeon washed up on beaches. They actually got pretty good data (sturgeon are very easily identifiable) and lots of participation, but the location data ending up being largely useless because it was fuzzed (I think by iOS?) to a large enough degree to no longer be helpful, and the fields for manual coordinate entry had very low usage
Oh that's fascinating. I hadn't considered OS-level fuzzing as a hurdle until now. I'm an pixel guy and typically I get decently-accurate location heatmaps in the Photos app when I search by location; I wonder how we would have handled this. HABs are so difficult, they break my heart.
How does iOS decide whether to default to including location?
I coulda sworn, even in earlier versions of iOS 26, if you told it not to include location when sending a photo once then it would not include it by default the next time.
Also I thought that when you uploaded a photo from your camera roll to the web I thought it defaulted to no location. And that seems to have changed too. (Of course, you can still tap a button to withhold location EXIF.)
I wonder if there would be any way to fix this with the right messaging. With infinite funding and the right agency cooperation, I bet you could include this in a state parks app that you could also use for other useful purposes, like pulling up trail maps, paying for parking and camping, fishing licensing, signing up for volunteer events, receiving notifications with news around particular parks you frequent, etc.
But in the real world, if you put a QR code at the trailhead and said "take a picture of this code. When you see a tortoise nest, use the code to go to our website and share your exact location."
If people are wary of sharing their location with the conservation agency, you might have better luck if the website was run by a nongovernmental conservation group?
Well that's just it - in most of the submissions the coordinates weren't supplied at all, and when any location information was given it would come down to just a city name or a park name. They're trying to pipe these results into ArcGIS to inform park rangers where to reroute trails, public works departments where to survey before digging, and real estate developers which lots need proper relocation assistance before building on. They were depending on the average citizen to know how to fill out a technical field in this form and to do so accurately, and without and form validation. The whole project needed re-thinking.
Sounds like a combination of 'can it be geocoded?' and 'is their location precise enough?' There is some progress on resolving human-written locations in cities ( https://www.danvk.org/2026/03/08/oldnyc-updates.html ) but I imagine once you lose reference points, '100 feet into Golden Gate Park...' would be interpretable but not possible to fix to one point.
I've also noticed that iNaturalist also fuzzes exact locations for some species within a geographic grid (example: zebra) even the ranch zebra in San Simeon, California.
> I’d wager 99.9% of the users didn’t realize that they are effectively sending their live GPS coords to a random website when taking a photo.
I'd wager 90% of the photos on Google Maps associated with various listings don't actually know their photos are in public. I keep coming across selfies and other photos that look very personal, but somehow someone uploaded to Google Maps, the photo is next to a store or something and Google somehow linked them together, probably by EXIF.
Google Maps app sees that you took photo near POI and later in the day asks you in notification if you want to share it on maps.
You review the photo and go "lol, sure".
At least for me that doesn't even feel like posting due to how frictionless it is and that it's about natural discoverability (someone has to click that POI and scroll through photos to find it).
I remember arriving in Lisbon, leaving a favorable review for a restaurant because they were so nice to us, and Google sending me a notification that I'm now a local guide for Lisbon.
What exactly does that mean though? Is there any benefits to it? All I see is a badge/label, that's it?
There are some benefits that definitely used to exist, and maybe still exist, like early access to new features and additional Google Drive storage. But in practice today, the only real benefit is the badge.
I had a popup on my iPhone one day "You were in City Park last weekend, would you like to share those photos?". I stopped allowing google access to my photos after that. A little late though, they had apparently scraped all of my data already.
I had a similar moment a few years ago. That Google Maps pop-up was what caused me to first switch to de-googled Android, and once that turned out to be a hassle after a couple of years, switch to an iPhone without Google stuff. (On Android, Google is a location provider, so blocking their access is much harder.)
True. Sidenote: they are still however push notifications provider, so good luck getting rid of them completely (unless you're fine with not getting the notifications). MicroG is awesome wrt. that as you can turn it on/off as you wish, and it just works. GrapheneOS however only supports Google services in sandbox, but the notifications work sporadically IME (maybe because I keep turning them off and on... not sure). So... Pick your poison.
I don't even have G-apps on my phone. They work fine in a browser, until they don't. I was trying to use streetview yesterday and it would not open in the browser and kept trying to redirect me to the app store. So now they are deliberately borking their webapps to punish those not using native apps.
Yeah, there are lots of pages that don't show the (google) map if you don't have google services enabled on your android phone. Not sure if this is something that could be solved on browser level though? I'm quite certain that these pages still work on iphones...
I suspect there used to be a flow which was far too easy to share directly to Google maps. I was browsing the map once and found a picture of a credit card in a room in a hotel. I guess the guy intended to send it to his PA or something.
I have friends that do that and it’s intentional. Had a good time at a store or restaurant? Take a selfie and upload to Google Maps. Also take a selfie video and upload to Instagram stories. It’s a way of life that defaults to more sharing.
> actually using the geolocation is an extremely niche usecase for images uploaded from mobile browsers
Is it only for mobile browsers? The article makes it sound [0] as if it is a general thing, even when sharing through bluetooth, and that only copying the image via usb connection allows you to keep geolocation in exif. Not sure what happens when you upload to native apps, eg to some cloud storage app (photo specific or not). I definitely want my location to stay when I make a cloud backup of my photos with an app intended for that.
[0] Quote:
>> Using a "Progressive Web App" doesn't work either. So, can users transfer their photos via Bluetooth or QuickShare? No. That's now broken as well. You can't even directly share via email without the location being stripped away. Literally the only way to get a photo with geolocation intact is to plug in a USB cable, copy the photo to your computer, and then upload it via a desktop web browser?
I'm guessing they changed the default behavior from "include metadata" to "strip metadata" so now any app that wants metadata has to request it explicitly, and any older apps which don't know how to make such a request are simply unable to get location data?
Yes, it's about that permission. It's not even that recent, it has been implemented since Android 10. I think it's summarized quite well here [0]:
If your app targets Android 10 (API level 29) or higher and needs to retrieve unredacted EXIF metadata from photos, you need to declare the ACCESS_MEDIA_LOCATION permission in your app's manifest, then request this permission at runtime.
So if the app-developer didn't take explicit effort to request this data (and the user-permission for it), his app will not receive it.
It is absolutely Apple's job to protect people who do not have the desire or capacity to decide what is a good use case or not from predators (yes, the ad industry is 100% predatory).
The whole reason I and my entire family have iPhones is because there are entire classes of scams and scum that you don't have to be constantly vigilant against. If it didn't do that, I wouldn't buy them.
I'm gonna die on this hill, but silently attaching very sensitive PII (including exact lat/lon) to photos has always been a terrible anti-feature. One of those "WTF were they actually thinking?" terrible anti-features. Imagine if you created a word document and Microsoft silently attached your home address to them as metadata. Awful and totally unexpected to the vast majority of users.
I want the location on every time, without exception.
The current behavior is exactly what I wanted.
These "all users are imbeciles that need our protection" design pattern needs to die a swift death.
It's maddening, We're constantly taking kitchen knives and replacing them with the colorful plastic toddler version and still have the same cutting tasks.
I was a fan of the idea that the OS would strip location data on any upload via web/app, but would preserve the data when doing specific types of transfers deemed not via third party like direct transfer to computer or AirDrop
No. Upload file means upload file. If you want to mutate the file, mutate the file.
When tools assume you're stupid and insert silent surprises unrelated to the task they no longer deserve the title "tool" because they are fundamentally doing other things.
Most people have no idea when they upload a “photo” they are also letting anyone know their “location”. On iOS at least, from the browser, you specifically choose whether you want to upload a file from the Files app (that lets you upload files from iCloud, Google Drive, Dropbox or any other storage type service you have installed) or a photo.
Yes and no one who knows how to change an engine should drive a car. This is why geeks make horrible product people and after 30 years geeks are still waiting for “The Year of Linux on the Desktop”.
What you're advocating for is more like the Bluetooth hijacking when you get in a car of transferring your call from you ear piece to your sound system as if you want to blast your phone call to everyone in the parking lot.
Turn on car doesn't mean hijack Bluetooth connection.
About Linux: it won the Unix war, the cloud computing war, the embedded war, and is the most installed OS on the planet.
On that point I would agree - I never used that. But Google also
lied why it wanted to destroy ublock origin. It was clear to
everyone that they did it because people can break away from
ads infiltrating their computers. I can't use the modern www
anymore without general content blocker; ublock lite is good
but nowhere as useful as ublock origin was. I notice this when
I compare e. g. firefox with default chrome. So many websites
have a totally broken UI. With ublock origin not only can I
get rid of popups or ads but also horrible UI choices. I use
that on so many websites to simplify them.
It's a sad story and a fun-looking project but I think Google 100% did the right thing here. Most people have no idea how much information is included in photo metadata, and stripping it as much as possible lines up to how people expect the world to work.
If google really cared about privacy, they wouldn't have moved maps away from a subdomain. now if I want maps to have my location (logical), I need to grant google _search_ my location too.
It's not all-or-nothing; sometimes some people at Google push for some things to improve privacy. Rarely happens when revenue is at stake.
Android used to ask you "do you want to alllow internet access?" as an app permission. Google removed that, as it would stop ads from showing up. Devastating change for privacy and security, great for revenue.
People act like Google products are a charity that had been free forever, and then this mega-corp called Google came along and started harvesting the data of innocent people who just want to get directions to Starbucks.
For those of us stuck on normal android, is there a way to achieve that? I know it used to work with some firewall apps but nowdays they all require root access.
Or you can set your DNS resolver to dns.adguard-dns.com and it blocks almost all ads. You can search "private dns" in Android settings app and set it there.
It looks like you can't revoke the internet permission, but you can use the firewall via ADB. Settings are lost on reboot, but you can use an automation with Tasker or similar to set them on boot:
iOS allows this, but only on mobile data, which is pretty infuriating. Why should I not be able to also restrict apps from dialing home/anywhere just because I'm on a Wi-Fi network (which isn't even necessarily unmetered)?
It's really annoying. I have a sudoku game on my phone, works great but give it internet access and it's suddenly full of sketchy adverts.
If I'm playing it on my commute, it's usable with mobile data disabled for the app. But when the train stops in a station long enough to auto-connect to wifi, immediate full screen adverts :(
Then don’t use an ad supported app? I have one as supported app on my phone - Overcast. The developer created their own ad platform and serves topic based ads based on the podcast you are listening to right now. Ironically enough I started to pay for a subscription even though it didn’t give me any real benefit just to support him until he started having ads.
I’m gonna be That Guy for a minute: if you enjoy using a Sudoku app, isn’t there one available on more acceptable terms, e.g. a single purchase or a IAP that removes the ads from this one? I’m not saying you have to pay like $3.99/week for a scam one, but more like pointing out that if you don’t like ads (as I also don’t) why not support the developers who believe in selling software to you for a few bucks rather than selling your annoyance to Google via Adsense?
You can lock down their usage. Limit it to three months storage and minimize sharing. They still report an old address for home and work for me since I dialed up the restrictions years ago. They have the data but it is less exposed.
I honestly don’t understand the scenario you’re defending against. Google still knows where you actually live and work trivially. If you don’t trust Google you should just de-Google completely.
Not GGP, but I suppose the general idea is: Granting permanent location permission to maps.google.com seems a bit more privacy preserving than granting it to *.google.com, assuming one opens maps significantly less often than e.g. GMail, search etc.
You can probably get around this problem by compressing the file and uploading it in a .zip. Google Files allows for making zip files at least, so I don't think it's a rare feature.
I think the linked spec suggestion makes the most sense: make the feature opt-in in the file picker, probably require the user to grant location permissions when uploading files with EXIF location information.
yeah it does sound kind of dodge that there's no option even for advanced users to bypass this, I would guess mainly a moat to protect Google Photos. I wonder if online photo competitors are finding a workaround or not as searching your photos by location seems like a big feature there
I don't know when Google's EXIF protections are supposed to kick in, but so far my photos auto-synced to Nextcloud still contain location information as expected.
I don't think this has anything to do with Google Photos. People fall victim to doxxing or stalking or even location history tracking by third party apps all the time because they don't realize their pictures contain location information. It's extra confusion to laypeople now that many apps (such as Discord) will strip EXIF data but others (websites, some chat apps) don't.
> It's extra confusion to laypeople now that many apps (such as Discord) will strip EXIF data but others (websites, some chat apps) don't.
You've given me a lot of sympathy for the young'uns whose first experiences on the web might have been with EXIF-safe apps. Then one day they use a web browser to send a photo, and there's an entirely new behavior they've never learned.
Seems like such a shitty thing to victimize the potential victim. But… if you didn’t know that images you took had metadata… maybe you shouldn’t be allowed to use a computer. I mean. I’m going on decades of knowing this. Feel like there is a mid 90s X-Files episode that even like breaks this down. If not NCIS or some shit.
Even people who know it, don't think about it and don't connect it with the potential consequences of uploading a picture to a website. And why would they? It's not visible, there's no warning, it's just not something that's going to be top of mind.
I said that people who already know don't think about it. That's not something you can solve by educating them more. When I'm sharing a photo, I am going to think about what I can see in the photo as a data risk, not the invisible stuff that I might intellectually have heard about. It's just not going to come to mind.
People who know about phishing get got by phishing attacks, too. How well has however many years of "cyber awareness training" gone?
You're right - this is a shitty view on this. It's incredibly opaque that images secretly contain the GPS coordinates of where they were taken. There's no way that's obvious or intuitive.
I think the 'ideal' thing to do would be an opt-in toggle for sharing "location and other extended info" for photos when selecting them, but I'm sure you can understand why a dev team took a shortcut to solve the immediate pain for most users most of the time.
When you upload the photo, at risk of great confusion they could essentially watermark the photo or add a banner showing the location and perhaps some of the other key details, like camera model, right on the photo so it would at least get across to the user that there is an association between these two things that needs to be disabled.
To dismiss the banner you'd have to click a dismiss button which would ask you to confirm that you want to get rid of the location data completely. Then there would be a tiny little button that says “hide this location inside the photo, where I can't see it easily, but everyone totally could”. (But less stupid.)
It would be terrible because there would be huge support threads on why it's trying to share an image with an overlay, but it would get it across. Would be a different failure mode for user privacy than what you would have with a text prompt or an interstitial or whatever.
This kills an entire class of useful crowdsourcing web apps though. Just off the top of my head, contributing to OSM is much easier when you can just take a bunch of photos and see them displayed on a map.
100% agreed; people generally don't realize how deanonymizing EXIF data can be.
I remember one of my cameras or phones including a "seconds since device startup" counter; together with the exact time the photo was taken, this yields a precise timestamp of when a phone was last restarted. This by itself can be highly deanonymizing out of a small to medium sized set of candidate phones/photographers.
True, but isn't it irrational to continue operating something you know could cause harm to you when used wrongly, despite not knowing how to use it correctly?
The hypothetical person we're considering does have an entire life, too. Their rationale may have emerged from careful risk analysis and weighing of opportunity costs.
I agree with you. The next steps should be to disable the internet nationwide like North Korea. People have no idea how much bad things are there. Also I don't like fun things.
In a similar move (silently changing a feature crucial to some users), in Android 11 Google suddenly removed the possibility to use "special" characters
":<>?|\*
in filenames[0], presumably because they're not allowed on Windows/NTFS and Windows users might end up struggling to transfer them to their Windows computer. I don't care about NTFS at all, though. I just want to be able to sync all my files with my Linux machines and now I'm no longer able to. Makes me want to scream.
I have a personal convention that all files I put into my synced folder must consist of lowercase alphanumeric characters, hyphens and periods (to be precise, match the regex /\.?([a-z0-9]([-.][a-z0-9])?)+/). It saves a lot of pain.
Yes and who needs Dropbox since for a Linux user, you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem. From Windows or Mac, this FTP account could be accessed through built-in software.
This is a common approach to "privacy" taken by orgs like Google.
You don't get to access or export your own data in order to protect your privacy, but Google still gets 100% access to it.
Some messaging apps do the same and won't let you take a screenshot of your own conversations. Like, someone sent me an address, but I can't take a screenshot to "protect my privacy".
Imagine my surprise when I attempted to record the iPhone mirroring application, which was running on macOS. Apple did a great job on their DRM because I simply recorded a black screen while I was attempting to play back a video from an app on the phone.
I'm sure it's given some businesses the confidence to invest in iOS app development, but it felt bad.
Yes, or a video editing app that wants you to buy it.
I'm not _entirely_ upset Apple is encouraging the market to develop high-quality solutions by allowing them to protect their revenue.
But it felt bad as if they were reaching into my Mac.
My iPhone is Apple’s playground. They let me use it. But I own my Mac, and if my eyes see something on the screen it feels dumb to send Tim Apple and Reed Hastings into my homeoffice telling me “no no get a capture card(?) or set up a DSLR to record your screen. But no direct recording big guy!”
Which messaging apps are those? I have only seen such behavior for one-time photos, where it makes sense (although one-time photos are security theater because nothing prevents you from taking a photo of the screen with another device).
In a very similar situation to OP, this move totally broke a volunteer-run platform that allows (allowed...) users to report issues with bicycle lanes, missing racks, dangerous spots for cyclists etc...
The app is very basic, but has amazingly little barriers to entry. Notably you don't need an account to just report things, what I'd call an "open door" app.
Sadly, without gps exif, this is much higher friction now. Pretty pissed at this. It's not hard to design a clean flow that permits to inform the user specifically of location sharing in the picker.
Similarly, the native Android photo picker strips the original filename.
This causes daily customer support issues, where people keep asking the app developer why they're renaming their files.
Obviously an image picker shouldn't leak filenames... The filename is a property of the directory entry storing the file storing the image. The image picker only grants access to the image, not to directories, directory entries or files.
If you want filenames, you need to request access to a directory, not to an image
There are many, many more cases where the user doesn’t expect the name to become public when he sends a photo. If I send you a photo of a friend that doesn’t mean I want you to know his name (which is the name I gave the file when I saved it)
From a technological standpoint, sure. I'd argue when you're staring down the barrel of 19,234 duplicate file deletions, with names like `image01.jpg`, `image02.jpg` instead of `happy_birthday.jpg`, there's a level of perceptual cognitive trust there that I just can't provide.
If your camera (or phone) uses the DCF standard [0], you will eventually end up with duplicates when you hit IMG_9999.JPG and it loops around to IMG_0001.JPG. Filename alone is an unreliable indicator.
Which systems still use this shortsighted convention? All photos I’ve taken with the default camera app in the last many years are named with a timestamp.
This a very weird set of choices by Google. How many users are uploading photos from their camera to their phone so they can then upload them from the phone to the web?
I bet almost 100% of photo uploads using the default Android photo picker, or the default Android web browser, are of photos that were taken with the default Android camera app. If Google feels that the location tags and filenames are unacceptably invasive, it can stop writing them that way.
My phone: my private space. Anything in the browser: not my private space.
I want exactly that: the OS to translate between that boundary with a sane default. It’s unavoidable to have cases where this is inconvenient or irritating.
I don’t even know on iPhone how files are named “internally” (nor do I care), since I do not access the native file system or even file format but in 99% of all use cases come in contact only with the exported JPEGs. I do want to see all my photos on a map based on the location they were taken, and I want a timestamp. Locally. Not when I share a photo with a third party.
> If Google feels that the location tags and filenames are unacceptably invasive, it can stop writing them that way.
Something can be "not invasive" when only done locally, but turn out to be a bad idea when you share publicly. Not hard to imagine a lot of users want to organize their libraries by location in a easy way, but still not share the location of every photo they share online.
> Not hard to imagine a lot of users want to organize their libraries by location in a easy way, but still not share the location of every photo they share online.
The location isn't just embedded in the EXIF tags. It's also embedded in the visual content.
I imagine people will get tired of their image uploads being blacked out pretty quickly.
> How many users are uploading photos from their camera to their phone so they can then upload them from the phone to the web?
To _their phone_ specifically? Probably almost nobody. But to their Google/Apple Photos library?
A lot, if not most of people who use DSLRs and other point-and-shoot cameras. Most people want a single library of photos, not segregated based on which device they shot it on.
Yep, and having location data is really useful for organizing said photos.
I think it's really neat Google Photos lets you see all photos taken at a particular location. One of my pet peeves is when friends share photos with me that we took together at a gathering and only the ones I took with my phone show up in that list unless I manually add location data. (Inaccurate timestamps are an even more annoying related issue.)
I use to send pictures over the camera wifi from my Sony W500 to my phone. The main purpose is backup (think I'm in the middle of nowhere or with little internet for days) and then to send them to friends with WhatsApp. If I'm at home I pull the SD card and read it from my laptop. It's quicker.
I don't know, a quick check in Android documentation seems to describe this quite well [0]:
If your app targets Android 10 (API level 29) or higher and needs to retrieve unredacted EXIF metadata from photos, you need to declare the ACCESS_MEDIA_LOCATION permission in your app's manifest, then request this permission at runtime.
Caution: Because you request the ACCESS_MEDIA_LOCATION permission at runtime, there is no guarantee that your app has access to unredacted EXIF metadata from photos. Your app requires explicit user consent to gain access to this information.
I made another quick check on my device, Chrome doesn't have the ACCESS_MEDIA_LOCATION permission and doesn't seem to request it at runtime, so the location info is stripped from the EXIF data when a file is selected.
Chromium also seems have no feature to ask the user whether he agrees to share the stored location when uploading images, so there is probably no capability to request the permission at runtime.
Not satisfying, I know, but despite some judgements in the tickets the implementation seems to work as designed.
Instead, it could be considered a feature-request for Chrome to ask the user about this on upload, or couple the location-permission of a website to the permission to share EXIF-location data when uploading files (Although I think the logic on that is not really tight, the user giving permission to share his location now doesn't necessarily mean that he agrees to share all his locations from the past from EXIF-data)
I wish they'd just switch to fuzzing the location instead of stripping it entirely. Instead of specifying 6 digits of lat/lon, publish 1 digit to identify what rough area you're in (to about 10km).
I've done a lot of neat projects with geolocation over the years. Including a personal travel diary, a bunch of visualizations of tweets and Flickr photos, etc etc. I am sad that's become nearly impossible but I do respect that most people don't understand the privacy risk.
Meanwhile on the advertising backend Google knows your exact location and is using it to help third parties target ads to you. And sleazy apps like Grindr sell location streams to anyone who asks. The bad guys get this data, just not the useful apps.
Depending on how populated your current location is, even a fuzzed location can reveal personal information. In a city, 10km is fine, nobody is identified. But if your home is the only one for 10km in any direction, and your fuzzing threshold is 10km, you've identified down to a single home.
Totally disagree, as I think that would be the worst of all possible worlds - too fuzzy to be useful for many of the niche use cases where it's needed, and still a privacy violation for the majority of users who don't know their photos reveal their location.
The other suggestion about requiring something like a useLocation or includeExif attribute on the file picker, and then requiring confirmation from the user, seems like a much better solution to me.
This is the right move. https://github.com/whatwg/html/issues/11724#issuecomment-419... and adding a feature to browsers to explicitly use the info is the best solution really. The problem is that there was a change without a backup solution without making a native app, but preventing people from accidentally uploading their location in an image is the right move. It really needs to be more well known and handled automatically.
While I think it's the right move to disable location tags by default, I also think Google should've waited until a solution to the missing functionality had at least hit the WHATWG spec.
Yes, I get it. It is inconvenient for legitimate uses. The problem is that our devices leak too much confidential data. Privacy was mentioned outright in the article. Safety/security was alluded to with an example, which is something that goes far beyond a company's image or even liability.
Unfortunately, there is no good way to solve the problem while maintaining convenience. As the author noted, prompts while uploading don't really work. Application defaults don't really work for web browsers, since what is acceptable for one website isn't necessarily acceptable for another. Having the user enter the location through the website make the user aware of the information being disclosed, but it is inconvenient.
Does the situation suck? Yes. On the other hand, I think Google is doing the responsible thing here.
Agreed. The default for a web browser should be maximum privacy/minimum sharing/minimum trust. If they want to access photos with geolocation they can make an app instead of a website, then the app can explictly ask for this permission. Too much trouble? Well then I guess it won't get done. Not the end of the world.
Location data should be opt in on capture, a checkbox deep in the settings: "capture location meta data" would be sufficient, or a button similar to the flash.
Strange UI that they are involuntarily capturing but then removing it.
I don't know a good solution for this. 99% of websites asking for this hypothetical permission would not deserve it. Users (rightfully) don't expect that uploading a photo leaks their location.
Element (the matrix client) used to not strip geolocation metadata for the longest time. I don't know if they fixed that yet.
I used to run a small website that allowed users to upload pictures. Most people were not aware that they were telling me where they were, when the picture was taken, their altitude, which direction they were facing, etc.
I noticed this in an app's changelog recently, saying something along the lines of "remove metadata comparison function because new Android versions no longer support it"
Thankfully F-Droid has a "never update this app" checkbox for now, but eventually I'm sure third-party developers will require minimum Android versions that mean I need to lose this functionality :/
I don't like this. The Right Thing is for camera apps to not add location metadata by default.
If you go in and turn location on (which should have a warning on it), then you're the sort of person who changes defaults, a more sophisticated user than the majority of the population who is able to take responsibility for the consequences. Yes, I can imagine a scenario where someone ends up with this setting turned on through no fault of their own, but it shouldn't be the role of an OS vendor to prevent every possible mistake.
The default camera app has this off by default. Most of the ones I've tried do.
But do you remember every options you've randomly toggled over the years? It's pretty easy to see how someone would flip on geotagging, forget about it, then be shocked a few months later when they discover all their photos are leaking their location.
defaulting to strip location on share, fine. demoting plain old <input type=file> into "find a usb cable" / "go build an app" is a hell of a line to draw
>So, can users transfer their photos via Bluetooth or QuickShare? .. Literally the only way to get a photo with geolocation intact is to plug in a USB cable
Bluetooth is not QuickShare, stop conflating them. Bluetooth works. I just tried it. It just sends the entire file to the destination, filename intact with all EXIF, no gimmicks, tricks, or extra toggles. As it has always done for 20+ years.
In my testing, when sharing from apps that use MediaStore like Google Photos or Fossify Gallery (using a `content://media/` URI), the GPS location was stripped even via Bluetooth. This seems to be the default behavior from Android 10 onwards.
On Android 16. Open photo. Hit share. Hit Bluetooth. Pick a device to send it to. Wait for xfer to finish. Observe in exifview. What detail is missing?
Already use imagepipe [0] since forever, sometimes it takes soms extra time, still worth the effort. Most of the time I take a picture share with imagepipe, share with external and don't share anything else
I will never share my location via images with anybody then myself. I do use location for my local Photoprism on my own server
> If anyone has a working way to let Android web-browsers access the full geolocation EXIF metadata of photos uploaded on the web, please drop a comment in the box.
No. I don't want people like you unknowingly spying on me when I upload a picture. GrapheneOS patched that insane behavior long ago, but not including leaky metadata should be the default, sane behavior.
GrapheneOS already does this, since forever. Android can't stop copying GOS. Maybe they'll add a network toggle after a few years and call it a privacy win.
You can choose whether you want to share the location or not when selecting photos in iOS. You'll see at the bottom a label that says "Location is included", and you can click the three dots to remove location:
I know which one works better for us. Which works better for grandma?
(Of course, Google's move shouldn't have been altruistic, it would have been pragmatic as mentioned elsewhere.)
If I got paid a nickel every time someone talked about protecting children online and I reinvested it into technology accessibility for seniors, it'd be fully funded! :)
Now, I don't fully understand why people want their images
to be tracked - but to each their own. I think this just
shows that Google is very selfish, from A to Z. People
should not empower this evil empire. Recently Google also
stated that "cookies can not be stolen":
However had to me this reads as "we control the now private
web". This also aligns, in my opinion, with age verification
(systemd already pushes for it). So we move into a not so open
world wide web. Are you identified? If yes, you can get information;
if no you can not. Personally I am in the underground anyway, as
long-term linux users so I don't really care that much (though I
also use Win10 on a computer on my left side, for various reasons).
But I am really annoyed at Google. Every day Google adds to problems
and drama. It is not good that this monopoly can control so much
in the whole ecosystem, even if I don't understand why people want
to share photos and geolocation and what underwear they were wearing
at that moment in time ...
> But it is just so tiresome that Google never consults their community. There was no advance notice of this change that I could find. Just a bunch of frustrated users in my inbox blaming me for breaking something.
I get it. This unequivocally sucks. It's a clear loss of functionality for a group of people who are educated about the advantages and disadvantages of embedded EXIF data. But I don't honestly think Google could have consulted their community. It's just too big. So when the author says:
> Because Google run an anticompetitive monopoly on their dominant mobile operating system.
I don't think the problem here is that Google is anticompetitive (though that's a problem in other areas). I think it's just too big that they can't possibly consult with any meaningful percentage of their 1 billion customers (or however many Android users are out there). They may also feel it's impossible to educate their users about the benefits and dangers of embedded location information (just thinking about myself personally, I'm certain that I'd struggle to convey they nuances of embedded location data to my parents).
I will note that Google Photos seems to happily let you add images to shared albums with embedded location information. I can't recall if you get any privacy-related warnings or notices.
> But I don't honestly think Google could have consulted their community. It's just too big.
The thing is, they frequently do. They have developer relations people, they publish blog posts about breaking changes, they work with W3C and other standards bodies, they reply on bug trackers.
But, in this case, nothing. Just a unilateral change with no communication. Not even a blog posts saying "As of April, this functionality is deprecated."
Yes. You can turn it off for Camera if you don't want the geotag to be included in the photo when taken. You can also, as part of the share media picker, opt to include or exclude location data on the photo.
Yeah, toggling in any manner you see fit (a Shortcut would be useful in this case) the location services in its totality or in the context of the Camera app would accomplish the same result.
Pretty good. I played a bit with gpt-4 a year or so ago by feeding it random screenshots from Google street view. It will pick up a lot of subtle hints from what otherwise looks like generic streets. I imagine more recent models might be better at this now.
I wonder if that might be another reason to just completely disable this feature and not make it a permission: otherwise people could use it to build trainingsets for geoguesser models.
Surprisingly iOS doesn't do this - at least not for photos uploaded via a web form these days. Try this tool to see that (it should demonstrate the Android EXIF stripping behavior too): https://tools.simonwillison.net/exif
iOS does this by default too, but it tells you about it and gives you the option to not strip the location from EXIF: the bottom of the photo picker has the text "Location not included", and the context menu opened by the "..." button on the left has a "Location" toggle. Just tested this myself on iOS 26.4.1.
Does the location messaging also feel more prominent to you from the Photos share sheet compared to the native image file picker? For example, that you would see when uploading to the ImgUr site.
Mainly top versus bottom placement, I think, but also font size.
I just tested this and the default setting is to include location, but once turned off it stays off (unlike the iPhone share sheet where you need to turn it off each time).
Couldn't you use <input type="file" accept=".jpg,.jpeg"> (different than image/jpeg mime-type I think, not sure if that also strips EXIF?), then manually parse the EXIF in JS? Shouldn't be that complicated to parse and I'm guessing there is a bunch of libraries for doing just that should you not want to do that yourself.
Which correctly seems to show the EXIF for uploaded images (both in Chrome and Firefox), and correctly filters things in the file picker window. What am I missing, why is this infeasible as a solution?
I’d wager 99.9% of the users didn’t realize that they are effectively sending their live GPS coords to a random website when taking a photo.
But yes, a prop to the input tag ’includeLocation’ which would then give the user some popup confirmation prompt would have been nice
I coulda sworn, even in earlier versions of iOS 26, if you told it not to include location when sending a photo once then it would not include it by default the next time.
Also I thought that when you uploaded a photo from your camera roll to the web I thought it defaulted to no location. And that seems to have changed too. (Of course, you can still tap a button to withhold location EXIF.)
But in the real world, if you put a QR code at the trailhead and said "take a picture of this code. When you see a tortoise nest, use the code to go to our website and share your exact location."
If people are wary of sharing their location with the conservation agency, you might have better luck if the website was run by a nongovernmental conservation group?
What made the data junk? Were the provided coordinates not precise enough, incorrect, something else?
I'd wager 90% of the photos on Google Maps associated with various listings don't actually know their photos are in public. I keep coming across selfies and other photos that look very personal, but somehow someone uploaded to Google Maps, the photo is next to a store or something and Google somehow linked them together, probably by EXIF.
I sometimes do that for random pictures, even like selfies, which I don't mind popping up there.
You review the photo and go "lol, sure".
At least for me that doesn't even feel like posting due to how frictionless it is and that it's about natural discoverability (someone has to click that POI and scroll through photos to find it).
https://www.localguidesconnect.com/t/e-mail-from-google-cong...
What exactly does that mean though? Is there any benefits to it? All I see is a badge/label, that's it?
https://grapheneos.org/features#network-location
Their approach encompasses GNSS location, too. Nothing Google required.
Is it only for mobile browsers? The article makes it sound [0] as if it is a general thing, even when sharing through bluetooth, and that only copying the image via usb connection allows you to keep geolocation in exif. Not sure what happens when you upload to native apps, eg to some cloud storage app (photo specific or not). I definitely want my location to stay when I make a cloud backup of my photos with an app intended for that.
[0] Quote:
>> Using a "Progressive Web App" doesn't work either. So, can users transfer their photos via Bluetooth or QuickShare? No. That's now broken as well. You can't even directly share via email without the location being stripped away. Literally the only way to get a photo with geolocation intact is to plug in a USB cable, copy the photo to your computer, and then upload it via a desktop web browser?
Seems like this is possibly related to the ACCESS_MEDIA_LOCATION permission[1], and Google's recent efforts to force applications to migrate to the scoped storage API. See: https://developer.android.com/training/data-storage/shared/m...
Probably someone more versed in Android's APIs could give a better explanation.
[1]: https://developer.android.com/reference/android/Manifest.per...
If your app targets Android 10 (API level 29) or higher and needs to retrieve unredacted EXIF metadata from photos, you need to declare the ACCESS_MEDIA_LOCATION permission in your app's manifest, then request this permission at runtime.
So if the app-developer didn't take explicit effort to request this data (and the user-permission for it), his app will not receive it.
[0] https://developer.android.com/training/data-storage/shared/m...
Can you compress a folder with a photo it and then email that? Just curious.
Phones are computers though, it’s not up to Google or Apple to decide what’s a good use case for my own pictures.
The whole reason I and my entire family have iPhones is because there are entire classes of scams and scum that you don't have to be constantly vigilant against. If it didn't do that, I wouldn't buy them.
The current behavior is exactly what I wanted.
These "all users are imbeciles that need our protection" design pattern needs to die a swift death.
It's maddening, We're constantly taking kitchen knives and replacing them with the colorful plastic toddler version and still have the same cutting tasks.
No. Upload file means upload file. If you want to mutate the file, mutate the file.
When tools assume you're stupid and insert silent surprises unrelated to the task they no longer deserve the title "tool" because they are fundamentally doing other things.
Turn on car doesn't mean hijack Bluetooth connection.
About Linux: it won the Unix war, the cloud computing war, the embedded war, and is the most installed OS on the planet.
I have not seen an ad in years.
As per op, it seems they've shut down _any_ means for you to get the data out of the phone other than using a USB cable.
Android used to ask you "do you want to alllow internet access?" as an app permission. Google removed that, as it would stop ads from showing up. Devastating change for privacy and security, great for revenue.
People act like Google products are a charity that had been free forever, and then this mega-corp called Google came along and started harvesting the data of innocent people who just want to get directions to Starbucks.
https://blokada.org/
https://www.reddit.com/r/tasker/comments/1mxjnvs/how_to_bloc...
If I'm playing it on my commute, it's usable with mobile data disabled for the app. But when the train stops in a station long enough to auto-connect to wifi, immediate full screen adverts :(
I’ve found a lot of useful podcasts from the ads.
Something that is very useful to 1% of users is stripped away. And we end up with dumb appliances (and ironically - most likely still no privacy )
I think the linked spec suggestion makes the most sense: make the feature opt-in in the file picker, probably require the user to grant location permissions when uploading files with EXIF location information.
I don't think this has anything to do with Google Photos. People fall victim to doxxing or stalking or even location history tracking by third party apps all the time because they don't realize their pictures contain location information. It's extra confusion to laypeople now that many apps (such as Discord) will strip EXIF data but others (websites, some chat apps) don't.
> It's extra confusion to laypeople now that many apps (such as Discord) will strip EXIF data but others (websites, some chat apps) don't.
You've given me a lot of sympathy for the young'uns whose first experiences on the web might have been with EXIF-safe apps. Then one day they use a web browser to send a photo, and there's an entirely new behavior they've never learned.
Wouldn't it be better if people were more tech-literate?
Coddling only works when those who are in charge of the tech play nice. But then breeds people who will more easily fall victim to the bad actors.
People who know about phishing get got by phishing attacks, too. How well has however many years of "cyber awareness training" gone?
I think the 'ideal' thing to do would be an opt-in toggle for sharing "location and other extended info" for photos when selecting them, but I'm sure you can understand why a dev team took a shortcut to solve the immediate pain for most users most of the time.
To dismiss the banner you'd have to click a dismiss button which would ask you to confirm that you want to get rid of the location data completely. Then there would be a tiny little button that says “hide this location inside the photo, where I can't see it easily, but everyone totally could”. (But less stupid.)
It would be terrible because there would be huge support threads on why it's trying to share an image with an overlay, but it would get it across. Would be a different failure mode for user privacy than what you would have with a text prompt or an interstitial or whatever.
I remember one of my cameras or phones including a "seconds since device startup" counter; together with the exact time the photo was taken, this yields a precise timestamp of when a phone was last restarted. This by itself can be highly deanonymizing out of a small to medium sized set of candidate phones/photographers.
Its better to do it from the source, obviously.
This sounds like a downward spiral concerning freedom.
[0]: https://github.com/GrapheneOS/os-issue-tracker/issues/952
You don't get to access or export your own data in order to protect your privacy, but Google still gets 100% access to it.
Some messaging apps do the same and won't let you take a screenshot of your own conversations. Like, someone sent me an address, but I can't take a screenshot to "protect my privacy".
I'm sure it's given some businesses the confidence to invest in iOS app development, but it felt bad.
I'm not _entirely_ upset Apple is encouraging the market to develop high-quality solutions by allowing them to protect their revenue.
But it felt bad as if they were reaching into my Mac.
My iPhone is Apple’s playground. They let me use it. But I own my Mac, and if my eyes see something on the screen it feels dumb to send Tim Apple and Reed Hastings into my homeoffice telling me “no no get a capture card(?) or set up a DSLR to record your screen. But no direct recording big guy!”
https://app.vigilo.city/
The app is very basic, but has amazingly little barriers to entry. Notably you don't need an account to just report things, what I'd call an "open door" app. Sadly, without gps exif, this is much higher friction now. Pretty pissed at this. It's not hard to design a clean flow that permits to inform the user specifically of location sharing in the picker.
https://issuetracker.google.com/issues/268079113 Status: Won't Fix (Intended Behavior).
If you want filenames, you need to request access to a directory, not to an image
There are plenty of use cases where the filename is relevant (and many, many people intentionally use the image name for sorting / cataloging).
/User/user/Images/20240110/happy_birthday.jpg
and
/User/user/Desktop/happy_birthday.jpg
are the same image.
Not impossible, just different and arguably better - comparing hashes is a better tool for finding duplicates.
[0]: https://en.wikipedia.org/wiki/Design_rule_for_Camera_File_sy...
Almost all cameras create a new directory, e.g. DSC002, and start from IMG_0001 to prevent collision.
I bet almost 100% of photo uploads using the default Android photo picker, or the default Android web browser, are of photos that were taken with the default Android camera app. If Google feels that the location tags and filenames are unacceptably invasive, it can stop writing them that way.
I want exactly that: the OS to translate between that boundary with a sane default. It’s unavoidable to have cases where this is inconvenient or irritating.
I don’t even know on iPhone how files are named “internally” (nor do I care), since I do not access the native file system or even file format but in 99% of all use cases come in contact only with the exported JPEGs. I do want to see all my photos on a map based on the location they were taken, and I want a timestamp. Locally. Not when I share a photo with a third party.
The word default is more appropriately used when the decision can be changed to something the user finds more suitable for their usecase
Google’s main business is ads, ie running hostile code on your machine.
Something can be "not invasive" when only done locally, but turn out to be a bad idea when you share publicly. Not hard to imagine a lot of users want to organize their libraries by location in a easy way, but still not share the location of every photo they share online.
The location isn't just embedded in the EXIF tags. It's also embedded in the visual content.
I imagine people will get tired of their image uploads being blacked out pretty quickly.
To _their phone_ specifically? Probably almost nobody. But to their Google/Apple Photos library?
A lot, if not most of people who use DSLRs and other point-and-shoot cameras. Most people want a single library of photos, not segregated based on which device they shot it on.
I think it's really neat Google Photos lets you see all photos taken at a particular location. One of my pet peeves is when friends share photos with me that we took together at a gathering and only the ones I took with my phone show up in that list unless I manually add location data. (Inaccurate timestamps are an even more annoying related issue.)
- have a local backup - being able to see them from a larger screen - being able to share them - sync them to home while I am away
I don't upload anything to google photos or apple cloud.
If your app targets Android 10 (API level 29) or higher and needs to retrieve unredacted EXIF metadata from photos, you need to declare the ACCESS_MEDIA_LOCATION permission in your app's manifest, then request this permission at runtime.
Caution: Because you request the ACCESS_MEDIA_LOCATION permission at runtime, there is no guarantee that your app has access to unredacted EXIF metadata from photos. Your app requires explicit user consent to gain access to this information.
I made another quick check on my device, Chrome doesn't have the ACCESS_MEDIA_LOCATION permission and doesn't seem to request it at runtime, so the location info is stripped from the EXIF data when a file is selected.
Chromium also seems have no feature to ask the user whether he agrees to share the stored location when uploading images, so there is probably no capability to request the permission at runtime.
Not satisfying, I know, but despite some judgements in the tickets the implementation seems to work as designed.
Instead, it could be considered a feature-request for Chrome to ask the user about this on upload, or couple the location-permission of a website to the permission to share EXIF-location data when uploading files (Although I think the logic on that is not really tight, the user giving permission to share his location now doesn't necessarily mean that he agrees to share all his locations from the past from EXIF-data)
[0] https://developer.android.com/training/data-storage/shared/m...
I've done a lot of neat projects with geolocation over the years. Including a personal travel diary, a bunch of visualizations of tweets and Flickr photos, etc etc. I am sad that's become nearly impossible but I do respect that most people don't understand the privacy risk.
Meanwhile on the advertising backend Google knows your exact location and is using it to help third parties target ads to you. And sleazy apps like Grindr sell location streams to anyone who asks. The bad guys get this data, just not the useful apps.
The other suggestion about requiring something like a useLocation or includeExif attribute on the file picker, and then requiring confirmation from the user, seems like a much better solution to me.
Unfortunately, there is no good way to solve the problem while maintaining convenience. As the author noted, prompts while uploading don't really work. Application defaults don't really work for web browsers, since what is acceptable for one website isn't necessarily acceptable for another. Having the user enter the location through the website make the user aware of the information being disclosed, but it is inconvenient.
Does the situation suck? Yes. On the other hand, I think Google is doing the responsible thing here.
Strange UI that they are involuntarily capturing but then removing it.
Element (the matrix client) used to not strip geolocation metadata for the longest time. I don't know if they fixed that yet.
I used to run a small website that allowed users to upload pictures. Most people were not aware that they were telling me where they were, when the picture was taken, their altitude, which direction they were facing, etc.
Thankfully F-Droid has a "never update this app" checkbox for now, but eventually I'm sure third-party developers will require minimum Android versions that mean I need to lose this functionality :/
Edit: found it, it was VesIC https://github.com/VincentEngel/VES-Image-Compare/releases/t...
If you go in and turn location on (which should have a warning on it), then you're the sort of person who changes defaults, a more sophisticated user than the majority of the population who is able to take responsibility for the consequences. Yes, I can imagine a scenario where someone ends up with this setting turned on through no fault of their own, but it shouldn't be the role of an OS vendor to prevent every possible mistake.
But do you remember every options you've randomly toggled over the years? It's pretty easy to see how someone would flip on geotagging, forget about it, then be shocked a few months later when they discover all their photos are leaking their location.
Bluetooth is not QuickShare, stop conflating them. Bluetooth works. I just tried it. It just sends the entire file to the destination, filename intact with all EXIF, no gimmicks, tricks, or extra toggles. As it has always done for 20+ years.
https://developer.android.com/training/data-storage/shared/m...
> Photographs > If your app uses scoped storage, the system hides location information by default
When sharing via FileProvider from file managers like MiXplorer or Total Commander, the raw file is sent as is, and the GPS location stays intact.
I don't know how modern your Android phone is, but on all of mine sharing via Bluetooth strips away some of the EXIF.
I'm pretty sure this is what happens in the iPhone at least, so I'd imagine it is the same in Android.
I will never share my location via images with anybody then myself. I do use location for my local Photoprism on my own server
0 https://codeberg.org/Starfish/Imagepipe#how-to-get-the-app
No. I don't want people like you unknowingly spying on me when I upload a picture. GrapheneOS patched that insane behavior long ago, but not including leaky metadata should be the default, sane behavior.
Well that's a good thing, isn't it?
Who knows, it may eventually be only available on Motorola devices.
https://imgur.com/a/lm0stDE
Not sure if there's a way to do that by default, I've never checked.
Wish android copied them for once lol
(Of course, Google's move shouldn't have been altruistic, it would have been pragmatic as mentioned elsewhere.)
If I got paid a nickel every time someone talked about protecting children online and I reinvested it into technology accessibility for seniors, it'd be fully funded! :)
https://www.heise.de/en/news/Google-Chrome-makes-cookie-thef...
However had to me this reads as "we control the now private web". This also aligns, in my opinion, with age verification (systemd already pushes for it). So we move into a not so open world wide web. Are you identified? If yes, you can get information; if no you can not. Personally I am in the underground anyway, as long-term linux users so I don't really care that much (though I also use Win10 on a computer on my left side, for various reasons). But I am really annoyed at Google. Every day Google adds to problems and drama. It is not good that this monopoly can control so much in the whole ecosystem, even if I don't understand why people want to share photos and geolocation and what underwear they were wearing at that moment in time ...
I get it. This unequivocally sucks. It's a clear loss of functionality for a group of people who are educated about the advantages and disadvantages of embedded EXIF data. But I don't honestly think Google could have consulted their community. It's just too big. So when the author says:
> Because Google run an anticompetitive monopoly on their dominant mobile operating system.
I don't think the problem here is that Google is anticompetitive (though that's a problem in other areas). I think it's just too big that they can't possibly consult with any meaningful percentage of their 1 billion customers (or however many Android users are out there). They may also feel it's impossible to educate their users about the benefits and dangers of embedded location information (just thinking about myself personally, I'm certain that I'd struggle to convey they nuances of embedded location data to my parents).
I will note that Google Photos seems to happily let you add images to shared albums with embedded location information. I can't recall if you get any privacy-related warnings or notices.
The thing is, they frequently do. They have developer relations people, they publish blog posts about breaking changes, they work with W3C and other standards bodies, they reply on bug trackers.
But, in this case, nothing. Just a unilateral change with no communication. Not even a blog posts saying "As of April, this functionality is deprecated."
As one can imagine, even when turning location services back on, the photo will never contain location data.
[0] https://www.bellingcat.com/resources/2025/08/14/llms-vs-geol...
Mainly top versus bottom placement, I think, but also font size.
Anyways, I did this: https://jsbin.com/teriduyexe/edit?html,output
Which correctly seems to show the EXIF for uploaded images (both in Chrome and Firefox), and correctly filters things in the file picker window. What am I missing, why is this infeasible as a solution?