Re: [Standards] Burner JIDs and MIX [WAS A possible MIX approach: hiding multiple clients]

[Sam Whited]

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]

[Kevin Smith]

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]

[Sam Whited]

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]

[Kevin Smith]

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]

[Sam Whited]

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 Whited]

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] Burner JIDs and MIX [WAS A possible MIX approach: hiding multiple clients]

[Sam Whited]

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
___