Anyways, I did this: https://jsbin.com/teriduyexe/edit?html,output
Which correctly seems to show the EXIF for uploaded images (both in Chrome and Firefox), and correctly filters things in the file picker window. What am I missing, why is this infeasible as a solution?
Both just show zeros in the GPS EXIF - the rest of the data are passed through unaltered.
Mainly top versus bottom placement, I think, but also font size.
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]
What's next, "I can't let you view this content, it has been deemed too radical "?
I guess I share to point out that the solution of developing a android native app is not that burdensome, and it is some kind of data you want the user to be intentional with.
Show a location picker with the user's current location and the option to select an alternative location. Not as smooth as using EXIF data, but doable.
Well that's a good thing, isn't it?
Who knows, it may eventually be only available on Motorola devices.
How can we combat being mislead by false AI generated images? I'd say keeping track of provenance is what we should adopt, at least as an option. I hope we will find solutions to propagate images over the net reliably keeping how, when and where they were taken.
https://phabricator.wikimedia.org/T356260
Just more push and pull on privacy, mostly pulling it away from you, it seems.
1. Copy file from A to B
2. Publish file to a public realm
If Google thinks that the average site cannot be trusted to indicate/clarify the difference... Well, that's fair, but (as the blogpost says) I'd rather see some browser permission thing like: "Can this website see original filenames and GPS data inside any media you upload?"
Not sure if there's a way to do that by default, I've never checked.
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
Related permission: https://developer.android.com/training/data-storage/shared/m...
[0] https://www.bellingcat.com/resources/2025/08/14/llms-vs-geol...
I get it. This unequivocally sucks. It's a clear loss of functionality for a group of people who are educated about the advantages and disadvantages of embedded EXIF data. But I don't honestly think Google could have consulted their community. It's just too big. So when the author says:
> Because Google run an anticompetitive monopoly on their dominant mobile operating system.
I don't think the problem here is that Google is anticompetitive (though that's a problem in other areas). I think it's just too big that they can't possibly consult with any meaningful percentage of their 1 billion customers (or however many Android users are out there). They may also feel it's impossible to educate their users about the benefits and dangers of embedded location information (just thinking about myself personally, I'm certain that I'd struggle to convey they nuances of embedded location data to my parents).
I will note that Google Photos seems to happily let you add images to shared albums with embedded location information. I can't recall if you get any privacy-related warnings or notices.
The thing is, they frequently do. They have developer relations people, they publish blog posts about breaking changes, they work with W3C and other standards bodies, they reply on bug trackers.
But, in this case, nothing. Just a unilateral change with no communication. Not even a blog posts saying "As of April, this functionality is deprecated."
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.
As one can imagine, even when turning location services back on, the photo will never contain location data.
(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’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
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?
What made the data junk? Were the provided coordinates not precise enough, incorrect, something else?
I for one am glad that that's the trained reaction of the masses
I'd wager 90% of the photos on Google Maps associated with various listings don't actually know their photos are in public. I keep coming across selfies and other photos that look very personal, but somehow someone uploaded to Google Maps, the photo is next to a store or something and Google somehow linked them together, probably by EXIF.
I sometimes do that for random pictures, even like selfies, which I don't mind popping up there.
Is it only for mobile browsers? The article makes it sound [0] as if it is a general thing, even when sharing through bluetooth, and that only copying the image via usb connection allows you to keep geolocation in exif. Not sure what happens when you upload to native apps, eg to some cloud storage app (photo specific or not). I definitely want my location to stay when I make a cloud backup of my photos with an app intended for that.
[0] Quote:
>> Using a "Progressive Web App" doesn't work either. So, can users transfer their photos via Bluetooth or QuickShare? No. That's now broken as well. You can't even directly share via email without the location being stripped away. Literally the only way to get a photo with geolocation intact is to plug in a USB cable, copy the photo to your computer, and then upload it via a desktop web browser?
Seems like this is possibly related to the ACCESS_MEDIA_LOCATION permission[1], and Google's recent efforts to force applications to migrate to the scoped storage API. See: https://developer.android.com/training/data-storage/shared/m...
Probably someone more versed in Android's APIs could give a better explanation.
[1]: https://developer.android.com/reference/android/Manifest.per...
Can you compress a folder with a photo it and then email that? Just curious.
Phones are computers though, it’s not up to Google or Apple to decide what’s a good use case for my own pictures.
The whole reason I and my entire family have iPhones is because there are entire classes of scams and scum that you don't have to be constantly vigilant against. If it didn't do that, I wouldn't buy them.
https://www.reddit.com/r/wikipedia/comments/am9mzq/its_neat_...
(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>"
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.
Chrome doesn't seem to request that permission, so the OS doesn't provide the location-data to the app.
If your app targets Android 10 (API level 29) or higher and needs to retrieve unredacted EXIF metadata from photos, you need to declare the ACCESS_MEDIA_LOCATION permission in your app's manifest, then request this permission at runtime.
Source: https://developer.android.com/training/data-storage/shared/m...
I have not seen an ad in years.
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".
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...
I'm sure it's given some businesses the confidence to invest in iOS app development, but it felt bad.
https://issuetracker.google.com/issues/268079113 Status: Won't Fix (Intended Behavior).
":<>?|\*
[0]: https://github.com/GrapheneOS/os-issue-tracker/issues/952
Recently, I've been struggling with adding locations to some photos after-the-fact, such as edited photos as well as screenshots (because these screenshots are from location-based apps).
The Photos app always tells me that "location will only be visible inside Photos" -- that is, only to users of the app, and those who I share with inside the app. If the image is downloaded or extracted from the Photos app, apparently it will lose that location info and it won't be stored in the EXIF as normal.
This is because Android, like iOS, seeks to assert control over the JPEG/PNG image file types, and claim them as a special object type which can only be handled by Photos and other image-handling apps.
These image-format objects will no longer be treated as normal files that you can just throw anywhere, but as something that only Photos can handle on your phone, and tied inextricably to the Photos app. Therefore, any metadata that you add shall be stored and managed by Photos, and not in the file itself, because that would be interoperable, and that would be absolutely nuts!
The app is very basic, but has amazingly little barriers to entry. Notably you don't need an account to just report things, what I'd call an "open door" app. Sadly, without gps exif, this is much higher friction now. Pretty pissed at this. It's not hard to design a clean flow that permits to inform the user specifically of location sharing in the picker.
I've done a lot of neat projects with geolocation over the years. Including a personal travel diary, a bunch of visualizations of tweets and Flickr photos, etc etc. I am sad that's become nearly impossible but I do respect that most people don't understand the privacy risk.
Meanwhile on the advertising backend Google knows your exact location and is using it to help third parties target ads to you. And sleazy apps like Grindr sell location streams to anyone who asks. The bad guys get this data, just not the useful apps.
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.
Unfortunately, there is no good way to solve the problem while maintaining convenience. As the author noted, prompts while uploading don't really work. Application defaults don't really work for web browsers, since what is acceptable for one website isn't necessarily acceptable for another. Having the user enter the location through the website make the user aware of the information being disclosed, but it is inconvenient.
Does the situation suck? Yes. On the other hand, I think Google is doing the responsible thing here.
Element (the matrix client) used to not strip geolocation metadata for the longest time. I don't know if they fixed that yet.
I care less about the location data as I usually know where the photos are just by looking at them but I understand there are good use cases for it and agree including location should be a user choice
I used to run a small website that allowed users to upload pictures. Most people were not aware that they were telling me where they were, when the picture was taken, their altitude, which direction they were facing, etc.
Thankfully F-Droid has a "never update this app" checkbox for now, but eventually I'm sure third-party developers will require minimum Android versions that mean I need to lose this functionality :/
Edit: found it, it was VesIC https://github.com/VincentEngel/VES-Image-Compare/releases/t...
If you go in and turn location on (which should have a warning on it), then you're the sort of person who changes defaults, a more sophisticated user than the majority of the population who is able to take responsibility for the consequences. Yes, I can imagine a scenario where someone ends up with this setting turned on through no fault of their own, but it shouldn't be the role of an OS vendor to prevent every possible mistake.
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.
I will never share my location via images with anybody then myself. I do use location for my local Photoprism on my own server
0 https://codeberg.org/Starfish/Imagepipe#how-to-get-the-app
https://www.heise.de/en/news/Google-Chrome-makes-cookie-thef...
However had to me this reads as "we control the now private web". This also aligns, in my opinion, with age verification (systemd already pushes for it). So we move into a not so open world wide web. Are you identified? If yes, you can get information; if no you can not. Personally I am in the underground anyway, as long-term linux users so I don't really care that much (though I also use Win10 on a computer on my left side, for various reasons). But I am really annoyed at Google. Every day Google adds to problems and drama. It is not good that this monopoly can control so much in the whole ecosystem, even if I don't understand why people want to share photos and geolocation and what underwear they were wearing at that moment in time ...
If your app targets Android 10 (API level 29) or higher and needs to retrieve unredacted EXIF metadata from photos, you need to declare the ACCESS_MEDIA_LOCATION permission in your app's manifest, then request this permission at runtime.
Caution: Because you request the ACCESS_MEDIA_LOCATION permission at runtime, there is no guarantee that your app has access to unredacted EXIF metadata from photos. Your app requires explicit user consent to gain access to this information.
I made another quick check on my device, Chrome doesn't have the ACCESS_MEDIA_LOCATION permission and doesn't seem to request it at runtime, so the location info is stripped from the EXIF data (by the OS!) when a file is selected.
Chromium also seems have no feature to ask the user whether he agrees to share the stored location when uploading images, so there is probably no capability to request the permission at runtime.
Not satisfying, I know, but despite some judgements in the tickets the implementation seems to work as designed.
Instead, it could be considered a feature-request for Chrome to ask the user about this on upload, or couple the location-permission of a website to the permission to share EXIF-location data when uploading files (Although I think the logic on that is not really tight, the user giving permission to share his location now doesn't necessarily mean that he agrees to share all his locations from the past from EXIF-data)
[0] https://developer.android.com/training/data-storage/shared/m...
Bluetooth is not QuickShare, stop conflating them. Bluetooth works. I just tried it. It just sends the entire file to the destination, filename intact with all EXIF, no gimmicks, tricks, or extra toggles. As it has always done for 20+ years.
I don't know how modern your Android phone is, but on all of mine sharing via Bluetooth strips away some of the EXIF.
https://developer.android.com/training/data-storage/shared/m...
> Photographs > If your app uses scoped storage, the system hides location information by default
When sharing via FileProvider from file managers like MiXplorer or Total Commander, the raw file is sent as is, and the GPS location stays intact.
I'm pretty sure this is what happens in the iPhone at least, so I'd imagine it is the same in Android.
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.
Something that is very useful to 1% of users is stripped away. And we end up with dumb appliances (and ironically - most likely still no privacy )
I think the linked spec suggestion makes the most sense: make the feature opt-in in the file picker, probably require the user to grant location permissions when uploading files with EXIF location information.
Chrome doesn't seem to request that permission, so the OS doesn't provide the location-data to the app. So Chrome rather ended up in this state by doing nothing, not by explicitly doing something...
If your app targets Android 10 (API level 29) or higher and needs to retrieve unredacted EXIF metadata from photos, you need to declare the ACCESS_MEDIA_LOCATION permission in your app's manifest, then request this permission at runtime.
Source: https://developer.android.com/training/data-storage/shared/m...
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.
As per op, it seems they've shut down _any_ means for you to get the data out of the phone other than using a USB cable.
Chrome doesn't seem to request that permission, so the OS doesn't provide the location-data to the app. So Chrome rather ended up in this state by doing nothing, not by explicitly doing something...
If your app targets Android 10 (API level 29) or higher and needs to retrieve unredacted EXIF metadata from photos, you need to declare the ACCESS_MEDIA_LOCATION permission in your app's manifest, then request this permission at runtime.
Source: https://developer.android.com/training/data-storage/shared/m...
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 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.
Its better to do it from the source, obviously.
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.
This sounds like a downward spiral concerning freedom.
If you want filenames, you need to request access to a directory, not to an image
There are plenty of use cases where the filename is relevant (and many, many people intentionally use the image name for sorting / cataloging).
/User/user/Images/20240110/happy_birthday.jpg
and
/User/user/Desktop/happy_birthday.jpg
are the same image.
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.
I bet almost 100% of photo uploads using the default Android photo picker, or the default Android web browser, are of photos that were taken with the default Android camera app. If Google feels that the location tags and filenames are unacceptably invasive, it can stop writing them that way.
I 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.
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.
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 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 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.
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...
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...
That's not a good position to be in; this duopoly we've allowed to prosper needs to go.
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!”
Cool article btw!
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.
The word default is more appropriately used when the decision can be changed to something the user finds more suitable for their usecase
Google’s main business is ads, ie running hostile code on your machine.
- have a local backup - being able to see them from a larger screen - being able to share them - sync them to home while I am away
I don't upload anything to google photos or apple cloud.
I think it's really neat Google Photos lets you see all photos taken at a particular location. One of my pet peeves is when friends share photos with me that we took together at a gathering and only the ones I took with my phone show up in that list unless I manually add location data. (Inaccurate timestamps are an even more annoying related issue.)
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.
You don't have this option?
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.
I am surprised that the # symbol isn’t on the list.
Classic MacOS used colon as a path separator, so to support creating files that could be opened on classic MacOS the Finder disallows it.
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...
To dismiss the banner you'd have to click a dismiss button which would ask you to confirm that you want to get rid of the location data completely. Then there would be a tiny little button that says “hide this location inside the photo, where I can't see it easily, but everyone totally could”. (But less stupid.)
It would be terrible because there would be huge support threads on why it's trying to share an image with an overlay, but it would get it across. Would be a different failure mode for user privacy than what you would have with a text prompt or an interstitial or whatever.
Now an app maybe just wants to set the image as wallpaper, send it to a printer or set as an avatar, so it requests to read it from storage. The OS injecting a watermark here or adding some UI would break decades of apps...
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.
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.
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.
Yeah no kidding the vulnerable animal population is in the park, that's where all their threats are removed. But sometimes "the park" is 60,000 acres and it would be nice if you could help narrow it down.
You have been paying attention to what’s going on haven’t you?
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.
Wouldn't it be better if people were more tech-literate?
Coddling only works when those who are in charge of the tech play nice. But then breeds people who will more easily fall victim to the bad actors.
People who know about phishing get got by phishing attacks, too. How well has however many years of "cyber awareness training" gone?
The prior threat-model was, that e.g. a camera/gallery app which may/may not have a permission to a users current location, also has access to the history of a users' locations just by scanning the images when showing the camera roll.
It frankly makes sense to create a separate permission just for this location metadata AND strip this data when no permission was granted, I believe everything else would be MUCH harder to explain the user...
I don't think this has anything to do with Google Photos. People fall victim to doxxing or stalking or even location history tracking by third party apps all the time because they don't realize their pictures contain location information. It's extra confusion to laypeople now that many apps (such as Discord) will strip EXIF data but others (websites, some chat apps) don't.
> It's extra confusion to laypeople now that many apps (such as Discord) will strip EXIF data but others (websites, some chat apps) don't.
You've given me a lot of sympathy for the young'uns whose first experiences on the web might have been with EXIF-safe apps. Then one day they use a web browser to send a photo, and there's an entirely new behavior they've never learned.
The article is actually about Google's web browser stripping the EXIF location-data when uploading a photo to a webpage, and the author complains about that behavior.
This is not an implementation of the browser itself. Android Chrome is behaving in that way because the app didn't request the required permission for that data from the OS (which would ask the user), so the files it receives to upload already has the data removed
Not impossible, just different and arguably better - comparing hashes is a better tool for finding duplicates.
[0]: https://en.wikipedia.org/wiki/Design_rule_for_Camera_File_sy...
Almost all cameras create a new directory, e.g. DSC002, and start from IMG_0001 to prevent collision.
Depends on what is meant by a "duplicate." It would be a good idea to get a checksum of the file, which can detect exact data duplicates, but not something where metadata is removed or if the image was rescaled. Perceptual hashing is more expensive but is better distinguish matches between rescaled or cropped images.
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.
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.
Also notable: as of last year, OnePlus allowed mobile and WiFi network toggle, effectively doing the same thing.
It uses the VPN functionality, but you can stack a Wireguard VPN on top of it.
https://www.reddit.com/r/tasker/comments/1mxjnvs/how_to_bloc...
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 :(
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).
https://www.localguidesconnect.com/t/e-mail-from-google-cong...
Thanks for the insight!
What exactly does that mean though? Is there any benefits to it? All I see is a badge/label, that's it?
https://grapheneos.org/features#network-location
Their approach encompasses GNSS location, too. Nothing Google required.
I’ve found a lot of useful podcasts from the ads.
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...
Turn on car doesn't mean hijack Bluetooth connection.
Let me phrase this another way: "Computer, I told you to transfer file, not strip meta data".
About Linux: it won the Unix war, the cloud computing war, the embedded war, and is the most installed OS on the planet.
As far as the BT car issue. I don’t have that issue. I turned off wireless CarPlay, don’t use BT and I connect my phone to my car using a regular old USB C cable to avoid that issue - and it’s more reliable
The problem shouldn't exist. The object should do what we instruct, and not have its own opinions of us and do stuff on our behalf presuming incompetency
Let's take another example, the 4chan-ification of the web making everything ephemeral. All the feed based sites basically hide what you just saw forever. They've fundamentally broken the web and made all content disposable.
It's no longer an addressable public record. It breaks the fundamental storage and organization principles of why computers exist and the fundamental purposes of why they're networked together, as a shared communal record.
Seeing this working well goes back to original online spaces like this in the 1970s https://en.wikipedia.org/wiki/Community_Memory
Or my favorite quote about this
> It was like an interactive bulletin board. This wasn’t a machine behind a locked door calling shots, quantifying your inadequacies… No! You could touch it. It was a radical reversal. We all knew who the computer was. But, this time, it had no idea who we were.” “Sounds like chaos!” Thomas responds.
> “No! It was anything but!” Orion snaps back protectively, “I could sit at the keyboard and it would say”hello human”. A black woman could sit down and it would say “hello human”. Henry Kissinger could. It would say “hello human” and not for any redemption on his part.
> It’s because the computer was taught how to help but nobody had fed it Instruction on how to hate. It was then I first saw the computer as a place. A place of hope: an apotheosis of everything I fight for and every thing I want the world to be.”
Instead we've broken this and made things aggressively caustic to the human spirit and it shows. Social media is a poison because it's designed poisonously.
This is a deep and systemic problem. You didn't have to see it
It's there but you don't have to see it
Ah yes, the good old, "I don't have that particular issue, so I can use my experience to dismiss your concern".
You do realize that sometimes bugs only affect a small percentage of users, right? And even if it affects, say 40% of users, you may personally never see the issue. Does that make it not worth talking about?
The same with the EXIF data being shared. Most people don’t want their location being shared with photos and there have been reports of stalkers using the information
