On Fri 2015-01-30 12:57:29 -0500, Lester Caine wrote:
> On 30/01/15 02:13, Daniel Kahn Gillmor wrote:
>> Clients requesting multiple unusual TZs together are more easily
>> identifiable to servers, than clients who request only one. Should
>> clients request all their interested TZs at once, or spread out their
>> polling updates over time? HTTP pipelining is clearly more efficient;
>> but what are the privacy implications if you have a system service that
>> does this?
>
> I've cherry picked here since the one thing that seems to have been
> missed is that the main target for tzdist is to provide a mirror of the
> TZ data. This is a complete set of tz information, and if my own
> distribution method is followed many of the 'security and tracking'
> risks being listed can never arise?
The specification i read seemed to encourage clients to pick up specific
zones of interest, not the full set of data. And the draft certainly
makes allowances for fetching specific sections (by time, by space) of
the TZ info. So i'm not sure if what you call "my own distribution
method" is intended to be the normal use case. If it is, maybe that
needs to be highlighted specifically in the draft?
Is there some set of client profiles (or use cases, if you prefer) that
are clearly distinct, with different implications? Can we identify
them?
> The clients computer has a local copy of TZ, and any local processing is
> done against that copy. On a regular basis they ask tzdist if there has
> been an update to the version of TZ they are using. If yes then all of
> the are pulled down. A monitoring tap has no idea where the client is?
> The only know that someone has updated from v to v+1 of the TZ data?
Yep, this is a useful approach for keeping inside a broader anonymity
set (but hm, timing issues might still be a concern).
However, systems using this approach are really solving the general
problem of "how to i get the latest version/updates of $X" where $X is
anything digital: software updates already fulfil this role on modern
operating systems. A deployed system on the Internet today that doesn't
have a software update mechanism is probably bound for trouble -- if it
*does* have a software update mechanism, why not suggest using that for
the TZ info? Debian systems just pull in a new version of the tzdata
package during system updates, for example. I haven't checked, but i
would assume that Microsoft Update and Apple's Software Update would
treat TZ data the same way that they treat other system updates. Is
that not the case?
Given that the all-tzdata-as-a-software-update mechanism is already
available, I sort of assumed that this draft was intended for systems
that don't already have such a mechanism.
> Client using subsets of the data such as embedded devices will be asking
> for a specific timezone, but that traffic will be within a local
> network. We know already where they are so we don't need any cleaver
> processing to hide the fact that we are in that physical location? I've
> just posted about local servers providing a specific subset of data -
> within the building it's serving - o you already have an even better
> idea of location than timezone :)
Are embedded devices guaranteed to be as stationary as you're making
them out to be? Some embedded devices are embedded in cars or mobile
telephones. Their motion within and between timezones seems like
something that would have serious privacy implications, if their queries
are linkable over time.
> As with just about any system, accessing the data can be abused exposing
> other information. We do need to identify what are 'secure' ways of
> accessing the data and what ars insecure, but not exposing anything that
> could not be deduced by other means anyway.
To kickstart a privacy considerations section, it might help to work
from a concrete example (though clearly that won't be an exhaustive
review). How about:
Consider an internet-connected bedside alarm clock (i think this counts
an embedded device) that i take with me when i travel. It updates
itself (using NTP?) to keep it on-time, and it uses this proposed
mechanism to make sure it's got the TZ up-to-date.
What should this device do as a client of this service? What are the
privacy implications of these choices? How do the privacy
considerations change for the client with respect to a passive or active
network observer, as compared to the Provider itself?
--dkg
_______________________________________________
ietf-privacy mailing list
ietf-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-privacy
