My first eye-opening moment working within the government was with team of herpetologists at the state conservation agency. They had a pretty slick public education campaign around protecting Gopher Tortoise habitats and a grand call-to-action "let the agency know where and when they see their nests". The whole thing fell apart because they were getting tons of earnestly-submitted junk data from earnestly-engaged citizens. Turns out the application was just a form that they asked people to fill out. I suggested they ask for user photos and scrape the EXIF data or ask them to opt-into sending their location and got laughed out of the room. Turns out that they discovered users immediately nope out of government websites that ask for their location! What a shame.
A colleague of mine tried doing this after a large sturgeon die off in the San Francisco Bay a few years ago. Citizens were asked to upload photos of dead sturgeon washed up on beaches. They actually got pretty good data (sturgeon are very easily identifiable) and lots of participation, but the location data ending up being largely useless because it was fuzzed (I think by iOS?) to a large enough degree to no longer be helpful, and the fields for manual coordinate entry had very low usage
Oh that's fascinating. I hadn't considered OS-level fuzzing as a hurdle until now. I'm an pixel guy and typically I get decently-accurate location heatmaps in the Photos app when I search by location; I wonder how we would have handled this. HABs are so difficult, they break my heart.
How does iOS decide whether to default to including location?
I coulda sworn, even in earlier versions of iOS 26, if you told it not to include location when sending a photo once then it would not include it by default the next time.
Also I thought that when you uploaded a photo from your camera roll to the web I thought it defaulted to no location. And that seems to have changed too. (Of course, you can still tap a button to withhold location EXIF.)
I wonder if there would be any way to fix this with the right messaging. With infinite funding and the right agency cooperation, I bet you could include this in a state parks app that you could also use for other useful purposes, like pulling up trail maps, paying for parking and camping, fishing licensing, signing up for volunteer events, receiving notifications with news around particular parks you frequent, etc.
But in the real world, if you put a QR code at the trailhead and said "take a picture of this code. When you see a tortoise nest, use the code to go to our website and share your exact location."
If people are wary of sharing their location with the conservation agency, you might have better luck if the website was run by a nongovernmental conservation group?
> 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.
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.
> 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.
> actually using the geolocation is an extremely niche usecase for images uploaded from mobile browsers
Is it only for mobile browsers? The article makes it sound [0] as if it is a general thing, even when sharing through bluetooth, and that only copying the image via usb connection allows you to keep geolocation in exif. Not sure what happens when you upload to native apps, eg to some cloud storage app (photo specific or not). I definitely want my location to stay when I make a cloud backup of my photos with an app intended for that.
[0] Quote:
>> Using a "Progressive Web App" doesn't work either. So, can users transfer their photos via Bluetooth or QuickShare? No. That's now broken as well. You can't even directly share via email without the location being stripped away. Literally the only way to get a photo with geolocation intact is to plug in a USB cable, copy the photo to your computer, and then upload it via a desktop web browser?
I'm gonna die on this hill, but silently attaching very sensitive PII (including exact lat/lon) to photos has always been a terrible anti-feature. One of those "WTF were they actually thinking?" terrible anti-features. Imagine if you created a word document and Microsoft silently attached your home address to them as metadata. Awful and totally unexpected to the vast majority of users.
I want the location on every time, without exception.
The current behavior is exactly what I wanted.
These "all users are imbeciles that need our protection" design pattern needs to die a swift death.
It's maddening, We're constantly taking kitchen knives and replacing them with the colorful plastic toddler version and still have the same cutting tasks.
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.
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".
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.
In a similar move (silently changing a feature crucial to some users), in Android 11 Google suddenly removed the possibility to use "special" characters
":<>?|\*
in filenames[0], presumably because they're not allowed on Windows/NTFS and Windows users might end up struggling to transfer them to their Windows computer. I don't care about NTFS at all, though. I just want to be able to sync all my files with my Linux machines and now I'm no longer able to. Makes me want to scream.
I 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!
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.
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.
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.
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.
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
I used to run a small website that allowed users to upload pictures. Most people were not aware that they were telling me where they were, when the picture was taken, their altitude, which direction they were facing, etc.
I noticed this in an app's changelog recently, saying something along the lines of "remove metadata comparison function because new Android versions no longer support it"
Thankfully F-Droid has a "never update this app" checkbox for now, but eventually I'm sure third-party developers will require minimum Android versions that mean I need to lose this functionality :/
I don't like this. The Right Thing is for camera apps to not add location metadata by default.
If you go in and turn location on (which should have a warning on it), then you're the sort of person who changes defaults, a more sophisticated user than the majority of the population who is able to take responsibility for the consequences. Yes, I can imagine a scenario where someone ends up with this setting turned on through no fault of their own, but it shouldn't be the role of an OS vendor to prevent every possible mistake.
Yeah, I also find this annoying. I created a site that lets Ham Radio Parks on the Air operators share photos of their setups in parks (https://www.potaparkpics.com). I do it with no login - you simply specify what park you are in, then upload photos. I use the geolocation (comparing the photo exif against the park you said you were in) as authentication. Works great - but only for iPhone users.
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
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 ...
This prevents uploading pictures, with chain of custody data attached, of law enforcement misbehaving. Was there pressure from ICE to install this feature?
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)
>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.
I suspect this horse has bolted. When I see a photo on a website and I want to know where it's taken, I assume it's been stripped already and ask an AI. The accuracy is uncanny.
Since it's a rare web site that leaves the EXIF data intact, I guess this is aimed at apps harvesting photos on the device itself. I hope Firefox gets a new site permission that allows you to upload photos with the EXIF intact, because that's often what I want. But that won't happen for a while, and until apps do get their permissions updated it's going to be annoying. It will be a right proper PITA to discover later your EXIF data is gone from the photos you transferred to your laptop.
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]
It's interesting that Android is actually ahead of iOS on this, as simonw pointed out, iOS still doesn't strip location data from photos uploaded via web forms. This should be the default on both platforms. Most people have no idea they're attaching exact GPS coordinates to every photo they share, and the safety implications alone (stalking, doxxing) make it worth the tradeoff for the small number of use cases that rely on it.
I am developing an Android application that uses image location data, in fact, the primary purpose of the app is for the user to curate the location data so it is accurate enough to depict the location and life cycle of a flower from a series of timestamped photos of the flower.
I guess I share to point out that the solution of developing a android native app is not that burdensome, and it is some kind of data you want the user to be intentional with.
I understand that you want the location of the photo and not the location of the user uploading that photo, but given that both are identical in many cases, getting the location with the regular geolocation API might be an acceptable solution that is also transparent to the user.
Show a location picker with the user's current location and the option to select an alternative location. Not as smooth as using EXIF data, but doable.
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.
This is a push for privacy and it is fundamentally pushes in the opposite direction from let's say "forming accurate knowledge about the world".
How can we combat being mislead by false AI generated images? I'd say keeping track of provenance is what we should adopt, at least as an option. I hope we will find solutions to propagate images over the net reliably keeping how, when and where they were taken.
Interestingly, the Wikipedia app devs prevent you from opting out of sharing supposedly-anonymous data with their app. Supposedly-anonymous because I think we all know how deanonymizing works by now, and how easy it is:
I feel this is a failure to capture/model the different use-cases between:
1. Copy file from A to B
2. Publish file to a public realm
If Google thinks that the average site cannot be trusted to indicate/clarify the difference... Well, that's fair, but (as the blogpost says) I'd rather see some browser permission thing like: "Can this website see original filenames and GPS data inside any media you upload?"
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?
Google always loves to keep a tight grip on Android to use it as their ultimate trump card. I reckon they should stop updating the Android Open Source Project source code; that way, Google would have even more control over Android and it would set the stage for more of their outrageous behaviour.
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.
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.
> 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.
> 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.
319 comments
I’d wager 99.9% of the users didn’t realize that they are effectively sending their live GPS coords to a random website when taking a photo.
But yes, a prop to the input tag ’includeLocation’ which would then give the user some popup confirmation prompt would have been nice
I coulda sworn, even in earlier versions of iOS 26, if you told it not to include location when sending a photo once then it would not include it by default the next time.
Also I thought that when you uploaded a photo from your camera roll to the web I thought it defaulted to no location. And that seems to have changed too. (Of course, you can still tap a button to withhold location EXIF.)
But in the real world, if you put a QR code at the trailhead and said "take a picture of this code. When you see a tortoise nest, use the code to go to our website and share your exact location."
If people are wary of sharing their location with the conservation agency, you might have better luck if the website was run by a nongovernmental conservation group?
> 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.
> earnestly-submitted junk data from earnestly-engaged citizens.
What made the data junk? Were the provided coordinates not precise enough, incorrect, something else?
> users immediately nope out of government websites that ask for their location
I for one am glad that that's the trained reaction of the masses
> 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.
> 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?
> 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.
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.
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".
https://issuetracker.google.com/issues/268079113 Status: Won't Fix (Intended Behavior).
[0]: https://github.com/GrapheneOS/os-issue-tracker/issues/952
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!
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.
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.
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.
Element (the matrix client) used to not strip geolocation metadata for the longest time. I don't know if they fixed that yet.
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
I used to run a small website that allowed users to upload pictures. Most people were not aware that they were telling me where they were, when the picture was taken, their altitude, which direction they were facing, etc.
Thankfully F-Droid has a "never update this app" checkbox for now, but eventually I'm sure third-party developers will require minimum Android versions that mean I need to lose this functionality :/
Edit: found it, it was VesIC https://github.com/VincentEngel/VES-Image-Compare/releases/t...
If you go in and turn location on (which should have a warning on it), then you're the sort of person who changes defaults, a more sophisticated user than the majority of the population who is able to take responsibility for the consequences. Yes, I can imagine a scenario where someone ends up with this setting turned on through no fault of their own, but it shouldn't be the role of an OS vendor to prevent every possible mistake.
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
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 ...
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...
>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.
Since it's a rare web site that leaves the EXIF data intact, I guess this is aimed at apps harvesting photos on the device itself. I hope Firefox gets a new site permission that allows you to upload photos with the EXIF intact, because that's often what I want. But that won't happen for a while, and until apps do get their permissions updated it's going to be annoying. It will be a right proper PITA to discover later your EXIF data is gone from the photos you transferred to your laptop.
I guess I share to point out that the solution of developing a android native app is not that burdensome, and it is some kind of data you want the user to be intentional with.
Show a location picker with the user's current location and the option to select an alternative location. Not as smooth as using EXIF data, but doable.
How can we combat being mislead by false AI generated images? I'd say keeping track of provenance is what we should adopt, at least as an option. I hope we will find solutions to propagate images over the net reliably keeping how, when and where they were taken.
https://phabricator.wikimedia.org/T356260
Just more push and pull on privacy, mostly pulling it away from you, it seems.
1. Copy file from A to B
2. Publish file to a public realm
If Google thinks that the average site cannot be trusted to indicate/clarify the difference... Well, that's fair, but (as the blogpost says) I'd rather see some browser permission thing like: "Can this website see original filenames and GPS data inside any media you upload?"
Strange UI that they are involuntarily capturing but then removing it.
> 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.
> 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.