This must be a Chrome thing, not an Android thing, no? I didn't test this but I'd be surprised if Firefox behaved the same.
fouc•Apr 13, 2026
Or Firefox would still be using android's file system / upload process, which probably hands off the photos with geotags stripped already.
I'm pretty sure this is what happens in the iPhone at least, so I'd imagine it is the same in Android.
darkhorn•Apr 13, 2026
Just tested with Firefox 149 on Android 13. There are no coordinates when I upload an image to EXIF viewer web sites.
iamcalledrob•Apr 13, 2026
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.
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.
embedding-shape•Apr 13, 2026
> 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.
eru•Apr 13, 2026
Definitely. I want to be able to search my Google Photos for "Berlin" and get me all the pictures I took there.
thaumasiotes•Apr 13, 2026
> 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.
47282847•Apr 13, 2026
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.
TheLNL•Apr 13, 2026
It is not just a default when it is the only option.
The word default is more appropriately used when the decision can be changed to something the user finds more suitable for their usecase
username223•Apr 13, 2026
> Anything in the browser: not my private space.
Google’s main business is ads, ie running hostile code on your machine.
klausa•Apr 13, 2026
> 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.
pmontra•Apr 13, 2026
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.
prmoustache•Apr 13, 2026
I do it all the time for different reasons:
- 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.
Ajedi32•Apr 13, 2026
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.)
lifis•Apr 13, 2026
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
butlike•Apr 13, 2026
The path is different than the filename though. If I want to find duplicates, it will be impossible if the filename changes. In my use case
/User/user/Images/20240110/happy_birthday.jpg
and
/User/user/Desktop/happy_birthday.jpg
are the same image.
dns_snek•Apr 13, 2026
> it will be impossible if the filename changes.
Not impossible, just different and arguably better - comparing hashes is a better tool for finding duplicates.
morissette•Apr 13, 2026
^ facts
butlike•Apr 13, 2026
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.
tart-lemonade•Apr 13, 2026
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.
Almost all cameras create a new directory, e.g. DSC002, and start from IMG_0001 to prevent collision.
xigoi•Apr 13, 2026
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.
Barbing•Apr 13, 2026
iOS 26
adolph•Apr 13, 2026
> If I want to find duplicates, it will be impossible if the filename changes.
Depends on what is meant by a "duplicate." It would be a good idea to get a checksum of the file, which can detect exact data duplicates, but not something where metadata is removed or if the image was rescaled. Perceptual hashing is more expensive but is better distinguish matches between rescaled or cropped images.
There are plenty of use cases where the filename is relevant (and many, many people intentionally use the image name for sorting / cataloging).
nslsm•Apr 13, 2026
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)
bornfreddy•Apr 13, 2026
So in webmail, when you upload an image / file to attach it to an email, you expect it to be renamed? I don't.
sib•Apr 13, 2026
I email images as attachments very, very frequently. I go through the browser's file picker and I pick out the photo by its filename. I would be surprised and angry if somewhere along the way the filename got changed to some random string without my knowledge and consent.
In fact, I often refer to the name of the photo in the body of the email (e.g., "front_before.jpg shows the front of the car when I picked it up, front_after.jpg shows it after the accident.")
I imagine this is an extremely common use case.
ieie3366•Apr 13, 2026
Most likely: actually using the geolocation is an extremely niche usecase for images uploaded from mobile browsers.
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
embedding-shape•Apr 13, 2026
> 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.
eru•Apr 13, 2026
Google prompts you in Google Maps if you want to upload your picture to Maps.
I sometimes do that for random pictures, even like selfies, which I don't mind popping up there.
PokemonNoGo•Apr 13, 2026
Wait... You post selfies on Google Maps? The thought never crossed my mind. What would the purpose be? Sorry I'm probably thick...
PepperdineG•Apr 13, 2026
I can say for me that after my father died I posted pictures of him at some of his favorite places or from favorite trips.
petu•Apr 13, 2026
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).
eru•Apr 13, 2026
About the latter: that's why Google Maps is my favourite social medium. It's hyper-local.
ClikeX•Apr 13, 2026
For that sweet local guide score.
embedding-shape•Apr 13, 2026
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?
gbear605•Apr 13, 2026
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.
Barbing•Apr 13, 2026
I will share a thread from someone asking where was their congratulatory email that they've come to expect from Google Maps.
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.
setopt•Apr 13, 2026
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.)
ThePowerOfFuet•Apr 13, 2026
>On Android, Google is a location provider, so blocking their access is much harder.
Their approach encompasses GNSS location, too. Nothing Google required.
bornfreddy•Apr 13, 2026
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.
dylan604•Apr 13, 2026
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.
eru•Apr 13, 2026
Facebook has done that for a long time. And linkedin, too.
bornfreddy•Apr 13, 2026
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...
kccqzy•Apr 13, 2026
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.
harvey9•Apr 13, 2026
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.
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.
MostlyStable•Apr 13, 2026
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
Shalomboy•Apr 13, 2026
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.
Barbing•Apr 13, 2026
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.)
latexr•Apr 13, 2026
> earnestly-submitted junk data from earnestly-engaged citizens.
What made the data junk? Were the provided coordinates not precise enough, incorrect, something else?
Shalomboy•Apr 13, 2026
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.
mapmeld•Apr 13, 2026
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.
Shalomboy•Apr 13, 2026
You're absolutely right. Highways are a little better since they have mile markers, but once you get into a nature preserve you're dealing with a whole bunch of "If you pass the pond with the cattails on your left, you've gone too far." Fishermen, it turned out, LOVED sending coordinates for stuff they saw so long as their fishing spot wasn't nearby.
Cool article btw!
AlexandrB•Apr 13, 2026
iNaturalist is great for stuff like this as it allows organizations to create projects for data collection on specific species.
mapmeld•Apr 13, 2026
I've also noticed that iNaturalist also fuzzes exact locations for some species within a geographic grid (example: zebra) even the ranch zebra in California.
raw_anon_1111•Apr 13, 2026
Really? You don’t understand why people wouldn’t want to share their location with the government?
Shalomboy•Apr 13, 2026
I was being facetious there, to be clear. my bad.
JTbane•Apr 13, 2026
If a state environmental agency asks you for your location on photos that you volunteered to upload and you freak out, you might be mentally ill.
Shalomboy•Apr 13, 2026
I wouldn't take it that far. For most users we spoke to, its often a reflex to deny location privilege popups, and on mobile it wasn't easy enough to fix once denied. However for some of the less-engaged folks who might be out in the park casually and stumbled on something worth sharing, the idea that we need their exact location probably sounded overbearing.
"I told them which park I was in, that should be enough!"
Yeah no kidding the vulnerable animal population is in the park, that's where all their threats are removed. But sometimes "the park" is 60,000 acres and it would be nice if you could help narrow it down.
saltcured•Apr 13, 2026
Or the permission prompt isn't clearly worded or precise enough to understand whether you are allowing the location of this one photo to be shared, versus agreeing to some ongoing tracking...
raw_anon_1111•Apr 13, 2026
You have way more faith in the government not using any information it has against you than I do….
You have been paying attention to what’s going on haven’t you?
kelnos•Apr 13, 2026
I get the reflex to deny permissions (and I also get the reflex to allow anything, in the interest of just getting the annoying pop-up to go away), but it's really tiresome that we have to expect people to avoid thinking even the least bit critically at every juncture.
If you're filling out a form with the express purpose of letting someone know specifically where something is... a request for location information is reasonable, duh. And I won't accept the "people are busy and don't have the time and energy to think this through" excuse. If you're taking the time to fill out this form, then yes, you have the time -- seconds, at most -- to think this through in this particular case.
raw_anon_1111•Apr 13, 2026
Right because that has worked so well with PCs over the last 40 years. Do you remember the people that had a dozen toolbars on their browser because if bundleware? Not to mention viruses and ransomware.
smelendez•Apr 13, 2026
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?
Shalomboy•Apr 13, 2026
> 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.
I wanted us to do this so badly; inter-agency coordination was the biggest issue with I had with large-scale projects. The funny part about your comment is that each feature you listed was a function that a different agency or contractor handled. I won't name names, but the agency I worked for had better-than-expected public outreach and engagement and were organizationally flexible enough to get low-footprint, high-impact conservation PR like this out the door and in front of people in time to make a difference. But in state government, the idea of several agencies pooling resources for a permanent app store project is totally pie-in-the-sky thinking largely because nobody has the bandwidth to contribute. I'm trying to imagine submitting a PR to 'The State Parks App' org board to get this form shipped and in every instance, I'm getting yelled at.
> 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?
Our NGO partners were incredible for this sort of thing. People legitimately do not think twice about pinging a facebook group run by, say, the local aquarium and including their location, a description of the site, and photos of what they found. Social media removes a lot of metadata from uploads - they probably keep it someplace and I just can't get at it without a brokerage, idk - but it still gets better results than we did. One fix for the tortoise problem was to supply personal trail maps and golf pencils at trail heads. Hikers were encouraged to take them, mark on the map where they saw burrows along the trail, and put them in a box at the end of the trail/parking lot/ranger station. Park rangers would scan in the maps and upload the scans to our internal site and we would work it out from there.
freehorse•Apr 13, 2026
> 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?
Ajedi32•Apr 13, 2026
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.
No way they broke it for Google Photos. Anyone who needs location and doesn’t do cables, or can’t figure this out, can simply subscribe!
Can you compress a folder with a photo it and then email that? Just curious.
rickdeckard•Apr 13, 2026
> Can you compress a folder with a photo it and then email that? Just curious.
If the app that creates the compressed file uses the media API to get the file and doesn't have the permission to get location-info, the data will be stripped before the OS is handing the file over to that app. This is likely different if the app uses the READ_EXTERNAL_STORAGE permission and API's to read the files though, which is a legacy permission that was mainly kept for file managers now...
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.
Phones are computers though, it’s not up to Google or Apple to decide what’s a good use case for my own pictures.
jen20•Apr 13, 2026
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.
ieie3366•Apr 13, 2026
You are not the target audience :)
kelnos•Apr 13, 2026
Then I'm not the target audience for any mobile OS, given the restrictions of Google's and Apple's platforms, not to mention the inadequacy (for me) of the features sets for any of the niche open source alternatives. While I expect I'm not in the majority, I'm certainly far from unique.
That's not a good position to be in; this duopoly we've allowed to prosper needs to go.
kristopolous•Apr 13, 2026
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.
dylan604•Apr 13, 2026
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
kristopolous•Apr 13, 2026
Upload file doesn't mean mutate file.
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.
raw_anon_1111•Apr 13, 2026
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.
kristopolous•Apr 13, 2026
These "all users are imbeciles that need our protection" design pattern needs to die a swift death.
raw_anon_1111•Apr 13, 2026
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”.
kristopolous•Apr 13, 2026
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.
Let me phrase this another way: "Computer, I told you to transfer file, not strip meta data".
About Linux: it won the Unix war, the cloud computing war, the embedded war, and is the most installed OS on the planet.
raw_anon_1111•Apr 13, 2026
And absolutely no one knows they are using Linux. Google had to hide all of the Unix underpinnings and do things like this to make it usable.
As far as the BT car issue. I don’t have that issue. I turned off wireless CarPlay, don’t use BT and I connect my phone to my car using a regular old USB C cable to avoid that issue - and it’s more reliable
kristopolous•Apr 13, 2026
See you've done all this workaround, fighting with what some designer did because they assumed all the users are imbeciles.
The problem shouldn't exist. The object should do what we instruct, and not have its own opinions of us and do stuff on our behalf presuming incompetency
Let's take another example, the 4chan-ification of the web making everything ephemeral. All the feed based sites basically hide what you just saw forever. They've fundamentally broken the web and made all content disposable.
It's no longer an addressable public record. It breaks the fundamental storage and organization principles of why computers exist and the fundamental purposes of why they're networked together, as a shared communal record.
> It was like an interactive bulletin board. This wasn’t a machine behind
a locked door calling shots, quantifying your inadequacies…
No! You could touch it. It was a radical reversal. We all knew who the
computer was. But, this time, it had no idea who we were.”
“Sounds like chaos!” Thomas responds.
> “No! It was anything but!” Orion snaps back protectively, “I could sit at
the keyboard and it would say”hello human”. A black woman could sit
down and it would say “hello human”. Henry Kissinger could. It would
say “hello human” and not for any redemption on his part.
> It’s because the computer was taught how to help but nobody had fed it
Instruction on how to hate.
It was then I first saw the computer as a place. A place of hope: an
apotheosis of everything I fight for and every thing I want the world
to be.”
Instead we've broken this and made things aggressively caustic to the human spirit and it shows. Social media is a poison because it's designed poisonously.
This is a deep and systemic problem. You didn't have to see it
It's there but you don't have to see it
raw_anon_1111•Apr 13, 2026
And the alternative is to inconvenience people who don’t want to have to press a button every time they get into a car to pair BT.
kelnos•Apr 13, 2026
> I don’t have that issue.
Ah yes, the good old, "I don't have that particular issue, so I can use my experience to dismiss your concern".
You do realize that sometimes bugs only affect a small percentage of users, right? And even if it affects, say 40% of users, you may personally never see the issue. Does that make it not worth talking about?
raw_anon_1111•Apr 13, 2026
And what would be the alternative that doesn’t have tradeoffs? Everytime you get into your car you have to press a button to manually pair your phone with it? Then another set of users would complain.
The same with the EXIF data being shared. Most people don’t want their location being shared with photos and there have been reports of stalkers using the information
kelnos•Apr 13, 2026
That's an incredibly bad analogy.
raw_anon_1111•Apr 13, 2026
It’s a great analogy. Every design decision has tradeoffs. Given a choice between optimizing for 90% over 10% is a fair trade
raw_anon_1111•Apr 13, 2026
And most people don’t want their location shared with random websites.
rickdeckard•Apr 13, 2026
Seems to be quite simple, an App which wants to access this info just needs to set the permission for it.
Chrome doesn't seem to request that permission, so the OS doesn't provide the location-data to the app.
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.
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.
drnick1•Apr 13, 2026
Use IronFox or Fennec, preferably on GrapheneOS. You won't have freedom on Google or Apple controlled devices.
I have not seen an ad in years.
raw_anon_1111•Apr 13, 2026
Well Apple has had ad blocking extensions for over a decade and full extension support for a few years
ryandrake•Apr 13, 2026
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.
nullfield•Apr 13, 2026
As someone else mentioned it IS entirely problematic how advertisers/others abuse people, and I get WHY location gets stripped. I still think it's abusive to take away the user's choice.
(and why do they have to strip almost ALL EXIF data, instead of just location? [yes, yes, fingerprinting, but there are LOTS of iPhone {NUMBER} whatever out there])
It really just needs to be clearly communicated, opt-in at attach time. Probably with a severely hidden, developer-screen level, or BIG WARNING in security settings to totally disable stripping.
I assume most people won't want it, _usually_, so when adding photos just have it be a double-opt in - you have to both hit an extra button during attachment, then select "include location" or "include location and metadata", then a modal warning/confirmation.
Something like: "Confirm including photo location? This will permit the recipient to see where the pictures were taken. <yes/no>"
inhumantsar•Apr 13, 2026
I agree with you that, when sharing, location should be stripped by default with an option to include it.
After seeing this post I checked my recent photos. I'm using a Pixel 6 Pro with the most recent android release and the stock camera app. None of my recent photos have location in the EXIF, even locally, and there's no option to turn it on.
It's particularly galling that the Camera app still wants location permissions and if you view a photo in the Google Photos app, the location is still there. Google can have those exact locations, but no one, not even the user, can.
It's abusive as hell.
embedding-shape•Apr 13, 2026
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.
embedding-shape•Apr 13, 2026
I'm not sure why I'm being downvoted for this, so I guess I kind of accidentally nerdsniped myself here...
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?
edent•Apr 13, 2026
I've just tried that in Chrome and Firefox on Android 16.
Both just show zeros in the GPS EXIF - the rest of the data are passed through unaltered.
embedding-shape•Apr 13, 2026
Aha, that'd explain it. Thanks a bunch for trying it out and telling me!
sixhobbits•Apr 13, 2026
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.
maccard•Apr 13, 2026
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.
butlike•Apr 13, 2026
I'm not sure I follow. maps.google.com still resolves?
maccard•Apr 13, 2026
maps.google.com now redirects to google.com/maps and has done for the past few years.
butlike•Apr 13, 2026
Ahh I see. Thanks.
amazingamazing•Apr 13, 2026
Google has your location either way. What difference does it make?
kevin_thibedeau•Apr 13, 2026
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.
amazingamazing•Apr 13, 2026
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.
lukan•Apr 13, 2026
I also don't trust my government. So should I just degovernment completely? Sounds just as practical or realistic for most people.
amazingamazing•Apr 13, 2026
You’re saying moving on from Google is similar to switching government?
lukan•Apr 13, 2026
In a way, yes, as google de facto governs and controls much of the internet.
Jtarii•Apr 13, 2026
Switching government and deleting google are probably on the same order of magnitude of difficulty for most people.
bornfreddy•Apr 13, 2026
Have you tried moving on from Google, and preferably not to Apple?
amazingamazing•Apr 13, 2026
Yes, it’s trivial. What are you having difficulty with? There are plenty of threads here on HN about this
shibapuppie•Apr 13, 2026
"Just move" seems to be a pretty popular sentiment, in that scenario.
lxgr•Apr 13, 2026
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.
edgineer•Apr 13, 2026
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.
sathackr•Apr 13, 2026
GrapheneOS still does this -- allows controlling internet access on a per-app basis.
lukan•Apr 13, 2026
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.
Zak•Apr 13, 2026
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:
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.
xigoi•Apr 13, 2026
This has the disadvantage that you can’t whitelist specific domains, which is something I need pretty often.
lxgr•Apr 13, 2026
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)?
joosters•Apr 13, 2026
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 :(
xp84•Apr 13, 2026
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?
raw_anon_1111•Apr 13, 2026
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’ve found a lot of useful podcasts from the ads.
unethical_ban•Apr 13, 2026
It's one of the big reasons I advocate for graphene even if one chooses to install Google services afterward.
Also notable: as of last year, OnePlus allowed mobile and WiFi network toggle, effectively doing the same thing.
WarmWash•Apr 13, 2026
It's not great for revenue, it is their 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.
username223•Apr 13, 2026
Google is pretty much just a wrapper around DoubleClick.
darkhorn•Apr 13, 2026
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.
andybak•Apr 13, 2026
But surely there's a way to do this without totally killing valuable functionality? It's like the Android Sideloading debate all over again.
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 )
sixhobbits•Apr 13, 2026
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
jeroenhd•Apr 13, 2026
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.
Barbing•Apr 13, 2026
Important point:
> 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.
rickdeckard•Apr 13, 2026
> Then one day they use a web browser to send a photo, and there's an entirely new behavior they've never learned.
The article is actually about Google's web browser stripping the EXIF location-data when uploading a photo to a webpage, and the author complains about that behavior.
This is not an implementation of the browser itself. Android Chrome is behaving in that way because the app didn't request the required permission for that data from the OS (which would ask the user), so the files it receives to upload already has the data removed
raw_anon_1111•Apr 13, 2026
This is honestly a horrible argument. Any app on Android can still get EXIF data
kelnos•Apr 13, 2026
You're replying to someone who is talking about a native app, but the overall issue here is about web apps. Chrome and Firefox don't request the appropriate permission (which, as things stand right now, is probably the safer choice), and there's no way for a website to signal to the browser that it wants that permission, so that the browser could prompt the user only for websites that ask for it, and persist the allow/deny response, similarly to how general location permission works via the JS location APIs.
jeroenhd•Apr 13, 2026
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.
rickdeckard•Apr 13, 2026
Seems to be quite simple, an App which wants to access this info just needs to set the permission for it.
Chrome doesn't seem to request that permission, so the OS doesn't provide the location-data to the app. So Chrome rather ended up in this state by doing nothing, not by explicitly doing something...
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.
That's not sufficient. We need a standardized attribute on the HTML form to request the permission as well. If Chrome requests the permission, great, but that's not fine-grained enough for a web browser.
rickdeckard•Apr 13, 2026
Well yes, agree, but as stated Chrome didn't end up with this behavior because they did something, the Browser behaves like this because they didn't implement any logic for this permission.
A standardized attribute on an HTML-form would be difficult to define, because in this context the page just requests/receives a binary file, so a generic "strip embedded location information" decision from the user would be hard to enforce and uphold (also, by whom?).
In this case Android only knows the file-structure and EXIF because the file is requested by Chrome from a Media Library in the OS, not a file-manager.
W3C keeps thinking about this data-minimization topic repeatedly [0], so far they managed to define the principles [1], but enforcing them technically is quite hard if any kind of content can be submitted from a storage to a webpage...
AFAIK a lot of the bigger sites / services already hide or outright strip EXIF.
Its better to do it from the source, obviously.
sylario•Apr 13, 2026
On reddit half of "the is it AI?" question are answered by "Yes, it say so in the metadata".
master-lincoln•Apr 13, 2026
Because most people have no idea how the tools they chose to buy and operate work, the few rational people who educate themselves have to suffer...
This sounds like a downward spiral concerning freedom.
roywiggins•Apr 13, 2026
You don't have to be irrational to not know things.
master-lincoln•Apr 13, 2026
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?
Barbing•Apr 13, 2026
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.
morissette•Apr 13, 2026
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.
pjmlp•Apr 13, 2026
100% of the people that don't know that HN exists, most likely don't know images have metadata.
roywiggins•Apr 13, 2026
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.
SirMaster•Apr 13, 2026
So we should educate people about it. Don't you think that constantly coddling people about tech just breeds tech-illiterate people?
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.
roywiggins•Apr 13, 2026
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?
rickdeckard•Apr 13, 2026
Agree. That's also the dilemma with asking the user for his permission, it is very difficult to frame a concise question and get an educated decision there. So, better to only ask if the App explicitly requests that permission sounds reasonable.
The prior threat-model was, that e.g. a camera/gallery app which may/may not have a permission to a users current location, also has access to the history of a users' locations just by scanning the images when showing the camera roll.
It frankly makes sense to create a separate permission just for this location metadata AND strip this data when no permission was granted, I believe everything else would be MUCH harder to explain the user...
madeofpalk•Apr 13, 2026
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.
Barbing•Apr 13, 2026
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.
rickdeckard•Apr 13, 2026
Sounds fun, but in this case it's actually the OS which is stripping the meta-data before fulfilling the file-access request to the app.
Now an app maybe just wants to set the image as wallpaper, send it to a printer or set as an avatar, so it requests to read it from storage. The OS injecting a watermark here or adding some UI would break decades of apps...
lxgr•Apr 13, 2026
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.
buildbot•Apr 13, 2026
I mean the serial number of the camera and possibly lens are included too…
lxgr•Apr 13, 2026
Not for most phones, fortunately.
WhyNotHugo•Apr 13, 2026
It's not that hard to add a little checkmark "include location" under it, rather than unconditionally remove it.
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.
rickdeckard•Apr 13, 2026
Seems to be quite simple, an App which wants to access this info just needs to set the permission for it.
Chrome doesn't seem to request that permission, so the OS doesn't provide the location-data to the app. So Chrome rather ended up in this state by doing nothing, not by explicitly doing something...
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.
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.
kelnos•Apr 13, 2026
You do realize that Google only cares about user privacy when it doesn't affect their own business model to do so, right? And also, like in this case, where not caring could end up creating some nasty headlines that hurt their reputation?
Meanwhile, Google probably has one of the most comprehensive databases on the planet of user behavior, gleaned from tracking their users all over the internet. Surveillance capitalism at its finest. But hey, they protect people from accidentally sending their photo geolocations to random websites, so good job Google, pat on the back for you.
adrianN•Apr 13, 2026
How good are LLMs at geoguessing?
embedding-shape•Apr 13, 2026
Basically all up to the training data, as things often are.
eru•Apr 13, 2026
You still need some smarts, since the picture you just took won't be in the training data.
xg15•Apr 13, 2026
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.
GRiMe2D•Apr 13, 2026
People already uploaded tons of images and data while playing Pokemon GO. Probably model is already has been built and being tested right now
firtoz•Apr 13, 2026
Pretty good. I test it every now and then from random photos. Sometimes spot on, sometimes gets very close, unless it's really ambiguous.
jcalx•Apr 13, 2026
Quite good, per Bellingcat [0] — Google Lens and ChatGPT could localize the majority of their test photos pretty specifically.
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.
softwaredoug•Apr 13, 2026
Is location sharing something you can disable in iOS?
ndegruchy•Apr 13, 2026
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.
Barbing•Apr 13, 2026
You can also for example just by voice ask the phone to turn off location services, then take your photos.
As one can imagine, even when turning location services back on, the photo will never contain location data.
ndegruchy•Apr 13, 2026
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.
II2II•Apr 13, 2026
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.
SoftTalker•Apr 13, 2026
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.
eminence32•Apr 13, 2026
> 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.
edent•Apr 13, 2026
> 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."
1970-01-01•Apr 13, 2026
>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.
edent•Apr 13, 2026
OP here. I'm not conflating them. That's why I used the word "or".
I don't know how modern your Android phone is, but on all of mine sharing via Bluetooth strips away some of the EXIF.
1970-01-01•Apr 13, 2026
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?
edent•Apr 13, 2026
All the GPS data are nulled / set to zero.
ajifurai•Apr 13, 2026
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.
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.
jeroenhd•Apr 13, 2026
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.
master-lincoln•Apr 13, 2026
I would agree if they switched the order: first make a UI to opt-in/out and then change the default. Now they just made operations impossible
flipped•Apr 13, 2026
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.
palata•Apr 13, 2026
> Android can't stop copying GOS.
Well that's a good thing, isn't it?
HumblyTossed•Apr 13, 2026
Good?
flipped•Apr 13, 2026
NSA agent getting burned?
edent•Apr 13, 2026
I don't think that's quite right. Up until recently I was able to share photos with geolocation from my GrapheneOS device.
flipped•Apr 13, 2026
Metadata can be attached but it's off by default.
pjmlp•Apr 13, 2026
GrapheneOS only exists because Google hasn't yet completely closed shop on AOSP availability.
Who knows, it may eventually be only available on Motorola devices.
antiloper•Apr 13, 2026
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.
celsoazevedo•Apr 13, 2026
For most users, I think this is a good change.
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.
p_stuart82•Apr 13, 2026
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
izacus•Apr 13, 2026
Apple was massively praised when they started stripping location data from shared and uploaded photos.
bilsbie•Apr 13, 2026
Does iPhone do this? Kind of scary to be accidentally sending your home address anywhere you upload a photo.
nozzlegear•Apr 13, 2026
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:
Not sure if there's a way to do that by default, I've never checked.
sambellll•Apr 13, 2026
I feel like that's the optimal implementation - best of both worlds
Wish android copied them for once lol
Barbing•Apr 13, 2026
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! :)
bilsbie•Apr 13, 2026
Interesting. How does it work for texting?
srcoder•Apr 13, 2026
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
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
smileybarry•Apr 13, 2026
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.
akamaka•Apr 13, 2026
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).
smileybarry•Apr 13, 2026
Odd, it was off for me the first time I opened that website, maybe it's persisted from some other context.
NelsonMinar•Apr 13, 2026
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.
hn_throwaway_99•Apr 13, 2026
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.
ryandrake•Apr 13, 2026
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.
Zak•Apr 13, 2026
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.
edent•Apr 13, 2026
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.
black_puppydog•Apr 13, 2026
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.
WhyNotHugo•Apr 13, 2026
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".
Barbing•Apr 13, 2026
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.
busymom0•Apr 13, 2026
I think that's for apps like Netflix or other movie streaming apps being recorded for piracy?
Barbing•Apr 13, 2026
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!”
xigoi•Apr 13, 2026
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).
rickdeckard•Apr 13, 2026
Seems to be quite simple, an App which wants to access location info from images just needs to set the permission for it.
Chrome doesn't seem to request that permission, so the OS doesn't provide the location-data to the app. So Chrome rather ended up in this state by doing nothing, not by explicitly doing something...
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.
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 ...
codethief•Apr 13, 2026
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.
Putting a star into a filename is a pain in the ass, no matter the OS.
xp84•Apr 13, 2026
Escaping and quoting isn’t really that hard
raw_anon_1111•Apr 13, 2026
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.
xigoi•Apr 13, 2026
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.
raw_anon_1111•Apr 13, 2026
And you don’t see why Google would cater to Windows and a Mac users at the expense of Linux users?
driverdan•Apr 13, 2026
What types of files are you syncing that have those characters in their names?
Aachen•Apr 13, 2026
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 :/
> 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.
trashb•Apr 13, 2026
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.
rickdeckard•Apr 13, 2026
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 (by the OS!) 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)
My personal pet peeve is that iOS strips exif time taken (probably all exif) through certain flows - I think iMessage does it? So then if my family texts me a photo of a trip way after it happened and I save it it ends up in the wrong part of my photo timeline. Whereas if they share it a different way like Dropbox it comes through with that metadata intact.
I care less about the location data as I usually know where the photos are just by looking at them but I understand there are good use cases for it and agree including location should be a user choice
adolph•Apr 13, 2026
The article is about browsers filtering EXIF metadata from image uploads and not about advising users when observable sun angle or other distinctive features may disclose the photograph's location.
Suncalc models the relationship between the date, time of day, the geographic
location of a place, and the position of the sun in the sky, together with
the length & direction of the shadows it casts. [0]
A warning before uploading with the option to strip metadata would make sense. But I want to ability to upload a file to a website without it getting silently corrupted in transit.
Johnny555•Apr 13, 2026
I like having location in my photo album (so I can easily search for vacation photos, or figure out where a photo was taken), but I don't want it stored in the photo metadata I share the photo. Is there any way to have Apple or Google photos track the location when the photo is uploaded, but not store it in the photo itself?
ButlerianJihad•Apr 13, 2026
I noticed that this headline is in lowercase, and I can tell you why Google/Android is doing this: because of the uppercase app "Photos" by Google.
Recently, I've been struggling with adding locations to some photos after-the-fact, such as edited photos as well as screenshots (because these screenshots are from location-based apps).
The Photos app always tells me that "location will only be visible inside Photos" -- that is, only to users of the app, and those who I share with inside the app. If the image is downloaded or extracted from the Photos app, apparently it will lose that location info and it won't be stored in the EXIF as normal.
This is because Android, like iOS, seeks to assert control over the JPEG/PNG image file types, and claim them as a special object type which can only be handled by Photos and other image-handling apps.
These image-format objects will no longer be treated as normal files that you can just throw anywhere, but as something that only Photos can handle on your phone, and tied inextricably to the Photos app. Therefore, any metadata that you add shall be stored and managed by Photos, and not in the file itself, because that would be interoperable, and that would be absolutely nuts!
35 Comments
I'm pretty sure this is what happens in the iPhone at least, so I'd imagine it is the same in Android.
https://issuetracker.google.com/issues/268079113 Status: Won't Fix (Intended Behavior).
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.
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.
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.
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.
- 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.
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.)
If you want filenames, you need to request access to a directory, not to an image
/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.
Depends on what is meant by a "duplicate." It would be a good idea to get a checksum of the file, which can detect exact data duplicates, but not something where metadata is removed or if the image was rescaled. Perceptual hashing is more expensive but is better distinguish matches between rescaled or cropped images.
https://en.wikipedia.org/wiki/Perceptual_hashing
There are plenty of use cases where the filename is relevant (and many, many people intentionally use the image name for sorting / cataloging).
In fact, I often refer to the name of the photo in the body of the email (e.g., "front_before.jpg shows the front of the car when I picked it up, front_after.jpg shows it after the accident.")
I imagine this is an extremely common use case.
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'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).
What exactly does that mean though? Is there any benefits to it? All I see is a badge/label, that's it?
https://www.localguidesconnect.com/t/e-mail-from-google-cong...
https://grapheneos.org/features#network-location
Their approach encompasses GNSS location, too. Nothing Google required.
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.)
What made the data junk? Were the provided coordinates not precise enough, incorrect, something else?
Cool article btw!
Yeah no kidding the vulnerable animal population is in the park, that's where all their threats are removed. But sometimes "the park" is 60,000 acres and it would be nice if you could help narrow it down.
You have been paying attention to what’s going on haven’t you?
If you're filling out a form with the express purpose of letting someone know specifically where something is... a request for location information is reasonable, duh. And I won't accept the "people are busy and don't have the time and energy to think this through" excuse. If you're taking the time to fill out this form, then yes, you have the time -- seconds, at most -- to think this through in this particular case.
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?
I wanted us to do this so badly; inter-agency coordination was the biggest issue with I had with large-scale projects. The funny part about your comment is that each feature you listed was a function that a different agency or contractor handled. I won't name names, but the agency I worked for had better-than-expected public outreach and engagement and were organizationally flexible enough to get low-footprint, high-impact conservation PR like this out the door and in front of people in time to make a difference. But in state government, the idea of several agencies pooling resources for a permanent app store project is totally pie-in-the-sky thinking largely because nobody has the bandwidth to contribute. I'm trying to imagine submitting a PR to 'The State Parks App' org board to get this form shipped and in every instance, I'm getting yelled at.
> 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?
Our NGO partners were incredible for this sort of thing. People legitimately do not think twice about pinging a facebook group run by, say, the local aquarium and including their location, a description of the site, and photos of what they found. Social media removes a lot of metadata from uploads - they probably keep it someplace and I just can't get at it without a brokerage, idk - but it still gets better results than we did. One fix for the tortoise problem was to supply personal trail maps and golf pencils at trail heads. Hikers were encouraged to take them, mark on the map where they saw burrows along the trail, and put them in a box at the end of the trail/parking lot/ranger station. Park rangers would scan in the maps and upload the scans to our internal site and we would work it out from there.
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.
If the app that creates the compressed file uses the media API to get the file and doesn't have the permission to get location-info, the data will be stripped before the OS is handing the file over to that app. This is likely different if the app uses the READ_EXTERNAL_STORAGE permission and API's to read the files though, which is a legacy permission that was mainly kept for file managers now...
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.
Source: https://developer.android.com/training/data-storage/shared/m...
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.
That's not a good position to be in; this duopoly we've allowed to prosper needs to go.
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.
Let me phrase this another way: "Computer, I told you to transfer file, not strip meta data".
About Linux: it won the Unix war, the cloud computing war, the embedded war, and is the most installed OS on the planet.
As far as the BT car issue. I don’t have that issue. I turned off wireless CarPlay, don’t use BT and I connect my phone to my car using a regular old USB C cable to avoid that issue - and it’s more reliable
The problem shouldn't exist. The object should do what we instruct, and not have its own opinions of us and do stuff on our behalf presuming incompetency
Let's take another example, the 4chan-ification of the web making everything ephemeral. All the feed based sites basically hide what you just saw forever. They've fundamentally broken the web and made all content disposable.
It's no longer an addressable public record. It breaks the fundamental storage and organization principles of why computers exist and the fundamental purposes of why they're networked together, as a shared communal record.
Seeing this working well goes back to original online spaces like this in the 1970s https://en.wikipedia.org/wiki/Community_Memory
Or my favorite quote about this
> It was like an interactive bulletin board. This wasn’t a machine behind a locked door calling shots, quantifying your inadequacies… No! You could touch it. It was a radical reversal. We all knew who the computer was. But, this time, it had no idea who we were.” “Sounds like chaos!” Thomas responds.
> “No! It was anything but!” Orion snaps back protectively, “I could sit at the keyboard and it would say”hello human”. A black woman could sit down and it would say “hello human”. Henry Kissinger could. It would say “hello human” and not for any redemption on his part.
> It’s because the computer was taught how to help but nobody had fed it Instruction on how to hate. It was then I first saw the computer as a place. A place of hope: an apotheosis of everything I fight for and every thing I want the world to be.”
Instead we've broken this and made things aggressively caustic to the human spirit and it shows. Social media is a poison because it's designed poisonously.
This is a deep and systemic problem. You didn't have to see it
It's there but you don't have to see it
Ah yes, the good old, "I don't have that particular issue, so I can use my experience to dismiss your concern".
You do realize that sometimes bugs only affect a small percentage of users, right? And even if it affects, say 40% of users, you may personally never see the issue. Does that make it not worth talking about?
The same with the EXIF data being shared. Most people don’t want their location being shared with photos and there have been reports of stalkers using the information
Chrome doesn't seem to request that permission, so the OS doesn't provide the location-data to the app.
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.
Source: https://developer.android.com/training/data-storage/shared/m...
I have not seen an ad in years.
(and why do they have to strip almost ALL EXIF data, instead of just location? [yes, yes, fingerprinting, but there are LOTS of iPhone {NUMBER} whatever out there])
It really just needs to be clearly communicated, opt-in at attach time. Probably with a severely hidden, developer-screen level, or BIG WARNING in security settings to totally disable stripping.
I assume most people won't want it, _usually_, so when adding photos just have it be a double-opt in - you have to both hit an extra button during attachment, then select "include location" or "include location and metadata", then a modal warning/confirmation.
Something like: "Confirm including photo location? This will permit the recipient to see where the pictures were taken. <yes/no>"
After seeing this post I checked my recent photos. I'm using a Pixel 6 Pro with the most recent android release and the stock camera app. None of my recent photos have location in the EXIF, even locally, and there's no option to turn it on.
It's particularly galling that the Camera app still wants location permissions and if you view a photo in the Google Photos app, the location is still there. Google can have those exact locations, but no one, not even the user, can.
It's abusive as hell.
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?
Both just show zeros in the GPS EXIF - the rest of the data are passed through unaltered.
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.
https://www.reddit.com/r/tasker/comments/1mxjnvs/how_to_bloc...
https://blokada.org/
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.
Also notable: as of last year, OnePlus allowed mobile and WiFi network toggle, effectively doing the same thing.
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.
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 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.
The article is actually about Google's web browser stripping the EXIF location-data when uploading a photo to a webpage, and the author complains about that behavior.
This is not an implementation of the browser itself. Android Chrome is behaving in that way because the app didn't request the required permission for that data from the OS (which would ask the user), so the files it receives to upload already has the data removed
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.
Chrome doesn't seem to request that permission, so the OS doesn't provide the location-data to the app. So Chrome rather ended up in this state by doing nothing, not by explicitly doing something...
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.
Source: https://developer.android.com/training/data-storage/shared/m...
A standardized attribute on an HTML-form would be difficult to define, because in this context the page just requests/receives a binary file, so a generic "strip embedded location information" decision from the user would be hard to enforce and uphold (also, by whom?).
In this case Android only knows the file-structure and EXIF because the file is requested by Chrome from a Media Library in the OS, not a file-manager.
W3C keeps thinking about this data-minimization topic repeatedly [0], so far they managed to define the principles [1], but enforcing them technically is quite hard if any kind of content can be submitted from a storage to a webpage...
[0] https://www.w3.org/blog/2019/adding-another-permission/
[1] https://www.w3.org/TR/security-privacy-questionnaire/#data-m...
Its better to do it from the source, obviously.
This sounds like a downward spiral concerning freedom.
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?
The prior threat-model was, that e.g. a camera/gallery app which may/may not have a permission to a users current location, also has access to the history of a users' locations just by scanning the images when showing the camera roll.
It frankly makes sense to create a separate permission just for this location metadata AND strip this data when no permission was granted, I believe everything else would be MUCH harder to explain the user...
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.
Now an app maybe just wants to set the image as wallpaper, send it to a printer or set as an avatar, so it requests to read it from storage. The OS injecting a watermark here or adding some UI would break decades of apps...
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.
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.
Chrome doesn't seem to request that permission, so the OS doesn't provide the location-data to the app. So Chrome rather ended up in this state by doing nothing, not by explicitly doing something...
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.
Source: https://developer.android.com/training/data-storage/shared/m...
Meanwhile, Google probably has one of the most comprehensive databases on the planet of user behavior, gleaned from tracking their users all over the internet. Surveillance capitalism at its finest. But hey, they protect people from accidentally sending their photo geolocations to random websites, so good job Google, pat on the back for you.
[0] https://www.bellingcat.com/resources/2025/08/14/llms-vs-geol...
As one can imagine, even when turning location services back on, the photo will never contain location data.
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.
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."
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.
I don't know how modern your Android phone is, but on all of mine sharing via Bluetooth strips away some of the EXIF.
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.
Well that's a good thing, isn't it?
Who knows, it may eventually be only available on Motorola devices.
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.
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! :)
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
Mainly top versus bottom placement, I think, but also font size.
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.
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.
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.
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!”
Chrome doesn't seem to request that permission, so the OS doesn't provide the location-data to the app. So Chrome rather ended up in this state by doing nothing, not by explicitly doing something...
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.
Source: https://developer.android.com/training/data-storage/shared/m...
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 ...
[0]: https://github.com/GrapheneOS/os-issue-tracker/issues/952
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...
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.
Strange UI that they are involuntarily capturing but then removing it.
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 (by the OS!) 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 care less about the location data as I usually know where the photos are just by looking at them but I understand there are good use cases for it and agree including location should be a user choice
Recently, I've been struggling with adding locations to some photos after-the-fact, such as edited photos as well as screenshots (because these screenshots are from location-based apps).
The Photos app always tells me that "location will only be visible inside Photos" -- that is, only to users of the app, and those who I share with inside the app. If the image is downloaded or extracted from the Photos app, apparently it will lose that location info and it won't be stored in the EXIF as normal.
This is because Android, like iOS, seeks to assert control over the JPEG/PNG image file types, and claim them as a special object type which can only be handled by Photos and other image-handling apps.
These image-format objects will no longer be treated as normal files that you can just throw anywhere, but as something that only Photos can handle on your phone, and tied inextricably to the Photos app. Therefore, any metadata that you add shall be stored and managed by Photos, and not in the file itself, because that would be interoperable, and that would be absolutely nuts!