Is that cursed? Seems like the right privacy-focused default behavior and good design to me
Imo the cursed part is that only some so that and not all.
It’s cursed because it happens silently, such that you might accidentally be deleting gps data you wanted to keep without noticing, for a reason that you probably wouldn’t think to check, probably instead erroneously filing a bug on the app for doing it.
Unless I’m uploading pictures to cloud storage I want GPS data filed off. I’d rather have some unnecessary bug reports targeting the wrong things then stalkers showing up at my door.
Immich is a self-hosted photo hosting service. They’re listing this in their docs because people are trying to upload photos with GPS data, hitting this cursed behavior because they didn’t give immich Location access (because why would you?), and then filing unnecessary bug reports on them about their disappearing data.
To be clear, no one is against stripping GPS data, that’s not what anyone takes issue with, it’s the silently part that is unexpected behavior.
I think all apps should have those explanation screens of what’s not going to work if you deny X permission and why, especially in the case of an issue like this
It should request location access, and if it’s denied tell the user that it won’t be able to get the location data from images and give them a button to have it ask permission again
I find it to be a bit sketchy in general, because it means the OS is actually parsing and editing the actual bytes of the file contextually when an app tries to access it. Probably making a shadow copy somewhere without the GPS exif data.
But yeah, I agree, at a minimum the OS should pop up a notification that “By default, GPS data will be stripped from the file due to inadequate location permissions” until the user either changes their preference or says “that’s fine, don’t remind me for this app”. Having it happen silently just isn’t good.
You’re probably right but it wouldn’t be a clean implementation for the os to do it. If it was more universal and better documented app devs could just put notices in themselves
It’s the silently part that is the problem. If you want your personal pictures to be stored on your personal cloud, you’re a lot more likely to want location tags attached. If it just told you that it was stripping the tags, then you could disable it for certain apps, Rather than not noticing until you already deleted the original images from the phone.
So if I download an image from the web with GPS data, and then open it in an app that just reads images (so it doesn’t need location permissions)… That app (on some phones) gets a modified version of the file?
Which could make me think that the image doesn’t have location information.
Which could result in me uploading that file using a browser (that does have location permission turned on) to a website, and I think it’s safe to share because there’s no private information in the image, but my phone has conspired to mislead me.
Yes, that is cursed.
I’m also worried that this is why gallery apps would require GPS location just for viewing photos (and their Metadata). Once gallery app has the permission, it can track your location in real time. It’s like this should be a separate permission rather than bundled together.
I agree completely.
I understand the motivation here — apps that lack location permission shouldn’t be able to get backdoor access to your location via your camera roll. That makes sense, because you know damn well every
spywaresocial media company would be doing that if they could.But the reverse is also true: apps that legitimately need to read photos and access all their metadata shouldn’t need to be granted full location access.
I was thinking this as well
this is based, as @nincodedo mentioned before it’s cursed they don’t all do this
That Javascript date indexing one is almost as cursed as fucking tire sizes.
This included that as well.
Where can I find this library?
that bcrypt one (ignoring everything past the first 72 bytes) is concerning
Yep, that’s why mastodon only allows for 72 characters maximum in passwords, I assume.
This is completely fine
