Knowing my subscribers

[Ancor Gonzalez Sosa]

I'm trying to implement this warning in Jangouts
https://github.com/jangouts/jangouts/issues/158

The basic idea is - you can't prevent people to join a room as listener without publishing content, but everybody in the room should be aware of that presence.

Right now, Janus notifies the participants when a new publisher joins so the participants can subscribe. But it does not notify publishers about them being listened by others. In short, there is no way to know who is subscribed to me. That makes very hard to detect "lurkers".

Of course, we could call listparticipants once in a while and check for participants with "published: False" but that looks more like a workaround to me. I think the list of my subscribers should be offered with a similar mechanism than the list of publishers, rather than requiring everybody to poll the room status every X seconds.

Am I overlooking something?

[Lorenzo Miniero]

There are a couple of ways you can do that:

1. use something like the auth tokens: users need to go through something of yours first, which results in a token being added to the Admin API that they can then use to talk to Janus; https://janus.conf.meetecho.com/docs/auth
2. use the recently added ACL support in the VideoRoom (and a couple others) plugin: again, users need to go through something of yours first, which results in an identifier being added to the room's ACL, and this identifier needs to be presented by users who want to join/subscribe: https://github.com/meetecho/janus-gateway/pull/745

Hope this helps,

Lorenzo

[Ancor Gonzalez Sosa]

El martes, 21 de febrero de 2017, 11:07:17 (UTC+1), Lorenzo Miniero escribió:

There are a couple of ways you can do that:

1. use something like the auth tokens: users need to go through something of yours first, which results in a token being added to the Admin API that they can then use to talk to Janus; https://janus.conf.meetecho.com/docs/auth
2. use the recently added ACL support in the VideoRoom (and a couple others) plugin: again, users need to go through something of yours first, which results in an identifier being added to the room's ACL, and this identifier needs to be presented by users who want to join/subscribe: https://github.com/meetecho/janus-gateway/pull/745

A little bit overkill, IMHO. One of the things I like about Jangouts is that, server-side, it only depends on Janus. Adding another component to the infrastructure or going for a full-featured authentication system is not exactly what I wanted.

I have identified 8 places in the videoroom plugin where the list of subscribers of a participant is altered. I will try to create a PR that sends a message to the publisher in all those 8 cases. Any reason you foresee for it to not work?
 

[Lorenzo Miniero]

Il giorno martedì 21 febbraio 2017 11:38:18 UTC+1, Ancor Gonzalez Sosa ha scritto:

El martes, 21 de febrero de 2017, 11:07:17 (UTC+1), Lorenzo Miniero escribió:

There are a couple of ways you can do that:

1. use something like the auth tokens: users need to go through something of yours first, which results in a token being added to the Admin API that they can then use to talk to Janus; https://janus.conf.meetecho.com/docs/auth
2. use the recently added ACL support in the VideoRoom (and a couple others) plugin: again, users need to go through something of yours first, which results in an identifier being added to the room's ACL, and this identifier needs to be presented by users who want to join/subscribe: https://github.com/meetecho/janus-gateway/pull/745

A little bit overkill, IMHO. One of the things I like about Jangouts is that, server-side, it only depends on Janus. Adding another component to the infrastructure or going for a full-featured authentication system is not exactly what I wanted.

I don't see this as overkill, especially considering it can be done without infrastructure I believe. I don't see how notifying the participant about anyone that subscribes to him is going to help either (if not to potentially add a lot more verbosity to the events, especially if publishers have a lot of viewers), as subscribers can be created without any context at all and so you wouldn't identify lurkers anyway. Any of the two mechanisms above would prevent that, as the former would prevent the creation of the handle, and the latter the ability to publish/subscribe: any other approach would only attempt to fix things after they already happened.

 

I have identified 8 places in the videoroom plugin where the list of subscribers of a participant is altered. I will try to create a PR that sends a message to the publisher in all those 8 cases. Any reason you foresee for it to not work?
 

As explained above, I don't like the idea of spamming the publisher with info on any new viewer that joins. We have scenarios with hundreds of viewers and this would be useless traffic, besides the fact that, since subscribers potentially don't have any context, this cannot be used to avoid lurkering. The private_id property allows for some context, but that's meant to stay private between user and server, and making it available to other participants is a bad idea.

Lorenzo

[Ancor Gonzalez Sosa]

Sorry, Gmail fooled me and I sent this only to Lorenzo. Re-replying to the list.

El martes, 21 de febrero de 2017, 11:48:44 (UTC+1), Lorenzo Miniero escribió:

Il giorno martedì 21 febbraio 2017 11:38:18 UTC+1, Ancor Gonzalez Sosa ha scritto:

El martes, 21 de febrero de 2017, 11:07:17 (UTC+1), Lorenzo Miniero escribió:

There are a couple of ways you can do that:

1. use something like the auth tokens: users need to go through something of yours first, which results in a token being added to the Admin API that they can then use to talk to Janus; https://janus.conf.meetecho.com/docs/auth
2. use the recently added ACL support in the VideoRoom (and a couple others) plugin: again, users need to go through something of yours first, which results in an identifier being added to the room's ACL, and this identifier needs to be presented by users who want to join/subscribe: https://github.com/meetecho/janus-gateway/pull/745

A little bit overkill, IMHO. One of the things I like about Jangouts is that, server-side, it only depends on Janus. Adding another component to the infrastructure or going for a full-featured authentication system is not exactly what I wanted.

I don't see this as overkill, especially considering it can be done without infrastructure I believe.

Then I misunderstood something. As I see both 1 and 2, I need something to keep the list of "authorized" participants in a room and to generate one token for each participant (and delete the token when the user exits the room). That "something" would not be Janus itself and it would not be javascript code running in the client (browser), so I need some infrastructure. Something running anywhere so the javascript client can:

 - ask for a token so it can join

 - delete a token on exit

 - ask, at least, how many tokens are active, so I can verify the status is correct.

Isn't it? Or maybe I'm just misunderstanding how you suggest to use those features.

Take into account I don't want to implement real authentication (which is a quite complex topic and would open a can of worms). I just want to make sure the users have a clear view of the situation of the room (i.e. the real number of publishers/subscribers).

At most (not really a requisite), I would enforce symmetric use (you cannot subscribe unless you publish). But that is already one step too far... which means authentication is two steps too far :-)

 

I don't see how notifying the participant about anyone that subscribes to him is going to help either (if not to potentially add a lot more verbosity to the events, especially if publishers have a lot of viewers), as subscribers can be created without any context at all and so you wouldn't identify lurkers anyway.

But you will know they are there, which is my only goal so far.
 

Any of the two mechanisms above would prevent that, as the former would prevent the creation of the handle, and the latter the ability to publish/subscribe: any other approach would only attempt to fix things after they already happened.

I know, I wanted to alert the users about the situation, not necessarily prevent it from happening. At least, not at the cost of having to design a secure mechanism for (pseudo)authentication.
 

 

I have identified 8 places in the videoroom plugin where the list of subscribers of a participant is altered. I will try to create a PR that sends a message to the publisher in all those 8 cases. Any reason you foresee for it to not work?
 

As explained above, I don't like the idea of spamming the publisher with info on any new viewer that joins. We have scenarios with hundreds of viewers and this would be useless traffic, besides the fact that, since subscribers potentially don't have any context, this cannot be used to avoid lurkering. The private_id property allows for some context, but that's meant to stay private between user and server, and making it available to other participants is a bad idea.

I see. Just a question about this. Would those "lurkers" who have provided minimal context be displayed by the listparticipants command?

Cheers.

 

[Lorenzo Miniero]

Il giorno martedì 21 febbraio 2017 12:49:29 UTC+1, Ancor Gonzalez Sosa ha scritto:

Sorry, Gmail fooled me and I sent this only to Lorenzo. Re-replying to the list.

No problem, happens all the time to me as well...

 

El martes, 21 de febrero de 2017, 11:48:44 (UTC+1), Lorenzo Miniero escribió:

Il giorno martedì 21 febbraio 2017 11:38:18 UTC+1, Ancor Gonzalez Sosa ha scritto:

El martes, 21 de febrero de 2017, 11:07:17 (UTC+1), Lorenzo Miniero escribió:

There are a couple of ways you can do that:

1. use something like the auth tokens: users need to go through something of yours first, which results in a token being added to the Admin API that they can then use to talk to Janus; https://janus.conf.meetecho.com/docs/auth
2. use the recently added ACL support in the VideoRoom (and a couple others) plugin: again, users need to go through something of yours first, which results in an identifier being added to the room's ACL, and this identifier needs to be presented by users who want to join/subscribe: https://github.com/meetecho/janus-gateway/pull/745

A little bit overkill, IMHO. One of the things I like about Jangouts is that, server-side, it only depends on Janus. Adding another component to the infrastructure or going for a full-featured authentication system is not exactly what I wanted.

I don't see this as overkill, especially considering it can be done without infrastructure I believe.

Then I misunderstood something. As I see both 1 and 2, I need something to keep the list of "authorized" participants in a room and to generate one token for each participant (and delete the token when the user exits the room). That "something" would not be Janus itself and it would not be javascript code running in the client (browser), so I need some infrastructure. Something running anywhere so the javascript client can:

 - ask for a token so it can join

 - delete a token on exit

 - ask, at least, how many tokens are active, so I can verify the status is correct.

Isn't it? Or maybe I'm just misunderstanding how you suggest to use those features.

Take into account I don't want to implement real authentication (which is a quite complex topic and would open a can of worms). I just want to make sure the users have a clear view of the situation of the room (i.e. the real number of publishers/subscribers).

At most (not really a requisite), I would enforce symmetric use (you cannot subscribe unless you publish). But that is already one step too far... which means authentication is two steps too far :-)

With those two mechanisms you don't necessarily have to implement a complete authentication system. Tokens don't need to be per-user, they can also be shared, possibly even a single token for everybody, it's entirely up to you how this is done.

Considering approach #2 involves VideoRoom communication that you're already doing, one way to implement that could be as part of the room creation. One of your users creates the room, and so has the room secret (I'm assuming you use secrets here, and don't allow everybody to mess with rooms). After that, he creates an ACL with a single token in it, that can act as the room PIN if you'd like. At this point, all join requests (both publisher and subscriber) need to present that token, or they're rejected. How to distribute this token can then be decided by you: whatever is used for how to join a room can be used for this too.

Of course this is an over simplification and probably doesn't really solve the problem, but is an example of how you can at least put a gate that people need a key for (even though the key protection may be kind of lame).

 

 

I don't see how notifying the participant about anyone that subscribes to him is going to help either (if not to potentially add a lot more verbosity to the events, especially if publishers have a lot of viewers), as subscribers can be created without any context at all and so you wouldn't identify lurkers anyway.

But you will know they are there, which is my only goal so far.

My point is that, even with those events, you can not differentiate between lurkers and legitimate users: subscribe requests don't have any way of saying "this is Joe subscribing to Bob", all subscriptions are out of context. The only way you can do that correlation is using info on the server side, which is why I added stuff like handle opaque IDs and the private_id to the videoroom for the Event Handlers for instance (see http://www.meetecho.com/blog/correlating-janus-event-handlers/ for a clearer picture). Anything else (e.g, adding your public publisher ID as a parameter when subscribing) would not work and could be easily abused/spoofed.

The only way I see this working without that, is adding a mode to the VideoRoom where you use the private_id as the "gatekeeper": you send a subscribe, and use the private_id (which normally cannot be spoofed, as it's known only to you from when you joined as ptype=publisher) to identify yourself. In the VideoRoom code, you add an optional property that prevents subscriptions if that private_id is not associated to a participant that is also actively publishing media, or possibly simply notifies the publisher about a subscription coming from somebody who's not publishing himself. I see this as somehow fragile and prone to errors/race conditions (what if I subscribe shortly before I start publishing, because I joined when other people where already active? do I need to keep track of all available feeds and wait to subscribe until I've published myself, thus slowing down the setup?), but is a possible implementation.

 

 

Any of the two mechanisms above would prevent that, as the former would prevent the creation of the handle, and the latter the ability to publish/subscribe: any other approach would only attempt to fix things after they already happened.

I know, I wanted to alert the users about the situation, not necessarily prevent it from happening. At least, not at the cost of having to design a secure mechanism for (pseudo)authentication.
 

Got it.

 

 

I have identified 8 places in the videoroom plugin where the list of subscribers of a participant is altered. I will try to create a PR that sends a message to the publisher in all those 8 cases. Any reason you foresee for it to not work?
 

As explained above, I don't like the idea of spamming the publisher with info on any new viewer that joins. We have scenarios with hundreds of viewers and this would be useless traffic, besides the fact that, since subscribers potentially don't have any context, this cannot be used to avoid lurkering. The private_id property allows for some context, but that's meant to stay private between user and server, and making it available to other participants is a bad idea.

I see. Just a question about this. Would those "lurkers" who have provided minimal context be displayed by the listparticipants command?

listparticipants only lists the publishers who are "publishing" (that is, the users with ptype=publisher who have also created a PeerConnection). Non-publishing participants are not listed, and neither are subscribers as they don't "count" as participants.

Lorenzo

[Ancor Gonzalez Sosa]

El martes, 21 de febrero de 2017, 13:01:52 (UTC+1), Lorenzo Miniero escribió:

[...]

Just a note to anyone finding this old thread - everything we discussed here is already implemented in Janus Gateway since April 2019. You can configure your room with both "notify_joining" and "require_pvtid" and you will get basically what I asked originally. That is, you will get the full list of everyone who has joined (no matter whether they are publishing or not) and nobody will be able to subscribe to your feeds unless he/she has joined in advance.

Cheers.