Subject: Re: [Sipping] draft-shacham-sip-media-privacy

From: Brijesh Kumar <[email-masked]>
Date: Fri, 05 Aug 2005 09:52:41 -0400

Henning:

As I have already pointed out just tagging that media is "private" is not sufficient to ensure privacy. As a matter of fact that gives a false sense of privacy since any media that is available in the analog form can be duplicated, recorded and distributed at will no matter what session flag says. At best, such a flag can only be advisory since there is no way an initiator can enforce such a behaviour. 

Not even FCC and all DRMs have stopped re-recording and re-distribution of recorded media as we are all aware, and mere SIP flag won't be able to do it.

I think the draft must elaborate on the advisory nature of the flag and possibly need to look into mechanisms that can make some of the actions and events notifyable to the calling party (if possible to detect at all any voilation of the agreed privacy "contract"). 

Cheers,

--brijesh

----- Original Message -----
From: Henning Schulzrinne <[email-masked]>
Date: Friday, August 5, 2005 4:41 am
Subject: [Sipping] draft-shacham-sip-media-privacy

> During the SIPPING meeting, the concern was raised that the media 
> privacy tags could never guarantee such privacy and that devices 
> may not 
> be able to determine their privacy. This is true, but I think 
> somewhat 
> besides the point.
> 
> This type of indication/request can never be perfect, but can 
> prevent 
> some "accidents". I think this is mostly useful where devices are 
> known 
> not to be reliably-private, e.g., pay and lobby phones. For 
> example, in 
> a doctor's office, having a mechanism that indicates that such 
> devices 
> should not be used can be helpful.
> 
> Also, my perception was that there was a fair amount of interest 
> in the 
> recording issue. Maybe this can be broken out as needed.
> 
> I'd value further feedback on where to take this work.
> 
> Henning
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 06 Aug 2005 18:06:29 -0400

Brijesh Kumar wrote:
> Henning:
> 
> As I have already pointed out just tagging that media is "private" is
> not sufficient to ensure privacy. As a matter of fact that gives a
> false sense of privacy since any media that is available in the
> analog form can be duplicated, recorded and distributed at will no
> matter what session flag says. At best, such a flag can only be
> advisory since there is no way an initiator can enforce such a
> behaviour.

Indeed; this needs to be made much clearer in the draft. In this, it is 
very similar to the GEOPRIV privacy rules in location objects. Indeed, 
they are almost exactly equivalent, as GEOPRIV specifies basic object 
rules for distribution (equivalent to the media privacy) and retention 
(recording).

> 
> Not even FCC and all DRMs have stopped re-recording and
> re-distribution of recorded media as we are all aware, and mere SIP
> flag won't be able to do it.

Fully agreed. There was a long discussion on this, but our colleagues in 
the privacy world convinced us that having a clear statement of intent 
is significantly better than "he-said-she-said" after the fact.

> 
> I think the draft must elaborate on the advisory nature of the flag
> and possibly need to look into mechanisms that can make some of the
> actions and events notifyable to the calling party (if possible to
> detect at all any voilation of the agreed privacy "contract").

I don't see much hope of enforcing observance mechanically, but if we 
proceed, I do want to make sure that the behavior is made clearer. For 
example, by including a 'Proxy-Require' (Sec. 5, RFC 3841), the UAC can 
at least ensure that path elements understand the mechanism.