[ntp:hackers] Privacy: refclock_nmea is now munging lat/long

tglassey tglassey at glassey.com
Sun Apr 26 01:49:34 UTC 2009


Harlan Stenn wrote:
> Hal 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.
>>     
>
> Thanks!
>
>   
>> 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  
>> (Yup.)
>>
>> 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.
>>
>> Is there a privacy policy for ntpd?  Where does this fit in?
>>     
>
> 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.
>>     
>
> I agree.
>
> 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
> http://support.ntp.org/bin/view/Dev/NtpVariablesAndNtpq .
>
>   
>> 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.
>   
Exactly - the policy controls on the security provisions should be 
settable based on the use model.
> H
> _______________________________________________
> hackers mailing list
> hackers at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/hackers
>   
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 8.0.238 / Virus Database: 270.12.4/2080 - Release Date: 04/25/09 08:29:00
>
>   



More information about the hackers mailing list