Re: [Standards] Addressing Security Concerns in XEP-0115 Entity Capabilities
On 9/7/11 2:33 PM, Joe Hildebrand wrote: > On 9/5/11 6:39 AM, "Dave Cridland" wrote: > >> Of course, it may be simplest just to bite the bullet and switch hash >> algorithm - or even change the 'hash' attribute name - because then >> it'll get treated as a pre-1.4 caps by the vast majority of entities >> and everything will happen right (or at least, no worse than it often >> does today anyway). > > A bunch of our software already assumes that if you're doing old caps, you > don't have any caps we care about. > >> I'm gradually leaning toward this, because although it's *quite* >> violent, the downside is not impossible. >> >> BTW, anyone any idea what happens if you include more than one >> in a presence, in practical terms? > > I imagine you'd break enough stuff that my vote would be to use a different > namespace. And then all of the people who complain to me about the *VAST* > number of octets that caps takes will redouble their bitching and moaning. That's one reason I'd prefer to patch up XEP-0115. Including both caps and son-of-caps in presence broadcast strikes me as a bad idea. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] Addressing Security Concerns in XEP-0115 Entity Capabilities
On 9/5/11 1:54 PM, "Dave Cridland" wrote: >>> Let's say that we add (yet) another attribute to the caps element, >>> indicating that the "new" restrictions are in place. (These might include >>> the various restrictions mentioned in this thread). >>> >>> Now, when a client sees a caps marked as restricted, it can validate the >>> disco#info it gets. >>> >>> If a client sees two caps strings, one marked as restricted and one not, it >>> should assume that the caps string is intended to be restricted as proceed >>> accordingly. >> >> That's a fairly interesting idea. More thinking required. >> >> > Right, it's not a fully fleshed-out solution, for sure. Granted I might not have read the entire thread closely enough, I don't think anyone has suggested the massive-hack approach recently: REQUIRE marker entries that always sort to the end of each section, perhaps by starting with a nice high codepoint. PROHIBIT any entry that sorts higher. REJECT (and negatively cache) any response that doesn't meet these criteria. You might even choose a different marker entry for each section. Old software would still work. New software could decide how much policy to enforce. -- Joe Hildebrand
Re: [Standards] Addressing Security Concerns in XEP-0115 Entity Capabilities
On 9/5/11 6:39 AM, "Dave Cridland" wrote: > Of course, it may be simplest just to bite the bullet and switch hash > algorithm - or even change the 'hash' attribute name - because then > it'll get treated as a pre-1.4 caps by the vast majority of entities > and everything will happen right (or at least, no worse than it often > does today anyway). A bunch of our software already assumes that if you're doing old caps, you don't have any caps we care about. > I'm gradually leaning toward this, because although it's *quite* > violent, the downside is not impossible. > > BTW, anyone any idea what happens if you include more than one > in a presence, in practical terms? I imagine you'd break enough stuff that my vote would be to use a different namespace. And then all of the people who complain to me about the *VAST* number of octets that caps takes will redouble their bitching and moaning. -- Joe Hildebrand
[Standards] Fwd: SCRAM-*-PLUS examples and running servers?
Hi, I forward this email on standards@, as I was adviced so that maybe someone could help me. Thanks. Jehan -- Forwarded message -- From: Jehan Pagès Date: 2011/9/7 Subject: SCRAM-*-PLUS examples and running servers? To: "kit...@ietf.org" Hello, I have 2 clients SASL SCRAM implementations (in Objective Caml, and recently I added the support to the PHP Pear Auth_SASL package). I'd like to add the channel binding support. I think that should be more or less straightforward from reading the RFCs but what I miss are specific examples to compare with and/or a server to test with (ideally both!). The example in section 5 of RFC5802 has no channel binding, nor has the one in section 9.1.2 of RFC6120. Is there any other place with a detailed example (whatever, a RFC, a blog post, or simply an answer to this email! :-)? And would you know any Free software server implementation (preferably XMPP because I already have code to test with this, but some other protocols may do the part) which supports channel binding on SCRAM? The only I seem to find is M-Link from Isode, but it is not Free Software so I cannot install it. Alternatively if you have an already installed server with channel binding and you would be willing to provide me a test account (hence letting me do authentication tests on it), that would do it as well, of course! (that's for a good cause, 2 Free Software implementations!) Sorry for asking this on this standards list, but I did not know where I could get these information otherwise, after searching quite a bit. Thanks. Jehan
Re: [Standards] Microblogging: XEP-0277 and beyond
On 09/07/2011 07:40 AM, Justin Karneges wrote:
> On Sunday, September 04, 2011 11:47:55 PM Sergey Dobrov wrote:
>> On 09/05/2011 12:17 PM, Justin Karneges wrote:
>>> On Saturday, September 03, 2011 03:07:45 AM Sergey Dobrov wrote:
On 09/03/2011 12:41 AM, Justin Karneges wrote:
> The drawback to node metadata is it does not support update
> notifications. I have the need to track this data, particularly the
> conversation title.
Don't understand why to change that.
>>>
>>> Don't understand why the title of a conversation might change?
>>
>> Yup.
>
> In my experience a title change for a commenting area is usually only done to
> correct a typo. Still, applications that cache titles (think long running
> apps like web sites) should have a way to keep them up to date.
ok, maybe it can be useful but not a first-time needed feature. anyway,
from my point of view it will be more useful to invent more flexible
metadata protocol for nodes. (i mean, if node configuration changes may
be delivered immediately as event, why metadata can't? but I really hate
producing entities in a kind of nodes)
>
> Activity makes it much easier to determine what has happened to an
> item. For example, if a moderator edits a comment, this is easily
> described in activity terms. Simply doing complete replacement of
> comment items is not terrible but it makes it harder for listeners to
> figure out what is going on.
>
> The main point is the activity node is an append-only changelog, and
> the comments node is an up-to-date compilation of that log.
That's funny: some earlier you said: "My stance is there is nothing
wrong with using a journal to implement pubsub, but ideally pubsub-using
protocols should not be so complex that they require a journal-based
implementation to participate." And now you talking about inventing the
same journal but in specific (non-universal) way and in much more
complex manner. Why?
>>>
>>> It's simple: the activity node has optional persistence, hence the
>>> journal is optional.
>>
>> Journal is optional feature anyway. So it's more usable to make it
>> universal and not force it to depend on an applied protocol, isn't it?
>
> The activity node is actually the most normal. It doesn't even define any
> parameters. It's the raw stream of what's happening.
It is. But it's not flexible (for other protocols than XEP-303). Again,
I think that it's completely unnecessary complication for servers (since
server should support consistency of that nodes). Pubsub services are
not too ideal without that complications. If we will produce more and
more entities that can not be reused we will have the sad end. So I
think that it will be better to invent FLEXIBLE journal than reinvent it
in each applied protocol.
>
> The comments node is the weird one. It's a view/compilation of the activity.
>
> The plan for likes is you'd publish to the activity node ("Justin likes
> comment X"), but on the comment node this would be reflected as a
> property of an existing comment rather than a new item. Comment items
> could have "like" data stored within them, such as a count and maybe a
> list of the last five people to like the comment.
I think that all these actions should not be copied from centralized
services since that services have more possibilities to control them. I
mean, it will be very hard to check if likes are winded by some bad
mans. Also it will be hard to represent some statistics of most liked
items. So I think that these things should be solved in that manner how
google ranking web pages: aggregators will rank items by repost counts
or something. And, yes, for user like button should be replaced by
"repost" or "repost with comment", I have such functionality in my
microblogging service and I want to add it into the XEP-277.
>>>
>>> What do you mean by centralized? That the conversation is the authority
>>> on all of its replies and likes?
>>
>> Yes, I don't understand what is the reason to have likes in such system
>> if we can't count them globally and give stats.
>
> The problem with distributing a single conversation across servers is then
> you
> need a way of aggregating even in the common case. Simply viewing the
> conversation properly with nested threads and like points requires an
> aggregator.
>This is what Salmon is for in the HTTP world: telling upstream
> you've made a reply/like/etc.
But it's already solved in the pubsub world: we have event delivering
system.
> My humble opinion is that this approach does
> have some cool-factor but it is also a giant pain in the ass in terms of
> practicality.
>
> I think that if we ever did support distributed conversations then you'd
> still
> want the main conversation node (root node) to be able to hold copies of all
> the content (e.g. use a salmon-like process so
