> On Mar 10, 2015, at 8:51 AM, Christian Ulrich <christian...@rechenwerk.net> 
> wrote:
> 
> 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.

Well, the text would need changing once that form is included in the XEP. The 
point though is that using that form will only be able to disable information 
in practice, not enable it. Even if you try enabling `include-message-bodies`, 
message bodies wouldn't actually be included if the user had previously 
disabled that option.


I would gladly concede that I'm being overly paranoid here. Feedback welcome on 
if this cautious approach is even useful.


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

+1, I imagine this will end up working like the disco features for pubsub.



Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to