On Di, 2015-03-10 at 00:43 -0700, Lance Stout wrote:
> The intent in the security section is to not allow changing in-band what
> content gets delivered via the push notifications, not the enabling/disabling
> of push services.
>
> Otherwise, a client could surreptitiously change the settings to include
> private information like full message bodies and contact JIDs when the user
> had previously chosen not to allow publishing that data.
>
> I'll add some clarifying language.
>
> Of course, the same sort of opportunities exist for bad clients already, such
> as adding to a user's roster without their consent. However, such things are
> generally noticeable by the user and correctable. Push services are more
> shielded from the user's notice and thus much easier to exploit.
>
I must have skipped the "in-band-configuration not recommended"
paragraph the first time, so my suggestion of including settings in the
enabled stanza is not recommended.
An example for out-of-band configuration would be logging into a web
interface and deselect include-message-bodies, right? That's a lot of
effort, so maybe the server should at least tell the user how it's
configured. Then the user can decide if re-configuring is necessary.
Service discovery could return the user-specific configuration:
<iq from='jul...@capulet.lit'
to='jul...@capulet.lit/balcony'
id='disco1'
type='result'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<identity category='account' type='registered'/>
<feature var='urn:xmpp:push:0'/>
<x xmlns='jabber:x:data'>
<field var='FORM_TYPE'>
<value>urn:xmpp:push:0#configuration</value>
</field>
<field var='include-message-count'><value>1<value></field>
<field var='include-message-bodies'><value>0<value></field>
<field var='include-senders'><value>0<value></field>
<field var='include-pending-subscription-count'>
<value>1<value>
</field>
</x>
</query>
</iq>
Christian
