Hacker News

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

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.

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!

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

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

In a similar move (silently changing a feature crucial to some users), in Android 11 Google suddenly removed the possibility to use "special" characters

  ":<>?|\*

[0]: https://github.com/GrapheneOS/os-issue-tracker/issues/952

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.

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.

This is the right move. https://github.com/whatwg/html/issues/11724#issuecomment-419... and adding a feature to browsers to explicitly use the info is the best solution really. The problem is that there was a change without a backup solution without making a native app, but preventing people from accidentally uploading their location in an image is the right move. It really needs to be more well known and handled automatically.

Yes, I get it. It is inconvenient for legitimate uses. The problem is that our devices leak too much confidential data. Privacy was mentioned outright in the article. Safety/security was alluded to with an example, which is something that goes far beyond a company's image or even liability.

Unfortunately, there is no good way to solve the problem while maintaining convenience. As the author noted, prompts while uploading don't really work. Application defaults don't really work for web browsers, since what is acceptable for one website isn't necessarily acceptable for another. Having the user enter the location through the website make the user aware of the information being disclosed, but it is inconvenient.

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

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

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

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

I used to run a small website that allowed users to upload pictures. Most people were not aware that they were telling me where they were, when the picture was taken, their altitude, which direction they were facing, etc.

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

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.

My personal pet peeve is that iOS strips exif time taken (probably all exif) through certain flows - I think iMessage does it? So then if my family texts me a photo of a trip way after it happened and I save it it ends up in the wrong part of my photo timeline. Whereas if they share it a different way like Dropbox it comes through with that metadata intact.

I care less about the location data as I usually know where the photos are just by looking at them but I understand there are good use cases for it and agree including location should be a user choice

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

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

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

>So, can users transfer their photos via Bluetooth or QuickShare? .. Literally the only way to get a photo with geolocation intact is to plug in a USB cable

Bluetooth is not QuickShare, stop conflating them. Bluetooth works. I just tried it. It just sends the entire file to the destination, filename intact with all EXIF, no gimmicks, tricks, or extra toggles. As it has always done for 20+ years.

This must be a Chrome thing, not an Android thing, no? I didn't test this but I'd be surprised if Firefox behaved the same.

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.

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

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.

GrapheneOS already does this, since forever. Android can't stop copying GOS. Maybe they'll add a network toggle after a few years and call it a privacy win.

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

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

Nice drunk theme! All web site should have one.

> But it is just so tiresome that Google never consults their community. There was no advance notice of this change that I could find. Just a bunch of frustrated users in my inbox blaming me for breaking something.

I get it. This unequivocally sucks. It's a clear loss of functionality for a group of people who are educated about the advantages and disadvantages of embedded EXIF data. But I don't honestly think Google could have consulted their community. It's just too big. So when the author says:

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

I don't think the problem here is that Google is anticompetitive (though that's a problem in other areas). I think it's just too big that they can't possibly consult with any meaningful percentage of their 1 billion customers (or however many Android users are out there). They may also feel it's impossible to educate their users about the benefits and dangers of embedded location information (just thinking about myself personally, I'm certain that I'd struggle to convey they nuances of embedded location data to my parents).

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

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

Is location sharing something you can disable in iOS?

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

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]

How good are LLMs at geoguessing?

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

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.