Re: [Standards] MUC2 - The case for removing semi-anonymous
I would like us to Get This Right, though. People have been mumbling about replacing MUC for years, and I’ve always been resistant; the discussions at the summit this year persuaded me that we finally have requirements that MUC1 can’t easily meet, but I really do not want us to do MUC2 now and MUC3 in 2017 to fix the stuff we got wrong in MUC2. [Steve Kille] Kev - I strongly agree with this goal. It seems to me that the default semi-anonymous MUC1 is generally seen as the way MUC works and is not a conscious option selection choice. I've not seen use where this behaviour seems particularly desirable. I have seen significant customer concern about controlling mis-leading use of nicks and people misrepresenting themselves in MUCs. I suspect that non-anonymous would be better behaviour for many MUC users, but there has not been active consideration to use it. MUC2 will allow MUCs to allow users to read MUCs without sharing presence. This seems a highly desirable option (lots of reasons). This option will allow people to read MUCs anonymously, which I think for some MUCs can be a sensible and desirable privacy option. I think that if you want to share your presence with the group or send a message to a group, that enforcing that you also share your jid is highly desirable.In XMPP the jid is who you are. I can't see a clear use case for allowing people to post to a MUC without clearly identifying themselves. Steve
Re: [Standards] MUC2 - The case for removing semi-anonymous
On 26 Jun 2015 07:24, Steve Kille steve.ki...@isode.com wrote: I would like us to Get This Right, though. People have been mumbling about replacing MUC for years, and I’ve always been resistant; the discussions at the summit this year persuaded me that we finally have requirements that MUC1 can’t easily meet, but I really do not want us to do MUC2 now and MUC3 in 2017 to fix the stuff we got wrong in MUC2. [Steve Kille] Kev - I strongly agree with this goal. I think a key criterion for success will be if MUC2 can meet all commonly deployed use-cases across both XEP-0045 and other multiparty chat (including non-XMPP cases). It seems to me that the default semi-anonymous MUC1 is generally seen as the way MUC works and is not a conscious option selection choice. It's tempting to go that way, but it's very close to saying I disagree with the outcome, so the evidence must be wrong. The problem is that the only evidence we have as to how desirable this feature is is the number of chatrooms commonly using it. That *could* easily be that it's the default in many servers, but that in turn raises the question of why that's so. In short, I don't claim to know, but I hesitate to ascribe all such use to ignorance on behalf of the administrators. What I can tell you is that when I asked about the Prosody default (it's semi-anonymous), the response was that we try to make the defaults privacy friendly; this implies that the default, at least, was a conscious choice. I've a feeling that M-Link defaults the same way for the same reason - maybe that's changed (and if not, maybe it should). I've not seen use where this behaviour seems particularly desirable. I have seen significant customer concern about controlling mis-leading use of nicks and people misrepresenting themselves in MUCs. I suspect that non-anonymous would be better behaviour for many MUC users, but there has not been active consideration to use it. So what you're saying is that in all the chatrooms I'm usually in, only the Openfire project leads have considered how to configure their chatroom? I'd note for the record that I'm usually present in both Prosody chatrooms and XSF chatrooms (xsf@ and jdev@), all of which are semi-anonymous. It seems odd to me that anonymity is such a problem if the administrators there are content to leave it in place - they're hardly unaware of the way MUC works. After all, many of those administrators are on this thread. I think within government, military, and enterprise, strong identity is an absolute requirement, but I'd note that misleading use of nicks and people misrepresenting themselves in MUCs is soluble already by nickname enforcement and registration, as part of XEP-0045. So if your customers are concerned about that, you should show them that, as well as (of course) the non-anonymous configuration. Finally, I'd note that under the semi-anonymous model, both the chatroom itself and any administrators are fully aware of the real jid of the occupant, and can act directly upon it - so the scope for abuse is limited entirely to what the chatroom allows. (Unless the abuse is also possible by non-anonymous users). MUC2 will allow MUCs to allow users to read MUCs without sharing presence. This seems a highly desirable option (lots of reasons). This option will allow people to read MUCs anonymously, which I think for some MUCs can be a sensible and desirable privacy option. I don't think that the absence of presence means (or should mean) that subscriptions are anonymous or invisible. Part of basic privacy would be being aware of people reading your messages, even those messages to a group. The only way to read such messages would be if the archive was available to unsubscribed users. I think that if you want to share your presence with the group or send a message to a group, that enforcing that you also share your jid is highly desirable.In XMPP the jid is who you are. I can't see a clear use case for allowing people to post to a MUC without clearly identifying themselves. I absolutely agree that making non-anonymous better is highly desirable. In a number of markets, and certainly in Isode's and Surevine's, hiding the real jid behind an occupant jid is problematic, and the relative obscurity of the real jid in MUC means that non-anonymous rooms are somewhat of a second-class citizen. From a technical standpoint, having the address of an occupant, and therefore the identity, selected by that occupant causes a number of issues, including security ones. However, just because non-anonymous is useful for some markets should not preclude anonymity for others. Dave.
Re: [Standards] MUC2
On 25 Jun 2015, at 11:11, Daniel Gultsch dan...@gultsch.de wrote: As I understand this MUC2 should not rely replace the current MUC but provide an alternative. Not really, the aim is to fix the issues MUC has, and produce something better that can be used in its place in the future. Someone who needs the full IRC-like feature set (large groups mostly with people you don't know personally) can still use MUC1. Well, they can’t, because that’s one of the things that MUC1 scales quite badly at, with all the presences and traffic at login. Fixing that in MUC2 would be good. Yes. Plus that gives us the ability to not have private messages which are always a mess (carbons) - not sure if this is what you meant by addressing messes. One of several things, yes. /K
Re: [Standards] MUC2
Hi, 2015-06-25 10:27 GMT+02:00 Kevin Smith kevin.sm...@isode.com: Thinking a bit about the MUC2 stuff. MUC1 had Anon/semianon/nonanon. We’ve pretty much killed off fully anonymous rooms in MUC1. Can people share their thoughts on usecases for semi-anon, please? It’s not entirely clear to me what these are (users who want anonymity seem to already be using throw-away JIDs to achieve that, instead of relying on MUC configuration). As I understand this MUC2 should not rely replace the current MUC but provide an alternative. Someone who needs the full IRC-like feature set (large groups mostly with people you don't know personally) can still use MUC1. Therefore we shouldn't be afraid to really limit the feature set of MUC2 to something that a majority of people will actually use. There seems to be some significant merit in having MUCs always be non-anonymous in MUC2, to solve some of the addressing messes we’ve found ourselves in. Yes. Plus that gives us the ability to not have private messages which are always a mess (carbons) - not sure if this is what you meant by addressing messes. And we can do proper PEP for avatars and other stuff. cheers Daniel
Re: [Standards] MUC2
On Thu, Jun 25, 2015 at 3:27 AM, Kevin Smith kevin.sm...@isode.com wrote: Can people share their thoughts on usecases for semi-anon, please? It’s not entirely clear to me what these are (users who want anonymity seem to already be using throw-away JIDs to achieve that, instead of relying on MUC configuration). It's not clear to me that there are *any* use cases. Maintaining two methods of having 1:1 conversations (normal 1:1's, and the anon-MUC version of 1:1's) just makes everything more complicated for no real benefit. There seems to be some significant merit in having MUCs always be non-anonymous in MUC2, to solve some of the addressing messes we’ve found ourselves in. Agreed; MUC2 should absolutely remove the semi-anon capabilities. This will ensure that the MUC2 specification is kept clean and simple. If a user wants to keep their JID private (for some reason), joining an anonymous MUC is not the way to do it anyways (since admins can still see it, and/or the server admin could always make the MUC public and you probably wouldn't even notice), so (as you said) people are going to end up using burner JID's anyways. Having them always be non-private also serves the added benefit of providing some sort of assurance that you're actually talking to the same person two days in a row (eg. Alice talks to Bob on day 1, the next day she talks to Bob but it's someone else who claimed the same nick... now she can verify that the JID is the same, so it's at least someone with access to Bob's account). Of course, this can already be better achieved with PGP, but let's be honest, that never works (going slightly OT with that line of reasoning though). I'm very much hoping that MUC2 will be one of the hot topics at the North American Summit this October. —Sam -- Sam Whited pub 4096R/54083AE104EA7AD3 https://blog.samwhited.com
Re: [Standards] MUC2
On 25 jun. 2015, at 10:27, Kevin Smith kevin.sm...@isode.com wrote: Thinking a bit about the MUC2 stuff. MUC1 had Anon/semianon/nonanon. We’ve pretty much killed off fully anonymous rooms in MUC1. Can people share their thoughts on usecases for semi-anon, please? It’s not entirely clear to me what these are (users who want anonymity seem to already be using throw-away JIDs to achieve that, instead of relying on MUC configuration). 1. Privacy. 2. To not turn public MUCs into treasure troves for spam bots. All of these JIDs have an active client signed in, so they are great targets. 3. Best practices currently dictate that resources should be random, as they are privacy-sensitive. That’s almost opposite of revealing it to everyone in a room. Thijs
Re: [Standards] MUC2
On Thu, Jun 25, 2015 at 9:39 AM, Kevin Smith kevin.sm...@isode.com wrote: On 25 Jun 2015, at 15:28, Peter Saint-Andre - yet pe...@andyet.net wrote: Semi-anonymous rooms are like IRC channels. Draw your own conclusions for whether that's good or bad. I don’t think that’s true, is it? Having or not having @ in a particular channel doesn’t affect your ability to whois a user on IRC to the best of my knowledge. It's true in the sense that a nick in IRC (or a semi-anonymous MUC) is effectively an ephemeral identity. Eg. if you're talking to someone on IRC and they part and then join again, you can't be sure it's actually the same user (unless they've registered the nick; let's ignore the fact that you can probably whois and snag their IP address... maybe it's dynamic and it changes between your conversations). However, once you throw JIDs into the mix it doesn't matter if the nick is ephemeral, you can always see that the JID is the same, meaning that whomever you're speaking with at least has access to the same account. —Sam -- Sam Whited pub 4096R/54083AE104EA7AD3 https://blog.samwhited.com
Re: [Standards] MUC2
On 25.06.2015 17:09, Thijs Alkemade wrote: On 25 jun. 2015, at 10:27, Kevin Smith kevin.sm...@isode.com wrote: Thinking a bit about the MUC2 stuff. MUC1 had Anon/semianon/nonanon. We’ve pretty much killed off fully anonymous rooms in MUC1. Can people share their thoughts on usecases for semi-anon, please? It’s not entirely clear to me what these are (users who want anonymity seem to already be using throw-away JIDs to achieve that, instead of relying on MUC configuration). 1. Privacy. 2. To not turn public MUCs into treasure troves for spam bots. All of these JIDs have an active client signed in, so they are great targets. To hide your contact data should never and can't be the answer against SPAM. I stopped obfuscating my Mail address a few years ago. It's available in a few dozen places over the net. Yet I don't have an issue with SPAM. That same should be true for my JID. 3. Best practices currently dictate that resources should be random, as they are privacy-sensitive. That’s almost opposite of revealing it to everyone in a room. Ack. MUC2 (or similar protocols) should be designed to only show the bare JID of the participants. - Florian signature.asc Description: OpenPGP digital signature
Re: [Standards] MUC2
On 25 Jun 2015, at 15:28, Peter Saint-Andre - yet pe...@andyet.net wrote: On 6/25/15 2:27 AM, Kevin Smith wrote: Thinking a bit about the MUC2 stuff. MUC1 had Anon/semianon/nonanon. s/had/has/ I think ‘had’ was right. Anonymous rooms were removed in 0.6 by a certain “PSA” :) Now it has semianon and nonanon. Can people share their thoughts on usecases for semi-anon, please? Semi-anonymous rooms are like IRC channels. Draw your own conclusions for whether that's good or bad. I don’t think that’s true, is it? Having or not having @ in a particular channel doesn’t affect your ability to whois a user on IRC to the best of my knowledge. It’s not entirely clear to me what these are (users who want anonymity seem to already be using throw-away JIDs to achieve that, instead of relying on MUC configuration). We didn't have throw-away JIDs (well, SASL anonymous JIDs anyway) in the old days. I didn't mean SASL ANONYMOUS when I said throw-away JIDs, I meant that people are registering single-purpose JIDs. There was a brief discussion in xsf@ earlier that if people wanted anonymity they’d be better served by someone writing an anonymising proxy. The only use case we came up with so far that wasn’t better served with throw-away/singleuse JIDs (at first glance; I’m happy to admit I’m missing things here) was a company-internal one where an anonymising proxy would probably be appropriate. There seems to be some significant merit in having MUCs always be non-anonymous in MUC2, to solve some of the addressing messes we’ve found ourselves in. I do think that a system needing anonymity (say, a helpline) can handle that using anonymous JIDs, not anonymous roomnicks. Great. /K
Re: [Standards] MUC2
On 25 Jun 2015, at 15:48, Sam Whited s...@samwhited.com wrote: On Thu, Jun 25, 2015 at 9:39 AM, Kevin Smith kevin.sm...@isode.com wrote: On 25 Jun 2015, at 15:28, Peter Saint-Andre - yet pe...@andyet.net wrote: Semi-anonymous rooms are like IRC channels. Draw your own conclusions for whether that's good or bad. I don’t think that’s true, is it? Having or not having @ in a particular channel doesn’t affect your ability to whois a user on IRC to the best of my knowledge. It's true in the sense that a nick in IRC (or a semi-anonymous MUC) is effectively an ephemeral identity. Eg. if you're talking to someone on IRC and they part and then join again, you can't be sure it's actually the same user (unless they've registered the nick; let's ignore the fact that you can probably whois and snag their IP address... maybe it's dynamic and it changes between your conversations). However, once you throw JIDs into the mix it doesn't matter if the nick is ephemeral, you can always see that the JID is the same, meaning that whomever you're speaking with at least has access to the same account. I think that says “Ignore the bit that makes it untrue” is probably detrimental to this argument :) In my mind, the closest analogy to MUC nicks is IRC nicks, and the closest analogy to JIDs is the whois result. It’s not a clean mapping to start with, because just having someone’s nick (especially on registered-nick services) is enough to be able to identify someone across the whole service, they’re not per-MUC. /K
Re: [Standards] MUC2
On 25 June 2015 at 15:28, Peter Saint-Andre - yet pe...@andyet.net wrote: On 6/25/15 2:27 AM, Kevin Smith wrote: Thinking a bit about the MUC2 stuff. MUC1 had Anon/semianon/nonanon. s/had/has/ We’ve pretty much killed off fully anonymous rooms in MUC1. I think those were never supported. Can people share their thoughts on usecases for semi-anon, please? Semi-anonymous rooms are like IRC channels. Draw your own conclusions for whether that's good or bad. It’s not entirely clear to me what these are (users who want anonymity seem to already be using throw-away JIDs to achieve that, instead of relying on MUC configuration). We didn't have throw-away JIDs (well, SASL anonymous JIDs anyway) in the old days. There seems to be some significant merit in having MUCs always be non-anonymous in MUC2, to solve some of the addressing messes we’ve found ourselves in. I do think that a system needing anonymity (say, a helpline) can handle that using anonymous JIDs, not anonymous roomnicks. I vaguely recall that many years ago we discussed that individuals have anonymity requirements, and not rooms. If you predicate the existence of services which act as pseudonymizers (if you're one of the ancients, anon.penet.fi), then chaining a few of these together gives much stronger assurances than an anonymous MUC room ever could. Peter -- Peter Saint-Andre https://andyet.com/
Re: [Standards] MUC2
On 6/25/15 8:39 AM, Kevin Smith wrote: On 25 Jun 2015, at 15:28, Peter Saint-Andre - yet pe...@andyet.net wrote: On 6/25/15 2:27 AM, Kevin Smith wrote: Thinking a bit about the MUC2 stuff. MUC1 had Anon/semianon/nonanon. s/had/has/ I think ‘had’ was right. Anonymous rooms were removed in 0.6 by a certain “PSA” :) Now it has semianon and nonanon. Ah, I thought you were talking about XEP-0045 in the past tense. ;-) Can people share their thoughts on usecases for semi-anon, please? Semi-anonymous rooms are like IRC channels. Draw your own conclusions for whether that's good or bad. I don’t think that’s true, is it? Having or not having @ in a particular channel doesn’t affect your ability to whois a user on IRC to the best of my knowledge. True. It’s not entirely clear to me what these are (users who want anonymity seem to already be using throw-away JIDs to achieve that, instead of relying on MUC configuration). We didn't have throw-away JIDs (well, SASL anonymous JIDs anyway) in the old days. I didn't mean SASL ANONYMOUS when I said throw-away JIDs, I meant that people are registering single-purpose JIDs. There was a brief discussion in xsf@ earlier that if people wanted anonymity they’d be better served by someone writing an anonymising proxy. The only use case we came up with so far that wasn’t better served with throw-away/singleuse JIDs (at first glance; I’m happy to admit I’m missing things here) was a company-internal one where an anonymising proxy would probably be appropriate. Something like an undernet for a company? There seems to be some significant merit in having MUCs always be non-anonymous in MUC2, to solve some of the addressing messes we’ve found ourselves in. I do think that a system needing anonymity (say, a helpline) can handle that using anonymous JIDs, not anonymous roomnicks. Great. Violent agreement. Peter -- Peter Saint-Andre https://andyet.com/
Re: [Standards] MUC2
On 25 Jun 2015, at 16:59, Dave Cridland d...@cridland.net wrote: Removing a widely deployed feature doesn't strike me as a viable option. Well, if we s/widely deployed/widely required/ then I agree. But not baking something into the MUC2 core doesn’t necessarily mean removing the feature. If we’re going to try to blank-canvas a MUC replacement, I’d like to try and look at options as widely as we can. For example, (assuming semi-anonymousness is a requirement) is it possible to not require anything other than non-anonymous in MUC2, but discuss (either in spec or out of spec) how one would do anonymising if one wanted to? I don’t know. I would like us to Get This Right, though. People have been mumbling about replacing MUC for years, and I’ve always been resistant; the discussions at the summit this year persuaded me that we finally have requirements that MUC1 can’t easily meet, but I really do not want us to do MUC2 now and MUC3 in 2017 to fix the stuff we got wrong in MUC2. /K
Re: [Standards] MUC2
On 25 Jun 2015 18:05, Kevin Smith kevin.sm...@isode.com wrote: On 25 Jun 2015, at 16:59, Dave Cridland d...@cridland.net wrote: Removing a widely deployed feature doesn't strike me as a viable option. Well, if we s/widely deployed/widely required/ then I agree. But not baking something into the MUC2 core doesn’t necessarily mean removing the feature. If we’re going to try to blank-canvas a MUC replacement, I’d like to try and look at options as widely as we can. Well, what you're trying to avoid is addressable occupants, correct? That removes private messages, rather than anonymity, I think. Private messages do cause problems in a variety of interesting ways, but equally I find it interesting that they provide me with an immediate indicator of where someone has found me. For example, (assuming semi-anonymousness is a requirement) is it possible to not require anything other than non-anonymous in MUC2, but discuss (either in spec or out of spec) how one would do anonymising if one wanted to? I don’t know. Maybe the better idea is to look at how chatrooms are actually used, and run UX interviews with people who are regular users. It's not very technical, I admit, but I find it very hard to gauge whether some of these features are desirable or confusing, since I've simply got used to this being the way things work. People keep telling us that Slack has ask these things right, but aside from having a nice user interface and plenty of integration, I'm not clear if there's anything else that makes it a clear winner. I would like us to Get This Right, though. People have been mumbling about replacing MUC for years, and I’ve always been resistant; the discussions at the summit this year persuaded me that we finally have requirements that MUC1 can’t easily meet, but I really do not want us to do MUC2 now and MUC3 in 2017 to fix the stuff we got wrong in MUC2. /K
Re: [Standards] MUC2
On 25 June 2015 at 09:27, Kevin Smith kevin.sm...@isode.com wrote: Thinking a bit about the MUC2 stuff. MUC1 had Anon/semianon/nonanon. We’ve pretty much killed off fully anonymous rooms in MUC1. Can people share their thoughts on usecases for semi-anon, please? It’s not entirely clear to me what these are (users who want anonymity seem to already be using throw-away JIDs to achieve that, instead of relying on MUC configuration). There seems to be some significant merit in having MUCs always be non-anonymous in MUC2, to solve some of the addressing messes we’ve found ourselves in. Some thoughts: I think almost every MUC room I'm in is semi-anonymous. The only exception I could immediately find was the Openfire chatroom, open_c...@conference.igniterealtime.org - it seems pretty unlikely that this is by accident, but perhaps every server does this by default, and none of the admins have ever noticed. Removing a widely deployed feature doesn't strike me as a viable option. I (personally, mind you) would be happy if pseudonymized users in chatrooms reduced available features. For example, it seems bizarre that in the typical [semi-]anonymous MUC, I can query a vCard of an anonymous user. So for example I can join the XSF chatroom, and while I cannot discover Zash's jid, I can find his real name and email address. This strikes me as nuts. I also suspect that if we promoted the usage of anonymizers as a day-to-day way to shield one's jid, this might have detrimental effects on chatroom abuse. Dave.
