Justin Karneges wrote:
On Tuesday 05 August 2008 08:54:22 Pavel Simerda wrote:On Mon, 04 Aug 2008 16:59:50 -0600Peter Saint-Andre <[EMAIL PROTECTED]> wrote:Right. Or XEP-0191. Effectively Google Talk (and other similar services) deploy a rule of "forbid communications with people not on my roster" on the user's behalf -- no need for fancy privacy rules managed by the user.But this also disallows chatting with people outside your roster, which is something I often do. I'm for any way that doesn't leak presence but allows chat sessions (or single messages)... without giving any presence info. It's nice to be able to decide about the non-roster people blocking separately. Some people would also like to use the "invisible" facility, that would also be orthogonal to the roster subscriptions. (I never used invisible personally.) Sorry if I'm just repeating the obvious.I've suggested using directed presence (which need not contain the same information as broadcasted presence, if any) for this.A related discussion is that we wanted a way to trade caps and resource information between unsubscribed/invisible contacts. Robert suggested sending directed presence with caps and a special field to indicate you want to trade capabilities and reveal each others' resource name. E.g.:<presence from='contactA/Resource' to='contactB'> <tradewithme/> <c ...> // caps </presence>I believe most clients drop unsolicited presence on the floor. What we'd need is for clients to notice the <tradewithme> element on these stanzas as a request to trade presence temporarily with the sender, but not necessarily form a subscription. So your client might say, "User 'contactA' wishes to engage in communication with you. Is this okay? [Yes/No]" If the user selects 'Yes', then your client would reply with the same kind of presence packet. Now, each party may determine disco information of the other, and they can chat, do file transfers, jingle, etc.
Right.
Servers could then have a scheme where they block/bounce all communication except from contacts that have your presence. Presence is the key word here, not subscriptions, since if you login invisible you'd still want the bouncing effect on subscribed contacts that you've not revealed yourself to. I think presence is the most natural privacy control mechanism.
More natural than presence subscriptions or the roster?
There's just one problem, and this was brought up at the summit: if both parties forbid communication with people not in the roster (or, more appropriately, forbid communication with people who don't have their presence), then it would not be possible to trade directed presence. Oops!
If this were implemented using privacy lists, your client could automatically update the default "don't talk with strangers" privacy list when you do presence sharing. But we'd still need a way to bootstrap. Hmm.
IMO, for this to work we need to define some server exceptions. For example, GTalk will let <presence type='subscribe'> packets through. We'd want to take this a step further and let through any presence packet containing a <tradewithme> element.
Server DOM grovelling to look for the right extension? That doesn't sound very appealing to server developers.
We need two new XEPs: "Temporary Presence Exchange" (for exchanging caps/resource information with unknown/invisible entities),
What more does that involve on top of directed presence containing caps?
and "Presence-based Privacy" (which is TPE-aware).
I feel a lot of hoops here. How about a way to send a presence subscription request but indicate that it's intended to be only temporary?
<presence type='subscribe'> <temporary/> </presence> That'll get through without all sorts of server upgrades etc. /psa
smime.p7s
Description: S/MIME Cryptographic Signature
