[jitsi-dev] Privacy patches


#1

I’ve been playing around with Jitsi Meet recently and I really love it. It’s so much quicker and easier for people to join video conferences than with the native Jitsi desktop software (doesn’t require any accounts or special software, just works). I’m looking into running a Jitsi Meet server for some very privacy and security conscious video conferences (including Freedom of the Press Foundation board meetings with Edward Snowden attending), so that we can finally stop relying on Google Hangouts.

The readme says discuss feature requests on the this list before opening issues on GitHub. I would like to be able to configure my Jitsi Meet server to not make any 3rd party requests at all. Right now, when you load a Jitsi Meet website it makes requests to: api.callstats.io, www.gravatar.com, and www.google-analytics.com.

Even if you aren’t using CallStats, the javascript is still always loaded in index.html, meaning that this company will get a web request from each person who wants to make a video call on our server. And I know Gravatar is nice, but it would be great if there were an option to completely disable it, and use a generic image for everyone’s avatar. And it would also be great if we could disable Google Analytics — we don’t want Google to get notified each time we’re having a video call. (For that matter, it would be nice to be able to replace the GA id with your own, or add support Piwik, but that would be a totally different issue.)

Would you be willing to implement these minor privacy code changes, or accept a pull request with them?

Finally, it would be amazing if Jitsi Meet could offer verifiable end-to-end encryption with ZRTP. I know this is obviously a much bigger and longer-term task. Are you currently looking into it or working on it? It looks like others are working on a ZRTP/WebRTC spec: https://tools.ietf.org/html/draft-johnston-rtcweb-zrtp-00

···

--
Micah Lee
OpenPGP: 927F 419D 7EC8 2C2F 149C 1BD1 403C 2657 CD99 4F73


#2

Bump.

Would the Jitsi Meet project be open to a pull request that makes it
possible to not include any third party web resources, for privacy reasons?

···

On 10/26/2015 04:26 PM, Micah Lee wrote:

I’ve been playing around with Jitsi Meet recently and I really love it. It’s so much quicker and easier for people to join video conferences than with the native Jitsi desktop software (doesn’t require any accounts or special software, just works). I’m looking into running a Jitsi Meet server for some very privacy and security conscious video conferences (including Freedom of the Press Foundation board meetings with Edward Snowden attending), so that we can finally stop relying on Google Hangouts.

The readme says discuss feature requests on the this list before opening issues on GitHub. I would like to be able to configure my Jitsi Meet server to not make any 3rd party requests at all. Right now, when you load a Jitsi Meet website it makes requests to: api.callstats.io, www.gravatar.com, and www.google-analytics.com.

Even if you aren’t using CallStats, the javascript is still always loaded in index.html, meaning that this company will get a web request from each person who wants to make a video call on our server. And I know Gravatar is nice, but it would be great if there were an option to completely disable it, and use a generic image for everyone’s avatar. And it would also be great if we could disable Google Analytics — we don’t want Google to get notified each time we’re having a video call. (For that matter, it would be nice to be able to replace the GA id with your own, or add support Piwik, but that would be a totally different issue.)

Would you be willing to implement these minor privacy code changes, or accept a pull request with them?

Finally, it would be amazing if Jitsi Meet could offer verifiable end-to-end encryption with ZRTP. I know this is obviously a much bigger and longer-term task. Are you currently looking into it or working on it? It looks like others are working on a ZRTP/WebRTC spec: https://tools.ietf.org/html/draft-johnston-rtcweb-zrtp-00

--
Micah Lee
OpenPGP: 927F 419D 7EC8 2C2F 149C 1BD1 403C 2657 CD99 4F73


#3

Hi Micah,

Bump.

Would the Jitsi Meet project be open to a pull request that makes it
possible to not include any third party web resources, for privacy reasons?

I’ve been playing around with Jitsi Meet recently and I really love it. It’s so much quicker and easier for people to join video conferences than with the native Jitsi desktop software (doesn’t require any accounts or special software, just works). I’m looking into running a Jitsi Meet server for some very privacy and security conscious video conferences (including Freedom of the Press Foundation board meetings with Edward Snowden attending), so that we can finally stop relying on Google Hangouts.

The readme says discuss feature requests on the this list before opening issues on GitHub. I would like to be able to configure my Jitsi Meet server to not make any 3rd party requests at all. Right now, when you load a Jitsi Meet website it makes requests to: api.callstats.io, www.gravatar.com, and www.google-analytics.com.

Even if you aren’t using CallStats, the javascript is still always loaded in index.html, meaning that this company will get a web request from each person who wants to make a video call on our server. And I know Gravatar is nice, but it would be great if there were an option to completely disable it, and use a generic image for everyone’s avatar. And it would also be great if we could disable Google Analytics — we don’t want Google to get notified each time we’re having a video call. (For that matter, it would be nice to be able to replace the GA id with your own, or add support Piwik, but that would be a totally different issue.)

Would you be willing to implement these minor privacy code changes, or accept a pull request with them?

+1 does it even make sense to load them if they’re not properly properly?

Finally, it would be amazing if Jitsi Meet could offer verifiable end-to-end encryption with ZRTP. I know this is obviously a much bigger and longer-term task. Are you currently looking into it or working on it? It looks like others are working on a ZRTP/WebRTC spec: https://tools.ietf.org/html/draft-johnston-rtcweb-zrtp-00

If the webrtc.org <http://webrtc.org/> implementation adds support for it, I think we’d be more than happy to support ZRTP as well.

···

On Nov 9, 2015, at 12:22 AM, Micah Lee <micah@micahflee.com> wrote:
On 10/26/2015 04:26 PM, Micah Lee wrote:

-
George

--
Micah Lee
OpenPGP: 927F 419D 7EC8 2C2F 149C 1BD1 403C 2657 CD99 4F73

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#4

Hey Micah,

Bump.

Would the Jitsi Meet project be open to a pull request that makes it
possible to not include any third party web resources, for privacy
reasons?

Yes, this sounds like a good thing to have. More below.

I’ve been playing around with Jitsi Meet recently and I really love
it. It’s so much quicker and easier for people to join video
conferences than with the native Jitsi desktop software (doesn’t
require any accounts or special software, just works). I’m looking
into running a Jitsi Meet server for some very privacy and security
conscious video conferences (including Freedom of the Press
Foundation board meetings with Edward Snowden attending), so that
we can finally stop relying on Google Hangouts.

The readme says discuss feature requests on the this list before
opening issues on GitHub. I would like to be able to configure my
Jitsi Meet server to not make any 3rd party requests at all. Right
now, when you load a Jitsi Meet website it makes requests to:
api.callstats.io, www.gravatar.com, and www.google-analytics.com.

Even if you aren’t using CallStats, the javascript is still always
loaded in index.html, meaning that this company will get a web
request from each person who wants to make a video call on our
server. And I know Gravatar is nice, but it would be great if there
were an option to completely disable it, and use a generic image
for everyone’s avatar. And it would also be great if we could
disable Google Analytics — we don’t want Google to get notified
each time we’re having a video call. (For that matter, it would be
nice to be able to replace the GA id with your own,

What is preventing you from doing this now?

or add support

Piwik, but that would be a totally different issue.)

It is. But again: what's stopping you from just replacing the GA script with yours?

Would you be willing to implement these minor privacy code changes,
or accept a pull request with them?

Yup, as mentioned above.

Finally, it would be amazing if Jitsi Meet could offer verifiable
end-to-end encryption with ZRTP. I know this is obviously a much
bigger and longer-term task. Are you currently looking into it or
working on it? It looks like others are working on a ZRTP/WebRTC
spec: https://tools.ietf.org/html/draft-johnston-rtcweb-zrtp-00

Peter, Ingo and George already touched on that. While it is my favourite tool for e2e encryption in 1-to-1 calls, ZRTP doesn't really have much to offer on top of what you can already do with DTLS/SRTP in a bridged call. Alan's draft is meant for cases where you talk directly to peers.

We all hope PERC will come up with something nice, but

a) it will be a while before they do
b) once they are ready we'd still need for the browser implementations to catch up
c) I am sceptical that it would offer better guarantees than the option of running your own Jitsi Videobridge deployment + protecting it with DTLS/SRTP.

On c), I think PERC would focus more on solving a slightly different issue: if you connect for a conference on superconf.com and it uses cloud bridges from megabridge.com, then PERC would probably guarantee to superconf.com that megabridge.com are not able to access user data. I don't believe that PERC would remove the need for you to trust superconf.com.

I would be very happy to be proven wrong.

Cheers,
Emil

···

On 9.11.15 г. 0:22, Micah Lee wrote:

On 10/26/2015 04:26 PM, Micah Lee wrote:

--
https://jitsi.org


#5

+1

Boris

···

On 09/11/15 09:52, George Politis wrote:

Hi Micah,

On Nov 9, 2015, at 12:22 AM, Micah Lee <micah@micahflee.com >> <mailto:micah@micahflee.com>> wrote:

Bump.

Would the Jitsi Meet project be open to a pull request that makes it
possible to not include any third party web resources, for privacy
reasons?

On 10/26/2015 04:26 PM, Micah Lee wrote:

I’ve been playing around with Jitsi Meet recently and I really love
it. It’s so much quicker and easier for people to join video
conferences than with the native Jitsi desktop software (doesn’t
require any accounts or special software, just works). I’m looking
into running a Jitsi Meet server for some very privacy and security
conscious video conferences (including Freedom of the Press
Foundation board meetings with Edward Snowden attending), so that we
can finally stop relying on Google Hangouts.

The readme says discuss feature requests on the this list before
opening issues on GitHub. I would like to be able to configure my
Jitsi Meet server to not make any 3rd party requests at all. Right
now, when you load a Jitsi Meet website it makes requests to:
api.callstats.io <http://api.callstats.io>, www.gravatar.com
<http://www.gravatar.com>, and www.google-analytics.com
<http://www.google-analytics.com>.

Even if you aren’t using CallStats, the javascript is still always
loaded in index.html, meaning that this company will get a web
request from each person who wants to make a video call on our
server. And I know Gravatar is nice, but it would be great if there
were an option to completely disable it, and use a generic image for
everyone’s avatar. And it would also be great if we could disable
Google Analytics — we don’t want Google to get notified each time
we’re having a video call. (For that matter, it would be nice to be
able to replace the GA id with your own, or add support Piwik, but
that would be a totally different issue.)

Would you be willing to implement these minor privacy code changes,
or accept a pull request with them?

+1 does it even make sense to load them if they’re not properly properly?


#6

Finally, it would be amazing if Jitsi Meet could offer verifiable
end-to-end encryption with ZRTP. I know this is obviously a much bigger
and longer-term task. Are you currently looking into it or working on
it? It looks like others are working on a ZRTP/WebRTC spec:
https://tools.ietf.org/html/draft-johnston-rtcweb-zrtp-00

If the webrtc.org implementation adds support for it, I think we’d be more
than happy to support ZRTP as well.

The problem with ZRTP is: the Videobridge is basically a MitM. The original ZRTP protocol supports a mode called Trusted MitM, at the time intended for PBXs like Asterisk. So the Videobridge needs to become a trusted MitM. But this IMO makes ZRTP superfluous: if you trust the bridge, you can do directly trust/verify the DTLS-SRTP fingerprints. The whole WebRTC/ZRTP only makes sense for peer2peer connections.

Or am I missing something?

George

Ingo


#7

Sorry about the really long delay. FYI I just opened an issue about
this: https://github.com/jitsi/jitsi-meet/issues/422

Even if you aren’t using CallStats, the javascript is still always
loaded in index.html, meaning that this company will get a web
request from each person who wants to make a video call on our
server. And I know Gravatar is nice, but it would be great if there
were an option to completely disable it, and use a generic image
for everyone’s avatar. And it would also be great if we could
disable Google Analytics — we don’t want Google to get notified
each time we’re having a video call. (For that matter, it would be
nice to be able to replace the GA id with your own,

What is preventing you from doing this now?

I am doing this now, but the issue is that my server gets automatic
updates from Jitsi's debian repository, and my custom patches get
replaced with each update.

Also, removing the Gravatar requests is a lot tricker, since it involves
actually modifying some of the javascript and then re-minifying it
(since app.bundle.min.js is what gets loaded) as part of the patch process.

or add support

Piwik, but that would be a totally different issue.)

It is. But again: what's stopping you from just replacing the GA script
with yours?

Same, automatic updates. It's just overall nicer to run a server if you
don't have to maintain a set of custom patches and re-apply them after
each update. And I imagine I'm not the only one who wants to remove
third-party requests.

Finally, it would be amazing if Jitsi Meet could offer verifiable
end-to-end encryption with ZRTP. I know this is obviously a much
bigger and longer-term task. Are you currently looking into it or
working on it? It looks like others are working on a ZRTP/WebRTC
spec: https://tools.ietf.org/html/draft-johnston-rtcweb-zrtp-00

Peter, Ingo and George already touched on that. While it is my favourite
tool for e2e encryption in 1-to-1 calls, ZRTP doesn't really have much
to offer on top of what you can already do with DTLS/SRTP in a bridged
call. Alan's draft is meant for cases where you talk directly to peers.

We all hope PERC will come up with something nice, but

a) it will be a while before they do
b) once they are ready we'd still need for the browser implementations
to catch up
c) I am sceptical that it would offer better guarantees than the option
of running your own Jitsi Videobridge deployment + protecting it with
DTLS/SRTP.

On c), I think PERC would focus more on solving a slightly different
issue: if you connect for a conference on superconf.com and it uses
cloud bridges from megabridge.com, then PERC would probably guarantee to
superconf.com that megabridge.com are not able to access user data. I
don't believe that PERC would remove the need for you to trust
superconf.com.

I would be very happy to be proven wrong.

Thanks for clarifying. I didn't realize that ZRTP was only for 1-to-1
calls, but that makes sense.

I know that verifiable end-to-end encryption in multi-party calls is
complicated and the tech isn't quite there. It's good to hear that
you're keeping up with it.

···

On 11/11/2015 08:11 PM, Emil Ivov wrote:

--
Micah Lee
OpenPGP: 927F 419D 7EC8 2C2F 149C 1BD1 403C 2657 CD99 4F73


#8

End-to-end encryption through a bridge is a hard problem. Some folks at the IETF are working on standardized solutions:

http://datatracker.ietf.org/wg/perc/charter/

http://datatracker.ietf.org/wg/perc/documents/

Peter

···

On 11/9/15 9:04 AM, Ingo Bauersachs wrote:

Finally, it would be amazing if Jitsi Meet could offer verifiable
end-to-end encryption with ZRTP. I know this is obviously a much bigger
and longer-term task. Are you currently looking into it or working on
it? It looks like others are working on a ZRTP/WebRTC spec:
https://tools.ietf.org/html/draft-johnston-rtcweb-zrtp-00

If the webrtc.org implementation adds support for it, I think we’d be more
than happy to support ZRTP as well.

The problem with ZRTP is: the Videobridge is basically a MitM. The original ZRTP protocol supports a mode called Trusted MitM, at the time intended for PBXs like Asterisk. So the Videobridge needs to become a trusted MitM. But this IMO makes ZRTP superfluous: if you trust the bridge, you can do directly trust/verify the DTLS-SRTP fingerprints. The whole WebRTC/ZRTP only makes sense for peer2peer connections.

Or am I missing something?


#9

I don’t think you’re missing anything, I missed the "end-to-end" encryption requirement and only ZRTP caught my attention, I’m sorry. Maybe this will be possible with EKT, as Peter suggests.

···

On Nov 9, 2015, at 10:04 AM, Ingo Bauersachs <ingo@jitsi.org> wrote:

Finally, it would be amazing if Jitsi Meet could offer verifiable
end-to-end encryption with ZRTP. I know this is obviously a much bigger
and longer-term task. Are you currently looking into it or working on
it? It looks like others are working on a ZRTP/WebRTC spec:
https://tools.ietf.org/html/draft-johnston-rtcweb-zrtp-00

If the webrtc.org implementation adds support for it, I think we’d be more
than happy to support ZRTP as well.

The problem with ZRTP is: the Videobridge is basically a MitM. The original ZRTP protocol supports a mode called Trusted MitM, at the time intended for PBXs like Asterisk. So the Videobridge needs to become a trusted MitM. But this IMO makes ZRTP superfluous: if you trust the bridge, you can do directly trust/verify the DTLS-SRTP fingerprints. The whole WebRTC/ZRTP only makes sense for peer2peer connections.

Or am I missing something?

-
George

George

Ingo

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#10

Hi Micah,

Good post! I have also been looking into those same issues you mentioned.
I'm sure there are other "paranoid" folks on this list that also want to
remove any dependence from 3rd parties.

As Emil says, removing GA is easy. All I did in my case was comment it out
in the index file.

Gravatar removal, as you correctly point out, is not so trivial but is also
doable (in fact there was a time, probably last year?, where jitsi-meet
loaded the avatars locally instead of using gravatar IIRC. I confess that I
had forgotten about callstats.io, so I'll have to take a look at where that
hooks into the code and how easy it would be to remove.

Anyway, if you have implemented any of these changes could you share them
with me so I don't have to reinvent the wheel? I know that updates will
overwrite our changes, but I don't see any easy way around that unless we
fork the project and develop our own privacy-enhanced jitsi meet repo, but
that would be a lot of work. Also, not sure how feasible that would be nor
if the Jitsi team would like that approach.

As for ZRTP, I too am a huge fan and have been using it in different
implementations for a couple of years now. The problem, as many pointed
out, is that in jitsi-meet you already have to trust the bridge given it is
not p2p but a SFU, so adding ZRTP by copying the SIP trusted MiTM approach
won't bring any more security. However, I am working on a simpler POC app
which does do p2p webRTC (limit of 4 participants however, since it can't
really scale more than that and keep the p2p architecture), and in that use
case ZRTP would be very useful. It's not really a priority for me right now
but I hope to hire some dev soon to work on implementing it.

Let me know if you'd like to exchange some ideas or info off list. And
please share the changes you've mentioned above if you've already
implemented any of them.

Cheers,
Peter

···

On Tue, Dec 1, 2015 at 9:00 PM, Micah Lee <micah@micahflee.com> wrote:

Sorry about the really long delay. FYI I just opened an issue about
this: https://github.com/jitsi/jitsi-meet/issues/422

On 11/11/2015 08:11 PM, Emil Ivov wrote:
>>> Even if you aren’t using CallStats, the javascript is still always
>>> loaded in index.html, meaning that this company will get a web
>>> request from each person who wants to make a video call on our
>>> server. And I know Gravatar is nice, but it would be great if there
>>> were an option to completely disable it, and use a generic image
>>> for everyone’s avatar. And it would also be great if we could
>>> disable Google Analytics — we don’t want Google to get notified
>>> each time we’re having a video call. (For that matter, it would be
>>> nice to be able to replace the GA id with your own,
>
> What is preventing you from doing this now?

I am doing this now, but the issue is that my server gets automatic
updates from Jitsi's debian repository, and my custom patches get
replaced with each update.

Also, removing the Gravatar requests is a lot tricker, since it involves
actually modifying some of the javascript and then re-minifying it
(since app.bundle.min.js is what gets loaded) as part of the patch process.

>> or add support
>>> Piwik, but that would be a totally different issue.)
>
> It is. But again: what's stopping you from just replacing the GA script
> with yours?

Same, automatic updates. It's just overall nicer to run a server if you
don't have to maintain a set of custom patches and re-apply them after
each update. And I imagine I'm not the only one who wants to remove
third-party requests.

>>> Finally, it would be amazing if Jitsi Meet could offer verifiable
>>> end-to-end encryption with ZRTP. I know this is obviously a much
>>> bigger and longer-term task. Are you currently looking into it or
>>> working on it? It looks like others are working on a ZRTP/WebRTC
>>> spec: https://tools.ietf.org/html/draft-johnston-rtcweb-zrtp-00
>
> Peter, Ingo and George already touched on that. While it is my favourite
> tool for e2e encryption in 1-to-1 calls, ZRTP doesn't really have much
> to offer on top of what you can already do with DTLS/SRTP in a bridged
> call. Alan's draft is meant for cases where you talk directly to peers.
>
> We all hope PERC will come up with something nice, but
>
> a) it will be a while before they do
> b) once they are ready we'd still need for the browser implementations
> to catch up
> c) I am sceptical that it would offer better guarantees than the option
> of running your own Jitsi Videobridge deployment + protecting it with
> DTLS/SRTP.
>
> On c), I think PERC would focus more on solving a slightly different
> issue: if you connect for a conference on superconf.com and it uses
> cloud bridges from megabridge.com, then PERC would probably guarantee to
> superconf.com that megabridge.com are not able to access user data. I
> don't believe that PERC would remove the need for you to trust
> superconf.com.
>
> I would be very happy to be proven wrong.

Thanks for clarifying. I didn't realize that ZRTP was only for 1-to-1
calls, but that makes sense.

I know that verifiable end-to-end encryption in multi-party calls is
complicated and the tech isn't quite there. It's good to hear that
you're keeping up with it.

--
Micah Lee
OpenPGP: 927F 419D 7EC8 2C2F 149C 1BD1 403C 2657 CD99 4F73

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev