zlacker

>>dsr12+(OP)
This is great for some situations. However, my personal policy is to upload my protest content to Google Photos asap (if appropriate). This makes sure your content is off your device if your phone gets confiscated AND it provides (be it thin) layer of authenticity/validation of the content.

>>cowmix+S2
Google Photos isn't going to provide you with any authenticity claims, and metadata gets scrambled by both their "high quality" and "original" settings.

If you want to make sure the actual, original image gets stored safely on another device automatically, use SyncThing or Resilio Sync.

>>mceach+Mc
> metadata gets scrambled by both their "high quality" and "original" settings.

This is NOT true, at least for the "original" setting. Upload an image, download it again - the checksums are identical.

If you modify the time/date or add comments within Google Photos, that new information is kept in a .json file instead of the exif data, but Google NEVER modifies the original photo if you select "original" quality.

>>pgalvi+9o
That's not my experience with a couple Google Pixels, using original quality.

If you fetch your image via takeout or via the API, the image bytes are the same, but the EXIF headers have been changed.

I've tried in both a standard Gmail account and a custom domain. Same behavior.

Are you saying your file SHA is the same from your device and your takeout?

I wonder if I am seeing US-account-exclusive behavior?

>>mceach+wR
Yep, the SHA1/256 checksum of the original on my Android device is the same as the one from both Google Takeout and downloading from the Google Photos Web UI.

Same for the .heic files on my iPhone, too.

>>pgalvi+I56
Interesting, thanks for sharing. I wonder what's different between our accounts and devices.