[Bug 24909] Anonymity API (e.g. suppressing caller-ID)
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Tue Mar 23 23:56:15 CET 2010
http://bugs.freedesktop.org/show_bug.cgi?id=24909
--- Comment #15 from Andres Salomon <dilinger at collabora.co.uk> 2010-03-23 15:56:14 PST ---
(In reply to comment #14)
> (In reply to comment #12)
> > > "Headers" -> "Network" (meaning conceal network routing information etc.)
> >
> > I went with "PersonalInfo", providing examples of "URIs, telephone numbers,
> > various informational email headers, etc". Maybe this should be split into
> > AddressingInfo (ie, Network stuff like phone numbers, email addresses, etc) and
> > PersonalInfo (useragent headers, etc)?
>
> It might be useful, but SIP makes no such distinction. So we've come up three
> categories to anonymize:
>
> originator info: caller ID, From address, etc.
> network info: origin/route IP addresses, contact URI, etc.
> client info: user agent information, capabilities, etc.
>
> The first two are matched to "user" and "headers" in SIP, and the third one can
> simply be implemented by the UAC by omitting all revealing information that
> falls under this category, since none of it requires intermediate support.
> So I vote for the three flags :)
Sounds good to me. I threw the history-info stuff into NetworkInfo flag, as
it's close enough that I don't see much point in having a separate flag.
I also restored the InitialAnonymityMode stuff too.
>
> > Perhaps we could make this a property on the Connection iface called
> > "DisplayName", where we leave it up to the CM whether the property is 'read' or
> > 'readwrite'?
>
> This then sounds more like AssumedIdentity interface than Anonymity :)
>
> For purposes of anonymity, I think it's better to let the CM scramble the ID if
> the User flag is set, and have a read-only channel property of type string, to
> inform the UI about the apparent ID.
>
Added to the Channel iface.
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the telepathy-bugs
mailing list