291–300 of 330 posts
Earlier quoted context omitted.
Wait... You post selfies on Google Maps? The thought never crossed my mind. What would the purpose be? Sorry I'm probably thick...
For that sweet local guide score.
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
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.
https://www.reddit.com/r/wikipedia/comments/am9mzq/its_neat_...
Earlier quoted context omitted.
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.
This has the disadvantage that you can’t whitelist specific domains, which is something I need pretty often.
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?"
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).
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
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.
It's interesting that Android is actually ahead of iOS on this, as simonw pointed out, iOS still doesn't strip location data from photos uploaded via web forms. This should be the default on both platforms. Most people have no idea they're attaching exact GPS coordinates to every photo they share, and the safety implications alone (stalking, doxxing) make it worth the tradeoff for the small number of use cases that r…
Earlier quoted context omitted.
> 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 pe…
Thank you! Meant my comment for anyone who's not on the very latest version, anyone who experienced Android or another OS with disparate privacy-related behaviors as long as that OS has been around. Yes, now, the issue I'm talking about is solved for the general public on the latest Android devices! At reported cost to power users.
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...