Direct links to avatar images compromise privacy

[dlthomas]

Fair point. For anyone that wants to tie their Snowdrift identity to others, this isn't a problem, but we should probably make that more explicit and provide a site-hosted option.

[neko-kai]

@dlthomas

For anyone that wants to tie their Snowdrift identity to others, this isn't a problem, but we should probably make that more explicit and provide a site-hosted option.

No, not the profile owner's privacy, the privacy of anyone who views the page.

Note how github (and everybody else) protects against it, I've embedded a logger the line above, but you won't get compromised even if you click the link — github downloaded the image and hosts it on their own servers. (you may get compromised if you click the link in the e-mail, though, I'm unsure.)

[dlthomas]

Ah, right.

[dlthomas]

Of course, Gravatar gets to harvest your github page views... :-P

Regarding what we should do, the most immediate solution is download these and serve a link to our copy. Allowing periodic expiration would allow automatic updating from a single source (the problem gravatar solves for people).

[dlthomas]

Note that this applies equally to anywhere an image can be linked (comments, wiki, profiles); these should all be fixed.

[wolftune]

After some discussion, the tentative plan includes:

• We should offer some hosting where users upload to us through a simple UI, we run pngquant or other compression and host the files
• We compile a whitelist of hosts with acceptable privacy policies (favoring 100% FLO ones, but any trustworthy host is acceptable). We permit those links.
  • We could potentially even integrate with select hosts to automate the upload process if we can figure out all the potential details.

[wolftune]

After discussion with Dave Crossland, who is quite knowledgeable about this stuff, I'm not sure this is really a concern to worry about.

He says "it could have a http://site.tld/aaronwolf/image.png style URL but then its not likely to be very useful for any kind of surveillance well gee i get to know this IP is accessing snowdift.coop regularly. wow, big insight."

[wolftune]

https://www.libravatar.org/ looks like an option to consider…

Not sure the details, but one of our users already has an avatar from Libravatar: https://snowdrift.coop/u/176

[wolftune]

I still think that this may be a minor issue, as per Dave Crossland's quote above, and that external hosting isn't horrible. And I still want use to look into libravatar. But the update is: we have the first stage of internally-hosted images as at least an option to offer or prefer or even require depending what we think is the right approach here.

[singpolyma]

I agree that self-hosting the avatars (and all assets) is ideal, but probably not blocking for MVP -- should the milestone-beta label be removed?

[wolftune]

I'm not sure we should remove the label, we already have img upload feature! So, the only thing we need to change is to change the form to require it to specify a snowdrift.coop/img/ address. It's an easy fix (although there are non-MVP but important questions about managing the image upload functionality. Anyway, given the situation, I think it makes sense to at least keep this in consideration for beta, even if we don't prioritize it.

[jazzyeagle]

I'm going to try to get to the /u pages next. I'll be looking to change this somehow. Because folks already have avatars from other sites, we may want to discuss whether we want to allow folks to choose an image from off-site or basically break the avatars they currently have and force them to upload a new (to the server) image directly.

Please also note that, at this time, images are stored at a global level, so the image is not specific to just a specific user nor project. If it's in there, in theory, anyone can use it for any purpose. Because we're talking about people's faces (typically), we may want to discuss whether or not we want to add in the capability into the image stuff to identify what user/project an image belongs to in order to be able to apply restrictions on what images pop up when someone goes to change their avatar/project logo (Yes, I know it's uploaded with the appropriate permissions to allow anyone to use the image for any purpose, but at the same time... 1) I don't want people to, by default, use my avatar and try to pretend to be me, 2) I don't necessarily want my face to be the logo of a project (which I probably don't need to worry about, because seriously... Who'd want my ugly face to be the face of their project?!), and 3) I don't want to be wading through a sea of users' faces and a ton of other projects' logos looking for the project logo I just updated for my page).

Just some food for thought...

[wolftune]

There's a new Haskell library for libravatar btw: https://hackage.haskell.org/package/libravatar

[pharpend]

I think someone integrated libravatar support into snowdrift. I'm not sure. Could someone confirm? If so, can this issue be closed.

[chreekat]

It's merged, not sure if deployed On Aug 13, 2015 9:16 PM, "Peter Harpending" notifications@github.com wrote:

I think someone integrated libravatar support into snowdrift. I'm not sure. Could someone confirm? If so, can this issue be closed.

— Reply to this email directly or view it on GitHub https://github.com/snowdriftcoop/snowdrift/issues/106#issuecomment-130959872 .

[wolftune]

Libravatar support is deployed and working, however it isn't enough to close this ticket. In order to close this privacy-related issue, we need to stop allowing people to specify arbitrary image URLs (I think). So, we will need to either require Libravatar or integrate our image upload function or something else.

I'm really not an expert about the privacy concerns here. I'm glad we support Libravatar, but we still need to finish making sure that no options we allow are problematic for privacy (or reject the concern, if appropriate)

[chreekat]

I'm in favor of simply requiring Libravatar for the time beign.

[wolftune]

I'm fine with requiring Libravatar maybe even long-term, just to push Libravatar. All we need to do is to update the code to require it and remove the arbitrary URL option, and link to instructions about how to use it.