Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No exif #292

Merged
merged 9 commits into from Oct 7, 2014
Merged

No exif #292

merged 9 commits into from Oct 7, 2014

Conversation

mapkyca
Copy link
Member

@mapkyca mapkyca commented Jun 4, 2014

Strips exif data of photo uploads.

Rational: Exif contains sensitive location tracking data, which should not be public, and certainly shouldn't be syndicated. If people complain that location data isn't preserved we can make it configurable, but we should protect users by default - and most of them won't care.

Closes #288

@mapkyca
Copy link
Member Author

mapkyca commented Jun 5, 2014

Ok, latest code now extracts and saves exif against the photo itself. Exif can be safely stripped from the image itself but still used for thumbnail generation.

If we go so far as to strip EXIF from images to protect our customers, we probably shouldn't be storing it at all.
@benwerd
Copy link
Member

benwerd commented Jun 10, 2014

So, I definitely want to store things like GPS data - unless the user doesn't want to. Having all your data joined and analyzed by a third party is creepy; doing it yourself on your own site can be cool and useful. There's a lot you can do if you literally own all your data, and can join it up.

@mapkyca
Copy link
Member Author

mapkyca commented Jun 10, 2014

Hmmm... well, my view is that we need to wean ourselves off the habit of storing data unless there's a compelling reason to do so. Because storing for the sake of storage is a bad habit and is what got us in to trouble in the first place... if it's not there, it can't be hacked and harvested, or NSLed.

I guess what I mean, is we should reset the defaults... so instead of storing unless you have a reason not to, we don't store unless you have a good reason to do so.... so, at the moment, we have no good reason to do so. In the future that may change, but at the moment, what clear specific reason do you have to want to store it?

@mapkyca
Copy link
Member Author

mapkyca commented Jun 10, 2014

(sorry if I came over a bit in your face there! :) )

@timmmmyboy
Copy link
Contributor

From the standpoint of an enduser I can see a lot of useful ways that plugins could interact with exif metadata on photos including geolocation information. A better question I would ask: Is it the prerogative of a particular piece of software to strip out data that exists in an uploaded object? Again, as an end user that has taken photos and uploaded them the idea that parts of that object are being stripped out would be disappointing (even if done with the best of intentions). I mostly bring that up because I see the potential of Known to act as a data locker for people who want to have a central place for their data that they then syndicate out to other services.

@benwerd
Copy link
Member

benwerd commented Jun 10, 2014

@mapkyca, regarding clear reasons, I want to:

  • analyze and aggregate camera settings over time
  • eventually cross-reference GPS in pictures with, eg, FitBit data
  • visualize all my data in all kinds of funky ways I haven't thought of yet

I second @timmmmyboy re: acting as a data locker. This is particularly useful with Known, eg, running on an IndieBox. I think the issues are very different to storing data in a silo, and I do think that being able to gather more data about yourself, somewhere that you genuinely own and control access to, is useful.

That said, I'm totally down with a plugin stripping data for people who want that. Again, it's about control. I don't want to be prescriptive.

@mapkyca
Copy link
Member Author

mapkyca commented Jun 10, 2014

Clearly I'm out voted on this one, but for me it's about safe defaults... Protect the user first, over future functionality which is hypothetical at this point. I can think of a bunch of uses for this data as well, but until they're actually built I see no sense in storing it and every reason not to. When we have a compelling bit of functionality that depends on exif we can revisit the question.

Your average joe, who we are presumably aiming for, isn't even aware of exif and the location and other data attached, so won't miss it and by their lack of knowledge aren't in a position to make an informed choice.

We've no way of knowing what the install environment may be, or where people will take the engine, and we know what the risks are, now, so I firmly believe we should fail safe.

@mapkyca
Copy link
Member Author

mapkyca commented Jun 15, 2014

Exif save reinstated btw..

Conflicts:
	Idno/Entities/File.php
	IdnoPlugins/Photo/Photo.php
@mapkyca
Copy link
Member Author

mapkyca commented Aug 16, 2014

bump

Conflicts:
	Idno/Entities/File.php
@mapkyca
Copy link
Member Author

mapkyca commented Aug 31, 2014

Updated to remove conflicts with new file code

Conflicts:
	Idno/Entities/File.php
	IdnoPlugins/Photo/Photo.php
@mapkyca
Copy link
Member Author

mapkyca commented Oct 6, 2014

Updated to remove conflicts.

benwerd added a commit that referenced this pull request Oct 7, 2014
@benwerd benwerd merged commit d0b366c into idno:master Oct 7, 2014
@mapkyca mapkyca deleted the no-exif branch October 7, 2014 20:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Strip EXIF off attachments
3 participants