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.
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.
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.
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.
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.
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.
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.
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...
A government agency, which might even have good use for the data, isn't the problem. The problem is sending your precise location to Facebook and a two dozen silly little games and a note app, which all sell this data to anyone and their brother.
By framing the problem as being with untrustworthy government agencies rather than with greedy data brokers selling data everywhere, you are part of the problem. You may distrust your government as much as you'd like, but before we solve the problems with private data brokers, we can never improve the situation.
The difference is that private brokers don’t have “a monopoly on [legslized] violence”. Facebook doesn’t have an army of masked jack booted thugs with military gear.
> I’d wager 99.9% of the users didn’t realize that they are effectively sending their live GPS coords to a random website when taking a photo.
I'd wager 90% of the photos on Google Maps associated with various listings don't actually know their photos are in public. I keep coming across selfies and other photos that look very personal, but somehow someone uploaded to Google Maps, the photo is next to a store or something and Google somehow linked them together, probably by EXIF.
Google Maps app sees that you took photo near POI and later in the day asks you in notification if you want to share it on maps.
You review the photo and go "lol, sure".
At least for me that doesn't even feel like posting due to how frictionless it is and that it's about natural discoverability (someone has to click that POI and scroll through photos to find it).
I remember arriving in Lisbon, leaving a favorable review for a restaurant because they were so nice to us, and Google sending me a notification that I'm now a local guide for Lisbon.
What exactly does that mean though? Is there any benefits to it? All I see is a badge/label, that's it?
There are some benefits that definitely used to exist, and maybe still exist, like early access to new features and additional Google Drive storage. But in practice today, the only real benefit is the badge.
I really don't know why anyone would try hard to get that. On Chinese map app (Amap) at least you can get a ride hailing coupon, for a nice taxi discount.
I had a popup on my iPhone one day "You were in City Park last weekend, would you like to share those photos?". I stopped allowing google access to my photos after that. A little late though, they had apparently scraped all of my data already.
I had a similar moment a few years ago. That Google Maps pop-up was what caused me to first switch to de-googled Android, and once that turned out to be a hassle after a couple of years, switch to an iPhone without Google stuff. (On Android, Google is a location provider, so blocking their access is much harder.)
True. Sidenote: they are still however push notifications provider, so good luck getting rid of them completely (unless you're fine with not getting the notifications). MicroG is awesome wrt. that as you can turn it on/off as you wish, and it just works. GrapheneOS however only supports Google services in sandbox, but the notifications work sporadically IME (maybe because I keep turning them off and on... not sure). So... Pick your poison.
I don't even have G-apps on my phone. They work fine in a browser, until they don't. I was trying to use streetview yesterday and it would not open in the browser and kept trying to redirect me to the app store. So now they are deliberately borking their webapps to punish those not using native apps.
Yeah, there are lots of pages that don't show the (google) map if you don't have google services enabled on your android phone. Not sure if this is something that could be solved on browser level though? I'm quite certain that these pages still work on iphones...
I 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.
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.
> actually using the geolocation is an extremely niche usecase for images uploaded from mobile browsers
Is it only for mobile browsers? The article makes it sound [0] as if it is a general thing, even when sharing through bluetooth, and that only copying the image via usb connection allows you to keep geolocation in exif. Not sure what happens when you upload to native apps, eg to some cloud storage app (photo specific or not). I definitely want my location to stay when I make a cloud backup of my photos with an app intended for that.
[0] Quote:
>> Using a "Progressive Web App" doesn't work either. So, can users transfer their photos via Bluetooth or QuickShare? No. That's now broken as well. You can't even directly share via email without the location being stripped away. Literally the only way to get a photo with geolocation intact is to plug in a USB cable, copy the photo to your computer, and then upload it via a desktop web browser?
I'm guessing they changed the default behavior from "include metadata" to "strip metadata" so now any app that wants metadata has to request it explicitly, and any older apps which don't know how to make such a request are simply unable to get location data?
Yes, it's about that permission. It's not even that recent, it has been implemented since Android 10. I think it's summarized quite well here [0]:
If your app targets Android 10 (API level 29) or higher and needs to retrieve unredacted EXIF metadata from photos, you need to declare the ACCESS_MEDIA_LOCATION permission in your app's manifest, then request this permission at runtime.
So if the app-developer didn't take explicit effort to request this data (and the user-permission for it), his app will not receive it.
> 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.
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.
It is absolutely Apple's job to protect people who do not have the desire or capacity to decide what is a good use case or not from predators (yes, the ad industry is 100% predatory).
The whole reason I and my entire family have iPhones is because there are entire classes of scams and scum that you don't have to be constantly vigilant against. If it didn't do that, I wouldn't buy them.
I'm gonna die on this hill, but silently attaching very sensitive PII (including exact lat/lon) to photos has always been a terrible anti-feature. One of those "WTF were they actually thinking?" terrible anti-features. Imagine if you created a word document and Microsoft silently attached your home address to them as metadata. Awful and totally unexpected to the vast majority of users.
Well Microsoft actually did attach metadata to word files, and it led to the arrest of a serial killer. Not saying they should do it, just found it funny that you picked the one example that did actually happen.
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>"
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.
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.
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.
I was a fan of the idea that the OS would strip location data on any upload via web/app, but would preserve the data when doing specific types of transfers deemed not via third party like direct transfer to computer or AirDrop
No. Upload file means upload file. If you want to mutate the file, mutate the file.
When tools assume you're stupid and insert silent surprises unrelated to the task they no longer deserve the title "tool" because they are fundamentally doing other things.
Most people have no idea when they upload a “photo” they are also letting anyone know their “location”. On iOS at least, from the browser, you specifically choose whether you want to upload a file from the Files app (that lets you upload files from iCloud, Google Drive, Dropbox or any other storage type service you have installed) or a photo.
Yes and no one who knows how to change an engine should drive a car. This is why geeks make horrible product people and after 30 years geeks are still waiting for “The Year of Linux on the Desktop”.
What you're advocating for is more like the Bluetooth hijacking when you get in a car of transferring your call from you ear piece to your sound system as if you want to blast your phone call to everyone in the parking lot.
Turn on car doesn't mean hijack Bluetooth connection.
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.
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
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
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?
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
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.
Why do I need protection from Apple if my goal is not to deal with ads? Unless you are making the (very valid) point that you still have to deal with ads in the App Store and soon Apple Maps.
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.
You can probably get around this problem by compressing the file and uploading it in a .zip. Google Files allows for making zip files at least, so I don't think it's a rare feature.
I think the linked spec suggestion makes the most sense: make the feature opt-in in the file picker, probably require the user to grant location permissions when uploading files with EXIF location information.
yeah it does sound kind of dodge that there's no option even for advanced users to bypass this, I would guess mainly a moat to protect Google Photos. I wonder if online photo competitors are finding a workaround or not as searching your photos by location seems like a big feature there
I don't know when Google's EXIF protections are supposed to kick in, but so far my photos auto-synced to Nextcloud still contain location information as expected.
I don't think this has anything to do with Google Photos. People fall victim to doxxing or stalking or even location history tracking by third party apps all the time because they don't realize their pictures contain location information. It's extra confusion to laypeople now that many apps (such as Discord) will strip EXIF data but others (websites, some chat apps) don't.
> It's extra confusion to laypeople now that many apps (such as Discord) will strip EXIF data but others (websites, some chat apps) don't.
You've given me a lot of sympathy for the young'uns whose first experiences on the web might have been with EXIF-safe apps. Then one day they use a web browser to send a photo, and there's an entirely new behavior they've never learned.
> 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
Thank you! Meant my comment for anyone who's not on the very latest version, anyone who experienced Android or another OS with disparate privacy-related behaviors as long as that OS has been around. Yes, now, the issue I'm talking about is solved for the general public on the latest Android devices! At reported cost to power users.
Just to add some more context: The change was applied in Android 10, which was released in 2019.
On OS-level there is no reduction in functionality, the implementation just ensures that the user agrees on sharing his location data to an app, and until that has been agreed it is not being shared (as to not hinder any normal app-operation).
Now the fact that the Chrome app doesn't trigger to ask the user-permissions is another topic, with its own (huge) complexity: If the user disagrees to share his location-history to a webpage, and Android can only ensure this for known media file types (while i.e. Windows cannot do this for ANY filetype, and on iOS I believe the user cannot even decide to not have it stripped), Chrome actually cannot commit to any decision taken by the user.
It's a known dilemma in the W3C, the Browser should ensure user privacy but for binary data it technically can't...
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.
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.
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...
If google really cared about privacy, they wouldn't have moved maps away from a subdomain. now if I want maps to have my location (logical), I need to grant google _search_ my location too.
It's not all-or-nothing; sometimes some people at Google push for some things to improve privacy. Rarely happens when revenue is at stake.
Android used to ask you "do you want to alllow internet access?" as an app permission. Google removed that, as it would stop ads from showing up. Devastating change for privacy and security, great for revenue.
People act like Google products are a charity that had been free forever, and then this mega-corp called Google came along and started harvesting the data of innocent people who just want to get directions to Starbucks.
For those of us stuck on normal android, is there a way to achieve that? I know it used to work with some firewall apps but nowdays they all require root access.
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.
iOS allows this, but only on mobile data, which is pretty infuriating. Why should I not be able to also restrict apps from dialing home/anywhere just because I'm on a Wi-Fi network (which isn't even necessarily unmetered)?
It's really annoying. I have a sudoku game on my phone, works great but give it internet access and it's suddenly full of sketchy adverts.
If I'm playing it on my commute, it's usable with mobile data disabled for the app. But when the train stops in a station long enough to auto-connect to wifi, immediate full screen adverts :(
Then don’t use an ad supported app? I have one as supported app on my phone - Overcast. The developer created their own ad platform and serves topic based ads based on the podcast you are listening to right now. Ironically enough I started to pay for a subscription even though it didn’t give me any real benefit just to support him until he started having ads.
I’m gonna be That Guy for a minute: if you enjoy using a Sudoku app, isn’t there one available on more acceptable terms, e.g. a single purchase or a IAP that removes the ads from this one? I’m not saying you have to pay like $3.99/week for a scam one, but more like pointing out that if you don’t like ads (as I also don’t) why not support the developers who believe in selling software to you for a few bucks rather than selling your annoyance to Google via Adsense?
Google doesn't care about privacy, but its easier for them to keep collecting your data if they can also keep it from getting unintentionally leaked to others.
The last thing Google wants is for people to start thinking about the amount of data they're handing over.
You can lock down their usage. Limit it to three months storage and minimize sharing. They still report an old address for home and work for me since I dialed up the restrictions years ago. They have the data but it is less exposed.
I honestly don’t understand the scenario you’re defending against. Google still knows where you actually live and work trivially. If you don’t trust Google you should just de-Google completely.
If you think it's trivial you must not be paying attention. You cannot keep your data from Google. Government websites include google tracking. Google drives past your house to take photos and sniff your wifi traffic. Your employer hands your data over to google. Your doctor hands your data over to google. Your bank hands your data over to google. You can limit how much you actively and voluntarily give them, but you can't free yourself from them entirely and still function in society.
Trivial? Ha! Way to say that you never tried it. Either that, or that you don't care for things like push notifications. Yes, most of the things work, but not nearly all of them.
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.
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.
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.
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.
Seems like such a shitty thing to victimize the potential victim. But… if you didn’t know that images you took had metadata… maybe you shouldn’t be allowed to use a computer. I mean. I’m going on decades of knowing this. Feel like there is a mid 90s X-Files episode that even like breaks this down. If not NCIS or some shit.
Even people who know it, don't think about it and don't connect it with the potential consequences of uploading a picture to a website. And why would they? It's not visible, there's no warning, it's just not something that's going to be top of mind.
I said that people who already know don't think about it. That's not something you can solve by educating them more. When I'm sharing a photo, I am going to think about what I can see in the photo as a data risk, not the invisible stuff that I might intellectually have heard about. It's just not going to come to mind.
People who know about phishing get got by phishing attacks, too. How well has however many years of "cyber awareness training" gone?
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...
I assume Google are very hesitant to add additional permissions, and any additions get very carefully thought about. Having too many prompts can lead to popup blindness, which defeats the entire purposr of the permission system in the first place.
I'm sure I recall much older Android versions presenting all of the app's permissions at install-time. I'm very willing to bet that most users didn't actually read any of it. Overall, it seems like a very interesting problem to solve.
You're right - this is a shitty view on this. It's incredibly opaque that images secretly contain the GPS coordinates of where they were taken. There's no way that's obvious or intuitive.
I think the 'ideal' thing to do would be an opt-in toggle for sharing "location and other extended info" for photos when selecting them, but I'm sure you can understand why a dev team took a shortcut to solve the immediate pain for most users most of the time.
When you upload the photo, at risk of great confusion they could essentially watermark the photo or add a banner showing the location and perhaps some of the other key details, like camera model, right on the photo so it would at least get across to the user that there is an association between these two things that needs to be disabled.
To dismiss the banner you'd have to click a dismiss button which would ask you to confirm that you want to get rid of the location data completely. Then there would be a tiny little button that says “hide this location inside the photo, where I can't see it easily, but everyone totally could”. (But less stupid.)
It would be terrible because there would be huge support threads on why it's trying to share an image with an overlay, but it would get it across. Would be a different failure mode for user privacy than what you would have with a text prompt or an interstitial or whatever.
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...
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.
True, but isn't it irrational to continue operating something you know could cause harm to you when used wrongly, despite not knowing how to use it correctly?
The hypothetical person we're considering does have an entire life, too. Their rationale may have emerged from careful risk analysis and weighing of opportunity costs.
I agree with you. The next steps should be to disable the internet nationwide like North Korea. People have no idea how much bad things are there. Also I don't like fun things.
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".
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.
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).
Imagine my surprise when I attempted to record the iPhone mirroring application, which was running on macOS. Apple did a great job on their DRM because I simply recorded a black screen while I was attempting to play back a video from an app on the phone.
I'm sure it's given some businesses the confidence to invest in iOS app development, but it felt bad.
Yes, or a video editing app that wants you to buy it.
I'm not _entirely_ upset Apple is encouraging the market to develop high-quality solutions by allowing them to protect their revenue.
But it felt bad as if they were reaching into my Mac.
My iPhone is Apple’s playground. They let me use it. But I own my Mac, and if my eyes see something on the screen it feels dumb to send Tim Apple and Reed Hastings into my homeoffice telling me “no no get a capture card(?) or set up a DSLR to record your screen. But no direct recording big guy!”
Similarly, the native Android photo picker strips the original filename.
This causes daily customer support issues, where people keep asking the app developer why they're renaming their files.
Obviously an image picker shouldn't leak filenames... The filename is a property of the directory entry storing the file storing the image. The image picker only grants access to the image, not to directories, directory entries or files.
If you want filenames, you need to request access to a directory, not to an image
I have had more cases where I was very surprised that the local filename I used for something became part of its record when I uploaded it somewhere. (For instance, uploading an Mp3 using Discord on desktop web.)
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)
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.")
From a technological standpoint, sure. I'd argue when you're staring down the barrel of 19,234 duplicate file deletions, with names like `image01.jpg`, `image02.jpg` instead of `happy_birthday.jpg`, there's a level of perceptual cognitive trust there that I just can't provide.
If your camera (or phone) uses the DCF standard [0], you will eventually end up with duplicates when you hit IMG_9999.JPG and it loops around to IMG_0001.JPG. Filename alone is an unreliable indicator.
Which systems still use this shortsighted convention? All photos I’ve taken with the default camera app in the last many years are named with a timestamp.
> 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.
It's not "obvious" at all, since it's contextual, it depends on the purpose and semantics of whatever service you're uploading the photo to.
Depending on how it'll be used next, not only can the current filename be important, I may even want to give something a custom filename with more data than before.
This a very weird set of choices by Google. How many users are uploading photos from their camera to their phone so they can then upload them from the phone to the web?
I bet almost 100% of photo uploads using the default Android photo picker, or the default Android web browser, are of photos that were taken with the default Android camera app. If Google feels that the location tags and filenames are unacceptably invasive, it can stop writing them that way.
My phone: my private space. Anything in the browser: not my private space.
I want exactly that: the OS to translate between that boundary with a sane default. It’s unavoidable to have cases where this is inconvenient or irritating.
I don’t even know on iPhone how files are named “internally” (nor do I care), since I do not access the native file system or even file format but in 99% of all use cases come in contact only with the exported JPEGs. I do want to see all my photos on a map based on the location they were taken, and I want a timestamp. Locally. Not when I share a photo with a third party.
> If Google feels that the location tags and filenames are unacceptably invasive, it can stop writing them that way.
Something can be "not invasive" when only done locally, but turn out to be a bad idea when you share publicly. Not hard to imagine a lot of users want to organize their libraries by location in a easy way, but still not share the location of every photo they share online.
> Not hard to imagine a lot of users want to organize their libraries by location in a easy way, but still not share the location of every photo they share online.
The location isn't just embedded in the EXIF tags. It's also embedded in the visual content.
I imagine people will get tired of their image uploads being blacked out pretty quickly.
> How many users are uploading photos from their camera to their phone so they can then upload them from the phone to the web?
To _their phone_ specifically? Probably almost nobody. But to their Google/Apple Photos library?
A lot, if not most of people who use DSLRs and other point-and-shoot cameras. Most people want a single library of photos, not segregated based on which device they shot it on.
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.
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.)
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.
After throwing away that thing you will never use to creating filenames far beyond 8.3 format, the problem always comes soon after the matter is fully resolved:
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.
It can handle files with colon in the name fine, Finder just won't let you name them like that. The files themselves work fine if you created them in the Terminal/through sync.
Classic MacOS used colon as a path separator, so to support creating files that could be opened on classic MacOS the Finder disallows it.
Personal notes, and tons of academic papers and ebooks, all of which might contain question marks and colons. Occasionally, I also use arrows -> in travel itineraries / ticket PDFs.
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.
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.
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.
I wish they'd just switch to fuzzing the location instead of stripping it entirely. Instead of specifying 6 digits of lat/lon, publish 1 digit to identify what rough area you're in (to about 10km).
I've done a lot of neat projects with geolocation over the years. Including a personal travel diary, a bunch of visualizations of tweets and Flickr photos, etc etc. I am sad that's become nearly impossible but I do respect that most people don't understand the privacy risk.
Meanwhile on the advertising backend Google knows your exact location and is using it to help third parties target ads to you. And sleazy apps like Grindr sell location streams to anyone who asks. The bad guys get this data, just not the useful apps.
Depending on how populated your current location is, even a fuzzed location can reveal personal information. In a city, 10km is fine, nobody is identified. But if your home is the only one for 10km in any direction, and your fuzzing threshold is 10km, you've identified down to a single home.
Totally disagree, as I think that would be the worst of all possible worlds - too fuzzy to be useful for many of the niche use cases where it's needed, and still a privacy violation for the majority of users who don't know their photos reveal their location.
The other suggestion about requiring something like a useLocation or includeExif attribute on the file picker, and then requiring confirmation from the user, seems like a much better solution to me.
Yes, I get it. It is inconvenient for legitimate uses. The problem is that our devices leak too much confidential data. Privacy was mentioned outright in the article. Safety/security was alluded to with an example, which is something that goes far beyond a company's image or even liability.
Unfortunately, there is no good way to solve the problem while maintaining convenience. As the author noted, prompts while uploading don't really work. Application defaults don't really work for web browsers, since what is acceptable for one website isn't necessarily acceptable for another. Having the user enter the location through the website make the user aware of the information being disclosed, but it is inconvenient.
Does the situation suck? Yes. On the other hand, I think Google is doing the responsible thing here.
Agreed. The default for a web browser should be maximum privacy/minimum sharing/minimum trust. If they want to access photos with geolocation they can make an app instead of a website, then the app can explictly ask for this permission. Too much trouble? Well then I guess it won't get done. Not the end of the world.
I don't know a good solution for this. 99% of websites asking for this hypothetical permission would not deserve it. Users (rightfully) don't expect that uploading a photo leaks their location.
Element (the matrix client) used to not strip geolocation metadata for the longest time. I don't know if they fixed that yet.
I used to run a small website that allowed users to upload pictures. Most people were not aware that they were telling me where they were, when the picture was taken, their altitude, which direction they were facing, etc.
I noticed this in an app's changelog recently, saying something along the lines of "remove metadata comparison function because new Android versions no longer support it"
Thankfully F-Droid has a "never update this app" checkbox for now, but eventually I'm sure third-party developers will require minimum Android versions that mean I need to lose this functionality :/
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.
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 don't like this. The Right Thing is for camera apps to not add location metadata by default.
If you go in and turn location on (which should have a warning on it), then you're the sort of person who changes defaults, a more sophisticated user than the majority of the population who is able to take responsibility for the consequences. Yes, I can imagine a scenario where someone ends up with this setting turned on through no fault of their own, but it shouldn't be the role of an OS vendor to prevent every possible mistake.
The default camera app has this off by default. Most of the ones I've tried do.
But do you remember every options you've randomly toggled over the years? It's pretty easy to see how someone would flip on geotagging, forget about it, then be shocked a few months later when they discover all their photos are leaking their location.
This prevents uploading pictures, with chain of custody data attached, of law enforcement misbehaving. Was there pressure from ICE to install this feature?
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
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
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 ...
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.
In my testing, when sharing from apps that use MediaStore like Google Photos or Fossify Gallery (using a `content://media/` URI), the GPS location was stripped even via Bluetooth. This seems to be the default behavior from Android 10 onwards.
On my Pixel 9 Pro Fold (Android 16) and Oppo Find X3 Pro (Android 13), when I opened a photo in the Google Photos app and selected Share → Bluetooth, the GPS location was stripped. What app did you share from?
However, I confirmed that the GPS location remains when sharing an image file that isn't stored in the MediaStore (for example, placed in the same directory as a .nomedia file).
In this case, only the Share button is displayed at the bottom of the Photos app, and the shared URI is not `content://com.google.android.apps.photos.contentprovider/0/1/content://media/...` but like `content://com.google.android.apps.photos.contentprovider/-1/1/file:///data/...`. You can check the URI by sharing to Intent Intercept app on F-Droid.
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?
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]
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.
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.
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?"
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.
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.
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.
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?
You can choose whether you want to share the location or not when selecting photos in iOS. You'll see at the bottom a label that says "Location is included", and you can click the three dots to remove location:
I know which one works better for us. Which works better for grandma?
(Of course, Google's move shouldn't have been altruistic, it would have been pragmatic as mentioned elsewhere.)
If I got paid a nickel every time someone talked about protecting children online and I reinvested it into technology accessibility for seniors, it'd be fully funded! :)
I just checked in iMessage. When you add an attachment and select photos, you get the same picker that the rest of the OS uses, it's just in a collapsed state. If you swipe up, it'll expand to fill the screen and that same "Location is included" label and configuration menu is available.
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.
It uses native APIs to request the media file from the OS and since the app doesn't request the permission to receive location data along with it, the OS provides the files without the location
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.
It seems the Android heavily modified versions on Chinese phones have been doing this for a long time; I recall for Xiaomi it was MIUI 12—5 versions ago.
Pretty good. I played a bit with gpt-4 a year or so ago by feeding it random screenshots from Google street view. It will pick up a lot of subtle hints from what otherwise looks like generic streets. I imagine more recent models might be better at this now.
I wonder if that might be another reason to just completely disable this feature and not make it a permission: otherwise people could use it to build trainingsets for geoguesser models.
> But it is just so tiresome that Google never consults their community. There was no advance notice of this change that I could find. Just a bunch of frustrated users in my inbox blaming me for breaking something.
I get it. This unequivocally sucks. It's a clear loss of functionality for a group of people who are educated about the advantages and disadvantages of embedded EXIF data. But I don't honestly think Google could have consulted their community. It's just too big. So when the author says:
> Because Google run an anticompetitive monopoly on their dominant mobile operating system.
I don't think the problem here is that Google is anticompetitive (though that's a problem in other areas). I think it's just too big that they can't possibly consult with any meaningful percentage of their 1 billion customers (or however many Android users are out there). They may also feel it's impossible to educate their users about the benefits and dangers of embedded location information (just thinking about myself personally, I'm certain that I'd struggle to convey they nuances of embedded location data to my parents).
I will note that Google Photos seems to happily let you add images to shared albums with embedded location information. I can't recall if you get any privacy-related warnings or notices.
> But I don't honestly think Google could have consulted their community. It's just too big.
The thing is, they frequently do. They have developer relations people, they publish blog posts about breaking changes, they work with W3C and other standards bodies, they reply on bug trackers.
But, in this case, nothing. Just a unilateral change with no communication. Not even a blog posts saying "As of April, this functionality is deprecated."
> 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.
Yes. You can turn it off for Camera if you don't want the geotag to be included in the photo when taken. You can also, as part of the share media picker, opt to include or exclude location data on the photo.
Yeah, toggling in any manner you see fit (a Shortcut would be useful in this case) the location services in its totality or in the context of the Camera app would accomplish the same result.
Surprisingly iOS doesn't do this - at least not for photos uploaded via a web form these days. Try this tool to see that (it should demonstrate the Android EXIF stripping behavior too): https://tools.simonwillison.net/exif
iOS does this by default too, but it tells you about it and gives you the option to not strip the location from EXIF: the bottom of the photo picker has the text "Location not included", and the context menu opened by the "..." button on the left has a "Location" toggle. Just tested this myself on iOS 26.4.1.
Does the location messaging also feel more prominent to you from the Photos share sheet compared to the native image file picker? For example, that you would see when uploading to the ImgUr site.
Mainly top versus bottom placement, I think, but also font size.
I just tested this and the default setting is to include location, but once turned off it stays off (unlike the iPhone share sheet where you need to turn it off each time).
Couldn't you use <input type="file" accept=".jpg,.jpeg"> (different than image/jpeg mime-type I think, not sure if that also strips EXIF?), then manually parse the EXIF in JS? Shouldn't be that complicated to parse and I'm guessing there is a bunch of libraries for doing just that should you not want to do that yourself.
Which correctly seems to show the EXIF for uploaded images (both in Chrome and Firefox), and correctly filters things in the file picker window. What am I missing, why is this infeasible as a solution?
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.
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.
> earnestly-submitted junk data from earnestly-engaged citizens.
What made the data junk? Were the provided coordinates not precise enough, incorrect, something else?
Well that's just it - in most of the submissions the coordinates weren't supplied at all, and when any location information was given it would come down to just a city name or a park name. They're trying to pipe these results into ArcGIS to inform park rangers where to reroute trails, public works departments where to survey before digging, and real estate developers which lots need proper relocation assistance before building on. They were depending on the average citizen to know how to fill out a technical field in this form and to do so accurately, and without and form validation. The whole project needed re-thinking.
Sounds like a combination of 'can it be geocoded?' and 'is their location precise enough?' There is some progress on resolving human-written locations in cities ( https://www.danvk.org/2026/03/08/oldnyc-updates.html ) but I imagine once you lose reference points, '100 feet into Golden Gate Park...' would be interpretable but not possible to fix to one point.
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!
iNaturalist is great for stuff like this as it allows organizations to create projects for data collection on specific species.
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.
> 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
Really? You don’t understand why people wouldn’t want to share their location with the government?
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.
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.
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.
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.
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...
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?
A government agency, which might even have good use for the data, isn't the problem. The problem is sending your precise location to Facebook and a two dozen silly little games and a note app, which all sell this data to anyone and their brother.
By framing the problem as being with untrustworthy government agencies rather than with greedy data brokers selling data everywhere, you are part of the problem. You may distrust your government as much as you'd like, but before we solve the problems with private data brokers, we can never improve the situation.
If I were to visit or migrate to the US, I'd have to take every precaution to avoid ICE mistaking me for an illegal immigrant.
The difference is that private brokers don’t have “a monopoly on [legslized] violence”. Facebook doesn’t have an army of masked jack booted thugs with military gear.
so aaron schwartz is alive?
I was being facetious there, to be clear. my bad.
> I’d wager 99.9% of the users didn’t realize that they are effectively sending their live GPS coords to a random website when taking a photo.
I'd wager 90% of the photos on Google Maps associated with various listings don't actually know their photos are in public. I keep coming across selfies and other photos that look very personal, but somehow someone uploaded to Google Maps, the photo is next to a store or something and Google somehow linked them together, probably by EXIF.
Google 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.
Wait... You post selfies on Google Maps? The thought never crossed my mind. What would the purpose be? Sorry I'm probably thick...
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.
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).
About the latter: that's why Google Maps is my favourite social medium. It's hyper-local.
I will share a thread from someone asking where was their congratulatory email that they've come to expect from Google Maps.
https://www.localguidesconnect.com/t/e-mail-from-google-cong...
Oh... I... don't know what to say about that post. How foreign? :|
Thanks for the insight!
For that sweet local guide score.
I remember arriving in Lisbon, leaving a favorable review for a restaurant because they were so nice to us, and Google sending me a notification that I'm now a local guide for Lisbon.
What exactly does that mean though? Is there any benefits to it? All I see is a badge/label, that's it?
There are some benefits that definitely used to exist, and maybe still exist, like early access to new features and additional Google Drive storage. But in practice today, the only real benefit is the badge.
I really don't know why anyone would try hard to get that. On Chinese map app (Amap) at least you can get a ride hailing coupon, for a nice taxi discount.
If you accrue a high score, Google should give you a plaque like they give to Youtubers with many subscribers.
I had a popup on my iPhone one day "You were in City Park last weekend, would you like to share those photos?". I stopped allowing google access to my photos after that. A little late though, they had apparently scraped all of my data already.
I had a similar moment a few years ago. That Google Maps pop-up was what caused me to first switch to de-googled Android, and once that turned out to be a hassle after a couple of years, switch to an iPhone without Google stuff. (On Android, Google is a location provider, so blocking their access is much harder.)
>On Android, Google is a location provider, so blocking their access is much harder.
https://grapheneos.org/features#network-location
Their approach encompasses GNSS location, too. Nothing Google required.
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.
[dead]
I don't even have G-apps on my phone. They work fine in a browser, until they don't. I was trying to use streetview yesterday and it would not open in the browser and kept trying to redirect me to the app store. So now they are deliberately borking their webapps to punish those not using native apps.
Yeah, there are lots of pages that don't show the (google) map if you don't have google services enabled on your android phone. Not sure if this is something that could be solved on browser level though? I'm quite certain that these pages still work on iphones...
Facebook has done that for a long time. And linkedin, too.
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.
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.
Like IMG_0001 https://news.ycombinator.com/item?id=42314547
> actually using the geolocation is an extremely niche usecase for images uploaded from mobile browsers
Is it only for mobile browsers? The article makes it sound [0] as if it is a general thing, even when sharing through bluetooth, and that only copying the image via usb connection allows you to keep geolocation in exif. Not sure what happens when you upload to native apps, eg to some cloud storage app (photo specific or not). I definitely want my location to stay when I make a cloud backup of my photos with an app intended for that.
[0] Quote:
>> Using a "Progressive Web App" doesn't work either. So, can users transfer their photos via Bluetooth or QuickShare? No. That's now broken as well. You can't even directly share via email without the location being stripped away. Literally the only way to get a photo with geolocation intact is to plug in a USB cable, copy the photo to your computer, and then upload it via a desktop web browser?
I'm guessing they changed the default behavior from "include metadata" to "strip metadata" so now any app that wants metadata has to request it explicitly, and any older apps which don't know how to make such a request are simply unable to get location data?
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...
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.
[0] https://developer.android.com/training/data-storage/shared/m...
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.
> 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...
> 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.
You are not the target audience :)
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.
It is absolutely Apple's job to protect people who do not have the desire or capacity to decide what is a good use case or not from predators (yes, the ad industry is 100% predatory).
The whole reason I and my entire family have iPhones is because there are entire classes of scams and scum that you don't have to be constantly vigilant against. If it didn't do that, I wouldn't buy them.
I'm gonna die on this hill, but silently attaching very sensitive PII (including exact lat/lon) to photos has always been a terrible anti-feature. One of those "WTF were they actually thinking?" terrible anti-features. Imagine if you created a word document and Microsoft silently attached your home address to them as metadata. Awful and totally unexpected to the vast majority of users.
Well Microsoft actually did attach metadata to word files, and it led to the arrest of a serial killer. Not saying they should do it, just found it funny that you picked the one example that did actually happen.
https://www.reddit.com/r/wikipedia/comments/am9mzq/its_neat_...
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>"
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.
> None of my recent photos have location in the EXIF, even locally, and there's no option to turn it on.
You don't have this option?
https://imgur.com/a/piFLtfD
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.
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.
Source: https://developer.android.com/training/data-storage/shared/m...
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
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.
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.
These "all users are imbeciles that need our protection" design pattern needs to die a swift death.
Yes and no one who knows how to change an engine should drive a car. This is why geeks make horrible product people and after 30 years geeks are still waiting for “The Year of Linux on the Desktop”.
What you're advocating for is more like the Bluetooth hijacking when you get in a car of transferring your call from you ear piece to your sound system as if you want to blast your phone call to everyone in the parking lot.
Turn on car doesn't mean hijack Bluetooth connection.
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.
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
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.
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
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.
> 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?
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
That's an incredibly bad analogy.
It’s a great analogy. Every design decision has tradeoffs. Given a choice between optimizing for 90% over 10% is a fair trade
And most people don’t want their location shared with random websites.
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.
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.
Well Apple has had ad blocking extensions for over a decade and full extension support for a few years
Unfortunately, this won't protect you from Apple itself.
Why do I need protection from Apple if my goal is not to deal with ads? Unless you are making the (very valid) point that you still have to deal with ads in the App Store and soon Apple Maps.
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.
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 )
You can probably get around this problem by compressing the file and uploading it in a .zip. Google Files allows for making zip files at least, so I don't think it's a rare feature.
I think the linked spec suggestion makes the most sense: make the feature opt-in in the file picker, probably require the user to grant location permissions when uploading files with EXIF location information.
yeah it does sound kind of dodge that there's no option even for advanced users to bypass this, I would guess mainly a moat to protect Google Photos. I wonder if online photo competitors are finding a workaround or not as searching your photos by location seems like a big feature there
I don't know when Google's EXIF protections are supposed to kick in, but so far my photos auto-synced to Nextcloud still contain location information as expected.
I don't think this has anything to do with Google Photos. People fall victim to doxxing or stalking or even location history tracking by third party apps all the time because they don't realize their pictures contain location information. It's extra confusion to laypeople now that many apps (such as Discord) will strip EXIF data but others (websites, some chat apps) don't.
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.
> 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
Thank you! Meant my comment for anyone who's not on the very latest version, anyone who experienced Android or another OS with disparate privacy-related behaviors as long as that OS has been around. Yes, now, the issue I'm talking about is solved for the general public on the latest Android devices! At reported cost to power users.
Just to add some more context: The change was applied in Android 10, which was released in 2019.
On OS-level there is no reduction in functionality, the implementation just ensures that the user agrees on sharing his location data to an app, and until that has been agreed it is not being shared (as to not hinder any normal app-operation).
Now the fact that the Chrome app doesn't trigger to ask the user-permissions is another topic, with its own (huge) complexity: If the user disagrees to share his location-history to a webpage, and Android can only ensure this for known media file types (while i.e. Windows cannot do this for ANY filetype, and on iOS I believe the user cannot even decide to not have it stripped), Chrome actually cannot commit to any decision taken by the user.
It's a known dilemma in the W3C, the Browser should ensure user privacy but for binary data it technically can't...
This is honestly a horrible argument. Any app on Android can still get EXIF data
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.
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.
Source: https://developer.android.com/training/data-storage/shared/m...
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.
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...
[0] https://www.w3.org/blog/2019/adding-another-permission/
[1] https://www.w3.org/TR/security-privacy-questionnaire/#data-m...
If google really cared about privacy, they wouldn't have moved maps away from a subdomain. now if I want maps to have my location (logical), I need to grant google _search_ my location too.
It's not all-or-nothing; sometimes some people at Google push for some things to improve privacy. Rarely happens when revenue is at stake.
Android used to ask you "do you want to alllow internet access?" as an app permission. Google removed that, as it would stop ads from showing up. Devastating change for privacy and security, great for revenue.
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.
Google is pretty much just a wrapper around DoubleClick.
GrapheneOS still does this -- allows controlling internet access on a per-app basis.
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.
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.
Rethink DNS can block internet access of an app (besides doing DNS-based blocking, etc.): https://rethinkdns.com
It uses the VPN functionality, but you can stack a Wireguard VPN on top of it.
Netguard No Root Firewall still works for me: https://github.com/M66B/NetGuard
+1 for Netguard, it is awesome. A bit clumsy UI, but indispensible.
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:
https://www.reddit.com/r/tasker/comments/1mxjnvs/how_to_bloc...
Not the same thing, but you can install an app like Blokada Libre to block ads and trackers in all apps.
https://blokada.org/
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.
This has the disadvantage that you can’t whitelist specific domains, which is something I need pretty often.
You can signup for private adguard dns, then you should be able to whitelist domains.
Go to settings > App > $SCUMMY_APP > Mobile Data & WiFi. Uncheck all.
Not a thing on stock android
Why does Apple not give that Wi-Fi option there? I mean, is there a reason we’d be sympathetic to?
iOS allows this, but only on mobile data, which is pretty infuriating. Why should I not be able to also restrict apps from dialing home/anywhere just because I'm on a Wi-Fi network (which isn't even necessarily unmetered)?
It's really annoying. I have a sudoku game on my phone, works great but give it internet access and it's suddenly full of sketchy adverts.
If I'm playing it on my commute, it's usable with mobile data disabled for the app. But when the train stops in a station long enough to auto-connect to wifi, immediate full screen adverts :(
The OS ought to let you deny internet access to an app entirely, but DNS-based adblocking might solve your problem: https://mullvad.net/en/help/dns-over-https-and-dns-over-tls
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.
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?
Google doesn't care about privacy, but its easier for them to keep collecting your data if they can also keep it from getting unintentionally leaked to others. The last thing Google wants is for people to start thinking about the amount of data they're handing over.
Google has your location either way. What difference does it make?
You can lock down their usage. Limit it to three months storage and minimize sharing. They still report an old address for home and work for me since I dialed up the restrictions years ago. They have the data but it is less exposed.
I honestly don’t understand the scenario you’re defending against. Google still knows where you actually live and work trivially. If you don’t trust Google you should just de-Google completely.
I also don't trust my government. So should I just degovernment completely? Sounds just as practical or realistic for most people.
"Just move" seems to be a pretty popular sentiment, in that scenario.
As if the government doesn't monitor both non-citizens and ex-citizens living in other countries too.
You’re saying moving on from Google is similar to switching government?
Switching government and deleting google are probably on the same order of magnitude of difficulty for most people.
In a way, yes, as google de facto governs and controls much of the internet.
Have you tried moving on from Google, and preferably not to Apple?
Yes, it’s trivial. What are you having difficulty with? There are plenty of threads here on HN about this
If you think it's trivial you must not be paying attention. You cannot keep your data from Google. Government websites include google tracking. Google drives past your house to take photos and sniff your wifi traffic. Your employer hands your data over to google. Your doctor hands your data over to google. Your bank hands your data over to google. You can limit how much you actively and voluntarily give them, but you can't free yourself from them entirely and still function in society.
Trivial? Ha! Way to say that you never tried it. Either that, or that you don't care for things like push notifications. Yes, most of the things work, but not nearly all of them.
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.
I'm not sure I follow. maps.google.com still resolves?
maps.google.com now redirects to google.com/maps and has done for the past few years.
Ahh I see. Thanks.
[flagged]
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.
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.
Source: https://developer.android.com/training/data-storage/shared/m...
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.
I mean the serial number of the camera and possibly lens are included too…
Not for most phones, fortunately.
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.
Seems like such a shitty thing to victimize the potential victim. But… if you didn’t know that images you took had metadata… maybe you shouldn’t be allowed to use a computer. I mean. I’m going on decades of knowing this. Feel like there is a mid 90s X-Files episode that even like breaks this down. If not NCIS or some shit.
Even people who know it, don't think about it and don't connect it with the potential consequences of uploading a picture to a website. And why would they? It's not visible, there's no warning, it's just not something that's going to be top of mind.
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.
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?
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...
I assume Google are very hesitant to add additional permissions, and any additions get very carefully thought about. Having too many prompts can lead to popup blindness, which defeats the entire purposr of the permission system in the first place.
I'm sure I recall much older Android versions presenting all of the app's permissions at install-time. I'm very willing to bet that most users didn't actually read any of it. Overall, it seems like a very interesting problem to solve.
You're right - this is a shitty view on this. It's incredibly opaque that images secretly contain the GPS coordinates of where they were taken. There's no way that's obvious or intuitive.
I think the 'ideal' thing to do would be an opt-in toggle for sharing "location and other extended info" for photos when selecting them, but I'm sure you can understand why a dev team took a shortcut to solve the immediate pain for most users most of the time.
When you upload the photo, at risk of great confusion they could essentially watermark the photo or add a banner showing the location and perhaps some of the other key details, like camera model, right on the photo so it would at least get across to the user that there is an association between these two things that needs to be disabled.
To dismiss the banner you'd have to click a dismiss button which would ask you to confirm that you want to get rid of the location data completely. Then there would be a tiny little button that says “hide this location inside the photo, where I can't see it easily, but everyone totally could”. (But less stupid.)
It would be terrible because there would be huge support threads on why it's trying to share an image with an overlay, but it would get it across. Would be a different failure mode for user privacy than what you would have with a text prompt or an interstitial or whatever.
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...
100% of the people that don't know that HN exists, most likely don't know images have metadata.
On reddit half of "the is it AI?" question are answered by "Yes, it say so in the metadata".
They could probably include an option for sending metadata for people who want to. I guess it should default to off.
AFAIK a lot of the bigger sites / services already hide or outright strip EXIF.
Its better to do it from the source, obviously.
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.
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.
You don't have to be irrational to not know things.
True, but isn't it irrational to continue operating something you know could cause harm to you when used wrongly, despite not knowing how to use it correctly?
The hypothetical person we're considering does have an entire life, too. Their rationale may have emerged from careful risk analysis and weighing of opportunity costs.
I agree with you. The next steps should be to disable the internet nationwide like North Korea. People have no idea how much bad things are there. Also I don't like fun things.
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".
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.
Source: https://developer.android.com/training/data-storage/shared/m...
Facebook app does the same. All exported photos do not have any EXIF, but you'd be damn well sure they are using that EXIF for themselves.
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).
Requiring someone to have access to another camera is not "theater" if it vastly reduces the liklihood someone will be able to produce a copy.
It gives people a false sense of security. You think the other person can’t copy the photo, but they actually can.
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.
I think that's for apps like Netflix or other movie streaming apps being recorded for piracy?
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!”
As if day 0 rippers needed this sort of mucking around to rip their stuff.
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
"Obviously"
There are plenty of use cases where the filename is relevant (and many, many people intentionally use the image name for sorting / cataloging).
I have had more cases where I was very surprised that the local filename I used for something became part of its record when I uploaded it somewhere. (For instance, uploading an Mp3 using Discord on desktop web.)
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)
So in webmail, when you upload an image / file to attach it to an email, you expect it to be renamed? I don't.
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.
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.
> it will be impossible if the filename changes.
Not impossible, just different and arguably better - comparing hashes is a better tool for finding duplicates.
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.
^ facts
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.
[0]: https://en.wikipedia.org/wiki/Design_rule_for_Camera_File_sy...
> loops around to IMG_0001
Almost all cameras create a new directory, e.g. DSC002, and start from IMG_0001 to prevent collision.
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.
iOS 26
> 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.
https://en.wikipedia.org/wiki/Perceptual_hashing
It's not "obvious" at all, since it's contextual, it depends on the purpose and semantics of whatever service you're uploading the photo to.
Depending on how it'll be used next, not only can the current filename be important, I may even want to give something a custom filename with more data than before.
This a very weird set of choices by Google. How many users are uploading photos from their camera to their phone so they can then upload them from the phone to the web?
I bet almost 100% of photo uploads using the default Android photo picker, or the default Android web browser, are of photos that were taken with the default Android camera app. If Google feels that the location tags and filenames are unacceptably invasive, it can stop writing them that way.
My phone: my private space. Anything in the browser: not my private space.
I want exactly that: the OS to translate between that boundary with a sane default. It’s unavoidable to have cases where this is inconvenient or irritating.
I don’t even know on iPhone how files are named “internally” (nor do I care), since I do not access the native file system or even file format but in 99% of all use cases come in contact only with the exported JPEGs. I do want to see all my photos on a map based on the location they were taken, and I want a timestamp. Locally. Not when I share a photo with a third party.
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
> Anything in the browser: not my private space.
Google’s main business is ads, ie running hostile code on your machine.
> If Google feels that the location tags and filenames are unacceptably invasive, it can stop writing them that way.
Something can be "not invasive" when only done locally, but turn out to be a bad idea when you share publicly. Not hard to imagine a lot of users want to organize their libraries by location in a easy way, but still not share the location of every photo they share online.
> Not hard to imagine a lot of users want to organize their libraries by location in a easy way, but still not share the location of every photo they share online.
The location isn't just embedded in the EXIF tags. It's also embedded in the visual content.
I imagine people will get tired of their image uploads being blacked out pretty quickly.
Definitely. I want to be able to search my Google Photos for "Berlin" and get me all the pictures I took there.
> 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.
I use to send pictures over the camera wifi from my Sony W500 to my phone. The main purpose is backup (think I'm in the middle of nowhere or with little internet for days) and then to send them to friends with WhatsApp. If I'm at home I pull the SD card and read it from my laptop. It's quicker.
I 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.
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.)
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.[0]: https://github.com/GrapheneOS/os-issue-tracker/issues/952
After throwing away that thing you will never use to creating filenames far beyond 8.3 format, the problem always comes soon after the matter is fully resolved:
https://news.ycombinator.com/item?id=29186222
I'm not following?
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.
And you don’t see why Google would cater to Windows and a Mac users at the expense of Linux users?
macOS can also handle files with any of those characters in the filename, it's only Windows that's affected.
You mean 90% of desktop users…
I am surprised that the # symbol isn’t on the list.
Not colon.
It can handle files with colon in the name fine, Finder just won't let you name them like that. The files themselves work fine if you created them in the Terminal/through sync.
Classic MacOS used colon as a path separator, so to support creating files that could be opened on classic MacOS the Finder disallows it.
What types of files are you syncing that have those characters in their names?
Personal notes, and tons of academic papers and ebooks, all of which might contain question marks and colons. Occasionally, I also use arrows -> in travel itineraries / ticket PDFs.
Putting a star into a filename is a pain in the ass, no matter the OS.
Escaping and quoting isn’t really that hard
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.
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!
AFAIK iOS gives you the option to include location data when sharing a photo, no?
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.
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.
I wish they'd just switch to fuzzing the location instead of stripping it entirely. Instead of specifying 6 digits of lat/lon, publish 1 digit to identify what rough area you're in (to about 10km).
I've done a lot of neat projects with geolocation over the years. Including a personal travel diary, a bunch of visualizations of tweets and Flickr photos, etc etc. I am sad that's become nearly impossible but I do respect that most people don't understand the privacy risk.
Meanwhile on the advertising backend Google knows your exact location and is using it to help third parties target ads to you. And sleazy apps like Grindr sell location streams to anyone who asks. The bad guys get this data, just not the useful apps.
Depending on how populated your current location is, even a fuzzed location can reveal personal information. In a city, 10km is fine, nobody is identified. But if your home is the only one for 10km in any direction, and your fuzzing threshold is 10km, you've identified down to a single home.
Fuzzing should go to the centre of the nearest town with some minimum population, so long as that town is in the same state/country/timezone.
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.
Yes, I get it. It is inconvenient for legitimate uses. The problem is that our devices leak too much confidential data. Privacy was mentioned outright in the article. Safety/security was alluded to with an example, which is something that goes far beyond a company's image or even liability.
Unfortunately, there is no good way to solve the problem while maintaining convenience. As the author noted, prompts while uploading don't really work. Application defaults don't really work for web browsers, since what is acceptable for one website isn't necessarily acceptable for another. Having the user enter the location through the website make the user aware of the information being disclosed, but it is inconvenient.
Does the situation suck? Yes. On the other hand, I think Google is doing the responsible thing here.
Agreed. The default for a web browser should be maximum privacy/minimum sharing/minimum trust. If they want to access photos with geolocation they can make an app instead of a website, then the app can explictly ask for this permission. Too much trouble? Well then I guess it won't get done. Not the end of the world.
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.
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.
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 :/
Edit: found it, it was VesIC https://github.com/VincentEngel/VES-Image-Compare/releases/t...
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.
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 don't like this. The Right Thing is for camera apps to not add location metadata by default.
If you go in and turn location on (which should have a warning on it), then you're the sort of person who changes defaults, a more sophisticated user than the majority of the population who is able to take responsibility for the consequences. Yes, I can imagine a scenario where someone ends up with this setting turned on through no fault of their own, but it shouldn't be the role of an OS vendor to prevent every possible mistake.
The default camera app has this off by default. Most of the ones I've tried do.
But do you remember every options you've randomly toggled over the years? It's pretty easy to see how someone would flip on geotagging, forget about it, then be shocked a few months later when they discover all their photos are leaking their location.
This prevents uploading pictures, with chain of custody data attached, of law enforcement misbehaving. Was there pressure from ICE to install this feature?
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
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
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":
https://www.heise.de/en/news/Google-Chrome-makes-cookie-thef...
However had to me this reads as "we control the now private web". This also aligns, in my opinion, with age verification (systemd already pushes for it). So we move into a not so open world wide web. Are you identified? If yes, you can get information; if no you can not. Personally I am in the underground anyway, as long-term linux users so I don't really care that much (though I also use Win10 on a computer on my left side, for various reasons). But I am really annoyed at Google. Every day Google adds to problems and drama. It is not good that this monopoly can control so much in the whole ecosystem, even if I don't understand why people want to share photos and geolocation and what underwear they were wearing at that moment in time ...
I 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)
[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.
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.
You're doing it wrong then. I again verified on Android 16 using native Bluetooth sharing.
On my Pixel 9 Pro Fold (Android 16) and Oppo Find X3 Pro (Android 13), when I opened a photo in the Google Photos app and selected Share → Bluetooth, the GPS location was stripped. What app did you share from?
https://i.imgur.com/cwbigQ8.mp4 before: https://i.imgur.com/ixBvA4T.jpeg after (received): https://i.imgur.com/S5fTEG4.jpeg
However, I confirmed that the GPS location remains when sharing an image file that isn't stored in the MediaStore (for example, placed in the same directory as a .nomedia file). In this case, only the Share button is displayed at the bottom of the Photos app, and the shared URI is not `content://com.google.android.apps.photos.contentprovider/0/1/content://media/...` but like `content://com.google.android.apps.photos.contentprovider/-1/1/file:///data/...`. You can check the URI by sharing to Intent Intercept app on F-Droid.
If you're seeing this all the way back on Android 13, something else is involved. Again, no issues with Android 16. Same STR.
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.
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?
All the GPS data are nulled / set to zero.
I'm not able to repro, but you're likely seeing a problem with your flavor of device overlaid on vanilla Android.
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.
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.
Apple was massively praised when they started stripping location data from shared and uploaded photos.
Apple gives you the option in the photo picker to include or not include the location data.
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.
0. https://bellingcat.gitbook.io/toolkit/more/all-tools/suncalcI 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.
What happens if I upload my images a week from now, in a completely different location?
The problem is that lots of scenic areas have slow or no Internet access. So uploading as you go isn't always practical.
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.
But iOS allows to choose whether location should be included or stripped, and remembers your choice for next upload if I remember correctly.
God, I hate that OSes have nannies that are getting more and more involved, and look at how many HNers like you are saying that it's a great idea...
What's next, "I can't let you view this content, it has been deemed too radical "?
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.
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:
https://phabricator.wikimedia.org/T356260
Just more push and pull on privacy, mostly pulling it away from you, it seems.
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?"
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.
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.
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.
> Android can't stop copying GOS.
Well that's a good thing, isn't it?
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.
Metadata can be attached but it's off by default.
Good?
NSA agent getting burned?
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?
That's the default behavior on Android these days - using the share sheet strips location data.
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.
I feel like that's the optimal implementation - best of both worlds
Wish android copied them for once lol
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! :)
Interesting. How does it work for texting?
I just checked in iMessage. When you add an attachment and select photos, you get the same picker that the rest of the OS uses, it's just in a collapsed state. If you swipe up, it'll expand to fill the screen and that same "Location is included" label and configuration menu is available.
Wow you’re right. I’ve never thought to look there.
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.
Location data is off by default on pretty much all phones.
Is it possible to extract exif info client side (in browser, via javascript) and then upload photo standard way and exif metadata via side channel?
No, the Chrome app doesn't do the stripping.
It uses native APIs to request the media file from the OS and since the app doesn't request the permission to receive location data along with it, the OS provides the files without the location
Related permission: https://developer.android.com/training/data-storage/shared/m...
How lovely, a file read API that lies to you...
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.
It seems the Android heavily modified versions on Chinese phones have been doing this for a long time; I recall for Xiaomi it was MIUI 12—5 versions ago.
Nice drunk theme! All web site should have one.
The author wrote about it here: https://shkspr.mobi/blog/2025/09/drunk-css/
Whew! Glad I can stop tell folks to turn that feature off then.
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.
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.
People already uploaded tons of images and data while playing Pokemon GO. Probably model is already has been built and being tested right now
You still need some smarts, since the picture you just took won't be in the training data.
> But it is just so tiresome that Google never consults their community. There was no advance notice of this change that I could find. Just a bunch of frustrated users in my inbox blaming me for breaking something.
I get it. This unequivocally sucks. It's a clear loss of functionality for a group of people who are educated about the advantages and disadvantages of embedded EXIF data. But I don't honestly think Google could have consulted their community. It's just too big. So when the author says:
> Because Google run an anticompetitive monopoly on their dominant mobile operating system.
I don't think the problem here is that Google is anticompetitive (though that's a problem in other areas). I think it's just too big that they can't possibly consult with any meaningful percentage of their 1 billion customers (or however many Android users are out there). They may also feel it's impossible to educate their users about the benefits and dangers of embedded location information (just thinking about myself personally, I'm certain that I'd struggle to convey they nuances of embedded location data to my parents).
I will note that Google Photos seems to happily let you add images to shared albums with embedded location information. I can't recall if you get any privacy-related warnings or notices.
> But I don't honestly think Google could have consulted their community. It's just too big.
The thing is, they frequently do. They have developer relations people, they publish blog posts about breaking changes, they work with W3C and other standards bodies, they reply on bug trackers.
But, in this case, nothing. Just a unilateral change with no communication. Not even a blog posts saying "As of April, this functionality is deprecated."
> 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.
Hooray for nanny-enabled computing being forced on us!
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.
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.
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.
[dead]
[dead]
[dead]
[dead]
[dead]
Surprisingly iOS doesn't do this - at least not for photos uploaded via a web form these days. Try this tool to see that (it should demonstrate the Android EXIF stripping behavior too): https://tools.simonwillison.net/exif
iOS does this by default too, but it tells you about it and gives you the option to not strip the location from EXIF: the bottom of the photo picker has the text "Location not included", and the context menu opened by the "..." button on the left has a "Location" toggle. Just tested this myself on iOS 26.4.1.
Thanks, just found that option hidden in the "..." and then "Options" menu: https://gist.github.com/simonw/6d530cdca574ac56450dfa805f25e...
Does the location messaging also feel more prominent to you from the Photos share sheet compared to the native image file picker? For example, that you would see when uploading to the ImgUr site.
Mainly top versus bottom placement, I think, but also font size.
I just tested this and the default setting is to include location, but once turned off it stays off (unlike the iPhone share sheet where you need to turn it off each time).
Odd, it was off for me the first time I opened that website, maybe it's persisted from some other context.
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'm not sure why I'm being downvoted for this, so I guess I kind of accidentally nerdsniped myself here...
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?
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.
Aha, that'd explain it. Thanks a bunch for trying it out and telling me!