Re: Git Privacy

["nick" <nick@nicholasjohnson.ch>]

Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > and just use them), we should NOT be adding a "--privacy" option
> > that picks rand(24)*60 as UTC offset and pretends that it the
> > timezone of the author, and picks some random timestamp between the
> > timestamp of the latest commit in the repository and the actual
> > wallclock timestamp and pretends that is the author time.  After
> > all, our project is not about coming up with a quality time
> > obfusucation.
>
> We could go to the extreme in the complete opposite, if we do not
> care about the quality of the "privacy" feature, and you could
> probably talk me into adopting below as long as the option or the
> configuration are not named with the word "privacy" in them (a
> "--useless-time" option, or a "core.uselesstime" configuration
> variable, are OK).

I hadn't considered it in my other responses, but calling it --privacy
would be a bad idea for exactly the reasons you laid out. Calling it
--useless-time would be better.

> When the feature is in effect, all timestamps in commit and tag
> objects pretend to be in UTC timezone, and
>
> (1) the commits record the Epoch as its timestamps if there is no
> parent;
>
> (2) the commits record one second after the largest of the
> timestamps as its timestamps of all its parents;
>
> (3) in any case, the same (phoney) timestamp is used for author and
> committer.
>
> (4) the tags record the Epoch as its timestamp if they point at
> trees or blobs.
>
> (5) the tags record one second after the largest timestamp of
> pointee as their timestamp, if they point at tags or commits.
>
> (6) as the reflog is a local matter, its timestamp may be local,
> but it is OK if it ends up being just a useless number if that
> is more convenient to implement.

You're the expert on Git's internals and clearly know best how to
implement this with the least amount of breakage. So I can't comment on
that.

I will say these points seem to be sufficient to satisfy the privacy use
case. I don't think any more can reasonably be expected.

> The resulting history will be shouting that "I am privacy conscious
> and hiding my activities behind a fake clock" in capital letters,
> which I would not call a quality design of a privacy feature, but it
> does completely dissociate the wallclock time from the recorded
> history without breaking the monotonicity of timestamps in the
> recorded history.

Depending on one's threat model, revealing the fact that one is using a
privacy feature/tool isn't necessarily a problem. I agree that perhaps a
really high-quality implementation of a privacy feature could do this,
but I think that's outside the scope and way too much to expect from
devs as you said.

> When the useless-time feature is in use, you cannot expect features
> like "git log --since" would work sensibly, but that is a given, I
> would guess.

There could be a warning in the documentation that this feature may
cause breakage.