[ntp:hackers] Privacy: refclock_nmea is now munging lat/long
davehart at gmail.com
Sat Apr 25 23:45:17 UTC 2009
I'm the one who implemented the NMEA reported position truncation and
failed to make it configurable or disclose it in the ChangeLog. I
apologize, I was not trying to sneak it past anyone, but had huge
pile of ntpd improvements in a variety of areas and overlooked the
truncation in describing the refclock_nmea changes. My motivation for
the truncation is a time server of mine sitting on a business-class
residential DSL in an area of large lots (quite a few horse farms
there). Without the truncation, ntpd reports via ntpq a position not
just good enough to narrow it down to a single property, but actually
good enough to tell you which of several structures around the
driveway holds the GPS and timeserver. If the structure in question
is unoccupied at night and there's no dog to bark, a little privacy
goes a long way.
Please forgive me if I respond mostly on a technical front and leave
policy issues to others.
I should have anticipated that position fuzzing would be unwelcome by
people tracking GPS performance via position stability. Ideally, I
would like to see the reference clock interface changed to allow a
distinction between the original timecode string for the clockstats
file and a potentially modified or disabled timecode string for
clockvars. I believe it's useful to allow a configuration where the
untrusted public can use read-only ntpq queries while still obscurinig
the precise position of the time server's GPS antenna.
There are a number of ways to fix the NMEA refclock for Hal's use, and
I'm open to all:
1) Revert the position privacy change (and this could be done
first and something better later)
2) Add a mechanism (presumably a fudge flag) to make the position
3) Extend the reference clock interface to track a user-visible and
an original timecode string separately. User visible to the variables
exposed to ntpq, original to clockstats. Then if you have a flag or
knob to control it, you the choice is about what the user sees, the
clockstats are not affected by the flag/knob.
Arguing for simply reverting the change, the operator can choose to
use the $GPZDA NMEA sentence that lacks position information,
providing privacy with no changes to the traditional
I'm torn on adding a fudge to control it, because refclock_nmea
supports a lot of varied devices and I hate to burn the limited fudge
vars if it can be avoided, such as by separating display from original
timecodes. That might not be enough to avoid a knob, though, as some
NTP servers lack the ability to record clockstats, leaving ntpq the
only way to recover timecode strings for monitoring.
I also take to heart Hal's comment that simply truncating at the ~1
mile fractional minutes is crude and will provide better privacy to
those whose reported position doesn't flicker across a minute
boundary. One approach would be to use a "time" fudge flag to specify
the magnitude to fuzz the position by, possibly also in minutes and
Despite being the person behind the privacy change I am not opposed to
reverting it or otherwise making it more broadly acceptable. I will
start by prototyping changes to the refclock interface to allow for a
different display timecode from the clockstats original. I encourage
anyone interested in the reference clock interface or refclock_nmea to
chime in with their input.
On Sat, Apr 25, 2009 at 10:32 PM, Hal Murray <hmurray at megapathdsl.net> wrote:
> 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.
> 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)
> 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.
> 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
> Is there a wiki page or such describing the policy/philosophy of changes?
> 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
> 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 ...
> These are my opinions, not necessarily my employer's. I hate spam.
> hackers mailing list
> hackers at lists.ntp.org
More information about the hackers