Signals
| AnonymityModesChanged | (u: Modes) |
Properties
| SupportedAnonymityModes | u (Anonymity_Mode_Flags) | Read only | |
| AnonymityMandatory | b | Read/Write | |
| AnonymityModes | u (Anonymity_Mode_Flags) | Read/Write |
Types
| Anonymity_Mode_Flags | Flags | u |
Description
An interface to support anonymity settings on a per-connection basis. This defines what personal identifying information a remote contact may or may not see. For example, GSM might use this for CLIR, while SIP might use this for privacy service requests.
Signals
AnonymityModesChanged (u: Modes)
Parameters
- Modes — u (Anonymity_Mode_Flags)
Properties
SupportedAnonymityModes — u (Anonymity_Mode_Flags)
AnonymityMandatory — b
Note: Connections implementing this property SHOULD provide a corresponding parameter named org.freedesktop.Telepathy.Connection.Interface.Anonymity with the DBus_Property flag. Clients SHOULD update this property by calling UpdateParameters on the relevant rather than setting the property directly; change notification is via AccountPropertyChanged.
This specifies whether or not the anonymity settings MUST be respected
by the CM and any intermediaries between the local and remote contacts.
If this is set to true but anonymity settings cannot be followed, then
the session MUST be denied with a
org.freedesktop.Telepathy.Errors.WouldBreakAnonymity
error.
Any client that sets AnonymityModes
SHOULD also set this property first (rather than accepting the CM's
default value).
AnonymityModes — u (Anonymity_Mode_Flags)
Note: Connections implementing this property SHOULD provide a corresponding parameter named org.freedesktop.Telepathy.Connection.Interface.Anonymity with the DBus_Property flag. Clients SHOULD update this property by calling UpdateParameters on the relevant rather than setting the property directly; change notification is via AccountPropertyChanged.
The currently enabled anonymity modes for the connection. Setting has the effect of requesting new modes for the connection, and may raise an error if the unsupported modes are set. Successfully changing the modes will result in emission of AnonymityModesChanged signal.
Types
Anonymity_Mode_Flags — u
Flags for the various types of anonymity modes. These modes are solely to inform the CM of the desired anonymous settings. It is up to the CM to determine whether the anonymity modes should be handled within the CM itself, or whether the network that a CM might be talking to should be enforcing anonymity.
CMs MAY support only a subset of these modes, and specific connections MAY support none at all.
- Client_Info (1)
- Show_Client_Info (2)
- Network_Info (4)
Obscure any information that provides user identification, user-agent identification or personal details. Examples of this information might be GSM CallerID, SIP from address, various informational email headers, etc.
The CM should scrub/replace any of this information before passing messages or data onto the network. Note that a CM which has the option of obscuring the information at the CM or privacy service level would choose both (anonymity services are opaque to clients of this interface).
Clients SHOULD NOT set both Client_Info and Show_Client_Info modes. If they are set, the CM MUST respect Client_Info and ignore Show_Client_Info.
Explicitly request showing of client information. In connection context, this can be used to override service default. In channel context, this overrides connection anonymity modes.
Rationale:
In GSM, it's possible to have CLIR enabled by default, and explicitly suppress CLIR for a single phone call.
Clients SHOULD NOT set both Client_Info and Show_Client_Info modes. If they are set, the CM MUST respect Client_Info and ignore Show_Client_Info. The CM MAY set both Client_Info and Show_Client_Info in SupportedAnonymityModes to indicate its support for explicitly hiding and publicising client information.
Obscure any originating IP address information, contact URIs, and anonymize all traffic involved with sending/receiving any media streams or call content. Examples of this include the "headers" portions of RFC 3323 as well as the History-Info (described in RFC 4244) for a SIP CM.
This SHOULD have the effect of hiding address information from the remote contact (ie, the contact cannot know what IP address the session is originated from). Obviously the network still needs to be able to route information between contacts, so this provides no guarantees of what can be seen by intermediaries.