Android now stops you sharing your location in photos

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

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".

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.

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.

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.

https://issuetracker.google.com/issues/268079113 Status: Won't Fix (Intended Behavior).

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...

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.

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.

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.

I don't know a good solution for this. 99% of websites asking for this hypothetical permission would not deserve it. Users (rightfully) don't expect that uploading a photo leaks their location.

Element (the matrix client) used to not strip geolocation metadata for the longest time. I don't know if they fixed that yet.

I 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.

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.

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

0 https://codeberg.org/Starfish/Imagepipe#how-to-get-the-app

>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.

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.

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.

Does iPhone do this? Kind of scary to be accidentally sending your home address anywhere you upload a photo.

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

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

Nice drunk theme! All web site should have one.

> 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.

Is location sharing something you can disable in iOS?

How good are LLMs at geoguessing?

Apple was massively praised when they started stripping location data from shared and uploaded photos.

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.

I don't like this. The Right Thing is for camera apps to not add location metadata by default.

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".

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).

https://app.vigilo.city/

Does the situation suck? Yes. On the other hand, I think Google is doing the responsible thing here.

For most users, I think this is a good change.

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

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

Apple was massively praised when they started stripping location data from shared and uploaded photos.

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.

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

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.

> actually using the geolocation is an extremely niche usecase for images uploaded from mobile browsers

Is it only for mobile browsers? The article makes it sound [0] as if it is a general thing, even when sharing through bluetooth, and that only copying the image via usb connection allows you to keep geolocation in exif. Not sure what happens when you upload to native apps, eg to some cloud storage app (photo specific or not). I definitely want my location to stay when I make a cloud backup of my photos with an app intended for that.

[0] Quote:

>> Using a "Progressive Web App" doesn't work either. So, can users transfer their photos via Bluetooth or QuickShare? No. That's now broken as well. You can't even directly share via email without the location being stripped away. Literally the only way to get a photo with geolocation intact is to plug in a USB cable, copy the photo to your computer, and then upload it via a desktop web browser?

> I’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.

> extremely niche usecase

Phones are computers though, it’s not up to Google or Apple to decide what’s a good use case for my own pictures.

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.

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 )

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.

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.

On reddit half of "the is it AI?" question are answered by "Yes, it say so in the metadata".

AFAIK a lot of the bigger sites / services already hide or outright strip EXIF.

Its better to do it from the source, obviously.

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.

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.

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.

https://issuetracker.google.com/issues/268079113 Status: Won't Fix (Intended Behavior).

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

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.

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

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.

>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

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.

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.

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.

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.

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.

Just tested with Firefox 149 on Android 13. There are no coordinates when I upload an image to EXIF viewer web sites.

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.

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.

I don't think that's quite right. Up until recently I was able to share photos with geolocation from my GrapheneOS device.

> Android can't stop copying GOS.

Well that's a good thing, isn't it?

Does iPhone do this? Kind of scary to be accidentally sending your home address anywhere you upload a photo.

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:

https://imgur.com/a/lm0stDE

Not sure if there's a way to do that by default, I've never checked.

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.

Nice drunk theme! All web site should have one.

The author wrote about it here: https://shkspr.mobi/blog/2025/09/drunk-css/

> Because Google run an anticompetitive monopoly on their dominant mobile operating system.

I will note that Google Photos seems to happily let you add images to shared albums with embedded location information. I can't recall if you get any privacy-related warnings or notices.

> But I don't honestly think Google could have consulted their community. It's just too big.

The thing is, they frequently do. They have developer relations people, they publish blog posts about breaking changes, they work with W3C and other standards bodies, they reply on bug trackers.

But, in this case, nothing. Just a unilateral change with no communication. Not even a blog posts saying "As of April, this functionality is deprecated."

Is location sharing something you can disable in iOS?

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.

How good are LLMs at geoguessing?

Quite good, per Bellingcat [0] — Google Lens and ChatGPT could localize the majority of their test photos pretty specifically.

[0] https://www.bellingcat.com/resources/2025/08/14/llms-vs-geol...

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.

Pretty good. I test it every now and then from random photos. Sometimes spot on, sometimes gets very close, unless it's really ambiguous.

Basically all up to the training data, as things often are.