[ntp:hackers] Privacy: refclock_nmea is now munging lat/long
stenn at ntp.org
Sat Apr 25 23:50:23 UTC 2009
> I'm trying to be a good guy and make sure the about to be released -dev code
> doesn't have any surprises, at least in the way I use it.
> I found one. As a privacy measure, the NMEA driver is now munging some of
> the data that gets logged to clockstats. It replaces the fractional part of
> the lat/long with underbars. NMEA uses a weird format for lat/long:
> ddmm.mmmm, so that's truncating the fractional minutes of arc. A minute of
> arc is roughly a mile.
> The comment in the code says that data can leak out via ntpq -c clockvar
> I can't tell if this is a bug or a feature.
> I'm a certified privacy nut, so part of me thinks this is a great idea. On
> the other hand, I use that data for monitoring NMEA devices and I don't see
> any easy way to turn off that munging. (I hacked the source code.) It's
> also a change. I doubt if I'm the only one who looks at that data so others
> will probably get surprised too.
> This brings up a couple of issues.
Clearly, this is an opportunity.
> Note that this approach may not actually work. If you live on a minute
> boundary, the answer will vary between xxxx and xxxx+1. Or if you are in a
> rural area, you might be the only house within a mile. (or only geek)
I'm curious what John Hay and Venu Gopal have to say about this.
If it could be done, I'd like to see a flag bit, or a key id, or
something that would say "report accurate location". Otherwise, the
user could cause a specific value to be returned for the location.
> Another issues is changes. It's hard to fix something without
> breaking something else. I've been assuming that, at least as much as
> possible, old config files and code that looks at log files should
> just keep working. If a change is desired, the new behavior should
> require an edit to the config file.
I generally agree with this.
> Yes, the fine print of the lat/long is pretty obscure and not a good
> example of a significant change, and yes maybe the default for
> security/privacy should be do-the-right-thing rather than backward
> compatibility. At a minimum, I think changes like this should be
> mentioned in the ChangeLog rather than getting lumped under a general
> cleanup or fixing a bug that isn't related.
And while I'm open to having code or change reviews, so far I'm not sure
that we have enough people to do that work. If folks want to volnteer,
I'm game to go ahead and do that. I'm happy to see longer and more
descriptive ChangeLog comments.
> Is there a wiki page or such describing the policy/philosophy of changes?
No, and plesae feel free to start something. I'll help.
> My personal opinion is that this is going too far. If you are
> seriously worried about that level of privacy you should probably
> disable/restrict ntpq probes.
Would it be enough to decide what information would be visible in a
"public" response? Perhaps going to an ntpq response tat is moe
CSV-like, or perhaps along the lines of what is being discussed at
> At a minimum, there should be some simple way, like a configure
> parameter to turn this on/off. Better would be a run-time flag from
> the config file so people using a pre-compiled version shipped with
> their distribution don't have to learn how to compile ntpd from
> sources. Or maybe the pre-munged version should be written to the log
> file. Or ...
I'd rather see this be a runtime config thing.
More information about the hackers