Please file a bug against the internet for making it easy to track you. That said, if you care about these kind of things, gitg just isn't the client for you. Using gravatars is a pretty basic and useful feature. I'm fine with adding an option to disable the use of gravatars, but it definitely won't be opt-in.

I'd like to support request for this feature. I do not see enough reason for sarcasm. Features like fetching from gravatar should be controlled by user.
Please take this request seriously and make is configurable. I would gravatars to be disabled by default.

I would prefer gravatars to be disabled by default.

Actually I haven't noted the upstream comment on this before, probably better, since it would have just made me angry.

"file a bug against the internet for making it easy to track you"
Seems like and extremely self-sustaining argument...
You make software which enables tracking on the internet, and your excuse is that the internet tracks you.
I hope your buddies don't jump off bridges, or would you make an exception and not follow them then?

Further, gravatar is definitely not "basic"... it's just some company that may go down any time.
Much better, btw, would be to use the openly standardised alternative libravatar, which may even perform a bit better in terms of privacy - at least if everyone would use his own server.

And "useful"? It's a nice thing that makes the screen a bit more colourful and fancy - but that's it.
Maybe I should make a startup that allows for the voice of peers to be recorded... or perhaps even their smell... so one could fetch the most recent git commits from Linus in the early morning, before he hasn't showered yet, and - an appropriate device in place - smell how he smells after a night of hardcore coding...


o.O

With one side saying "privacy is a lost cause" and the other saying "you're just producing screen candy", I don't see this bug going in a very productive direction.

Maybe we can step back and pursue the compromise outlined in comment 1: Add an option to opt-out of using 3rd party services for avatars.

(In reply to Matthias Clasen from comment #5)
> With one side saying "privacy is a lost cause" and the other saying "you're
> just producing screen candy", I don't see this bug going in a very
> productive direction.
> 
> Maybe we can step back and pursue the compromise outlined in comment 1: Add
> an option to opt-out of using 3rd party services for avatars.

Indeed, I guess we should take this in several steps. One adding an option to enable/disable it in the prefs dialog. Then we can think about adding other providers and finally make a decision on which service to use as default.

I'd be very happy with a setting for this. Wrt providers, yeah sure, we can allow alternatives (can we list which ones are popular besides gravatar?). I'm not convinced that we should disable avatars by default.

I would like gitg to never make any network connections besides what git needs. Please care for our privacy.

AFAIK doing what gitg does as described in comment #1 is illegal in Germany and thus is distributing gitg. See also https://bugzilla.gnome.org/show_bug.cgi?id=750192 for a more detailled explanation.

@Matthias, et al,
I don't think that opting out is really a help here, as such option would only be noticed by people searching for it.

And who assumes that just by using git, e.g. gravatar could fully track your contacts, your ip addresses, when you're online, which sources you work upon and so on.


The way to go is opt-in, which can of course be a central setting which e.g. all gnome apps could use.


@Christian:
This probably doesn't just apply to Germany, at least most EU countries might be affected as well.
But whether this makes gitg already "illegal" is a completely different question.

In general I'd say don't care on any stupid laws of single countries, but at least here we can say: it's obviously not stupid

Programs shouldn't make communications without asking the user, unless these are totally obvious to any user with common sense.
E.g. it's obvious that a browser or MUA will do all kinds of things on the internet; DNS, http, SMTP, POP3/IMAP, perhaps OSCP, CRL retrival and so on.

But for a git program, only speking git, http, ssh (to the manually chosen git servers) would be something one assumes.
Leaking quite severely private data, especially to a commercial company makes the whole thing surely even more serious.

(In reply to Christoph Anton Mitterer from comment #9)

> But for a git program, only speking git, http, ssh (to the manually chosen
> git servers) would be something one assumes.
> Leaking quite severely private data, especially to a commercial company
> makes the whole thing surely even more serious.

Whats a "git program" ? Things don't fall that neatly into premade categories, and part of allure of software development is that you can make new programs that do new and interesting things by transcending those categories. A "git program" can offer new and useful functionality if it connects to e.g. bug trackers or offers you to connect with other developers via mail or irc (or learn more about them via things like avatars, etc). Laws that consider such innovations "illegal" are cringe-worthy at best.

I obviously don't disagree that we should make an effort to make users aware of the privacy consequences of such features, and offer them ways to control their online footprint. One way is of course to just not use the program if you disagree with the choices made by its developers.

If you just want a "git program", there's always git, the program...

(In reply to Christoph Anton Mitterer from comment #9)
> @Christian:
> This probably doesn't just apply to Germany, at least most EU countries
> might be affected as well.
So maybe this is an issue of internationalization: US default could be "connect to the internet" as opt-out, EU default could be "don't connect to gravatar by default, ask user first" as opt-in. Cultural differences?

The law I referred to exists to protect user's privacy.
From a privacy perspective it is a bad choice to load content from the internet without telling (informing) the user. Making a connection to any web server leaks sensitive data, and users might dislike this. I think that free software should give users freedom to choose whether they want this feature (and the resulting loss of privacy) or not.

(In reply to Matthias Clasen from comment #10)
> I obviously don't disagree that we should make an effort to make users aware
> of the privacy consequences of such features, and offer them ways to control
> their online footprint. One way is of course to just not use the program if
> you disagree with the choices made by its developers.

gitg is just the best Git GUI I've seen.

I think such issues should be considered on a case-by-case basis, based on the privacy policy of the organization in question. We should think about Gravatar's privacy policy (which I have not examined), decide if Gravatar is likely to track our users in practice, and categorically reject it if so (regardless of the features it provides), rather than considering the hypothetical risk that they could choose to track us. If they promise not to track us, then I think it's "good enough." This might be a cultural difference, indeed.

Note that libravitar is the APGL version of Gravatar, and might have a better privacy policy. I haven't investigated either, but libravitar is what we use in Fedora.

Certainly I don't think it's appropriate to consider the laws of particular countries in which GNOME is not established.

(In reply to Christian Stadelmann from comment #11)
> give users freedom to choose whether they want this
> feature (and the resulting loss of privacy) or not.

See comment 6, see comment 7.

commit bb22c056722473c2b17138b842bac2641da843f4
Author: Jesse van den Kieboom <jessevdk@gnome.org>
Date:   Fri Jul 31 08:47:59 2015 +0200

    Make use of gravatar optional and a preference setting
    
    https://bugzilla.gnome.org/show_bug.cgi?id=744159


At the moment the default value for the setting is to use gravatar. I think that changing this default would be a regression for existing users. The setting can be changed in the application preferences.

It should be noted as well that gitg was already caching avatars in-memory per application instance, so an avatar would only be requested once (cache is cleared when forcefully reloading the diff view) and possibly once more when doing a first commit. This eleviates the reported issue somewhat (but doesn't completely remove it of course).

Christoph: is this solution satisfactory for you? If so, please go ahead and close the issue.

In Debian we prefer to respect privacy by default so we would have to override defaults to disable Gravatar which means more work downstream and inconsistent defaults among various GNU/Linux distros.

It would be better to disable Gravatar by default in Gitg:
Better privacy is not a regression by any means and enabling Gravatar support from options dialog should be easy enough for anyone who uses Gitg.
Thanks.

It _is_ a regression for users that enjoy this functionality, I'm 100% sure we end up getting bug reports saying that since version 3.18 avatars do no longer show up if we change the default.

Another possibility would be to ask the user on first time use if the setting is not set yet.

Hey.


@Matthias:
I think one can simply apply some common sense at the question "what's a git" program.
If I do "git foo whatever" on the commandline, gitk, tig, gitg, the Eclipse git Team Provider or anything like that,... than it's IMHO justified to assume that every user can know: when I do this, there will be networking with my git remotes.
The same if one does, e.g. git send-email.

Or when one uses a browser, then one must assume, that all those networking is done, so that the actually desired action (e.g. open webpage xyz) can be fulfilled, which may include DNS, IP, TCP, HTTP, OSCP, CRL retrival and things like that.

These forms of "information" leak, are IMHO not a problem (unless perhaps such program would provide a specific "privacy" mode).


The problem is, if a program leaks information, when this isn't naturally obvious and especially when it's not required for the actual task.

Of course it's always difficult to draw the line, and I didn't claim to know exactly where it would be, but I think some cases are easy to identify as having crossed that line:
- If the browser would every time make a whois query on the TLD, or if e.g. it would automatically send the collected certificates to the EFF as part of their SSL observatory (*without having asked to user for consent*). This would IMHO definitely cross the line.
- Things like Google's safe browsing is already quite questionable, because Google get's basically knowledge of everything I do.
But there one can at least name some benefit, i.e. securing users against known malicious sites. So in that case I think one can argue, whether the default is better to opt-out.


As for gitg, showing the Avatars is definitely not needed for the actual task.
It's a nice add-on. And it's great that the developers implemented it. Actually I'd recommend them to implement the open gravatar alternative (libravatar) as well (which can be less privacy concerning).
But it should be still a deliberate decision of the users whether they want to activate such extra or not, especially when it has no direct benefit (apart from looking fancy) but real disadvantages (the privacy leak).
And this is nothing that anyone of the developers here needs to take personally in any way. =)

What you tell about adding new functionality, like IRC or a bug tracker connection.
Most likely that would also be something that the user would need to do explicitly, or how would git know about which IRC server? How would it know about the right bugtracker?
And even if,... these things would be straight visible (e.g. there would be some chat room in the git client, where the user sees "ohh... I'm chatting here").
Again, gravatar is IMHO different here:
Just by seeing the picture, doesn't automatically imply that there is some privacy leak.
Take for example the X-Face: header of mails, where the image is sent with each mail.
Or take libravatar, which can be decentralised (and IIRC even encrypted), which would also already reduce the information leakage.

"One way is of course to just not use the program if you disagree with the choices made by its developers."
Of course, or one could simply patch it, or block gravatar in iptables, etc. pp.
But I didn't open this bug to offend the developers or degrade their program, but rather to help them to make it better/safer for any of their users.
No one said, they'd have to completely remove the feature... that's why I suggested to make it opt-in configurable.




@Christian...
Internationalisation,... hehe ;-)
Well as I've said we shouldn't look so much to the laws here.

Even when some country like the US has much weaker privacy laws ... and even if their people actually care less,... it doesn't harm to give them an additional protection out-of-the box.



@Michael:
Hmm, case-by-case is difficult here.
A company like Gravatar may promise one just anything, but in reality you have no way of telling whether they adhere to or not.
And even if one would ever find out, it's too late, and one probably wouldn't even have a chance to sue them.
Take google with their 8.8.8.8 nameservers. They also promise not to use that data (i.e. the knowledge what people all over the world resolve).
But in fact, they cannot even make this promise. There are laws in the US and a single national security letter would force them to pass on basically any data to the NSA, FBI, etc.... and do you really believe that these would not use such a valuable data source?
So privacy policy documents are IMHO not worth the paper they're written on (btw: not just in the US, also in the EU)

What one can do on a case-by-case basis is IMHO to look at the technical system and it's implementation, to see how realistic the "threat" is.
For example: as mentioned earlier, libravatar can (theoretically) limit the privacy leak a bit. But in the real world, most people wouldn't set up their own libravatar server but use the "central" one.
And even if - it shouldn't be my peer (i.e. the guy who made some commit in the git repo I'm just looking at) who decides whether I want to leak privacy, but me.




@Jesse:
To be honest, calling disabling this a regression is quite some exaggeration.
Showing the avatar may be a nice thing, but not doing it doesn't in any way break existing functionality.
Also, it should be no problem to add a popup on the first start of the program when the default would have changed to opt-in, which asks whether legacy users would want to leave it enabled or not.

I think it's good that one can now configure it, but I (from my PoV) won't close the bug, and I truly hope you don't feel annoyed.
For the reasons laid out above, I think that the default should be opt-in. Maybe even on a system wide basis (e.g. having one GNOME-Control-Centre setting which controls whether avatar-systems are used, or perhaps even *which* systems are used and in which order,... maybe that should even be something standardised cross-desktop-envs).

Also, I don't think the "regression" (by changing now to a opt-in) for a limited set of users (all current users) than you mention, outweighs the inferior default value for all future users.




@Dmitry:
I'm also from the Debian side, and I'm afraid that I have to tell you, that privacy looks quite bad there in many places (not that I'd claim other distros would do better).
A recent example was the hard-coding of Google's nameservers as fallback into systemd's resolved.
:-(



Best wishes,
Chris.

Hi!

I think this such a "feature" should be removed at all. If this couldn't be done, please let this be only available as an opt-in.

Thanks!

Rereading the issue, I've changed my original mind on this and made the setting opt-in. Thanks for being persistent and taking the time to elaborate the issue.

No worries :) And thanks!

Actually I still think, that "this" is something that should perhaps be solved on a larger scale, and where the big players like the distros (debian, Fedora, Suse, arch) and desktop envs like GNOME, KDE, XFCE, LFCE, Cinnamon, etc. should sit together and think about an easy way how users can configure this "globally"... cause unfortunately there are quite a number of programs which do such things nowadays per default.

Cheers,
Chris.