Re: [Standards] Categories in the Bookmarks XEP

2013-08-15 Thread Maxim Ignatenko
On 15 August 2013 18:47, Peter Saint-Andre  wrote:
> On 8/15/13 2:26 AM, Jaussoin Timothée wrote:
>> I have implemented the Bookmarks XEP
>> (http://xmpp.org/extensions/xep-0048.html) in Movim (http://movim.eu/)
>> to store the conferences, URL and subscribed Pubsub feeds of the user.
>>
>> Maybe it can be a great idea to add a "category" tag with some "default"
>> categories like news, blog, nsfw... With this kind of feature I'll be
>> able to tag more precisely the Pubsub items and maybe add special
>> behaviours one some of them (like hide by default the content of the
>> nsfw items or display in priority the news items).
>
> In general, tagging is a good thing. :-)
>
> Do you propose that we add a 'tag' attribute to both the  element
> and the  element? Would it contain a space-separated list
> of tags?
>

Adding repeatable '' subelement looks like much better idea to
me and will avoid limitations of having a separator.

-- 
Best regards,
Maxim


Re: [Standards] SASL EXTERNAL (XEP-0178) and client awkwardness

2013-08-15 Thread Dave Cridland
On Thu, Aug 15, 2013 at 8:47 PM, Thijs Alkemade  wrote:

> Both the server's and the client's certificate are sent in plain during the
> handshake. This means that any id-on-xmppAddr attribute, common name field
> or
> any other personal info on the certificate will be visible to any passive
> observer of the stream. Every client I've used tries to avoid leaking your
> identity before TLS is active (no 'from' attribute on the initial stream)
> and
> this could break that.
>
> Even when a user is using a certificate with no personally identifiable
> information at all, just by looking at the public key an observer could
> try to
> correlate different connections to the same account.
>
>
Yes, but I don't think that's a particular point in mind with XEP-0178, or
indeed XMPP in general.


> In RFC 6120, §5.1.3 point 3 this is covered this by mentioning TLS
> renegotiation
> as a way to protect the client's certificate if it's known to be private. I
> guess this would work, though I'm not sure how well-supported that is.
>
>
Hmmm... I know at least some implementations might struggle. You'd have two
negotiations, and you'd have to hope that the server looked at the one you
wanted.


> I think it would be good if XEP-0178 at least mentioned that the
> certificate is
> sent in plain and pointed to §5.1.3 for a workaround.
>

I'd much rather we investigated the practical implications - '178 is
intended as best practice, so  it'd be nice to know it worked.


Re: [Standards] Categories in the Bookmarks XEP

2013-08-15 Thread Jaussoin Timothée

Le 15/08/2013 19:47, Peter Saint-Andre a écrit :

On 8/15/13 2:26 AM, Jaussoin Timothée wrote:

I have implemented the Bookmarks XEP
(http://xmpp.org/extensions/xep-0048.html) in Movim (http://movim.eu/)
to store the conferences, URL and subscribed Pubsub feeds of the user.

Maybe it can be a great idea to add a "category" tag with some "default"
categories like news, blog, nsfw... With this kind of feature I'll be
able to tag more precisely the Pubsub items and maybe add special
behaviours one some of them (like hide by default the content of the
nsfw items or display in priority the news items).

In general, tagging is a good thing. :-)

Do you propose that we add a 'tag' attribute to both the  element
and the  element? Would it contain a space-separated list
of tags?

Peter


Hi !

I've also added a specific element to bookmark the pubsub nodes, this way :

http://jabber.org/protocol/pubsub";>
  


name="Movim">

edhelas

subid="" node="BouletCorp" server="pubsub.movim.eu">



subid="" node="CerealesMatin" server="pubsub.movim.eu">



subid="" node="Chez_Kek" server="pubsub.movim.eu">



subid="" node="JournalDuGeek" server="pubsub.movim.eu">



subid="" node="LinuxFr" server="pubsub.movim.eu">





  


We can maybe re-use the same tag system than for the atom elements :


edhelas





It's just an idea :)



Re: [Standards] SASL EXTERNAL (XEP-0178) and client awkwardness

2013-08-15 Thread Thijs Alkemade

On 20 jun. 2013, at 05:14, Peter Saint-Andre  wrote:

>  
> >> So when we wrote XEP-0178 this was fairly vague, but the upshot
> >> is that it probably needs some revision:
> >> 
> >> 1) The right way to specify the jid you're expecting to become is
> >> by using the from attribute of the stream. This is most
> >> especially true for servers.
> > 
> > I'm still not sure I understand 10(c), though. Does "the address 
> > specified during SASL negotiation" refer to the "from" attribute on
> > the ?
> 
> IMHO that would indeed be the 'from' on the initial stream header. It
> would be good to clear that up in the spec, eh?
> 
> Peter

There's one more point I want to make about this, not exactly related, but close
enough to continue this thread.

The security considerations section of XEP-0178 states only:

"This document introduces no security considerations or concerns above and
beyond those discussed in RFC 6120 and RFC 6125."

While that may be true, there's one thing that might warrant some emphasis:

Both the server's and the client's certificate are sent in plain during the
handshake. This means that any id-on-xmppAddr attribute, common name field or
any other personal info on the certificate will be visible to any passive
observer of the stream. Every client I've used tries to avoid leaking your
identity before TLS is active (no 'from' attribute on the initial stream) and
this could break that.

Even when a user is using a certificate with no personally identifiable
information at all, just by looking at the public key an observer could try to
correlate different connections to the same account.

In RFC 6120, §5.1.3 point 3 this is covered this by mentioning TLS renegotiation
as a way to protect the client's certificate if it's known to be private. I
guess this would work, though I'm not sure how well-supported that is.

I think it would be good if XEP-0178 at least mentioned that the certificate is
sent in plain and pointed to §5.1.3 for a workaround.

Regards,
Thijs


signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: [Standards] Categories in the Bookmarks XEP

2013-08-15 Thread Peter Saint-Andre
On 8/15/13 2:26 AM, Jaussoin Timothée wrote:
> I have implemented the Bookmarks XEP
> (http://xmpp.org/extensions/xep-0048.html) in Movim (http://movim.eu/)
> to store the conferences, URL and subscribed Pubsub feeds of the user.
> 
> Maybe it can be a great idea to add a "category" tag with some "default"
> categories like news, blog, nsfw... With this kind of feature I'll be
> able to tag more precisely the Pubsub items and maybe add special
> behaviours one some of them (like hide by default the content of the
> nsfw items or display in priority the news items).

In general, tagging is a good thing. :-)

Do you propose that we add a 'tag' attribute to both the  element
and the  element? Would it contain a space-separated list
of tags?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/




[Standards] Categories in the Bookmarks XEP

2013-08-15 Thread Jaussoin Timothée
I have implemented the Bookmarks XEP 
(http://xmpp.org/extensions/xep-0048.html) in Movim (http://movim.eu/) 
to store the conferences, URL and subscribed Pubsub feeds of the user.


Maybe it can be a great idea to add a "category" tag with some "default" 
categories like news, blog, nsfw... With this kind of feature I'll be 
able to tag more precisely the Pubsub items and maybe add special 
behaviours one some of them (like hide by default the content of the 
nsfw items or display in priority the news items).


What do you think about this ?

Tim