https://www.schneier.com/blog/archives/2020/04/security_and_pr_1.html Bruce Schneier wrote an informative blog post about the problems with Zoom. https://jitsi.org/ He recommends Jitsi which has Debian packages among other things. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On 6/4/20 10:50 am, Russell Coker wrote:
https://www.schneier.com/blog/archives/2020/04/security_and_pr_1.html
Bruce Schneier wrote an informative blog post about the problems with Zoom.
He recommends Jitsi which has Debian packages among other things.
I've got a jitsi installed setup, the debian installed worked first time but adding any type of security to stop people just finding your site and using it is a total pain with a lot of documentation which is out of date or plain incorrect. Mike
Quoting Russell Coker (russell@coker.com.au):
https://www.schneier.com/blog/archives/2020/04/security_and_pr_1.html Bruce Schneier wrote an informative blog post about the problems with Zoom.
The Citizen Lab report from two days ago, to which Schneier links, is particularly damning, e.g., the firm lying about the nature of the crypto. https://citizenlab.ca/2020/04/move-fast-roll-your-own-crypto-a-quick-look-at...
https://jitsi.org/ He recommends Jitsi which has Debian packages among other things.
I participate in Jitsi Meet videoconferences on a Devuan Project server just about every week, and it works consistently very well indeed -- bearing in mind that the requirement don't include much as to security, and the Jitsi project doesn't promise much. Although in theory any modern Web browser able to support WebRTC would suffice, I always recommend Chromium. People trying to use, e.g., Firefox are more likely to have problems. (I suppose one could equally pick Google Chrome, but why use a proprietary variant of Chromium when you could use Chromium?) -- Cheers, "I suppose the process of acceptance will pass through the usual Rick Moen four stages: (i) This is worthless nonsense; (ii) This is an rick@linux interesting, but perverse, point of view; (iii) This is true, mafia.com but quite unimportant; (iv) I always said so." -- JBS Haldane
On 6/4/20 11:57 am, Rick Moen via luv-main wrote:
Quoting Russell Coker (russell@coker.com.au):
https://www.schneier.com/blog/archives/2020/04/security_and_pr_1.html Bruce Schneier wrote an informative blog post about the problems with Zoom.
The Citizen Lab report from two days ago, to which Schneier links, is particularly damning, e.g., the firm lying about the nature of the crypto. https://citizenlab.ca/2020/04/move-fast-roll-your-own-crypto-a-quick-look-at...
https://jitsi.org/ He recommends Jitsi which has Debian packages among other things.
I participate in Jitsi Meet videoconferences on a Devuan Project server just about every week, and it works consistently very well indeed -- bearing in mind that the requirement don't include much as to security, and the Jitsi project doesn't promise much.
Although in theory any modern Web browser able to support WebRTC would suffice, I always recommend Chromium. People trying to use, e.g., Firefox are more likely to have problems. (I suppose one could equally pick Google Chrome, but why use a proprietary variant of Chromium when you could use Chromium?)
Definitely not a support of Google Chrome, but it will likely get security patches more quickly than Chromium. I use a number of browsers for different reasons, and usually NEVER Google Chrome. Cheers A.
Quoting Andrew McGlashan (andrew.mcglashan@affinityvision.com.au):
Definitely not a support of Google Chrome, but it will likely get security patches more quickly than Chromium.
This seems surprising, given that Chromium is the base code: My understanding is that Google occasionally takes a snapshot, decides to deem it stable, and adds a few few proprietary extras before releasing that as a Google Chrome thing. (I have avoided ever running Google Chrome, as I try to have minimal dealings with the second-nosiest company on the planet, and see no reason to trust its binary-only code, given ample alternatives.) Of course, the burden is on users (and distro packagers) to refresh as suits local/distro policy. Just getting a Chromium daily build, e.g., directly from Google at chromium.org (ugh! proprietary-OS bad habits ahoy), and then _never updating_ would have adverse results over time. So, Don't Do That, Then. Perhaps you're referring to the lack of an 'automatic update' feature internal to the Chromium codebase. Personally, I consider those undesirable generically, tending to interfer with a distro's own maintenance policy. (Proprietary OSes of course don't have distro policies, so sucks to be them.)
On 7/4/20 5:11 am, Rick Moen via luv-main wrote:
Quoting Andrew McGlashan (andrew.mcglashan@affinityvision.com.au):
Definitely not a support of Google Chrome, but it will likely get security patches more quickly than Chromium.
This seems surprising, given that Chromium is the base code: My understanding is that Google occasionally takes a snapshot, decides to deem it stable, and adds a few few proprietary extras before releasing that as a Google Chrome thing. (I have avoided ever running Google Chrome, as I try to have minimal dealings with the second-nosiest company on the planet, and see no reason to trust its binary-only code, given ample alternatives.)
Okay, I was wrong then. However, Chromium is still, in some respects "Google property". Not sure which one gets updates first or how well they bounce those updates back and forth. I thought that Chromium was much like Google's Android vs the Google AOSP -- vanilla Android with less Google crap enforcement. Cheers A.
Quoting Andrew McGlashan (andrew.mcglashan@affinityvision.com.au):
Okay, I was wrong then. However, Chromium is still, in some respects "Google property". Not sure which one gets updates first or how well they bounce those updates back and forth.
The code checkins occur at the Chromium repo, which is a rolling codebase with (usually) multiple daily snapshots. Occasionally, Google decides to take a snapshot of the code, add in proprietary extras, and release that as the next version of Google Chrome. Yes, certainly Chromium is in some respects 'Google property', in that although anyone has the right to fork, only very rarely does anyone presume to do so, on account of maintenance being a gigantic job. (One example is the ungoogled-chromium browser. There are also a number of non-Google proprietary browsers based on Chromium.) I am unclear on whether Google accepts code contributions from non-employees into its repo for Chromium. -- Cheers, "I suppose the process of acceptance will pass through the usual Rick Moen four stages: (i) This is worthless nonsense; (ii) This is an rick@linux interesting, but perverse, point of view; (iii) This is true, mafia.com but quite unimportant; (iv) I always said so." -- JBS Haldane
On 7/4/20 4:56 pm, Rick Moen via luv-main wrote:
I am unclear on whether Google accepts code contributions from non-employees into its repo for Chromium.
(I work at Google as an SRE supporting some Chrome related stuff) Yes, Google absolutely accepts changes back, I believe Microsoft have had a bunch of things merged back in from their Edge browser. What level of CLA / grant etc. is required for that I don't know.
Quoting Julien Goodwin (luv-lists@studio442.com.au): [Chromium:]
Yes, Google absolutely accepts changes back, I believe Microsoft have had a bunch of things merged back in from their Edge browser.
What level of CLA / grant etc. is required for that I don't know.
Thank you, Julien. That's good to know, and kind of you to speak up. -- Cheers, "I suppose the process of acceptance will pass through the usual Rick Moen four stages: (i) This is worthless nonsense; (ii) This is an rick@linux interesting, but perverse, point of view; (iii) This is true, mafia.com but quite unimportant; (iv) I always said so." -- JBS Haldane
participants (5)
-
Andrew McGlashan -
Julien Goodwin -
Mike O'Connor -
Rick Moen -
Russell Coker