Run on https #160

Open benloh opened 3 years ago

In GitLab by @jdanish on May 4, 2021, 09:49

This has serious implications for webrtc, probably requiring a separate server and network retooling.

changed time estimate to 80h

In GitLab by @jdanish on May 6, 2021, 08:27

Yeah. I put it in here because we've noticed with Net.Create and MEME that some browsers, etc., block not secured urls. So, this is a nice to have for when we do things like these virtual tests, but a) not a major priority, and b) would likely not apply to when we are using video. Maybe. I just wanted it somewhere on our list to talk about what it gets / loses / requires.

Significant engineering feature
Would affect entire networking architecture
Might make sense to address along with other internet issues
Testing is complicated 10x, and slower to test
More difficult debugging because we can't access materials in real time
Probably need to hire expensive consultant
Access to streaming webcast will only work with https

If we can break it down to specific pain points, we can target things that are more doable.

This is a huge project in itself.

removed time estimate

In GitLab by @jdanish on May 6, 2021, 12:22

OK, then let's assume we are NOT doing this, but it's helpful to include the record of the discussion for me if nothing else.

The dynamic and flexible allocation of network devices that we make use of is antithetical to https security. Short of defining and deploying security certificates for every device, there isn't a simple solution. We've spent a fair amount of time researching this.

It is in fact one big concern with webrtc and video...it's not clear we're going to be able to get it to work without some kind of https support.

In GitLab by @jdanish on May 6, 2021, 14:32

Makes sense. How did the STEP version work?

STEP worked because it predated the beefing up of browser security. Things have changed a lot.

In GitLab by @jdanish on May 6, 2021, 14:36

Ahh and crud.

theRAPTLab / gsgo

Run on https #160