Article View: comp.groupware
Article #283Calendars and Privacy (repost)
From: David S. Stodolsky
Date: Fri, 26 Oct 1990 18:46
Date: Fri, 26 Oct 1990 18:46
306 lines
16145 bytes
16145 bytes
In the recent discussion of calendars, some important points were raised, but
not responded to adequately. If these are not dealt with, a calendar system
will not be accepted. (My apologies for not citing the posts in question and
any errors in this summary.)
In general, a groupware system must incorporate protection of information and
a mechanism of coordination. Some consideration of each of these occurred, but
on a superficial level compared to what is available in the literature and to
what is needed if these systems are to be widely accepted.
Power:
People pointed out that the system has to fit the culture in which it is used.
But some cultures are not a problematic, and a solution for the problematic
environments means that the calendars can also be used in others. These
problematic environments tend to be those where there are large power
differentials. In these situations benefits and costs are different for
different types of users and conflicts are likely to result. The system has to
be of benefit to all users or else some will try to undermine it. (The
protection of information is most important in the case of power imbalance,
coordination can be simple [e. g., the boss just tells everyone what to do]).
Privacy:
When there are power differences, open information increases the power of
power holders and increases the vulnerability of others. Not being able to see
why someone was not available was discussed, but just knowing that a time is
unavailable can compromise privacy. An example was given where someone's
secret affair was discovered because their lunch time was always booked. Being
able to say that you cannot (or will not) come to a meeting without revealing
further information seems essential (you can do this normally). Few people are
willing to have their diary public.
Policy:
Another point was that certain types of meetings were more fixed than others
and, in the case of conflicts, could be moved around without trouble. A newly
proposed meeting might trigger a large number of rearrangements, without
automatic negotiation, this isn't practical. (There is a substantial
literature in management science and operations research on room scheduling or
"facilities management". A typical application is to schedule rooms for
classes of students, avoiding conflicts, so students can take all required
courses, etc.) More important, if the calendar is policy driven, then
responding to a request for a meeting does not reveal all the information you
put into the system. People will only supply private information if they
benefit from doing so, and it is kept private.
Portability:
This was one of the most important requirements. A policy driven calendar
agent is "portable". You enter the policy and then it negotiates with other
people's agents to arrange meetings.
Summary:
The calendar system should provide benefits without any disadvantages compared
to a manual system. No proposal suggested has dealt fully with the privacy
disadvantage. A workable system has to use private information so the user's
agent can arrange meetings with maximum flexibility and minimum user
intervention.
Solution:
A conditional privacy protocol permitting negotiations that arrange the
appointments, but reveals no information beyond an "attend" or "will not
attend" response.
Earlier this year, I posted a long paper that must have made people wonder why
it was in comp.groupware, since I received no comments. One feature of the
idealized system presented, was to ensure that meetings arranged were not
opportunities for the spread of infectious disease. I gave a protocol for
conditional privacy that shows how to do this without revealing sensitive
information. The sensitive information was presence of infection. Sensitive
information in a calendar system might be that you want to avoid meetings on
topic X, or meetings called by manager Y, or meetings at time Z.
I am reproducing that section below, without modification. I don't have time
to rewrite it for a calendar type of application. If you can't understand it
out of context, I'll mail the whole paper. If I get more than three requests,
I will repost the paper. If there are still questions, then we can get into
the specifics of applying conditional privacy protocols to calendars.
=================================
>From: Stodolsky, D. (1990, March 11). Toward Personal Risk Management:
Information Technology Policy for the AIDS Pandemic. Comp.groupware [Usenet].
Do not cite off-line without permission.
--------------------------------
Abstract
The introduction of partner notification programs has exacerbated the policy
debate around the conflicting demands for privacy of HIV-infected persons and
for the right of others to protect themselves from infection. A novel partner
notification system, based upon personal-computer databases, that could
resolve these conflicting demands is specified. The hypothesized system would
permit individuals to avoid contacts that risk transmission of infection, as
well as providing notifications resulting from prior contacts. Privacy
preserving negotiation and anonymous communication allow this to be
accomplished without compromising sensitive information. Immediately
applicable policy recommendations are presented based upon an analysis of the
hypothetical risk management system. These include data security audits for
community-based drug trials, deregulation of cryptographic research and
equipment, and increased support for research upon the social aspects of
electronic mail and conferencing systems.
-------------------------------
_Interaction Models
In this section, an interaction model for personal risk management is
introduced through a commonly know social arrangement based upon
confidentiality. Then a privacy preserving mechanism permitting direct
negotiation between potential partners is specified. Finally, a multi-stage
information exchange model will be presented that preempts risky contacts
without revealing sensitive information.
__Confidential Matchmaking
If we assume a confidential relationship between potential partners and a
central matchmaking bureau, then establishment of partnerships capable of
transmitting an infectious agent can be easily avoided. The bureau would
merely consult medical records of persons in order to avoid arranging any such
contacts. This, of course, assumes that partnerships are arranged only through
the bureau. In order to eliminate the use of a trusted third party, and an
impractical social arrangement, a special type of privacy is needed.
__Privacy
The concept of privacy, as suggested above, is defined in terms message
contents (Table 1). We will limit this analysis to a two person interaction in
which anonymity is not possible. Only a Yes answer to a given question is
considered sensitive. One-bit of information is exchanged when a Yes is
transmitted by both sides, if we assume no prior knowledge. The protocol can
be repeated to exchange more information.
___Conditional Privacy
Conditional privacy permits information to be revealed only under certain
conditions. The condition, in this case, is that the other party reveals
corresponding information. Ideally, this information sharing is complete if
the condition is satisfied, but no information is transferred otherwise. An
ideal physical model for conditional privacy with one bit of information
exchange will be described. Next, a model and protocol for performing this
information sharing automatically will be given.
___Single Stage Models
The prototype for these procedures can be called one-bit matchmaking. If both
he and she have a Yes for each other, then the match takes place and the
information is revealed, but if either one has a No, the person with a Yes
does not wish to reveal it.
____An Ideal Physical Model
A physical model can be based upon light passing through a translucent
material. Each person places a opaque card in a translucent envelope. A Yes is
represented by a card with a hole in its middle. The covered cards are placed
together in another translucent envelope. Next, they are viewed against a
powerful light source which can penetrate the translucent material. If light
comes through the holes in the opaque cards, then the match succeeds, both
persons have transmitted a Yes. If either has transmitted a No, a completely
opaque card has been used, and no light is visible.
____Asymptotically Secure Models
A practical procedure can be based upon a model that uses playing cards in
envelopes. Each person places, say, a hundred cards in envelopes. This number
of cards limits failure rate of the protocol to about one time in a hundred. A
Yes is represented by an even numbered card in each envelope. A No is
represented by a odd numbered card in one of the envelopes and even numbered
cards in the rest. Each person puts their envelopes on the table. They take
turns in randomly selecting one of the other person's envelopes. That envelope
is opened, if the card is odd numbered, indicating No, the procedure
terminates without a match. If the card is even numbered, they continue
opening envelopes. If all cards are displayed and they are even, the match
succeeds.
This model can be implemented by using a one-way function. This is a function
that is easy to compute in one direction, but infeasible to compute in the
other. A card is represented by a number that may be even or odd. Odd could
mean No and even would then mean Yes. Cards are placed in envelopes by
encoding them with the one-way function. When an envelope is selected, the
card which produced it must be supplied. To verify that the number, odd or
even, produced the encoded number, the one-way function is applied to it
again, in order to produce the envelope. Massey (1988) gives a technical
introduction to one-way functions and other concepts of modern cryptology.
Thus, the entire negotiation proceeds by first agreeing on a function, on the
number of encoded numbers to be exchanged, and on the a meaning of odd and
even numbers. Each side then produces and sends the encoded numbers. First one
side selects a encoded number at random and the other side shows the unencoded
odd or even number used to produce it. The unencoded number is tested by
encoding it with the function and verifying that it corresponds to the
selected encoded number. Then the other side does the same. This continues
until a No is encountered or the numbers are exhausted.
___A Multi-Stage Model
Assume that all interacting persons are equipped with electronic notebooks
that they always used when contacts are organized. Before a partnership is
established the computer elements in their notebooks negotiate to determine if
a risk would result from a partnership. In the case that such a risk would
result, they wish to avoid the contact, however, they do not want to reveal
sensitive information. We limit the current example to sensitive information
about a single virus.
We assume repeated use of the one-bit matchmaking protocol. In the initial
stage of the protocol, both parties' computers respond to the question, "Have
you been tested HIV positive?" In stage two, their computers respond to the
question, "Do you wish to make the contact?" The negotiation process is
automatically started when two notebooks are placed close to each other. Thus,
the fact of information exchange is not informative. It is assumed that one
can transmit information to one's notebook privately at any time.
The rules for exchange of information that have been programmed are (Figure
1):
: if you satisfy the condition (i. e., have been tested positive), then
Stage 1: Send a Yes.
Stage 2a: If the potential partner also sent a Yes (in stage 1), then
express your intention in order to reach a decision.
Stage 2b: If the potential partner sent a No (in stage 1), then always
send a No.
: if you do not satisfy the condition, then
Stage 1: Send a No.
Stage 2: express your intention in order to reach a decision.
Attempts to initiate prohibited contacts always result in a finding that the
other party is unavailable. Whether this results from restrictions on the
transmission of infectious agents or from the lack of desire by the other
party, can not be determined within the confines of the protocol. Thus, an
infected person could freely search for a partner in a responsibly manner,
without risking the exposure of sensitive information.
These protocols illustrate that the total distribution of risk information is
an option for infectious disease management. Highly sensitive information can
be used for local decision making without employment of confidentiality, that
is, a trusted third party or central authority. A communication system for
anonymously transmitting risk information to these local databases will now be
considered.
=========================================================
Table 1
Classification of Messages
Content of Message
Known Unknown
--------------------------------
Identity Known | Public | Private |
of -----------------------------------------
Source Unknown | Anonymous | Secret |
--------------------------------
=====================================================
Stage 1
Start
/\
/ \
------- / \ -------
| | / \ | |
| Send | No / HIV + \ Yes | Send |
| No |<----\ ? /---->| Yes |
| | \ / | |
------- \ / -------
| \ / |
| \/ |
| |
- - | - - - - - - - - - - - - - | - - - - - - - - - - -
| V Stage 2
| /\
| / \
| / \ -------
| / Re- \ | |
| / ceived \ No | Send |
| \ Yes /----| No |
| \ ? / | |
| \ / -------
| \ /
| \/
| | Yes
V V
------------------------------------
| |
| Express intention toward contact |
| |
------------------------------------
Figure 1
--------------------------------
--
David S. Stodolsky Office: + 45 46 75 77 11 x 21 38
Department of Computer Science Home: + 45 31 55 53 50
Bldg. 20.2, Roskilde University Center Internet: david@ruc.dk
Post Box 260, DK-4000 Roskilde, Denmark Fax: + 45 46 75 74 01
Technical Details
Message-ID:
<1990Oct26.184648.6245@daimi.aau.dk>Path:
arc1-ca.pugleaf.net!utzoo!attcan!uunet!cs.utexas.edu!yale!mintaka!bloom-beacon!eru!hagbard!sunic!dkuug!daimi!dsstodolShow Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!attcan!uunet!cs.utexas.edu!yale!mintaka!bloom-beacon!eru!hagbard!sunic!dkuug!daimi!dsstodol From: dsstodol@daimi.aau.dk (David S. Stodolsky) Newsgroups: comp.groupware,comp.windows.x Subject: Calendars and Privacy (repost) Summary: Better privacy is needed for calendar applications Keywords: conditional privacy policy negotiation Message-ID: <1990Oct26.184648.6245@daimi.aau.dk> Date: 26 Oct 90 18:46:48 GMT Sender: dsstodol@daimi.aau.dk (David S. Stodolsky) Organization: DAIMI: Computer Science Department, Aarhus University, Denmark Lines: 306