Re: [Standards] Requirements for "Jid Hidden" Channels
On 2 June 2018 at 17:36, Steve Kille wrote: > It is clear that much of the complexity around JID encoding that is being > postulated as necessary, ties back to requirements to support participant > communication through JID Hidden channels. > > This note is to step back from the JID discussion, and consider JID Hidden > channel requirements. > > I'm writing out a list of requirements here, which I think when agreed, > could be usefully used as part of the introductory material to MIX-ANON. > > With JID Visible channels, real JIDs are shared and participants can use > this to communicate directly. > > When looking at MIX requirements, quite a few argued that we should not > have > JID Hidden. A lot of other chat systems (e.g., Facebook) do not have an > equivalent of JID Hidden. I think that many channels will be JID Visible. > > That's not been the case, though, historically. Most MUC rooms are anonymous. > > It was agreed clearly that we need JID Hidden, primarily to prevent JID > Harvesting. This is going to be useful for public and semi-public > channels. > > REQUIREMENTS: > > 1. Participants can see which other participants have one or more online > clients. > > 2. Online participants can be displayed with a Nick. > > 3. Participants MUST be able to see if another participant changes Nick. > > 4.Participants can sent messages to other participants through the > channel if channel policy allows this. > > 5.A participant can share real JID with another participant and request > real JID. Can't do this currently, but it seems sensible to allow a pair > of willing participants to shift from restricted communication through the > channel to direct communication. > > > POSSIBLE REQUIREMENTS: > > 6. Participants can share presence status additional to online/offline. > I am wondering if, in an environment where JIDs are being hidden, if it > makes sense to share other presence stuff with the channel. My sense is > that for a public MUC, it might make sense to restrict. I would vote to > make this a non-requirement. > > If we assume that people will use MIX in the same way MUC is typically used, then presence is usually (intentionally, I think) shared amongst anonymous participants. > > 7. Where a participant has multiple clients, other participants can see > independent status of these clients. I think that this is not appropriate > for JID Hidden channels. If you are not sharing your JID, it feels wrong > to > be sharing how many clients you have. > > I this this depends on *why* you're hiding your JID. In some cases, people are after perfect anonymity. In general, I think we should ensure that it is possible to have a MIX channel which JIDs are completely hidden (which probably includes avoiding pass-through for IQ, etc in those cases). The two cases I can think of are the e-health case, where we want to be able to assure participants that their identity is secret, and the legal case where corporations wish to participate in some collaborative venture without being definitively identified. (Cyber collaboration, or collaborative security, is an example of the last case). In most cases, though, people seem to want to hide their JID, but not hide their identity. This seems to be the case in the vast majority of MUC rooms I'm in, in fact. Your point (5) would be very useful here, since it would allow, in principle, to subscribe to your presence through a chatroom, which is (pretty much) the use-case here. > > NON REQUIREMENTS > > > 8. vCard. If you are hiding your JID, it seems wrong to allow retrieval > of generic information about you. I think that getting vCard information > about other participants should be explicitly excluded. > > Well, it does seem a bit crazy - and why, back when I did the higher level MUC implementation in M-Link, I explicitly made passing through vCard requests an option. But it turns out most people usually want this for avatars if nothing else. > > 9. Client Disco. I think that allowing clients to use IQ disco of JID > Hidden participants is wrong. If you feel that JID should be hidden, it > does not make sense to > > Totally disagree. This blocks nearly every elective feature of XMPP being used. You might think an anonymous client will never want to do, say, voice calls, but I suspect that's only true if the goal is true anonymity - in which case burner jids are more useful. In practise, though, things like focus users in conference systems work using this. > > > I appreciate that this has switched topics. I think that getting some > agreements here, would help to sort the JID discussion. > > Can we keep this thread on "JID Hidden" and see if we can agree > requirements? > > > > > > Steve > > > > > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___
Re: [Standards] Requirements for "Jid Hidden" Channels
On 2 Jun 2018, at 17:36, Steve Kille wrote: > It is clear that much of the complexity around JID encoding that is being > postulated as necessary, ties back to requirements to support participant > communication through JID Hidden channels. > > This note is to step back from the JID discussion, and consider JID Hidden > channel requirements. > > I'm writing out a list of requirements here, which I think when agreed, > could be usefully used as part of the introductory material to MIX-ANON. > > With JID Visible channels, real JIDs are shared and participants can use > this to communicate directly. I think that’s at the core of the issue with where the addressing/routing rules go - if it was true then moving them out into mix-anon would make sense, but I don’t believe it is. Because the current state of the network is that stanzas from entities not in your roster/not a room you’re joined to are very often blocked for spam reasons relying on real JID routing to enable communication between MIX participants is unlikely to work and that we’ll need the routing and addressing logic in core because of this. This is only the very basic routing/addressing logic and all of the anon-related stuff remains in mix-anon. > When looking at MIX requirements, quite a few argued that we should not have > JID Hidden. A lot of other chat systems (e.g., Facebook) do not have an > equivalent of JID Hidden. I think that many channels will be JID Visible. > > > It was agreed clearly that we need JID Hidden, primarily to prevent JID > Harvesting. This is going to be useful for public and semi-public > channels. > > REQUIREMENTS: > > 1. Participants can see which other participants have one or more online > clients. > > 2. Online participants can be displayed with a Nick. > > 3. Participants MUST be able to see if another participant changes Nick. > > 4.Participants can sent messages to other participants through the > channel if channel policy allows this. That’s the one that we fail with. > 5.A participant can share real JID with another participant and request > real JID. Can't do this currently, but it seems sensible to allow a pair > of willing participants to shift from restricted communication through the > channel to direct communication. Is that really a requirement? It might be, but also sharing the JID manually seems like a sensible sort of thing to do (I could be persuaded, but I don’t see this really as a core requirement currently) > POSSIBLE REQUIREMENTS: > > 6. Participants can share presence status additional to online/offline. > I am wondering if, in an environment where JIDs are being hidden, if it > makes sense to share other presence stuff with the channel. My sense is > that for a public MUC, it might make sense to restrict. I would vote to > make this a non-requirement. It might make sense to restrict it in some cases, but not in the general case, I think. > 7. Where a participant has multiple clients, other participants can see > independent status of these clients. I think that this is not appropriate > for JID Hidden channels. If you are not sharing your JID, it feels wrong to > be sharing how many clients you have. I’m not sure about this. > NON REQUIREMENTS > > > 8. vCard. If you are hiding your JID, it seems wrong to allow retrieval > of generic information about you. I think that getting vCard information > about other participants should be explicitly excluded. > > > 9. Client Disco. I think that allowing clients to use IQ disco of JID > Hidden participants is wrong. If you feel that JID should be hidden, it > does not make sense to Except that we rely on disco/caps for basic functionality, so this seems hard to avoid. There may be specific channels where it’s appropriate to block this (just as direct interactions are blocked in specific channels in MUC at the moment), but I don’t think that’s true in the general case. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Requirements for "Jid Hidden" Channels
On Sat, Jun 2, 2018, at 18:22, Steve Kille wrote: > Would you do me a BIG favour, and do a review of the new slimmed down > 369 (MIX-CORE). I've worked to get this to a simpler and cleaner base. > I would be very interested to hear which aspects of this you still > believe to be too complex. Let me start out by saying that MIX-CORE is now significantly easier to consume in isolation, and I really appreciate the work you've put into that. However, I don't think it's actually possible to read MIX-CORE in isolation. Eg. I get to 7.1.1 and read " The full specification of client interaction with the client's server is specified in MIX-PAM" so now I guess I have to go read MIX-PAM. Or I reach example 23 and read "the MIX service is responsible for unsubscribing the user from all nodes in the channel and for removing the user from the participants list. Presence removal is specified in MIX-PRESENCE" so I have to go read MIX-PRESENCE to understand what it's talking about and whether I need to be concerned with it. Hiding some of the complexity in other documents doesn't make it go away, even if they're "optional" in theory. And MIX-CORE at least looks complex straight from the get go. After I've cleared the initial requirements and intro sections the first thing I'm presented with is a giant table of documents that I'm told I might have to implement. This might just be a minor editorial problem that can easily be fixed, but it says "Only two of these XEPs are mandatory for providing a MIX service" and then presents a table that includes a lot more than two things marked as mandatory and a lot of section headers that aren't "MIX Service", so I'm not actually sure what it's talking about. My initial thought when seeing this is that I'll never make it through all those and that I don't know what any of the column titles even mean (eg. what is an "Administrative MIX Client"?). That being said, I do appreciate having some sort of list so that I know hat I have to look at and don't have to go dig through the bigger XEPs list to try and find them. > 4.6 Proxy JIDs All of this. At the summit where we started to write the current implementation of MIX proxy JIDs were only added to support anonymous rooms. They were later made mandatory for everything, and while I agree that this simplifies things over using them sometimes and not others, I still think the underlying assumption that they are necessary as part of the MIX protocol is wrong. Having proxy JIDs is complicated enough, but on top of that we also have a new specialized JID format to deal with that encodes information in the local part. > 5. Error Handling This section is another list of documents that must be read and supported. I'm all for building MIX out of existing building blocks, but his is becoming a long list of dependencies that are spread over multiple sections and which I have to tease out of the document (and I haven't even started looking at the 6 other MIX documents). In a more general sense, XMPP has a problem of trying to support everyones specific features while also remaining general purpose and future-compatible. The XMPP community doesn't seem to know if it's building a specific chat service meant to be run by many operators, a general protocol on top of which others may build distinct chat services that interop, or some mix of both. This means we start adding tons of specific features right out of the box. However, good software engineering and design should work the exact opposite way. We can always add features later. Good design is removing as much as possible without breaking things (I feel like I heard someone say that, but the only reference I could find was something vaguely similar in a recent blog post by Russ Cox, so apologies to whomever said it if it was a quote and I'm not citing you). —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Requirements for "Jid Hidden" Channels
Sam, > I've mostly been avoiding the MIX discussion because in its current form I > belive > that it is too complex to ever gain wide adoption and as far as I can tell > this is the > root cause of that. [Steve Kille] Would you do me a BIG favour, and do a review of the new slimmed down 369 (MIX-CORE). I've worked to get this to a simpler and cleaner base. I would be very interested to hear which aspects of this you still believe to be too complex. > For the level of complexity they introduce I don't think JID hidden channels > are > worth it. [Steve Kille] JID Hidden is now optional and in MIX-ANON, so that those who do not want them do not need to write any code. I have been convinced that there is a need for JID Hidden, but the stack of implicit requirements makes it a lot more complex than it need be. In the message you replied to, I've set out what I think should be the requirements. I think that a simple MIX-ANON will be helpful. I think that trying to relay IQs through the channel (which some seem to want) is OTT and making MIX-ANON complex not be helpful to adopting MIX or MIX-ANON. I'm hoping that we can have a sensible review of MIX-ANON / JID Hidden requirements, between those that think JID Hidden is important. Steve ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Requirements for "Jid Hidden" Channels
On 2 June 2018 at 22:08, Daniel Gultsch wrote: > 2018-06-02 19:17 GMT+02:00 Sam Whited : >> On Sat, Jun 2, 2018, at 11:36, Steve Kille wrote: >>> It was agreed clearly that we need JID Hidden, primarily to prevent JID >>> Harvesting. This is going to be useful for public and semi-public >>> channels. >> >> I've mostly been avoiding the MIX discussion because in its current form I >> belive that it is too complex to ever gain wide adoption and as far as I can >> tell this is the root cause of that. >> For the level of complexity they introduce I don't think JID hidden channels >> are worth it. >> We can always explore other mechanisms later, and maybe come up with a more >> general anonymity protocol that works for direct communication and group >> chats (eg. by making burner JIDs or some alternative work for the MIX use >> case) and doesn't require making MIX unnecessarily complicated. > > sorry I’m very busy these days and haven’t followed the wider MIX > discussion a lot but I mostly agree with Sam here > > in that > > a) public, anonymous rooms should not be a priority for MIX > b) if hiding JIDs adds a lot of complexity to MIX it should be avoided > c) anonymity / proxy jids can be added as an afterthought and might > actually be useful outside MIX as well and thus should probably be in > a separate XEP (I had be contemplating the idea of a dezentralized > push alternative that would benefit from proxy jids as well because > you don’t want to leak your real jid to the app server) > d) MUC wont go away any time soon. So people who want to keep their > anonymity and their complicated IRC-like access model will still be > able to use MUC. So in theory you could keep MUC around for the public > groups chats and have MIX be optimized for the WhatsApp like groups I have to say I agree with all the points Daniel makes. In my mind MIX does not need to solve all the use cases that MUC currently handles well. I think we're all in agreement that this is a complex problem we're trying to solve, and it's apparent that some of MUC's perceived weaknesses were probably actually hard to avoid in the first place. In tackling complex problems, I think limiting the scope works wonders. If we can do away with proxy JIDs, that would be a big win for making a simpler modern replacement for MUC. By the way, I really appreciate the effort that went into splitting MIX recently. I think that has helped to divide up the issues at hand and enable the discussions over the past few days. Regards, Matthew ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Requirements for "Jid Hidden" Channels
Hi, 2018-06-02 19:17 GMT+02:00 Sam Whited : > On Sat, Jun 2, 2018, at 11:36, Steve Kille wrote: >> It was agreed clearly that we need JID Hidden, primarily to prevent JID >> Harvesting. This is going to be useful for public and semi-public >> channels. > > I've mostly been avoiding the MIX discussion because in its current form I > belive that it is too complex to ever gain wide adoption and as far as I can > tell this is the root cause of that. > For the level of complexity they introduce I don't think JID hidden channels > are worth it. > We can always explore other mechanisms later, and maybe come up with a more > general anonymity protocol that works for direct communication and group > chats (eg. by making burner JIDs or some alternative work for the MIX use > case) and doesn't require making MIX unnecessarily complicated. sorry I’m very busy these days and haven’t followed the wider MIX discussion a lot but I mostly agree with Sam here in that a) public, anonymous rooms should not be a priority for MIX b) if hiding JIDs adds a lot of complexity to MIX it should be avoided c) anonymity / proxy jids can be added as an afterthought and might actually be useful outside MIX as well and thus should probably be in a separate XEP (I had be contemplating the idea of a dezentralized push alternative that would benefit from proxy jids as well because you don’t want to leak your real jid to the app server) d) MUC wont go away any time soon. So people who want to keep their anonymity and their complicated IRC-like access model will still be able to use MUC. So in theory you could keep MUC around for the public groups chats and have MIX be optimized for the WhatsApp like groups cheers Daniel ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Requirements for "Jid Hidden" Channels
On Sat, Jun 2, 2018, at 11:36, Steve Kille wrote: > It was agreed clearly that we need JID Hidden, primarily to prevent JID > Harvesting. This is going to be useful for public and semi-public > channels. I've mostly been avoiding the MIX discussion because in its current form I belive that it is too complex to ever gain wide adoption and as far as I can tell this is the root cause of that. For the level of complexity they introduce I don't think JID hidden channels are worth it. We can always explore other mechanisms later, and maybe come up with a more general anonymity protocol that works for direct communication and group chats (eg. by making burner JIDs or some alternative work for the MIX use case) and doesn't require making MIX unnecessarily complicated. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Requirements for "Jid Hidden" Channels
It is clear that much of the complexity around JID encoding that is being postulated as necessary, ties back to requirements to support participant communication through JID Hidden channels. This note is to step back from the JID discussion, and consider JID Hidden channel requirements. I'm writing out a list of requirements here, which I think when agreed, could be usefully used as part of the introductory material to MIX-ANON. With JID Visible channels, real JIDs are shared and participants can use this to communicate directly. When looking at MIX requirements, quite a few argued that we should not have JID Hidden. A lot of other chat systems (e.g., Facebook) do not have an equivalent of JID Hidden. I think that many channels will be JID Visible. It was agreed clearly that we need JID Hidden, primarily to prevent JID Harvesting. This is going to be useful for public and semi-public channels. REQUIREMENTS: 1. Participants can see which other participants have one or more online clients. 2. Online participants can be displayed with a Nick. 3. Participants MUST be able to see if another participant changes Nick. 4.Participants can sent messages to other participants through the channel if channel policy allows this. 5.A participant can share real JID with another participant and request real JID. Can't do this currently, but it seems sensible to allow a pair of willing participants to shift from restricted communication through the channel to direct communication. POSSIBLE REQUIREMENTS: 6. Participants can share presence status additional to online/offline. I am wondering if, in an environment where JIDs are being hidden, if it makes sense to share other presence stuff with the channel. My sense is that for a public MUC, it might make sense to restrict. I would vote to make this a non-requirement. 7. Where a participant has multiple clients, other participants can see independent status of these clients. I think that this is not appropriate for JID Hidden channels. If you are not sharing your JID, it feels wrong to be sharing how many clients you have. NON REQUIREMENTS 8. vCard. If you are hiding your JID, it seems wrong to allow retrieval of generic information about you. I think that getting vCard information about other participants should be explicitly excluded. 9. Client Disco. I think that allowing clients to use IQ disco of JID Hidden participants is wrong. If you feel that JID should be hidden, it does not make sense to I appreciate that this has switched topics. I think that getting some agreements here, would help to sort the JID discussion. Can we keep this thread on "JID Hidden" and see if we can agree requirements? Steve ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
