Re: [Standards] Burner JIDs and MIX [WAS A possible MIX approach: hiding multiple clients]
On Tue, Jan 10, 2017 at 9:23 AM, Kevin Smith wrote: > Except if it's the MIX issuing burners, isn't 'the server' in this case the > MIX server? Which you very possibly can't route to from your client because > it crosses an organisational boundary, and only S2S can get across? Could be either; I've been saying the MIX service, but I suppose you're right, it would have to be the server and the MIX service would be configured to check that JIDs were issued by the service. This does require some shared datastore or public key between them. Either way, I don't think this adds substantial overhead. > Except you need it tracked in your 'real' account, so clients know > connection details for all your burner JIDs, and you need to be jumping > through hoops as a client to do so each login. Yes; I'm unsure how much work this would be for current clients. I suspected that it would be relatively easy, but TBH I'm not sure. > Well, you have to have the clients check too, because otherwise they'll try > to join a room with their real JID and not be allowed because the room's > semi-anonymous. Fair. > Sure, I think MIX's use of proxy JIDs here is exactly doing this better than > MUC did :) > My original proposal to simplify things was to not have semi-anonymous > rooms, but people rapidly let me know that I was being an idiot and we need > this functionality ;) Same here; I didn't want this complexity when we first conceived MIX in Washington, and still think that either way just makes things too complicated (but as you said, I was rapidly overruled). Steve just started a new thread about this; maybe we should take discussion about other alternatives there. —Sam -- Sam Whited pub 4096R/54083AE104EA7AD3 ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Burner JIDs and MIX [WAS A possible MIX approach: hiding multiple clients]
On 10/01/2017 15:16, Sam Whited wrote: On Tue, Jan 10, 2017 at 9:01 AM, Kevin Smith wrote: I think you'd need to build so much extra stuff on top of burner JIDs … that you end up with vastly more complexity than proxy JIDs give you. I'm not so sure; you get a burner JID, you make a new connection to the server with it Except if it's the MIX issuing burners, isn't 'the server' in this case the MIX server? Which you very possibly can't route to from your client because it crosses an organisational boundary, and only S2S can get across? , you use it as if it were a normal JID and everything interacts with it exactly the same as it would have done with a normal JID. Except you need it tracked in your 'real' account, so clients know connection details for all your burner JIDs, and you need to be jumping through hoops as a client to do so each login. The only real thing you have to implement is the rules that check if a JID is allowed or not on the server if you *only* want to allow burner JIDs, but that's a special case anyways (since you might as well leave it up to users whether or not to expose their real JIDs at this point). Well, you have to have the clients check too, because otherwise they'll try to join a room with their real JID and not be allowed because the room's semi-anonymous. That being said, I could also see this being true; there's a lot of room for complexity here. I'd like to experiment with some implementations and find out. I think there might be a certain amount of optimism involved here in how much is needed to replace proxy JIDs with burners. By all means try to write up how burners would work :) Proxy JIDs are very similar in complexity to how MUC currently works, where you use a room-assigned (although client-requested) anonymising JID. I don't think anyone has problems with dealing with these concepts for MUC, and I don't think they will for MIX. I feel like this is one of the concepts that bothers me most about MUC (and causes many of my implementation headaches), probably second only to presence being tied to membership. I agree that they're similar levels of complexity, but I still think we can do better than MUC did in this regard, even if burner JIDs aren't that way. Sure, I think MIX's use of proxy JIDs here is exactly doing this better than MUC did :) My original proposal to simplify things was to not have semi-anonymous rooms, but people rapidly let me know that I was being an idiot and we need this functionality ;) /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Burner JIDs and MIX [WAS A possible MIX approach: hiding multiple clients]
On Tue, Jan 10, 2017 at 9:01 AM, Kevin Smith wrote: > I think you'd need to build so much extra stuff on top of burner JIDs … that > you end up with vastly more complexity than > proxy JIDs give you. I'm not so sure; you get a burner JID, you make a new connection to the server with it, you use it as if it were a normal JID and everything interacts with it exactly the same as it would have done with a normal JID. The only real thing you have to implement is the rules that check if a JID is allowed or not on the server if you *only* want to allow burner JIDs, but that's a special case anyways (since you might as well leave it up to users whether or not to expose their real JIDs at this point). That being said, I could also see this being true; there's a lot of room for complexity here. I'd like to experiment with some implementations and find out. > Proxy JIDs are very similar in complexity to how MUC currently works, where > you use a room-assigned (although client-requested) anonymising JID. I don't > think anyone has problems with dealing with these concepts for MUC, and I > don't think they will for MIX. I feel like this is one of the concepts that bothers me most about MUC (and causes many of my implementation headaches), probably second only to presence being tied to membership. I agree that they're similar levels of complexity, but I still think we can do better than MUC did in this regard, even if burner JIDs aren't that way. —Sam -- Sam Whited pub 4096R/54083AE104EA7AD3 ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Burner JIDs and MIX [WAS A possible MIX approach: hiding multiple clients]
On 06/01/2017 16:15, Sam Whited wrote: On Fri, Jan 6, 2017 at 10:10 AM, Steve Kille wrote: I don't object to this, but I can't see how it makes much difference to MIX. What impact is there besides following the rules for generating random JIDs? Using this removes the need for semi-anonymous channels and proxy JIDs, which will simplify the MIX spec a lot. It shifts the decision about whether or not a user is anonymous from the MIX service to the user since they can decide whether or not to use a burner JID before joining any channels (although the MIX service would still be able to enforce that a room be anonymous by only allowing in JIDs issued by its own burner JID service). I think you'd need to build so much extra stuff on top of burner JIDs (e.g., exposing real JIDs to admins, configuration so only your own burners can be admitted, users' clients checking if a room needs them to register a burner, and then registering it, and then joining the channel, working out how this all interacts with PAM, working out how this interacts with MAM, ensuring activation of burner JIDs 'just works' on login without additional steps, defining ways to bind burners into the same stream as all other traffic, to name just a few of of them) that you end up with vastly more complexity than proxy JIDs give you. Proxy JIDs are very similar in complexity to how MUC currently works, where you use a room-assigned (although client-requested) anonymising JID. I don't think anyone has problems with dealing with these concepts for MUC, and I don't think they will for MIX. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Burner JIDs and MIX [WAS A possible MIX approach: hiding multiple clients]
On Fri, Jan 6, 2017 at 10:42 AM, Steve Kille wrote: > Yes - your "publish the users real JID to a JID mapping node" is I think the > proxy JID model. I think this is the best way to achieve semi-anonymous > type channels. Right, it could if this is necessary but I don't think it actually is; the MIX service can enforce these things, the admins don't need to know the users JID. > Use of burner JIDs gives an approach for fully anonymous. I note that the > summit last year agreed that there was no requirement for fully anonymous. I think that when we first started on MIX in Washington this was because it added a lot of complexity and no one was using it for MUC anyways; but in this case it doesn't add any complexity over doing semi-anonymous (in fact, semi-anonymous is ever so slightly more complex in this case). —Sam -- Sam Whited pub 4096R/54083AE104EA7AD3 ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Burner JIDs and MIX [WAS A possible MIX approach: hiding multiple clients]
Sam, Yes - your "publish the users real JID to a JID mapping node" is I think the proxy JID model. I think this is the best way to achieve semi-anonymous type channels. Use of burner JIDs gives an approach for fully anonymous. I note that the summit last year agreed that there was no requirement for fully anonymous. Steve > -Original Message- > From: Standards [mailto:standards-boun...@xmpp.org] On Behalf Of Sam > Whited > Sent: 06 January 2017 16:35 > To: XMPP Standards > Subject: Re: [Standards] Burner JIDs and MIX [WAS A possible MIX approach: > hiding multiple clients] > > On Fri, Jan 6, 2017 at 10:24 AM, Steve Kille wrote: > > A key problem with this is the JIDs then become anonymous to the channel > management. > > > > Having a situation where channel participants do not know who is in a > channel is fine.I think that in many situations, it will be beneficial for > administration to know real JIDs. Would you really want to have the XSF > Room/Channel full of burner JIDs? Consider if I try to join the > channel > with a burner JID and nick of "Sam Whited". > > If the MIX service is issuing burner JIDs then it could refuse to issue new > burner JIDs to a user if one of that users burner JIDs has been banned (or > simply refuse to allow future burner JIDs issued to that user into that > specific > room if they weren't banned from the whole service), so in a way this could > provide "fully anonymous" rooms where even channel administration does > not know the persons real JID (only the MIX service and its administrators > do), but can still ban that JID. > > If the original JID should actually be known by channel administrators (the > semi-anonymous model), the MIX service could publish the users real JID to > a JID mapping node that can only be accessed by channel admins. > > —Sam > > > > -- > Sam Whited > pub 4096R/54083AE104EA7AD3 > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Burner JIDs and MIX [WAS A possible MIX approach: hiding multiple clients]
On Fri, Jan 6, 2017 at 10:24 AM, Steve Kille wrote: > A key problem with this is the JIDs then become anonymous to the channel > management. > > Having a situation where channel participants do not know who is in a channel > is fine.I think that in many situations, it will be beneficial for > administration to know real JIDs. Would you really want to have the XSF > Room/Channel full of burner JIDs? Consider if I try to join the > channel with a burner JID and nick of "Sam Whited". If the MIX service is issuing burner JIDs then it could refuse to issue new burner JIDs to a user if one of that users burner JIDs has been banned (or simply refuse to allow future burner JIDs issued to that user into that specific room if they weren't banned from the whole service), so in a way this could provide "fully anonymous" rooms where even channel administration does not know the persons real JID (only the MIX service and its administrators do), but can still ban that JID. If the original JID should actually be known by channel administrators (the semi-anonymous model), the MIX service could publish the users real JID to a JID mapping node that can only be accessed by channel admins. —Sam -- Sam Whited pub 4096R/54083AE104EA7AD3 ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Burner JIDs and MIX [WAS A possible MIX approach: hiding multiple clients]
Sam, A key problem with this is the JIDs then become anonymous to the channel management. Having a situation where channel participants do not know who is in a channel is fine.I think that in many situations, it will be beneficial for administration to know real JIDs. Would you really want to have the XSF Room/Channel full of burner JIDs? Consider if I try to join the channel with a burner JID and nick of "Sam Whited". Clearly one cannot prevent someone from joining a channel using a burner JID. However, it feels wrong to me to force users to do this as the only "JID hidden" mechanism. Steve > -Original Message- > From: Standards [mailto:standards-boun...@xmpp.org] On Behalf Of Sam > Whited > Sent: 06 January 2017 16:16 > To: XMPP Standards > Subject: Re: [Standards] Burner JIDs and MIX [WAS A possible MIX approach: > hiding multiple clients] > > On Fri, Jan 6, 2017 at 10:10 AM, Steve Kille wrote: > > I don't object to this, but I can't see how it makes much difference to MIX. > What impact is there besides following the rules for generating random JIDs? > > Using this removes the need for semi-anonymous channels and proxy JIDs, > which will simplify the MIX spec a lot. It shifts the decision about whether > or > not a user is anonymous from the MIX service to the user since they can > decide whether or not to use a burner JID before joining any channels > (although the MIX service would still be able to enforce that a room be > anonymous by only allowing in JIDs issued by its own burner JID service). > > —Sam > > -- > Sam Whited > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Burner JIDs and MIX [WAS A possible MIX approach: hiding multiple clients]
On Fri, Jan 6, 2017 at 10:10 AM, Steve Kille wrote: > I don't object to this, but I can't see how it makes much difference to MIX. > What impact is there besides following the rules for generating random JIDs? Using this removes the need for semi-anonymous channels and proxy JIDs, which will simplify the MIX spec a lot. It shifts the decision about whether or not a user is anonymous from the MIX service to the user since they can decide whether or not to use a burner JID before joining any channels (although the MIX service would still be able to enforce that a room be anonymous by only allowing in JIDs issued by its own burner JID service). —Sam -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Burner JIDs and MIX [WAS A possible MIX approach: hiding multiple clients]
Sam, I don't object to this, but I can't see how it makes much difference to MIX. What impact is there besides following the rules for generating random JIDs? Steve > -Original Message- > From: Standards [mailto:standards-boun...@xmpp.org] On Behalf Of Sam > Whited > Sent: 06 January 2017 16:06 > To: XMPP Standards > Subject: [Standards] Burner JIDs and MIX [WAS A possible MIX approach: > hiding multiple clients] > > On Fri, Jan 6, 2017 at 1:50 AM, Steve Kille wrote: > > The radical change is to make MIX presence "per user" (at least for > > JID Hidden channels). > > I would like to propose an alternative based on XEP-0383: Burner JIDs [1]. > > If the MIX service itself were to provide burner JIDs a few simple rules could > be enforced by the MIX service to make them work. Burner JIDs alocated by > the MIX service: > > 1. MUST have a 1:1 mapping with a real JID > 2. SHOULD NOT expire (although one might envision a situation where a > user starts getting spam to their burner JID so they want to copy over their > roster to a new one to rotate it; this sort of thing could also be described > in > the MIX spec if desirable, or maybe the user really does just want a different > proxy JID each time: either way, I suppose that's a matter of server policy > and/or user choice). > > This means that users are authenticated using their normal account, and are > authorized to use the MIX service by virtue of having been assigned a burner > JID. > > The only real downsides I see to this are that rooms will not show up in a > users normal roster (although this could be solved easily by clients in the > UI, > which may even be good because it would mean they don't show up in > clients that don't support MIX), and that it requires a separate connection to > the server for each burner JID in use (if you wanted a different one per > room, that could get expensive). I'm sure we could solve this by multiplexing > multiple sessions over one TCP connection though, and that's a problem that > can be addressed later if it ever becomes an issue. > > Thoughts? > > —Sam > > [1]: https://xmpp.org/extensions/xep-0383.html > > -- > Sam Whited > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Burner JIDs and MIX [WAS A possible MIX approach: hiding multiple clients]
On Fri, Jan 6, 2017 at 1:50 AM, Steve Kille wrote: > The radical change is to make MIX presence "per user" (at least for JID > Hidden channels). I would like to propose an alternative based on XEP-0383: Burner JIDs [1]. If the MIX service itself were to provide burner JIDs a few simple rules could be enforced by the MIX service to make them work. Burner JIDs alocated by the MIX service: 1. MUST have a 1:1 mapping with a real JID 2. SHOULD NOT expire (although one might envision a situation where a user starts getting spam to their burner JID so they want to copy over their roster to a new one to rotate it; this sort of thing could also be described in the MIX spec if desirable, or maybe the user really does just want a different proxy JID each time: either way, I suppose that's a matter of server policy and/or user choice). This means that users are authenticated using their normal account, and are authorized to use the MIX service by virtue of having been assigned a burner JID. The only real downsides I see to this are that rooms will not show up in a users normal roster (although this could be solved easily by clients in the UI, which may even be good because it would mean they don't show up in clients that don't support MIX), and that it requires a separate connection to the server for each burner JID in use (if you wanted a different one per room, that could get expensive). I'm sure we could solve this by multiplexing multiple sessions over one TCP connection though, and that's a problem that can be addressed later if it ever becomes an issue. Thoughts? —Sam [1]: https://xmpp.org/extensions/xep-0383.html -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___