[HN Gopher] Android now stops you sharing your location in photos
___________________________________________________________________
Android now stops you sharing your location in photos
Author : edent
Score : 296 points
Date : 2026-04-13 11:48 UTC (11 hours ago)
(HTM) web link (shkspr.mobi)
(TXT) w3m dump (shkspr.mobi)
| egeozcan wrote:
| This must be a Chrome thing, not an Android thing, no? I didn't
| test this but I'd be surprised if Firefox behaved the same.
| fouc wrote:
| Or Firefox would still be using android's file system / upload
| process, which probably hands off the photos with geotags
| stripped already.
|
| I'm pretty sure this is what happens in the iPhone at least, so
| I'd imagine it is the same in Android.
| darkhorn wrote:
| Just tested with Firefox 149 on Android 13. There are no
| coordinates when I upload an image to EXIF viewer web sites.
| iamcalledrob wrote:
| 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).
| thaumasiotes wrote:
| This a very weird set of choices by Google. How many users are
| uploading photos from their camera _to their phone_ so they can
| then upload them from the phone to the web?
|
| I bet almost 100% of photo uploads using the default Android
| photo picker, or the default Android web browser, are of photos
| that were taken with the default Android camera app. If Google
| feels that the location tags and filenames are unacceptably
| invasive, it can stop writing them that way.
| embedding-shape wrote:
| > If Google feels that the location tags and filenames are
| unacceptably invasive, it can stop writing them that way.
|
| Something can be "not invasive" when only done locally, but
| turn out to be a bad idea when you share publicly. Not hard
| to imagine a lot of users want to organize their libraries by
| location in a easy way, but still not share the location of
| every photo they share online.
| eru wrote:
| Definitely. I want to be able to search my Google Photos
| for "Berlin" and get me all the pictures I took there.
| thaumasiotes wrote:
| > Not hard to imagine a lot of users want to organize their
| libraries by location in a easy way, but still not share
| the location of every photo they share online.
|
| The location isn't just embedded in the EXIF tags. It's
| also embedded in the visual content.
|
| I imagine people will get tired of their image uploads
| being blacked out pretty quickly.
| 47282847 wrote:
| My phone: my private space. Anything in the browser: not my
| private space.
|
| I want exactly that: the OS to translate between that
| boundary with a sane default. It's unavoidable to have cases
| where this is inconvenient or irritating.
|
| I don't even know on iPhone how files are named "internally"
| (nor do I care), since I do not access the native file system
| or even file format but in 99% of all use cases come in
| contact only with the exported JPEGs. I do want to see all
| _my_ photos on a map based on the location they were taken,
| and I want a timestamp. _Locally_. Not when I share a photo
| with a third party.
| TheLNL wrote:
| It is not _just_ a default when it is the only option.
|
| The word default is more appropriately used when the
| decision can be changed to something the user finds more
| suitable for their usecase
| username223 wrote:
| > Anything in the browser: not my private space.
|
| Google's main business is ads, ie running hostile code on
| your machine.
| klausa wrote:
| > How many users are uploading photos from their camera to
| their phone so they can then upload them from the phone to
| the web?
|
| To _their phone_ specifically? Probably almost nobody. But to
| their Google/Apple Photos library?
|
| A lot, if not most of people who use DSLRs and other point-
| and-shoot cameras. Most people want a single library of
| photos, not segregated based on which device they shot it on.
| pmontra wrote:
| I use to send pictures over the camera wifi from my Sony
| W500 to my phone. The main purpose is backup (think I'm in
| the middle of nowhere or with little internet for days) and
| then to send them to friends with WhatsApp. If I'm at home
| I pull the SD card and read it from my laptop. It's
| quicker.
| prmoustache wrote:
| I do it all the time for different reasons:
|
| - have a local backup - being able to see them from a
| larger screen - being able to share them - sync them to
| home while I am away
|
| I don't upload anything to google photos or apple cloud.
| Ajedi32 wrote:
| Yep, and having location data is really useful for
| organizing said photos.
|
| I think it's really neat Google Photos lets you see all
| photos taken at a particular location. One of my pet peeves
| is when friends share photos with me that we took together
| at a gathering and only the ones I took with my phone show
| up in that list unless I manually add location data.
| (Inaccurate timestamps are an even more annoying related
| issue.)
| lifis wrote:
| Obviously an image picker shouldn't leak filenames... The
| filename is a property of the directory entry storing the file
| storing the image. The image picker only grants access to the
| image, not to directories, directory entries or files.
|
| If you want filenames, you need to request access to a
| directory, not to an image
| butlike wrote:
| The path is different than the filename though. If I want to
| find duplicates, it will be impossible if the filename
| changes. In my use case
|
| /User/user/Images/20240110/happy_birthday.jpg
|
| and
|
| /User/user/Desktop/happy_birthday.jpg
|
| are the same image.
| dns_snek wrote:
| > it will be impossible if the filename changes.
|
| Not impossible, just different and arguably better -
| comparing hashes is a better tool for finding duplicates.
| morissette wrote:
| ^ facts
| butlike wrote:
| From a technological standpoint, sure. I'd argue when
| you're staring down the barrel of 19,234 duplicate file
| deletions, with names like `image01.jpg`, `image02.jpg`
| instead of `happy_birthday.jpg`, there's a level of
| perceptual cognitive trust there that I just can't
| provide.
| tart-lemonade wrote:
| 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_F
| ile_sy...
| hebelehubele wrote:
| > loops around to IMG_0001
|
| Almost all cameras create a new directory, e.g. DSC002,
| and start from IMG_0001 to prevent collision.
| xigoi wrote:
| Which systems still use this shortsighted convention? All
| photos I've taken with the default camera app in the last
| many years are named with a timestamp.
| Barbing wrote:
| iOS 26
| adolph wrote:
| > 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
| sib wrote:
| "Obviously"
|
| There are plenty of use cases where the filename is relevant
| (and many, many people intentionally use the image name for
| sorting / cataloging).
| nslsm wrote:
| There are many, many more cases where the user doesn't
| expect the name to become public when he sends a photo. If
| I send you a photo of a friend that doesn't mean I want you
| to know his name (which is the name I gave the file when I
| saved it)
| bornfreddy wrote:
| So in webmail, when you upload an image / file to attach
| it to an email, you expect it to be renamed? I don't.
| sib wrote:
| I email images as attachments very, very frequently. I go
| through the browser's file picker and I pick out the
| photo by its filename. I would be surprised and angry if
| somewhere along the way the filename got changed to some
| random string without my knowledge and consent.
|
| In fact, I often refer to the name of the photo in the
| body of the email (e.g., "front_before.jpg shows the
| front of the car when I picked it up, front_after.jpg
| shows it after the accident.")
|
| I imagine this is an extremely common use case.
| ieie3366 wrote:
| Most likely: actually using the geolocation is an extremely niche
| usecase for images uploaded from mobile browsers.
|
| I'd wager 99.9% of the users didn't realize that they are
| effectively sending their live GPS coords to a random website
| when taking a photo.
|
| But yes, a prop to the input tag 'includeLocation' which would
| then give the user some popup confirmation prompt would have been
| nice
| embedding-shape wrote:
| > I'd wager 99.9% of the users didn't realize that they are
| effectively sending their live GPS coords to a random website
| when taking a photo.
|
| I'd wager 90% of the photos on Google Maps associated with
| various listings don't actually know their photos are in
| public. I keep coming across selfies and other photos that look
| very personal, but somehow someone uploaded to Google Maps, the
| photo is next to a store or something and Google somehow linked
| them together, probably by EXIF.
| eru wrote:
| Google prompts you in Google Maps if you want to upload your
| picture to Maps.
|
| I sometimes do that for random pictures, even like selfies,
| which I don't mind popping up there.
| PokemonNoGo wrote:
| Wait... You post selfies on Google Maps? The thought never
| crossed my mind. What would the purpose be? Sorry I'm
| probably thick...
| PepperdineG wrote:
| I can say for me that after my father died I posted
| pictures of him at some of his favorite places or from
| favorite trips.
| petu wrote:
| Google Maps app sees that you took photo near POI and
| later in the day asks you in notification if you want to
| share it on maps.
|
| You review the photo and go "lol, sure".
|
| At least for me that doesn't even feel like posting due
| to how frictionless it is and that it's about natural
| discoverability (someone has to click that POI and scroll
| through photos to find it).
| eru wrote:
| About the latter: that's why Google Maps is my favourite
| social medium. It's hyper-local.
| ClikeX wrote:
| For that sweet local guide score.
| embedding-shape wrote:
| I remember arriving in Lisbon, leaving a favorable review
| for a restaurant because they were so nice to us, and
| Google sending me a notification that I'm now a local
| guide for Lisbon.
|
| What exactly does that mean though? Is there any benefits
| to it? All I see is a badge/label, that's it?
| gbear605 wrote:
| There are some benefits that definitely used to exist,
| and maybe still exist, like early access to new features
| and additional Google Drive storage. But in practice
| today, the only real benefit is the badge.
| Barbing wrote:
| 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...
| sixothree wrote:
| I had a popup on my iPhone one day "You were in City Park
| last weekend, would you like to share those photos?". I
| stopped allowing google access to my photos after that. A
| little late though, they had apparently scraped all of my
| data already.
| setopt wrote:
| I had a similar moment a few years ago. That Google Maps
| pop-up was what caused me to first switch to de-googled
| Android, and once that turned out to be a hassle after a
| couple of years, switch to an iPhone without Google
| stuff. (On Android, Google is a location _provider_ , so
| blocking their access is much harder.)
| ThePowerOfFuet wrote:
| >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.
| bornfreddy wrote:
| True. Sidenote: they are still however _push
| notifications_ provider, so good luck getting rid of them
| completely (unless you 're fine with not getting the
| notifications). MicroG is awesome wrt. that as you can
| turn it on/off as you wish, and it just works. GrapheneOS
| however only supports Google services in sandbox, but the
| notifications work sporadically IME (maybe because I keep
| turning them off and on... not sure). So... Pick your
| poison.
| dylan604 wrote:
| I don't even have G-apps on my phone. They work fine in a
| browser, until they don't. I was trying to use streetview
| yesterday and it would not open in the browser and kept
| trying to redirect me to the app store. So now they are
| deliberately borking their webapps to punish those not
| using native apps.
| eru wrote:
| Facebook has done that for a long time. And linkedin,
| too.
| bornfreddy wrote:
| Yeah, there are lots of pages that don't show the
| (google) map if you don't have google services enabled on
| your android phone. Not sure if this is something that
| could be solved on browser level though? I'm quite
| certain that these pages still work on iphones...
| kccqzy wrote:
| I have friends that do that and it's intentional. Had a good
| time at a store or restaurant? Take a selfie and upload to
| Google Maps. Also take a selfie video and upload to Instagram
| stories. It's a way of life that defaults to more sharing.
| harvey9 wrote:
| 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.
| Barbing wrote:
| Like IMG_0001 https://news.ycombinator.com/item?id=42314547
| Shalomboy wrote:
| My first eye-opening moment working within the government was
| with team of herpetologists at the state conservation agency.
| They had a pretty slick public education campaign around
| protecting Gopher Tortoise habitats and a grand call-to-action
| "let the agency know where and when they see their nests". The
| whole thing fell apart because they were getting tons of
| earnestly-submitted junk data from earnestly-engaged citizens.
| Turns out the application was just a form that they asked
| people to fill out. I suggested they ask for user photos and
| scrape the EXIF data or ask them to opt-into sending their
| location and got laughed out of the room. Turns out that they
| discovered users immediately nope out of government websites
| that ask for their location! What a shame.
| MostlyStable wrote:
| A colleague of mine tried doing this after a large sturgeon
| die off in the San Francisco Bay a few years ago. Citizens
| were asked to upload photos of dead sturgeon washed up on
| beaches. They actually got pretty good data (sturgeon are
| very easily identifiable) and lots of participation, but the
| location data ending up being largely useless because it was
| fuzzed (I think by iOS?) to a large enough degree to no
| longer be helpful, and the fields for manual coordinate entry
| had very low usage
| Shalomboy wrote:
| Oh that's fascinating. I hadn't considered OS-level fuzzing
| as a hurdle until now. I'm an pixel guy and typically I get
| decently-accurate location heatmaps in the Photos app when
| I search by location; I wonder how we would have handled
| this. HABs are so difficult, they break my heart.
| Barbing wrote:
| How does iOS decide whether to default to including
| location?
|
| I coulda sworn, even in earlier versions of iOS 26, if you
| told it not to include location when sending a photo once
| then it would not include it by default the next time.
|
| Also I thought that when you uploaded a photo from your
| camera roll to the web I thought it defaulted to no
| location. And that seems to have changed too. (Of course,
| you can still tap a button to withhold location EXIF.)
| latexr wrote:
| > earnestly-submitted junk data from earnestly-engaged
| citizens.
|
| What made the data junk? Were the provided coordinates not
| precise enough, incorrect, something else?
| Shalomboy wrote:
| Well that's just it - in most of the submissions the
| coordinates weren't supplied at all, and when any location
| information was given it would come down to just a city
| name or a park name. They're trying to pipe these results
| into ArcGIS to inform park rangers where to reroute trails,
| public works departments where to survey before digging,
| and real estate developers which lots need proper
| relocation assistance before building on. They were
| depending on the average citizen to know how to fill out a
| technical field in this form and to do so accurately, and
| without and form validation. The whole project needed re-
| thinking.
| mapmeld wrote:
| Sounds like a combination of 'can it be geocoded?' and
| 'is their location precise enough?' There is some
| progress on resolving human-written locations in cities (
| https://www.danvk.org/2026/03/08/oldnyc-updates.html )
| but I imagine once you lose reference points, '100 feet
| into Golden Gate Park...' would be interpretable but not
| possible to fix to one point.
| Shalomboy wrote:
| You're absolutely right. Highways are a little better
| since they have mile markers, but once you get into a
| nature preserve you're dealing with a whole bunch of "If
| you pass the pond with the cattails on your left, you've
| gone too far." Fishermen, it turned out, LOVED sending
| coordinates for stuff they saw so long as their fishing
| spot wasn't nearby.
|
| Cool article btw!
| AlexandrB wrote:
| iNaturalist is great for stuff like this as it allows
| organizations to create projects for data collection on
| specific species.
| mapmeld wrote:
| I've also noticed that iNaturalist also fuzzes exact
| locations for some species within a geographic grid
| (example: zebra) even the ranch zebra in California.
| raw_anon_1111 wrote:
| Really? You don't understand why people wouldn't want to
| share their location with the government?
| Shalomboy wrote:
| I was being facetious there, to be clear. my bad.
| JTbane wrote:
| If a state environmental agency asks you for your location
| on photos that you volunteered to upload and you freak out,
| you might be mentally ill.
| Shalomboy wrote:
| I wouldn't take it that far. For most users we spoke to,
| its often a reflex to deny location privilege popups, and
| on mobile it wasn't easy enough to fix once denied.
| However for some of the less-engaged folks who might be
| out in the park casually and stumbled on something worth
| sharing, the idea that we need their exact location
| probably sounded overbearing. "I told them which park I
| was in, that should be enough!"
|
| Yeah no kidding the vulnerable animal population is in
| the park, that's where all their threats are removed. But
| sometimes "the park" is 60,000 acres and it would be nice
| if you could help narrow it down.
| saltcured wrote:
| Or the permission prompt isn't clearly worded or precise
| enough to understand whether you are allowing the
| location of this one photo to be shared, versus agreeing
| to some ongoing tracking...
| raw_anon_1111 wrote:
| 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?
| xorcist wrote:
| 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.
| raw_anon_1111 wrote:
| 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.
| kelnos wrote:
| I get the reflex to deny permissions (and I also get the
| reflex to _allow_ anything, in the interest of just getting
| the annoying pop-up to go away), but it 's really tiresome
| that we have to expect people to avoid thinking even the
| least bit critically at every juncture.
|
| If you're filling out a form with the express purpose of
| letting someone know specifically where something is... a
| request for location information is reasonable, duh. And I
| won't accept the "people are busy and don't have the time
| and energy to think this through" excuse. If you're taking
| the time to fill out this form, then yes, you have the time
| -- seconds, at most -- to think this through in this
| particular case.
| raw_anon_1111 wrote:
| Right because that has worked so well with PCs over the
| last 40 years. Do you remember the people that had a
| dozen toolbars on their browser because if bundleware?
| Not to mention viruses and ransomware.
| smelendez wrote:
| I wonder if there would be any way to fix this with the right
| messaging. With infinite funding and the right agency
| cooperation, I bet you could include this in a state parks
| app that you could also use for other useful purposes, like
| pulling up trail maps, paying for parking and camping,
| fishing licensing, signing up for volunteer events, receiving
| notifications with news around particular parks you frequent,
| etc.
|
| But in the real world, if you put a QR code at the trailhead
| and said "take a picture of this code. When you see a
| tortoise nest, use the code to go to our website and share
| your exact location."
|
| If people are wary of sharing their location with the
| conservation agency, you might have better luck if the
| website was run by a nongovernmental conservation group?
| Shalomboy wrote:
| > 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.
| NooneAtAll3 wrote:
| > 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
| freehorse wrote:
| > actually using the geolocation is an extremely niche usecase
| for images uploaded from mobile browsers
|
| Is it only for mobile browsers? The article makes it sound [0]
| as if it is a general thing, even when sharing through
| bluetooth, and that only copying the image via usb connection
| allows you to keep geolocation in exif. Not sure what happens
| when you upload to native apps, eg to some cloud storage app
| (photo specific or not). I definitely want my location to stay
| when I make a cloud backup of my photos with an app intended
| for that.
|
| [0] Quote:
|
| >> Using a "Progressive Web App" doesn't work either. So, can
| users transfer their photos via Bluetooth or QuickShare? No.
| That's now broken as well. You can't even directly share via
| email without the location being stripped away. Literally the
| only way to get a photo with geolocation intact is to plug in a
| USB cable, copy the photo to your computer, and then upload it
| via a desktop web browser?
| Ajedi32 wrote:
| 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...
| rickdeckard wrote:
| 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...
| Barbing wrote:
| No way they broke it for Google Photos. Anyone who needs
| location and doesn't do cables, or can't figure this out, can
| simply subscribe!
|
| Can you compress a folder with a photo it and then email
| that? Just curious.
| rickdeckard wrote:
| > 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...
| isodev wrote:
| > 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.
| jen20 wrote:
| It is absolutely Apple's job to protect people who do not
| have the desire or capacity to decide what is a good use case
| or not from predators (yes, the ad industry is 100%
| predatory).
|
| The whole reason I and my entire family have iPhones is
| because there are entire classes of scams and scum that you
| don't have to be constantly vigilant against. If it didn't do
| that, I wouldn't buy them.
| ieie3366 wrote:
| You are not the target audience :)
| kelnos wrote:
| Then I'm not the target audience for _any_ mobile OS, given
| the restrictions of Google 's and Apple's platforms, not to
| mention the inadequacy (for me) of the features sets for
| any of the niche open source alternatives. While I expect
| I'm not in the majority, I'm certainly far from unique.
|
| That's not a good position to be in; this duopoly we've
| allowed to prosper needs to go.
| kristopolous wrote:
| I want the location on every time, without exception.
|
| The current behavior is exactly what I wanted.
|
| These "all users are imbeciles that need our protection" design
| pattern needs to die a swift death.
|
| It's maddening, We're constantly taking kitchen knives and
| replacing them with the colorful plastic toddler version and
| still have the same cutting tasks.
| dylan604 wrote:
| I was a fan of the idea that the OS would strip location data
| on any upload via web/app, but would preserve the data when
| doing specific types of transfers deemed not via third party
| like direct transfer to computer or AirDrop
| kristopolous wrote:
| Upload file doesn't mean mutate file.
|
| No. Upload file means upload file. If you want to mutate
| the file, mutate the file.
|
| When tools assume you're stupid and insert silent surprises
| unrelated to the task they no longer deserve the title
| "tool" because they are fundamentally doing other things.
| raw_anon_1111 wrote:
| Most people have no idea when they upload a "photo" they
| are also letting anyone know their "location". On iOS at
| least, from the browser, you specifically choose whether
| you want to upload a file from the Files app (that lets
| you upload files from iCloud, Google Drive, Dropbox or
| any other storage type service you have installed) or a
| photo.
| kristopolous wrote:
| These "all users are imbeciles that need our protection"
| design pattern needs to die a swift death.
| raw_anon_1111 wrote:
| Yes and no one who knows how to change an engine should
| drive a car. This is why geeks make horrible product
| people and after 30 years geeks are still waiting for
| "The Year of Linux on the Desktop".
| kristopolous wrote:
| What you're advocating for is more like the Bluetooth
| hijacking when you get in a car of transferring your call
| from you ear piece to your sound system as if you want to
| blast your phone call to everyone in the parking lot.
|
| Turn on car doesn't mean hijack Bluetooth connection.
|
| Let me phrase this another way: "Computer, I told you to
| transfer file, not strip meta data".
|
| About Linux: it won the Unix war, the cloud computing
| war, the embedded war, and is the most installed OS on
| the planet.
| raw_anon_1111 wrote:
| And absolutely no one knows they are using Linux. Google
| had to hide all of the Unix underpinnings and do things
| like this to make it usable.
|
| As far as the BT car issue. I don't have that issue. I
| turned off wireless CarPlay, don't use BT and I connect
| my phone to my car using a regular old USB C cable to
| avoid that issue - and it's more reliable
| kristopolous wrote:
| 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
| raw_anon_1111 wrote:
| And the alternative is to inconvenience people who don't
| want to have to press a button every time they get into a
| car to pair BT.
| kelnos wrote:
| > _I don't have that issue._
|
| Ah yes, the good old, "I don't have that particular
| issue, so I can use my experience to dismiss your
| concern".
|
| You do realize that sometimes bugs only affect a small
| percentage of users, right? And even if it affects, say
| 40% of users, you may personally never see the issue.
| Does that make it not worth talking about?
| raw_anon_1111 wrote:
| And what would be the alternative that doesn't have
| tradeoffs? Everytime you get into your car you have to
| press a button to manually pair your phone with it? Then
| another set of users would complain.
|
| The same with the EXIF data being shared. Most people
| don't want their location being shared with photos and
| there have been reports of stalkers using the information
| kelnos wrote:
| That's an incredibly bad analogy.
| raw_anon_1111 wrote:
| It's a great analogy. Every design decision has
| tradeoffs. Given a choice between optimizing for 90% over
| 10% is a fair trade
| raw_anon_1111 wrote:
| And most people don't want their location shared with random
| websites.
| rickdeckard wrote:
| 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...
| shevy-java wrote:
| On that point I would agree - I never used that. But Google
| also lied why it wanted to destroy ublock origin. It was clear
| to everyone that they did it because people can break away from
| ads infiltrating their computers. I can't use the modern www
| anymore without general content blocker; ublock lite is good
| but nowhere as useful as ublock origin was. I notice this when
| I compare e. g. firefox with default chrome. So many websites
| have a totally broken UI. With ublock origin not only can I get
| rid of popups or ads but also horrible UI choices. I use that
| on so many websites to simplify them.
| drnick1 wrote:
| Use IronFox or Fennec, preferably on GrapheneOS. You won't
| have freedom on Google or Apple controlled devices.
|
| I have not seen an ad in years.
| raw_anon_1111 wrote:
| Well Apple has had ad blocking extensions for over a decade
| and full extension support for a few years
| ryandrake wrote:
| I'm gonna die on this hill, but silently attaching very
| sensitive PII (including exact lat/lon) to photos has always
| been a terrible anti-feature. One of those "WTF were they
| actually thinking?" terrible anti-features. Imagine if you
| created a word document and Microsoft silently attached your
| home address to them as metadata. Awful and totally unexpected
| to the vast majority of users.
| nullfield wrote:
| As someone else mentioned it IS entirely problematic how
| advertisers/others abuse people, and I get WHY location gets
| stripped. I still think it's abusive to take away the user's
| choice.
|
| (and why do they have to strip almost ALL EXIF data, instead
| of just location? [yes, yes, fingerprinting, but there are
| LOTS of iPhone {NUMBER} whatever out there])
|
| It really just needs to be clearly communicated, opt-in at
| attach time. Probably with a severely hidden, developer-
| screen level, or BIG WARNING in security settings to totally
| disable stripping.
|
| I assume most people won't want it, _usually_, so when adding
| photos just have it be a double-opt in - you have to both hit
| an extra button during attachment, then select "include
| location" or "include location and metadata", then a modal
| warning/confirmation.
|
| Something like: "Confirm including photo location? This will
| permit the recipient to see where the pictures were taken.
| <yes/no>"
| inhumantsar wrote:
| 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.
| ChoGGi wrote:
| > 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
| embedding-shape wrote:
| Couldn't you use <input type="file" accept=".jpg,.jpeg">
| (different than image/jpeg mime-type I think, not sure if that
| also strips EXIF?), then manually parse the EXIF in JS? Shouldn't
| be that complicated to parse and I'm guessing there is a bunch of
| libraries for doing just that should you not want to do that
| yourself.
| embedding-shape wrote:
| 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?
| edent wrote:
| I've just tried that in Chrome and Firefox on Android 16.
|
| Both just show zeros in the GPS EXIF - the rest of the data
| are passed through unaltered.
| embedding-shape wrote:
| Aha, that'd explain it. Thanks a bunch for trying it out
| and telling me!
| sixhobbits wrote:
| It's a sad story and a fun-looking project but I think Google
| 100% did the right thing here. Most people have no idea how much
| information is included in photo metadata, and stripping it as
| much as possible lines up to how people expect the world to work.
| maccard wrote:
| If google really cared about privacy, they wouldn't have moved
| maps away from a subdomain. now if I want maps to have my
| location (logical), I need to grant google _search_ my location
| too.
| butlike wrote:
| I'm not sure I follow. maps.google.com still resolves?
| maccard wrote:
| maps.google.com now redirects to google.com/maps and has
| done for the past few years.
| butlike wrote:
| Ahh I see. Thanks.
| amazingamazing wrote:
| Google has your location either way. What difference does it
| make?
| kevin_thibedeau wrote:
| You can lock down their usage. Limit it to three months
| storage and minimize sharing. They still report an old
| address for home and work for me since I dialed up the
| restrictions years ago. They have the data but it is less
| exposed.
| amazingamazing wrote:
| I honestly don't understand the scenario you're defending
| against. Google still knows where you actually live and
| work trivially. If you don't trust Google you should just
| de-Google completely.
| lukan wrote:
| I also don't trust my government. So should I just
| degovernment completely? Sounds just as practical or
| realistic for most people.
| amazingamazing wrote:
| You're saying moving on from Google is similar to
| switching government?
| lukan wrote:
| In a way, yes, as google de facto governs and controls
| much of the internet.
| Jtarii wrote:
| Switching government and deleting google are probably on
| the same order of magnitude of difficulty for most
| people.
| bornfreddy wrote:
| Have you _tried_ moving on from Google, and preferably
| not to Apple?
| amazingamazing wrote:
| Yes, it's trivial. What are you having difficulty with?
| There are plenty of threads here on HN about this
| shibapuppie wrote:
| "Just move" seems to be a pretty popular sentiment, in
| that scenario.
| lxgr wrote:
| Not GGP, but I suppose the general idea is: Granting
| permanent location permission to maps.google.com seems a
| bit more privacy preserving than granting it to
| *.google.com, assuming one opens maps significantly less
| often than e.g. GMail, search etc.
| edgineer wrote:
| It's not all-or-nothing; sometimes some people at Google push
| for some things to improve privacy. Rarely happens when
| revenue is at stake.
|
| Android used to ask you "do you want to alllow internet
| access?" as an app permission. Google removed that, as it
| would stop ads from showing up. Devastating change for
| privacy and security, great for revenue.
| sathackr wrote:
| GrapheneOS still does this -- allows controlling internet
| access on a per-app basis.
| lukan wrote:
| For those of us stuck on normal android, is there a way
| to achieve that? I know it used to work with some
| firewall apps but nowdays they all require root access.
| Zak wrote:
| 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_b
| loc...
| d2323 wrote:
| Netguard No Root Firewall still works for me:
| https://github.com/M66B/NetGuard
| bornfreddy wrote:
| +1 for Netguard, it is awesome. A bit clumsy UI, but
| indispensible.
| throw_await wrote:
| Go to settings > App > $SCUMMY_APP > Mobile Data & WiFi.
| Uncheck all.
| KomoD wrote:
| Not a thing on stock android
| Barbing wrote:
| Why does Apple not give that Wi-Fi option there? I mean,
| is there a reason we'd be sympathetic to?
| xigoi wrote:
| Not the same thing, but you can install an app like
| Blokada Libre to block ads and trackers in all apps.
|
| https://blokada.org/
| psnehanshu wrote:
| Or you can set your DNS resolver to dns.adguard-dns.com
| and it blocks almost all ads. You can search "private
| dns" in Android settings app and set it there.
| xigoi wrote:
| This has the disadvantage that you can't whitelist
| specific domains, which is something I need pretty often.
| lxgr wrote:
| iOS allows this, but _only on mobile data_ , which is
| pretty infuriating. Why should I not be able to also
| restrict apps from dialing home/anywhere just because I'm
| on a Wi-Fi network (which isn't even necessarily
| unmetered)?
| joosters wrote:
| It's really annoying. I have a sudoku game on my phone,
| works great but give it internet access and it's suddenly
| full of sketchy adverts.
|
| If I'm playing it on my commute, it's usable with mobile
| data disabled for the app. But when the train stops in a
| station long enough to auto-connect to wifi, immediate
| full screen adverts :(
| xp84 wrote:
| I'm gonna be That Guy for a minute: if you enjoy using a
| Sudoku app, isn't there one available on more acceptable
| terms, e.g. a single purchase or a IAP that removes the
| ads from this one? I'm not saying you have to pay like
| $3.99/week for a scam one, but more like pointing out
| that if you don't like ads (as I also don't) why not
| support the developers who believe in selling software to
| you for a few bucks rather than selling your annoyance to
| Google via Adsense?
| raw_anon_1111 wrote:
| Then don't use an ad supported app? I have one as
| supported app on my phone - Overcast. The developer
| created their own ad platform and serves topic based ads
| based on the podcast you are listening to _right now_.
| Ironically enough I started to pay for a subscription
| even though it didn't give me any real benefit just to
| support him until he started having ads.
|
| I've found a lot of useful podcasts from the ads.
| unethical_ban wrote:
| It's one of the big reasons I advocate for graphene even
| if one chooses to install Google services afterward.
|
| Also notable: as of last year, OnePlus allowed mobile and
| WiFi network toggle, effectively doing the same thing.
| WarmWash wrote:
| It's not great for revenue, it is their revenue.
|
| People act like Google products are a charity that had been
| free forever, and then this mega-corp called Google came
| along and started harvesting the data of innocent people
| who just want to get directions to Starbucks.
| username223 wrote:
| Google is pretty much just a wrapper around DoubleClick.
| darkhorn wrote:
| I agree with you. The next steps should be to disable the
| internet nationwide like North Korea. People have no idea how
| much bad things are there. Also I don't like fun things.
| andybak wrote:
| But surely there's a way to do this without totally killing
| valuable functionality? It's like the Android Sideloading
| debate all over again.
|
| Something that is very useful to 1% of users is stripped away.
| And we end up with dumb appliances (and ironically - most
| likely still no privacy )
| sixhobbits wrote:
| yeah it does sound kind of dodge that there's no option even
| for advanced users to bypass this, I would guess mainly a
| moat to protect Google Photos. I wonder if online photo
| competitors are finding a workaround or not as searching your
| photos by location seems like a big feature there
| jeroenhd wrote:
| I don't know when Google's EXIF protections are supposed to
| kick in, but so far my photos auto-synced to Nextcloud
| still contain location information as expected.
|
| I don't think this has anything to do with Google Photos.
| People fall victim to doxxing or stalking or even location
| history tracking by third party apps all the time because
| they don't realize their pictures contain location
| information. It's extra confusion to laypeople now that
| many apps (such as Discord) will strip EXIF data but others
| (websites, some chat apps) don't.
| Barbing wrote:
| Important point:
|
| > It's extra confusion to laypeople now that many apps
| (such as Discord) will strip EXIF data but others
| (websites, some chat apps) don't.
|
| You've given me a lot of sympathy for the young'uns whose
| first experiences on the web might have been with EXIF-
| safe apps. Then one day they use a web browser to send a
| photo, and there's an entirely new behavior they've never
| learned.
| rickdeckard wrote:
| > Then one day they use a web browser to send a photo,
| and there's an entirely new behavior they've never
| learned.
|
| The article is actually about Google's web browser
| stripping the EXIF location-data when uploading a photo
| to a webpage, and the author complains about that
| behavior.
|
| This is not an implementation of the browser itself.
| Android Chrome is behaving in that way because the app
| didn't request the required permission for that data from
| the OS (which would ask the user), so the files it
| receives to upload already has the data removed
| raw_anon_1111 wrote:
| This is honestly a horrible argument. Any _app_ on Android
| can still get EXIF data
| kelnos wrote:
| You're replying to someone who is talking about a native
| app, but the overall issue here is about web apps. Chrome
| and Firefox don't request the appropriate permission
| (which, as things stand right now, is probably the safer
| choice), and there's no way for a website to signal to
| the browser that it wants that permission, so that the
| browser could prompt the user only for websites that ask
| for it, and persist the allow/deny response, similarly to
| how general location permission works via the JS location
| APIs.
| jeroenhd wrote:
| You can probably get around this problem by compressing the
| file and uploading it in a .zip. Google Files allows for
| making zip files at least, so I don't think it's a rare
| feature.
|
| I think the linked spec suggestion makes the most sense: make
| the feature opt-in in the file picker, probably require the
| user to grant location permissions when uploading files with
| EXIF location information.
| rickdeckard wrote:
| 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...
| kelnos wrote:
| That's not sufficient. We need a standardized attribute on
| the HTML form to request the permission as well. If Chrome
| requests the permission, great, but that's not fine-grained
| enough for a web browser.
| rickdeckard wrote:
| 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...
| jorvi wrote:
| AFAIK a lot of the bigger sites / services already hide or
| outright strip EXIF.
|
| Its better to do it from the source, obviously.
| sylario wrote:
| On reddit half of "the is it AI?" question are answered by
| "Yes, it say so in the metadata".
| master-lincoln wrote:
| Because most people have no idea how the tools they chose to
| buy and operate work, the few rational people who educate
| themselves have to suffer...
|
| This sounds like a downward spiral concerning freedom.
| roywiggins wrote:
| You don't have to be _irrational_ to not know things.
| master-lincoln wrote:
| True, but isn't it irrational to continue operating
| something you know could cause harm to you when used
| wrongly, despite not knowing how to use it correctly?
| Barbing wrote:
| The hypothetical person we're considering does have an
| entire life, too. Their rationale may have emerged from
| careful risk analysis and weighing of opportunity costs.
| morissette wrote:
| Seems like such a shitty thing to victimize the potential
| victim. But... if you didn't know that images you took had
| metadata... maybe you shouldn't be allowed to use a computer. I
| mean. I'm going on decades of knowing this. Feel like there is
| a mid 90s X-Files episode that even like breaks this down. If
| not NCIS or some shit.
| pjmlp wrote:
| 100% of the people that don't know that HN exists, most
| likely don't know images have metadata.
| roywiggins wrote:
| Even people who know it, don't think about it and don't
| connect it with the potential consequences of uploading a
| picture to a website. And why would they? It's not visible,
| there's no warning, it's just not something that's going to
| be top of mind.
| SirMaster wrote:
| So we should educate people about it. Don't you think that
| constantly coddling people about tech just breeds tech-
| illiterate people?
|
| Wouldn't it be better if people were more tech-literate?
|
| Coddling only works when those who are in charge of the
| tech play nice. But then breeds people who will more easily
| fall victim to the bad actors.
| roywiggins wrote:
| I said that _people who already know don 't think about
| it_. That's not something you can solve by educating them
| more. When I'm sharing a photo, I am going to think about
| _what I can see in the photo_ as a data risk, not the
| invisible stuff that I might intellectually have heard
| about. It 's just not going to come to mind.
|
| People who know about phishing get got by phishing
| attacks, too. How well has however many years of "cyber
| awareness training" gone?
| rickdeckard wrote:
| 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...
| tentacleuno wrote:
| 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.
| madeofpalk wrote:
| You're right - this is a shitty view on this. It's incredibly
| opaque that images secretly contain the GPS coordinates of
| where they were taken. There's no way that's obvious or
| intuitive.
|
| I think the 'ideal' thing to do would be an opt-in toggle for
| sharing "location and other extended info" for photos when
| selecting them, but I'm sure you can understand why a dev
| team took a shortcut to solve the immediate pain for most
| users most of the time.
| Barbing wrote:
| When you upload the photo, at risk of great confusion they
| could essentially watermark the photo or add a banner
| showing the location and perhaps some of the other key
| details, like camera model, right on the photo so it would
| at least get across to the user that there is an
| association between these two things that needs to be
| disabled.
|
| To dismiss the banner you'd have to click a dismiss button
| which would ask you to confirm that you want to get rid of
| the location data completely. Then there would be a tiny
| little button that says "hide this location inside the
| photo, where I can't see it easily, but everyone totally
| could". (But less stupid.)
|
| It would be terrible because there would be huge support
| threads on why it's trying to share an image with an
| overlay, but it would get it across. Would be a different
| failure mode for user privacy than what you would have with
| a text prompt or an interstitial or whatever.
| rickdeckard wrote:
| Sounds fun, but in this case it's actually the OS which
| is stripping the meta-data before fulfilling the file-
| access request to the app.
|
| Now an app maybe just wants to set the image as
| wallpaper, send it to a printer or set as an avatar, so
| it requests to read it from storage. The OS injecting a
| watermark here or adding some UI would break decades of
| apps...
| lxgr wrote:
| 100% agreed; people generally don't realize how deanonymizing
| EXIF data can be.
|
| I remember one of my cameras or phones including a "seconds
| since device startup" counter; together with the exact time the
| photo was taken, this yields a precise timestamp of when a
| phone was last restarted. This by itself can be highly
| deanonymizing out of a small to medium sized set of candidate
| phones/photographers.
| buildbot wrote:
| I mean the serial number of the camera and possibly lens are
| included too...
| lxgr wrote:
| Not for most phones, fortunately.
| WhyNotHugo wrote:
| It's not that hard to add a little checkmark "include location"
| under it, rather than unconditionally remove it.
|
| As per op, it seems they've shut down _any_ means for you to
| get the data out of the phone other than using a USB cable.
| rickdeckard wrote:
| 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...
| bspammer wrote:
| This kills an entire class of useful crowdsourcing web apps
| though. Just off the top of my head, contributing to OSM is
| much easier when you can just take a bunch of photos and see
| them displayed on a map.
| kelnos wrote:
| You do realize that Google only cares about user privacy when
| it doesn't affect their own business model to do so, right? And
| also, like in this case, where _not_ caring could end up
| creating some nasty headlines that hurt their reputation?
|
| Meanwhile, Google probably has one of the most comprehensive
| databases on the planet of user behavior, gleaned from tracking
| their users all over the internet. Surveillance capitalism at
| its finest. But hey, they protect people from accidentally
| sending their photo geolocations to random websites, so good
| job Google, pat on the back for you.
| adrianN wrote:
| How good are LLMs at geoguessing?
| embedding-shape wrote:
| Basically all up to the training data, as things often are.
| eru wrote:
| You still need some smarts, since the picture you just took
| won't be in the training data.
| xg15 wrote:
| I wonder if that might be another reason to just completely
| disable this feature and not make it a permission: otherwise
| people could use it to build trainingsets for geoguesser
| models.
| GRiMe2D wrote:
| People already uploaded tons of images and data while
| playing Pokemon GO. Probably model is already has been
| built and being tested right now
| firtoz wrote:
| Pretty good. I test it every now and then from random photos.
| Sometimes spot on, sometimes gets very close, unless it's
| really ambiguous.
| jcalx wrote:
| 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...
| jillesvangurp wrote:
| Pretty good. I played a bit with gpt-4 a year or so ago by
| feeding it random screenshots from Google street view. It will
| pick up a lot of subtle hints from what otherwise looks like
| generic streets. I imagine more recent models might be better
| at this now.
| softwaredoug wrote:
| Is location sharing something you can disable in iOS?
| ndegruchy wrote:
| Yes. You can turn it off for Camera if you don't want the
| geotag to be included in the photo when taken. You can also, as
| part of the share media picker, opt to include or exclude
| location data on the photo.
| Barbing wrote:
| You can also for example just by voice ask the phone to turn
| off location services, then take your photos.
|
| As one can imagine, even when turning location services back
| on, the photo will never contain location data.
| ndegruchy wrote:
| Yeah, toggling in any manner you see fit (a Shortcut would
| be useful in this case) the location services in its
| totality or in the context of the Camera app would
| accomplish the same result.
| II2II wrote:
| Yes, I get it. It is inconvenient for legitimate uses. The
| problem is that our devices leak too much confidential data.
| Privacy was mentioned outright in the article. Safety/security
| was alluded to with an example, which is something that goes far
| beyond a company's image or even liability.
|
| Unfortunately, there is no good way to solve the problem while
| maintaining convenience. As the author noted, prompts while
| uploading don't really work. Application defaults don't really
| work for web browsers, since what is acceptable for one website
| isn't necessarily acceptable for another. Having the user enter
| the location through the website make the user aware of the
| information being disclosed, but it is inconvenient.
|
| Does the situation suck? Yes. On the other hand, I think Google
| is doing the responsible thing here.
| SoftTalker wrote:
| Agreed. The default for a web browser should be maximum
| privacy/minimum sharing/minimum trust. If they want to access
| photos with geolocation they can make an app instead of a
| website, then the app can explictly ask for this permission.
| Too much trouble? Well then I guess it won't get done. Not the
| end of the world.
| eminence32 wrote:
| > But it is just so tiresome that Google never consults their
| community. There was no advance notice of this change that I
| could find. Just a bunch of frustrated users in my inbox blaming
| me for breaking something.
|
| I get it. This unequivocally sucks. It's a clear loss of
| functionality for a group of people who are educated about the
| advantages and disadvantages of embedded EXIF data. But I don't
| honestly think Google could have consulted their community. It's
| just too big. So when the author says:
|
| > Because Google run an anticompetitive monopoly on their
| dominant mobile operating system.
|
| I don't think the problem here is that Google is anticompetitive
| (though that's a problem in other areas). I think it's just too
| big that they can't possibly consult with any meaningful
| percentage of their 1 billion customers (or however many Android
| users are out there). They may also feel it's impossible to
| educate their users about the benefits and dangers of embedded
| location information (just thinking about myself personally, I'm
| certain that I'd struggle to convey they nuances of embedded
| location data to my parents).
|
| I will note that Google Photos seems to happily let you add
| images to shared albums with embedded location information. I
| can't recall if you get any privacy-related warnings or notices.
| edent wrote:
| > But I don't honestly think Google could have consulted their
| community. It's just too big.
|
| The thing is, they frequently _do_. They have developer
| relations people, they publish blog posts about breaking
| changes, they work with W3C and other standards bodies, they
| reply on bug trackers.
|
| But, in this case, nothing. Just a unilateral change with no
| communication. Not even a blog posts saying "As of April, this
| functionality is deprecated."
| 1970-01-01 wrote:
| >So, can users transfer their photos via Bluetooth or QuickShare?
| .. Literally the only way to get a photo with geolocation intact
| is to plug in a USB cable
|
| Bluetooth is not QuickShare, stop conflating them. Bluetooth
| works. I just tried it. It just sends the entire file to the
| destination, filename intact with all EXIF, no gimmicks, tricks,
| or extra toggles. As it has always done for 20+ years.
| edent wrote:
| OP here. I'm not conflating them. That's why I used the word
| "or".
|
| I don't know how modern your Android phone is, but on all of
| mine sharing via Bluetooth strips away some of the EXIF.
| 1970-01-01 wrote:
| On Android 16. Open photo. Hit share. Hit Bluetooth. Pick a
| device to send it to. Wait for xfer to finish. Observe in
| exifview. What detail is missing?
| edent wrote:
| All the GPS data are nulled / set to zero.
| 1970-01-01 wrote:
| I'm not able to repro, but you're likely seeing a problem
| with your flavor of device overlaid on vanilla Android.
| ajifurai wrote:
| 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.
| 1970-01-01 wrote:
| You're doing it wrong then. I again verified on Android 16
| using native Bluetooth sharing.
| zenmac wrote:
| Nice drunk theme! All web site should have one.
| OuterVale wrote:
| The author wrote about it here:
| https://shkspr.mobi/blog/2025/09/drunk-css/
| adzm wrote:
| This is the right move.
| https://github.com/whatwg/html/issues/11724#issuecomment-419...
| and adding a feature to browsers to explicitly use the info is
| the best solution really. The problem is that there was a change
| without a backup solution without making a native app, but
| preventing people from accidentally uploading their location in
| an image is the right move. It really needs to be more well known
| and handled automatically.
| jeroenhd wrote:
| While I think it's the right move to disable location tags by
| default, I also think Google should've waited until a solution
| to the missing functionality had at least hit the WHATWG spec.
| master-lincoln wrote:
| I would agree if they switched the order: first make a UI to
| opt-in/out and then change the default. Now they just made
| operations impossible
| flipped wrote:
| GrapheneOS already does this, since forever. Android can't stop
| copying GOS. Maybe they'll add a network toggle after a few years
| and call it a privacy win.
| palata wrote:
| > Android can't stop copying GOS.
|
| Well that's a good thing, isn't it?
| HumblyTossed wrote:
| Good?
| flipped wrote:
| NSA agent getting burned?
| edent wrote:
| I don't think that's quite right. Up until recently I was able
| to share photos with geolocation from my GrapheneOS device.
| flipped wrote:
| Metadata can be attached but it's off by default.
| pjmlp wrote:
| GrapheneOS only exists because Google hasn't yet completely
| closed shop on AOSP availability.
|
| Who knows, it may eventually be only available on Motorola
| devices.
| antiloper wrote:
| I don't know a good solution for this. 99% of websites asking for
| this hypothetical permission would not deserve it. Users
| (rightfully) don't expect that uploading a photo leaks their
| location.
|
| Element (the matrix client) used to not strip geolocation
| metadata for the longest time. I don't know if they fixed that
| yet.
| celsoazevedo wrote:
| For most users, I think this is a good change.
|
| I used to run a small website that allowed users to upload
| pictures. Most people were not aware that they were telling me
| where they were, when the picture was taken, their altitude,
| which direction they were facing, etc.
| p_stuart82 wrote:
| defaulting to strip location on share, fine. demoting plain old
| <input type=file> into "find a usb cable" / "go build an app" is
| a hell of a line to draw
| izacus wrote:
| Apple was massively praised when they started stripping location
| data from shared and uploaded photos.
| bilsbie wrote:
| Does iPhone do this? Kind of scary to be accidentally sending
| your home address anywhere you upload a photo.
| nozzlegear wrote:
| 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.
| sambellll wrote:
| I feel like that's the optimal implementation - best of both
| worlds
|
| Wish android copied them for once lol
| Barbing wrote:
| I know which one works better for us. Which works better
| for grandma?
|
| (Of course, Google's move shouldn't have been altruistic,
| it would have been pragmatic as mentioned elsewhere.)
|
| If I got paid a nickel every time someone talked about
| protecting children online and I reinvested it into
| technology accessibility for seniors, it'd be fully funded!
| :)
| bilsbie wrote:
| Interesting. How does it work for texting?
| nozzlegear wrote:
| 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.
| srcoder wrote:
| 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
| simonw wrote:
| Surprisingly iOS doesn't do this - at least not for photos
| uploaded via a web form these days. Try this tool to see that (it
| should demonstrate the Android EXIF stripping behavior too):
| https://tools.simonwillison.net/exif
| smileybarry wrote:
| 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.
| simonw wrote:
| Thanks, just found that option hidden in the "..." and then
| "Options" menu: https://gist.github.com/simonw/6d530cdca574ac
| 56450dfa805f25e...
| Barbing wrote:
| Does the location messaging also feel more prominent to you
| from the Photos share sheet compared to the native image
| file picker? For example, that you would see when uploading
| to the ImgUr site.
|
| Mainly top versus bottom placement, I think, but also font
| size.
| akamaka wrote:
| I just tested this and the default setting is to include
| location, but once turned off it stays off (unlike the iPhone
| share sheet where you need to turn it off each time).
| smileybarry wrote:
| Odd, it was off for me the first time I opened that
| website, maybe it's persisted from some other context.
| NelsonMinar wrote:
| I wish they'd just switch to fuzzing the location instead of
| stripping it entirely. Instead of specifying 6 digits of lat/lon,
| publish 1 digit to identify what rough area you're in (to about
| 10km).
|
| I've done a lot of neat projects with geolocation over the years.
| Including a personal travel diary, a bunch of visualizations of
| tweets and Flickr photos, etc etc. I am sad that's become nearly
| impossible but I do respect that most people don't understand the
| privacy risk.
|
| Meanwhile on the advertising backend Google knows your exact
| location and is using it to help third parties target ads to you.
| And sleazy apps like Grindr sell location streams to anyone who
| asks. The bad guys get this data, just not the useful apps.
| hn_throwaway_99 wrote:
| Totally disagree, as I think that would be the worst of all
| possible worlds - too fuzzy to be useful for many of the niche
| use cases where it's needed, and still a privacy violation for
| the majority of users who don't know their photos reveal their
| location.
|
| The other suggestion about requiring something like a
| useLocation or includeExif attribute on the file picker, and
| then requiring confirmation from the user, seems like a much
| better solution to me.
| ryandrake wrote:
| Depending on how populated your current location is, even a
| fuzzed location can reveal personal information. In a city,
| 10km is fine, nobody is identified. But if your home is the
| only one for 10km in any direction, and your fuzzing threshold
| is 10km, you've identified down to a single home.
| Zak wrote:
| I don't like this. The Right Thing is for camera apps to not add
| location metadata by default.
|
| If you go in and turn location on (which should have a warning on
| it), then you're the sort of person who changes defaults, a more
| sophisticated user than the majority of the population who is
| able to take responsibility for the consequences. Yes, I can
| imagine a scenario where someone ends up with this setting turned
| on through no fault of their own, but it shouldn't be the role of
| an OS vendor to prevent every possible mistake.
| edent wrote:
| The default camera app has this off by default. Most of the
| ones I've tried do.
|
| But do you remember _every_ options you 've randomly toggled
| over the years? It's pretty easy to see how someone would flip
| on geotagging, forget about it, then be shocked a few months
| later when they discover all their photos are leaking their
| location.
| black_puppydog wrote:
| 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.
| WhyNotHugo wrote:
| This is a common approach to "privacy" taken by orgs like Google.
|
| You don't get to access or export your own data in order to
| protect your privacy, but Google still gets 100% access to it.
|
| Some messaging apps do the same and won't let you take a
| screenshot of your own conversations. Like, someone sent me an
| address, but I can't take a screenshot to "protect my privacy".
| Barbing wrote:
| Imagine my surprise when I attempted to record the iPhone
| mirroring application, which was running on macOS. Apple did a
| great job on their DRM because I simply recorded a black screen
| while I was attempting to play back a video from an app on the
| phone.
|
| I'm sure it's given some businesses the confidence to invest in
| iOS app development, but it felt bad.
| busymom0 wrote:
| I think that's for apps like Netflix or other movie streaming
| apps being recorded for piracy?
| Barbing wrote:
| Yes, or a video editing app that wants you to buy it.
|
| I'm not _entirely_ upset Apple is encouraging the market to
| develop high-quality solutions by allowing them to protect
| their revenue.
|
| But it felt bad as if they were reaching into my Mac.
|
| My iPhone is Apple's playground. They let me use it. But I
| own my Mac, and if my eyes see something on the screen it
| feels dumb to send Tim Apple and Reed Hastings into my
| homeoffice telling me "no no get a capture card(?) or set
| up a DSLR to record your screen. But no direct recording
| big guy!"
| xigoi wrote:
| Which messaging apps are those? I have only seen such behavior
| for one-time photos, where it makes sense (although one-time
| photos are security theater because nothing prevents you from
| taking a photo of the screen with another device).
| rickdeckard wrote:
| 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...
| cobertos wrote:
| 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.
| shevy-java wrote:
| 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 ...
| codethief wrote:
| 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
| ThePowerOfFuet wrote:
| Putting a star into a filename is a pain in the ass, no matter
| the OS.
| xp84 wrote:
| Escaping and quoting isn't really that hard
| raw_anon_1111 wrote:
| Yes and who needs Dropbox since for a Linux user, you can
| already build such a system yourself quite trivially by
| getting an FTP account, mounting it locally with curlftpfs,
| and then using SVN or CVS on the mounted filesystem. From
| Windows or Mac, this FTP account could be accessed through
| built-in software.
| xigoi wrote:
| I have a personal convention that all files I put into my
| synced folder must consist of lowercase alphanumeric
| characters, hyphens and periods (to be precise, match the regex
| /\\.?([a-z0-9]([-.][a-z0-9])?)+/). It saves a lot of pain.
| raw_anon_1111 wrote:
| And you don't see why Google would cater to Windows and a Mac
| users at the expense of Linux users?
| driverdan wrote:
| What types of files are you syncing that have those characters
| in their names?
| 1970-01-01 wrote:
| 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
| Aachen wrote:
| 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...
| drnick1 wrote:
| > If anyone has a working way to let Android web-browsers access
| the full geolocation EXIF metadata of photos uploaded on the web,
| please drop a comment in the box.
|
| No. I don't want people like you unknowingly spying on me when I
| upload a picture. GrapheneOS patched that insane behavior long
| ago, but not including leaky metadata should be the default, sane
| behavior.
| trashb wrote:
| 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.
| izacus wrote:
| Location data is off by default on pretty much all phones.
| rickdeckard wrote:
| 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...
| dgoldstein0 wrote:
| My personal pet peeve is that iOS strips exif time taken
| (probably all exif) through certain flows - I think iMessage does
| it? So then if my family texts me a photo of a trip way after it
| happened and I save it it ends up in the wrong part of my photo
| timeline. Whereas if they share it a different way like Dropbox
| it comes through with that metadata intact.
|
| I care less about the location data as I usually know where the
| photos are just by looking at them but I understand there are
| good use cases for it and agree including location should be a
| user choice
| adolph wrote:
| 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]
|
| 0. https://bellingcat.gitbook.io/toolkit/more/all-tools/suncalc
| CodesInChaos wrote:
| A warning before uploading with the option to strip metadata
| would make sense. But I want to ability to upload a file to a
| website without it getting silently corrupted in transit.
| Johnny555 wrote:
| 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?
| izacus wrote:
| That's the default behavior on Android these days - using the
| share sheet strips location data.
| ButlerianJihad wrote:
| 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!
| rstuart4133 wrote:
| 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.
___________________________________________________________________
(page generated 2026-04-13 23:02 UTC)