Bug 24909

The GSM interface also has a Privacy property, which might be related (I can't really tell)...

http://git.collabora.co.uk/?p=rtcom-telepathy-glib.git;a=blob;f=rtcom-telepathy-glib/Connection_Interface_GSM.xml

Ring doesn't use this API; what does?

(In reply to comment #2)
> Ring doesn't use this API; what does?
> 


Ok, GSM's privacy support is boolean; a simple hide/no-hide (CLIR).  This is probably why ring uses Connection.Interface.GSM's privacy bit as a way to quickly and easily toggle it for all connections.  Connection.Interface.Privacy can easily be made to do the same thing (if it doesn't already).

As far as Connection.Interface.Privacy, I suggest we use enums rather than privacy service strings (which are pretty SIP specific).

Note that there's already an existing Connection.Interface.Privacy in telepathy-spec; it's related to whether or not remote contacts may initiate connections w/ a user.   The functionality doesn't really seem to overlap w/ the GSM CLIR stuff, so it's worth keeping them separate.

(In reply to comment #4)
> Note that there's already an existing Connection.Interface.Privacy in
> telepathy-spec

Right, this is why I don't want a "Privacy" interface. The word means so many things to different people that we should use different names for each orthogonal aspect of privacy. This bug is about anonymity, i.e. not revealing your phone number/JID/other unique identifier.

(In reply to comment #5)
> (In reply to comment #4)
> > Note that there's already an existing Connection.Interface.Privacy in
> > telepathy-spec
> 
> Right, this is why I don't want a "Privacy" interface. The word means so many
> things to different people that we should use different names for each
> orthogonal aspect of privacy. This bug is about anonymity, i.e. not revealing
> your phone number/JID/other unique identifier.
> 


I've pushed an initial spec - http://git.collabora.co.uk/?p=user/dilinger/telepathy-spec;a=shortlog;h=refs/heads/anonymity

I took some liberty w/ the SIP privacy modes, so critique on that would be especially good.

(In reply to comment #6)
> I've pushed an initial spec -
> http://git.collabora.co.uk/?p=user/dilinger/telepathy-spec;a=shortlog;h=refs/heads/anonymity
> 
> I took some liberty w/ the SIP privacy modes, so critique on that would be
> especially good.

Thanks. From the initial looks of it, it looks like a spillover of SIP RFCs into Telepathy, so maybe some abstracting needs to be done. Like, "Headers" is meaningless to many protocols. "ID" could be renamed to be more self-explanatory.

I'm not sure it's useful to change anonymity modes on a channel besides the initial values. Like, start a call anonymously, but then reveal yourself?
I bet this will wreak all kinds of havoc with SIP dialogs, for one protocol.

I propose the following translation for flag names from SIP engineerese to my understanding of common English:

"Headers" -> "Network" (meaning conceal network routing information etc.)
"Session" -> "Media" (they mean to anonymize the origin of media streams)
"Critical" -> "Mandatory" or leave as is
"ID" -> "Untrusted" or "NotTrusted" (do not reveal to entities outside the trust domain)

Also, should "user" mode be communicated to CM so that it attempts to scramble the From URI as recommended in RFC 3323, or let the client do this explicitly with handles, perhaps by a requestable property? If the former, should the CM then expose the scrambled channel-specific self handle/ID as properties on Channel.Interface.Anonymity?

(In reply to comment #9)
> should the CM
> then expose the scrambled channel-specific self handle/ID as properties on
> Channel.Interface.Anonymity?

It may be a bad idea to offer it as a handle, because it will rub wrongly against any other channel interfaces that use handles. So, just a string to show in the UI with the meaning of "this is how your address is communicated to the other end".

(In reply to comment #8)
> I'm not sure it's useful to change anonymity modes on a channel besides the
> initial values. Like, start a call anonymously, but then reveal yourself?
> I bet this will wreak all kinds of havoc with SIP dialogs, for one protocol.
> 

I can only imagine some weird corner-cases where someone might want this.  You're right, I'll drop the Channel iface.  Thanks!

(In reply to comment #9)
> I propose the following translation for flag names from SIP engineerese to my
> understanding of common English:
> 
> "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)?

> "Session" -> "Media" (they mean to anonymize the origin of media streams)

A compromise - "MediaSession" :)

> "Critical" -> "Mandatory" or leave as is

Mandatory sounds much better, yep.

> "ID" -> "Untrusted" or "NotTrusted" (do not reveal to entities outside the
> trust domain)

"HideTrustDomain"?

> 
> Also, should "user" mode be communicated to CM so that it attempts to scramble
> the From URI as recommended in RFC 3323, or let the client do this explicitly
> with handles, perhaps by a requestable property? If the former, should the CM
> then expose the scrambled channel-specific self handle/ID as properties on
> Channel.Interface.Anonymity?
> 

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'?  For SIP, I would think it makes sense to have the CM scramble the From URI according to the RFC (and thus leave the property as 'read')... For some other VOIP services that go through an asterix PBX and allow configuration of caller-id, I can imagine this being 'read-write' as the user changes their display phone number.

(In reply to comment #11)
> I can only imagine some weird corner-cases where someone might want this. 
> You're right, I'll drop the Channel iface.

Wait, wait, the requestable channel properties are useful.

(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 :)

> 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.

(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.

So the Connection interface is used for setting the default, and then the Channel.I.Anonymity.InitialAnonymityModes property can be included in requests to override the default? I think each interface should explain its relationship to the other.

Can the anonymity mode change mid-call? Should there be another property on the channel for the flags that are *actually* in use (if you haven't set Mandatory: True, that is)?

Speaking of which:

> Mandatory (16)
> This specifies that anonymity settings MUST be respected by the CM and any intermediaries between the local and remote contacts. If the anonymity settings cannot be followed, then the session MUST be denied with a org.freedesktop.Telepathy.Errors.NotAvailable error.

Maybe this should be a separate property. It seems a bit strange to have a flagset where all the flags are features to hide except for one oddball flag nestling in the middle. I think there should also be a separate error for "this failed because your anonymity requirements weren't met".

telepathy-ring has a couple of connection properties which are also connection parameters, using the DBus_Property parameter flag (http://telepathy.freedesktop.org/spec/org.freedesktop.Telepathy.ConnectionManager.html#org.freedesktop.Telepathy.ConnectionManager.Conn_Mgr_Param_Flags). If Conn.I.Anonymity had a read-write property rather than a read-only property and a setter method, it could do the same.

(Argh, sorry, I stupidly thought that BZ would wrap that...)

(In reply to comment #16)
> So the Connection interface is used for setting the default, and then the
> Channel.I.Anonymity.InitialAnonymityModes property can be included in requests
> to override the default? I think each interface should explain its relationship
> to the other.
> 
> Can the anonymity mode change mid-call? Should there be another property on the
> channel for the flags that are *actually* in use (if you haven't set Mandatory:
> True, that is)?

I can't think of any protocol where anonymity mode can change for one channel. If there would be such a protocol, it could be specced later as a channel transition similar to how channels are merged into a conference.
So, only one channel property is needed for the modes, and it can both be requested and represent the actual anonymity flags.

> > Mandatory (16)
> 
> Maybe this should be a separate property. It seems a bit strange to have a
> flagset where all the flags are features to hide except for one oddball flag
> nestling in the middle. I think there should also be a separate error for "this
> failed because your anonymity requirements weren't met".

+1

(In reply to comment #18)
> (In reply to comment #16)
> 
> > > Mandatory (16)
> > 
> > Maybe this should be a separate property. It seems a bit strange to have a
> > flagset where all the flags are features to hide except for one oddball flag
> > nestling in the middle. I think there should also be a separate error for "this
> > failed because your anonymity requirements weren't met".
> 
> +1
> 

Ok, I created a separate Mandatory property (as well as an InitialMandatory property for the channel iface).

From a spec meeting:

Connection interface:

• SupportedAnonymityModes should be documented to only be stable once
  you've connected. Should x-ref the type.

• Should SetAM just be a writeable D-Bus property? Maybe not if it
  involves talking to the sky on GSM. But it needs to be a writeable
  D-Bus so that it can be a connection parameter which is also a D-Bus
  property using the DBus_Property Conn_Mgr_Param_Flag, allowing Mission
  Control to update it on the fly when you change the corresponding
  Account's parameters.

• Will wonders if this interface might be overly tinfoil hatty and
  support features no-one will ever use, and maybe we should just have a
  HideCallerID: b property?
  · Others think that supporting these other flags is fine, but we
    should order the flags by how obscure they are, so that the one you
    actually care about — OriginatorInfo, aka caller-id — is first, and
    then the introduction can say "If you just care about hiding your
    caller ID, call Set("Flags", 1)".

• Capitalization is wrong. smcv or similar needs to do an editorial
  pass-through.

Channel interface:

• Properties don't need to be Initial*, they're immutable. Should be
  AnonymityModes, AnonymityMandatory
• Should say that those two are requestable.
• AnonymizedDisplayName: this isn't a display name, it's an Identifier.
  Say that it's not requestable.

(In reply to comment #20)
> From a spec meeting:
> 
> Connection interface:
> 
> • SupportedAnonymityModes should be documented to only be stable once
>   you've connected. Should x-ref the type.

Thanks, fixed.


> 
> • Should SetAM just be a writeable D-Bus property? Maybe not if it
>   involves talking to the sky on GSM. But it needs to be a writeable
>   D-Bus so that it can be a connection parameter which is also a D-Bus
>   property using the DBus_Property Conn_Mgr_Param_Flag, allowing Mission
>   Control to update it on the fly when you change the corresponding
>   Account's parameters.

Huh?  I don't see why it would be controlled by mission-control; it's something for the CM/connection to export letting the client/UI know the connection's capabilities.  If there's some policy that requires one to disable anonymity modes, that's something that should be handled on the (SIP, or other VOIP) server.

> 
> • Will wonders if this interface might be overly tinfoil hatty and
>   support features no-one will ever use, and maybe we should just have a
>   HideCallerID: b property?

That depends upon the SIP folks; exactly how much control do you want to provide to a UI when allowing modification of SIP anonymity modes?  For GSM, HideCallerID would be just fine of course.
I'm not sure how much of the original rtcom privacy spec had actually been used by CMs, as well as how much of it had actually been used by clients/UIs.  Answering that question would probably give us a good idea of the answer to your question.



>   · Others think that supporting these other flags is fine, but we
>     should order the flags by how obscure they are, so that the one you
>     actually care about — OriginatorInfo, aka caller-id — is first, and
>     then the introduction can say "If you just care about hiding your
>     caller ID, call Set("Flags", 1)".

Sure, the ordering is arbitrary atm (as the modes have changed quite a bit).   A client who just wants to set caller-id shouldn't make assumptions about the CM, though; the process should be something like -

SetAnonymityMode(GetProperty("SupportedAnonymityModes"));
SetProperty("Mandatory", true);

Likewise, turning caller-id back off should be -

SetAnonymityMode(0);

If the client actually cares about a various subset of anonymity settings (ie, they only want to turn off caller-id, but leave hide-trust-domain turned off) is going to need to look at individual mode flags anyways.

> 
> • Capitalization is wrong. smcv or similar needs to do an editorial
>   pass-through.
> 
> Channel interface:
> 
> • Properties don't need to be Initial*, they're immutable. Should be
>   AnonymityModes, AnonymityMandatory
> • Should say that those two are requestable.

Thanks, fixed.

> • AnonymizedDisplayName: this isn't a display name, it's an Identifier.

Hm, my understanding was that it was literally the name that was displayed to the remote client.  In the case of GSM, this would be a phone number (an identifier); in the case of SIP, this would be "Anonymous" <sip:anonymous@anonymous.invalid>.


>   Say that it's not requestable.
> 

Done.

(In reply to comment #21)
> > • Will wonders if this interface might be overly tinfoil hatty and
> >   support features no-one will ever use, and maybe we should just have a
> >   HideCallerID: b property?
> 
> That depends upon the SIP folks; exactly how much control do you want to
> provide to a UI when allowing modification of SIP anonymity modes?

Umm, all of the flags, to just map it straight to the privacy header? :)
I tried to boil it down to some generally meaningful categories, but if such complexity is deemed not desirable/useful, some of them could be collapsed, with some consensus on what each broad privacy category should mean for SIP.

> I'm not sure how much of the original rtcom privacy spec had actually been used
> by CMs,

So far only telepathy-ring (the GSM CM) in Maemo implements it.

> as well as how much of it had actually been used by clients/UIs.

Lassi and Pekka, could you comment?

> > • AnonymizedDisplayName: this isn't a display name, it's an Identifier.
> 
> Hm, my understanding was that it was literally the name that was displayed to
> the remote client.  In the case of GSM, this would be a phone number (an
> identifier); in the case of SIP, this would be "Anonymous"
> <sip:anonymous@anonymous.invalid>.

I meant it to be the URI only, that is "sip:anonymous@anonymous.invalid" or whatever scrambling the CM would use. The display name is not important and set to "Anonymous" by convention; any client-specific variation here may breach anonymity.

(In reply to comment #21)
> > • AnonymizedDisplayName: this isn't a display name, it's an Identifier.
> 
> Hm, my understanding was that it was literally the name that was displayed to
> the remote client.  In the case of GSM, this would be a phone number (an
> identifier); in the case of SIP, this would be "Anonymous"
> <sip:anonymous@anonymous.invalid>.

Hmm, okay. Probably still worth differentiating this from http://telepathy.freedesktop.org/spec/org.freedesktop.Telepathy.Account.html#org.freedesktop.Telepathy.Account.DisplayName

(In reply to comment #23)
> (In reply to comment #21)
> > > • AnonymizedDisplayName: this isn't a display name, it's an Identifier.
> > 
> > Hm, my understanding was that it was literally the name that was displayed to
> > the remote client.  In the case of GSM, this would be a phone number (an
> > identifier); in the case of SIP, this would be "Anonymous"
> > <sip:anonymous@anonymous.invalid>.
> 
> Hmm, okay. Probably still worth differentiating this from
> http://telepathy.freedesktop.org/spec/org.freedesktop.Telepathy.Account.html#org.freedesktop.Telepathy.Account.DisplayName
> 

Ok, changed to AnonymizedName.

(In reply to comment #22)
> So far only telepathy-ring (the GSM CM) in Maemo implements it.
> 
> > as well as how much of it had actually been used by clients/UIs.
> 
> Lassi and Pekka, could you comment?

So far, HideCallerId boolean property on the connection would have sufficed. It could also be a requestable property on the channels, though at the moment, tp-ring parses it from the phone number (#31# and *31# from 3GPP 22.030).

(In reply to comment #25)
> > Lassi and Pekka, could you comment?
> 
> So far, HideCallerId boolean property on the connection would have sufficed. It
> could also be a requestable property on the channels, though at the moment,
> tp-ring parses it from the phone number (#31# and *31# from 3GPP 22.030).

There is a reason why a simple boolean did not suffice. The underlying CLIR supplementary service can be provisioned by the network to be permanently on, on by default or off by default. The setting cannot be changed (unless the network operator changes it). CLIR can be invoked or suppressed on per call basis, however.

The Maemo 5 settings UI provides three choices, "Use network default", "On" or "Off". The Privacy property is empty, "id" or "no-id", correspondingly. If the Privacy property is "id" or "no-id" (or #31# or *31# prefix was used with the  telephone number) a CLIR invocation or suppression element was added to the SETUP request sent to the network. 

Anonymity API should probably support both invocation or suppression of the anonymity services, either with two sets of flags, or with an extra flag for each service that can be suppressed.

It would be also a good idea to provide a specific error code for the cases where the anonymity service cannot be provided. (SIP does not do that, unless you use Proxy-Require: privacy and get 420 back.) On GSM, if you try to invoke CLIR but the CLIR service is not provisioned, a special cause code is returned.

(In reply to comment #21)
> (In reply to comment #20)
> >   · Others think that supporting these other flags is fine, but we
> >     should order the flags by how obscure they are, so that the one you
> >     actually care about — OriginatorInfo, aka caller-id — is first, and
> >     then the introduction can say "If you just care about hiding your
> >     caller ID, call Set("Flags", 1)".
> 
> Sure, the ordering is arbitrary atm (as the modes have changed quite a bit).  
> A client who just wants to set caller-id shouldn't make assumptions about the
> CM, though; the process should be something like -
> 
> SetAnonymityMode(GetProperty("SupportedAnonymityModes"));
> SetProperty("Mandatory", true);
> 
> Likewise, turning caller-id back off should be -
> 
> SetAnonymityMode(0);
> 
> If the client actually cares about a various subset of anonymity settings (ie,
> they only want to turn off caller-id, but leave hide-trust-domain turned off)
> is going to need to look at individual mode flags anyways.

AIUI the idea here is that we can perhaps come up with a logical ordering of the "anonymity-levels" (instead of a set of orthogonal flags), in which hiding the caller ID would be the first, and then additional anonymity (hiding of network info, sesison info, etc) would compound onto that.

(In reply to comment #26)
> (In reply to comment #25)
> > So far, HideCallerId boolean property on the connection would have sufficed. It
> > could also be a requestable property on the channels, though at the moment,
> > tp-ring parses it from the phone number (#31# and *31# from 3GPP 22.030).
> 
> There is a reason why a simple boolean did not suffice. The underlying CLIR
> supplementary service can be provisioned by the network to be permanently on,
> on by default or off by default. The setting cannot be changed (unless the
> network operator changes it). CLIR can be invoked or suppressed on per call
> basis, however.
> 
> The Maemo 5 settings UI provides three choices, "Use network default", "On" or
> "Off". The Privacy property is empty, "id" or "no-id", correspondingly. If the
> Privacy property is "id" or "no-id" (or #31# or *31# prefix was used with the 
> telephone number) a CLIR invocation or suppression element was added to the
> SETUP request sent to the network. 
> 
> Anonymity API should probably support both invocation or suppression of the
> anonymity services, either with two sets of flags, or with an extra flag for
> each service that can be suppressed.

This could tie in with what I've mentioned above - if we can have a logical ordering of anonymity levels, we can add "default" and "force show id" in there, too. Something like:

enum AnonymityLevel {
  SHOW_CALLER_ID,
  DEFAULT,
  HIDE_CALLER_ID,
  HIDE_NETWORK_INFO,
  ...
};

.. where DEFAULT means "whatever the default server settings are if we can't find out / unknown" in Connection context, and "whatever the connection settings are" in Channel context. With this, you can have channel suppressing CLIR even though it's enabled in Connecion

> That depends upon the SIP folks; exactly how much control do you want to
> provide to a UI when allowing modification of SIP anonymity modes?

Umm, all of the flags, to just map it straight to the privacy header? :)
I tried to boil it down to some generally meaningful categories, but if such
complexity is deemed not desirable/useful, some of them could be collapsed,
with some consensus on what each broad privacy category should mean for SIP.

From what I've seen here, both SIP Headers and Session privacy flags are network related - the former is for the control channel, while latter is for the media itself. So, if we want to have a smaller number of options, it might make sense to clump them together into eg. HideNetworkInfo.

OTOH if we don't want anonymity levels, and opt for orthogonal flags instead, I'd say we rather add the Caller ID one for the moment, and then just add more if/when we need to. But in this case, it looks to me like we're really going to have at least have Caller ID into a separate property, because of the tristate (enable, suppress, default) value for channels.

> It would be also a good idea to provide a specific error code for the cases
> where the anonymity service cannot be provided. (SIP does not do that, unless
> you use Proxy-Require: privacy and get 420 back.) On GSM, if you try to invoke
> CLIR but the CLIR service is not provisioned, a special cause code is returned.

Can't we have this with a combination of Mandatory flag and existing NotAvailable if it's set and the anonymity level is not available? (ie. if Mandatory is not set, can/should tp-ring ignore CLIR request failing?)

I've got a branch that implements the proposal from comment #27:

http://git.collabora.co.uk/?p=user/ptlo/tp-spec-senko/.git;a=shortlog;h=refs/heads/anonymity

The main change is usage of anonymity levels instead of modes. Only three levels are defined:
  * Anonymity_Level_Public - explicitly allow sending user/network info
  * Anonymity_Level_ClientInfo - hide user and client information (bikeshedding: maybe this would be better named UserInfo?)
  * Anonymity_Level_NetworkInfo - hide any network-related information, as much as possible; this implies Anonymity_Level_ClientInfo

There's also Anonymity_Level_None, used by CM to indicate no anonymity services are supported on the connection, and used by Client when requesting channels to indicate "use whatever anonymity level the connection has", or when resetting connection's anonimity to "default" (whatever that may mean for a particular CM - it will be the same as setting Anonymity_Level_Public explicitly).

This allows us to model GSM use case (Client can request Anonymity_Level_Public to suppress connection's Anonymity_Level_ClientInfo).

Devil's advocate: since the number of "real" anonymity levels here is small (2), it might make sense to not complicate things with levels and just have tristate properties for Anonimity_User_Info and Anonimity_Network_Info (yes, no, default). It would definitely make it easier for us to add more modes, at the cost of multiplying the number of properties.

OR, we could have struct AnonimityServices { tristate user_info, tristate network_info }, so that we can pass it around more easily. The more I think about levels, the more I like this alternative approach .. levels might be too complex solution.

Lint:

+        be "None", indicating no support for anonymity. Once a connection has
+        been established, this property MUST NOT change.

"Once Connection.Status has moved to Connected,"

I vaguely think it might be better to have separate tri-states for each thing you might want to keep private.

(In reply to comment #29)
> I vaguely think it might be better to have separate tri-states for each thing
> you might want to keep private.

I should clarify: I agree with your rationale that the number of things you might want to hide is small (2–3), so I don't think proliferation of properties is a problem.

On the flipside, if each should imply the previous one, there's not a great deal of point in separating them.

(In reply to comment #30)
> (In reply to comment #29)
> > I vaguely think it might be better to have separate tri-states for each thing
> > you might want to keep private.
> 
> I should clarify: I agree with your rationale that the number of things you
> might want to hide is small (2–3), so I don't think proliferation of properties
> is a problem.
> 
> On the flipside, if each should imply the previous one, there's not a great
> deal of point in separating them.

After giving it some more thought, I'm worried that setting up levels will bite us in the future (since we could only add more and more "anonymous" features, and they always have to imply all the ones before them; this might or might not be convenient).

OTOH, if we're willing to squint just a little bit, we can still only use flags, so we don't need to have multiple properties as well. The squint here is to ignore the fact that the two flags (of the three currently proposed) are not independent - and clarify what happens if the client or cm set both (my opinion is, the anonymising one wins, since we want to err on the side of privacy).

So, I've thrown away my previous patch, and just reworked the modes to include ClientInfo, ShowClientInfo, and NetworkInfo.

(In reply to comment #31)
> OTOH, if we're willing to squint just a little bit, we can still only use
> flags, so we don't need to have multiple properties as well. The squint here is
> to ignore the fact that the two flags (of the three currently proposed) are not
> independent - and clarify what happens if the client or cm set both (my opinion
> is, the anonymising one wins, since we want to err on the side of privacy).

Prior art exists for these pseudo-flags: Message_Part_Support_Flags are not independent either, but were implemented as flags so we can have "genuine flags" later.

> +        If this is set to true but anonymity settings cannot be followed, then
> +        the session MUST be denied with a
> +        <code>org.freedesktop.Telepathy.Errors.NotAvailable</code> error.

I think this should be a new error code, perhaps WouldBreakAnonymity - lots of things can raise NotAvailable already. Perhaps "MUST be denied; the error code SHOULD be ...WouldBreakAnonymity".

> +      <tp:flag value="1" suffix="ClientInfo">

Client_Info; also Show_Client_Info, etc. for the other flags.

> +      <tp:flag value="2" suffix="ShowClientInfo">

The docstring has the same <tp:rationale>/<p> mis-nesting I pointed out on another branch, and the typo "suppres" that wjt noticed.

I don't object to merging this as a draft, with or without my suggested changes.

Some of the changes I suggested are in 0.19.6.

I'm not sure that Senko's patch to rename Chan.I.Anonymity.AnonymityMandatory to Mandatory is appropriate; we generally have a policy of being nice to bindings that can't cope with name clashes in properties/signals/methods.

I attach a branch which makes the remaining changes I suggested, and renames Conn.I.A.Mandatory to AnonymityMandatory to be consistent.

My changes have been merged for 0.19.7. To get it undrafted, someone who's
involved in implementing this will need to pick it up.

12:58 < wjt> smcv: lassi says anonymity and servicepoint look fine for 
             undrafting from Ring's POV

With another batch of editorial changes (mainly improving the cross-referencing to things being RequestConnection parameters), I think it's ready to undraft.

Gitweb:
http://git.collabora.co.uk/?p=user/smcv/telepathy-spec-smcv.git;a=shortlog;h=refs/heads/anonymity
HTML:
http://people.freedesktop.org/~smcv/telepathy-spec-anonymity/spec/

Looks fine to me.

Hi,

I am on vacation until June 21st, 2010.

Regards,
Lassi

Fixed in git, will be considered stable in 0.19.7.