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.
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
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...
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...
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...
Android used to ask you "do you want to alllow internet access?" as an app permission. Google removed that, as it would stop ads from showing up. Devastating change for privacy and security, great for revenue.
People act like Google products are a charity that had been free forever, and then this mega-corp called Google came along and started harvesting the data of innocent people who just want to get directions to Starbucks.
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 :(
I’ve found a lot of useful podcasts from the ads.
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.
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'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.
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.
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...
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.