Microsoft werkt aan eind-tot-eindversleuteling voor Teams-gesprekken

Microsoft wil het voor zakelijke Teams-gebruikers mogelijk maken om Teams-gesprekken eind-tot-eind te kunnen versleutelen. Nu zijn de gesprekken wel versleuteld, maar niet eind-tot-eind. Eerst moeten ongeplande een-op-eengesprekken de eind-tot-eindversleuteling krijgen.

Wanneer medewerkers met elkaar of met klanten een eind-tot-eindversleuteld voip-gesprek willen voeren, moeten zowel de deelnemende gebruikers als de IT-afdeling hier toestemming voor geven, schrijft Microsoft. Als twee medewerkers een gesprek voeren en een van deze gebruikers heeft geen toestemming gegeven voor de eind-tot-eindversleuteling, dan wordt het gesprek niet eind-tot-eindversleuteld.

Het gaat om een gefaseerde uitgave waarbij ongeplande een-op-eengesprekken eerst de eind-tot-eindversleuteling kunnen krijgen. Pas later zijn online meetings met meerdere gebruikers aan de beurt. Concurrent Zoom biedt sinds oktober eind-tot-eindversleuteling aan.

Microsoft werkt daarnaast aan een invite-only-lobbyfunctie. Daarbij kunnen alleen mensen die uitgenodigd zijn voor een meeting daar aan meedoen. Een gebruiker die niet is uitgenodigd maar toch wil meedoen, wordt naar de lobby verwezen. Hier kan de meetinghost de gebruiker alsnog uitnodigen voor de meeting. Deze functie komt in maart beschikbaar voor alle Teams-gebruikers. Deze lente moet het daarnaast mogelijk zijn om als host de camera van individuele of alle gebruikers uit te kunnen schakelen.

Reacties (102)

[i_like_scotland]

Ik heb liever dat Microsoft gaat werken aan het belachelijk hoge CPU gebruik van Teams tijdens video call's of het delen van scherm content. Ik denk dat het toepassen van end to end encrypte de performance niet ten goede gaan komen.

[Verwijderd]

Men klaagt (terecht) over hoog CPU/memory usage voor Teams en voor Slack is het hetzelfde verhaal. Ook Discord heeft hier, in mindere mate, last van.

De overeenkomst tussen deze 3 programmas zijn dat ze met Electron zijn gemaakt. Electron is een manier om een desktop applicatie te maken met Javascript. Electron kun je zien als een "repackaged" browser, verhult als desktop applicatie.

Oftewel; Electron heeft het toegankelijk gemaakt voor "web developers" om vrij gemakkelijk desktop applicaties te maken. Net zoals Macromedia Flash het begin 2000s het makkelijk heeft gemaakt om creatieve web widgets te maken zonder hardcore HTML kennis (tot grote ergenis van "gevestigde web programmeurs" van die tijd).

Toch ligt de schuld niet helemaal bij deze javascript developers. Browsers komen tegenwoordig nou eenmaal met verschrikkelijk *veel* functionaliteit. Als je Chrome/webkit draait, draai je iets wat begint te lijken op een fully fledged OS. Vervolgens gebruiken developers SPA's (single-page-applications) om het allemaal nog wat performance intensiever te maken. I digress.

Jammer genoeg zijn er geen UI frameworks voor desktop applicaties waarin je snel mooie dingen kan maken zoals met HTML/CSS. Qt (Widgets of QML) of GTK komen dichtbij, maar vereist wel C/C++ kennis. Telegram/Wireshark/Battle.net zijn voorbeelden van Qt applicaties, en je merkt weldegelijk dat die applicaties sneller zijn t.o.v Electron.

Voor bedrijven is het maken van een Electron applicatie aantrekkelijk omdat ze snel talent kunnen aantrekken (er zijn genoeg frontend developers te vinden) en er kan in korte tijd een stap worden gezet naar de desktop. De prijs die de consument vervolgens betaald is een aanslag op hun CPU/RAM resources.

Ik denk dat de volgende grote chat applicatie een Slack/Teams clone gaat zijn, die *wel* performant is. Hier is markt voor, gezien CPUs niet persee sneller worden, maar Electron applicaties wel steeds langzamer, en de consument is hier bewust van (zie reacties in deze thread).

[Reactie gewijzigd door Verwijderd op 23 juli 2024 19:36]

[Superstoned]

Feel van het probleem is natuurlijk dat het van 5 of 10 h264 streams gewoon veel resources kost... dat moet je niet onderschatten.

[Verwijderd]

Ik denk dat die streams niet echt boeiend zijn vanwege hardware accelerated decoding, mijn gevoel is dat de meeste resources naar de V8 interpreter gaan en de rest van wat chromium allemaal doet om 10 streams op een HTML pagina te laten zien.

Met VLC kun je prima 10/20 films tegelijk afspelen en gaat disk I/O eerder een bottleneck zijn.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 19:36]

[Superstoned]

Mja, browsers zijn niet zo goed met hardware acceleratie, er zit absoluut ergens een bottleneck. Misschien is het inderdaad de display, kan ook. Maar ergens zit een probleem, het is idioot hoe moeilijk het lijkt te zijn om een groot aantal WebRTC video streams te laten zien in een browser...

[Zackito]

Ik heb zelf via Edge een “app” aangemaakt van de Teams website, werkt 10 keer sneller en freet minder resources. Mijn grootste hekelpunt aan Teams was het opstarten ervan bij openen van Windows en het RAM gebruik, dit kost gewoon teveel resources

[The Zep Man]

Mijn grootste hekelpunt aan Teams was het opstarten ervan bij openen van Windows en het RAM gebruik, dit kost gewoon teveel resources

Bron:

the Teams desktop client was developed on Electron, which uses Chromium for rendering.

Dat verklaart het. Tegenwoordig draait praktisch elke messenger als een eigen Electron applicatie. Dat houdt in dat het in een eigen versie van Chromium draait. Zoveel keer Chromium inladen en ja, het geheugengebruik wordt belachelijk hoog.

Geen wonder dat moderne computers zoveel geheugen nodig hebben.

[beau-key]

Geen wonder dat moderne computers zoveel geheugen nodig hebben.

Volgens mij hoor ik die opmerking al de laatste 30 jaar. Vraag is natuurlijk: maakt het geheugengebruik wat uit, behalve misschien voor de 15 miljoen andere applicaties die ook op de achtergrond draaien?

[Dnomyar96]

[...]


Volgens mij hoor ik die opmerking al de laatste 30 jaar. Vraag is natuurlijk: maakt het geheugengebruik wat uit, behalve misschien voor de 15 miljoen andere applicaties die ook op de achtergrond draaien?

Ja, dat maakt zeker uit. Ik heb zelf een aantal zware applicaties draaien als ik aan het werk ben. Als ik dan via Teams met iemand wil overleggen en mijn scherm deel, dan wordt de PC echt veel trager en lopen de applicaties constant vast. Dus ja, dat maakt wel degelijk uit.

[beau-key]

Ik geloof je onmiddelijk. Maar is de manier waarop jij werkt representatief voor de gemiddelde Teams gebruiker? Ik denk dat het overgrote deel (inclusief ondergetekende, ook een "zware" gebruiker) er niet zoveel last van heeft.

Problemen met vergader software hebben (IMHO) meer te maken met 1.) slechte Internet verbindingen, 2.) het gebruik van "50 cents" oortjes i.p.v. headsets met fatsoenlijk NC, 3.) vergader dicipline (I was talking on mute. I have to let the dog out. Sorry my child needs attention) 4. individuele dicipline (op tijd zijn, niet 25 andere dingen doen tijdens de meeting (Can you repeat the question?).

[Creesch]

Problemen met vergader software hebben (IMHO) meer te maken met 1.) slechte Internet verbindingen, 2.) het gebruik van "50 cents" oortjes i.p.v. headsets met fatsoenlijk NC, 3.) vergader dicipline (I was talking on mute. I have to let the dog out. Sorry my child needs attention) 4. individuele dicipline (op tijd zijn, niet 25 andere dingen doen tijdens de meeting (Can you repeat the question?).

Dat heeft toch allemaal betrekking op een totaal ander aspect van teams gebruik? Waar de persoon waar je op reageert het over heeft is het resource gebruik van teams tijdens een meeting, dit is inderdaad zeer hoog waardoor het lastiger kan worden om andere zaken te doen tijdens de meeting of om zaken te laten zien aan anderen in de meeting. Powerpoint e.d. lukt meestal nog wel maar iets anders moet je niet verwachten.

Het is niet ongewoon om te zien dat tijdens een vergadering via teams het CPU gebruik naar 100% te zien gaan en het geheugen gebruik ook flink omhoog, dat maakt het al snel een nare ervaring als je meer wil doen dan alleen naar elkaars video kijken.

[Reactie gewijzigd door Creesch op 23 juli 2024 19:36]

[Wouterkaas]

Houd er ook rekening mee dat de gemiddelde Teamsgebruiker mogelijk ook minder geheugen in zijn machine heeft dan een zware gebruiker

[Mr.Monk]

Zeker maakt dat uit. Helemaal als jij de resources moet delen met andere gebruikers zoals bv in een Citrix omgeving.

[Zwaai Haai]

Zolang de hardware het niet trekt wel. Ik kan niet via teams mijn werk in Photoshop en Illustrator live de veranderingen te laten zien. Vind het niet echt een vooruitgang om met een tweede device in te loggen en het scherm te filmen.

[Creesch]

Mja voor de basis teams functionaliteiten werkt het prima, voor meetings werkt de web versie toch net iets minder vind ik zelf aangezien je alleen maar de persoon kan zien die praat. Nu weet ik dat sommige mensen daar weinig waarde aan (zeggen te) hechten maar in mijn ervaring gaan meetings waarbij men de webcam aan heeft staan toch net wat meer organisch en soepeler.

[Zackito]

Ik vindt hetzelf prima dat ik alleen diegene zie die praat, eerlijk bekennen dat ik vaak ook andere dingen tussendoor aan het doen ben. Mocht het inderdaad nodig zijn voor een bepaalde functionaliteit dan start ook gewoon de lokale teams op.

[Question Mark]

Vergeet niet te vermelden dat je dan wel wat features mist, zoals bv. background blur, custom backgrounds en together mode om er maar een paar te noemen.

[TheVivaldi]

Ik heb eind december of begin januari Teams gebruikt in de browser en het was net zo cpu-onvriendelijk als de app, dus het is niet voor iedereen dé oplossing.

[david-v]

Dat is inderdaad één van de ergernissen die ik heb, enorm cpu gebruik. Er is nog genoeg werk aan de winkel daar bij het Teams team . Die zijn het afgelopen jaar wel even in een sneltrein terechtgekomen die ze niet hadden voorzien.

[Dedun]

Ik merkte vooral dat er een gigantisch verschil was in CPU gebruik tussen een Surface 2 en Surface 3 laptop. Kan het zijn dat hardwarematige versnellingsverschillen zijn tussen de relatief recente versies van Intel processoren?

[Knijpoog]

1,7 vs 2,4 ghz is best een verschil en de 2,4 ghz van de Surface 3 is ook nog een nieuwere soc en heeft snellere ram. aantal cores zijn gelijk.

[Reactie gewijzigd door Knijpoog op 23 juli 2024 19:36]

[Peran]

/offtopic

ghz vergelijken op Tweakers
Of gaat het hier om dezelfde CPU?
IPC's!!
toch?

[Pierdw]

Je zou bij settings in Teams eens kunnen proberen gpu accelleration uit te schakelen. Op mijn laptop deed dat wonderen. Alleen deed request control het daarna niet meer. Was begin 2020 volgens mij dus misschien werkt het nu wel. Ik gebruik de laptop al enige tijd niet meer dus hoe het nu gaat weet ik niet. Hoop dat je er iets mee kan.

[theduke1989]

Wij hebben daarom dan ook maar aan alle leden verteld om het via FileZilla "web versie" te gebruiken. Die vreet veeeeeeeel minder cpu power.

Toen we op onze Citrix farms de application hadden geïnstalleerd, was het geen pretje.

[PrinsPace]

Teams (of eender welke online vergaderapplicatie) aanbieden via Citrix? Dat lijkt me sowieso geen goede architectuurkeuze. Maar wie ben ik

[theduke1989]

WebEx daarin tegen werkt gewoon prima, geen gekke dingen etc. Alleen teams vreet zoveel energie, dus alles via de browser dan maar laten lopen. Of lokaal op de pc installeren via Intune.

[Reactie gewijzigd door theduke1989 op 23 juli 2024 19:36]

[Question Mark]

Dat werkt gewoon hoor. Audio en Video afhandeling wordt keurig out-of-band afgehandelt door het client-device. Je server farm of VDI hoeft daar 0,0 voor te doen. Alleen signaling en IM loopt over je backend.

[iAR]

En aan het wisselen van accounts, en dat password managers (zoals iCloud Keychain) werken tijdens inloggen, en dat Safari gewoon ondersteund wordt én bovenal: wat meer eenvoud.
We werken steeds meer met teams, nu ook nog bij een andere organisatie en ik moet zeggen: ik heb meer en meer weerstand.
Voor vergaderen is het handig maar de rest... nee.

[Magyku30]

Én het hoge memory gebruik.

[Zuury]

Ik zit atm in een meeting met 12 man en gedeeld scherm, 2/3% CPU usage, 500mb RAM usage en 6% GPU usage. Ryzen 3700x met een 1070ti

[Peran]

Appels en peren denk ik
De meeste mensen in deze context werken op een ultrabook, ultra low voltage CPU.

Vanaf de Intel 8xxxU komt de singel core snelheid overeen met bijvoorbeeld een i7-35??M.
throttling nog daar gelaten

[_Thanatos_]

Geen last van. Teams gebruikt de GPU, maar het ligt er misschien aan wat voor GPU je hebt, en hoeveel rekenkracht die nog over heeft om je CPU te helpen. Mijn laptop heeft een discrete Nvidia GPU naast de Intel IGP, dus dat zou de reden kunnen zijn dat Teams bij mij vlot blijft tijdens het delen van m'n scherm (wat ook nog es 4K is).

[Peran]

wat zijn je specs?

[_Thanatos_]

Pfoeh, goeie vraag. Hij is van de zaak, dus ik hou me er niet zo mee bezig (hij staat ook uit, as we speak ). Het is een XPS15. Met iig een 9th gen i7 of i9, 32GB RAM, en dus met een discrete Nvidia GPU naast de IGP.

[Reactie gewijzigd door _Thanatos_ op 23 juli 2024 19:36]

[Ernie_W]

Werd laatst uitgenodigd voor een Zoom meeting en na stug volhouden kreeg ik uiteindelijk een webinterface aangeboden, want die Zoom client kom er bij mij na hun malware grapjes, natuurlijk niet op. Expres in een Chromium browser, vanwege de beste WebRTC ondersteunig, maar m'n 4 jaar oude Mac Pro begon gelijk op te stijgen met ruim 150% cpu belasting.

Dat doet Jitsi een stuk beter en die kan ook E2E en is open source (kun je zelf hosten, ook Docker install voor).

[segil]

Daar zijn de meningen over verdeeld. Ik heb er geen last van. Juist wel last van hoge cpu bij Google Meet.

[Chrotenise]

Er zitten redelijk wat meningen in de post waarop @segil reageert. O.a.:
"Ik denk dat het toepassen van end to end encrypte de performance niet ten goede gaan komen. "

[orvintax]

Nu zijn de gesprekken wel versleuteld, maar niet eind-tot-eind.

Dus als ik het goed begrijp kan Microsoft nu gewoon meekijken ? Cool beans !

Wanneer medewerkers met elkaar of met klanten een eind-tot-eindversleuteld voip-gesprek willen voeren, moeten zowel de deelnemende gebruikers als de IT-afdeling hier toestemming voor geven, schrijft Microsoft.

Zou het niet eerder andersom moeten zijn? Ik snap niet goed wat de IT-afdeling hier mee te maken heeft.

[SirBlade]

Soms zijn bedrijven wettelijk verplicht alle of delen van communicatie op te slaan. Vaak zijn die wetten gemaakt voor email, faxen of brieven maar afhankelijk van hoe de wet is geschreven kunnen applicaties zoals Teams er ook onder vallen. Bij banken word op afdelingen waar ze beursopdrachten van klanten krijgen ieder telefoongesprek opgenomen.

Als je met dat soort processen te maken hebt wil je niet dat werknemers/klanten zelfstandig kunnen besluiten dat te omzeilen.

[the_stickie]

Er zijn massa's scenario's waarin meeluisteren, naluisteren of opslaan van gesprekken heel normaal is. Dat kan omwille van kwaliteitscontrole, metadata/gespreksanalyse/profilering, auditing of allerhande juridische redenen.
Ik denk dan bijv aan callcenters die via teams support zouden moeten leveren oid. Maar ook aan een groter advocatenkantoor dat gesmiezel kan missen - of juist voor de ultieme veiligheid van elk gesprek wil gaan.
Microsoft wil zeker zijn klanten niet voor het hoofd stoten die dat mis-of gebruiken rondom de wereld. Functionaliteit wegnemen (unencrypted bellen/opnemen is ook een functionaliteit) is ook niet hun stijl. Dan moet het dus configureerbaar, als het configureerbaar moet, dan maar ineens zodat het zoveel mogelijk scenarios dekt.

[maevian]

Bij de banken worden alle telefoongesprekken opgenomen niet enkel voor beurstransacties, toch in België.

[Yoshi]

IT afdelingen hebben best wel wat te configureren in een groot bedrijf, ook aan Teams.
https://docs.microsoft.co...rosoft-teams-landing-page
Het is niet even een msi of modern app installeren en de boel werkt zomaar. Ik ga er even snel vanuit dat je toch als IT departement je eigen certificaten wilt gebruiken ipv die van MS.
https://docs.microsoft.co...rview?view=o365-worldwide

[Reactie gewijzigd door Yoshi op 23 juli 2024 19:36]

[GekkePrutser]

Ja en nee. Je hoeft natuurlijk niet de certificaten van de derde partij te vertrouwen voor alles (dus je in je systeem zetten als vertrouwd).. Alleen voor Teams zou genoeg moeten zijn. Zeker als je als een guest joint, wat in zo'n geval (een chat tussen deelnemers van verschillende bedrijven) voor in elk geval 1 van de partijen het geval zal zijn.

De E2E key zou gewoon onderhandeld moeten kunnen worden via bijvoorbeeld een Diffie-Hellman key exchange. Is dan automatisch E2E en PFS (Perfect Forward Secrecy). Daar zou je de andere organisatie's root cert niet voor moeten hoeven vertrouwen.

Maar ik denk dat die toestemming van de IT admin hem vooral zit in het beschermen tegen exfiltratie. Als elke werknemer E2E Teams kan gebruiken, heb je potentieel een kanaal via waar interne bedrijfinformatie doorgespeeld kan worden zonder dat je dat als IT in kan zien. Aangezien de meeste grote bedrijven SSL inspectie gebruiken (wij ook) is dat normaal niet zo.

[Reactie gewijzigd door GekkePrutser op 23 juli 2024 19:36]

[Cergorach]

Daarvoor heeft MS/O365 toch DLP? Iets wat op client niveau al wordt bekeken en niet in de verbinding tussen twee (of meerdere) clients, MS/IT blijft controle houden over de client.

[GekkePrutser]

Ja Azure Information Protection en Windows Information Protection, als je dat gebruikt ja. Dat heeft nogal veel voeten in de aarde. Je moet al je documenten klassificeren en bovendien werkt het alleen volledig met Windows.

Wij zijn er ook mee bezig maar het is een meerjarenproject helaas. Het is wel mooi inderdaad en maakt dit soort overwegingen minder belangrijk.

[Reactie gewijzigd door GekkePrutser op 23 juli 2024 19:36]

[orvintax]

Aha, wist niet dat dit kon ! Thx

[Facerafter]

Customer Key encryption is voor data at rest, en zal niks doen met de teams audio, video streams en ook niet voor chat messages in transit. Dat word gewoon gedaan met TLS 1.2 en hier valt vrijwel niks aan te configureren.

Daarbij is het trouwens ook nog dat Customer Key encryption je de duurste licentie (E5 of Advanced Compliance add-on) nodig hebt. Waardoor veel organisaties dit niet zullen hebben.

[Reactie gewijzigd door Facerafter op 23 juli 2024 19:36]

[Yoshi]

klopt, maar Teams valt daar wel deels onder, het meeste is inderdaad onder TLS 1.2 geënctrypteerd. En dat is ook prima, maar wat ik wou verduidelijken ten opzichte van diegene waar ik op antwoordde is dat er wel het één en ander dient te worden geconfigueerd :-).
https://docs.microsoft.co...level?view=o365-worldwide
https://techcommunity.mic...blic-preview/ba-p/1999893

[Reactie gewijzigd door Yoshi op 23 juli 2024 19:36]

[Facerafter]

Ah, Ik begrijp je nu. Ik dacht dat je reactie was op het meekijken stukje

[Reactie gewijzigd door Facerafter op 23 juli 2024 19:36]

[Yoshi]

Ik had het misschien wat anders moeten formuleren, maar ik bedoel gewoon hetzelfde als jij zegt hoor :-)

[blinchik]

Ja, natuurlijk kunnen ze meekijken, want anders zou je niet vanaf eender welk toestel, gewoon kunnen inloggen, en je message en bestanden historiek of gesprekken zien. Alleen trekt niemand sinds het cloud gebeuren hier zich jammer genoeg iets van aan, of mensen beseffen dat niet meer.

End to end encryptie is veel moeilijker: Als dat zou geimplementeerd zijn moet je met keys per device werken, zoals Signal het doet.

[_Thanatos_]

De vendor van een chat-app kan altijd meekijken met de gesprekken, ook mét E2E encryption. Het is (of kan zijn) een wassen neus, schijnbeveiliging, een facade.

Waarom? Heel simpel: de app is closed source, en de backing services zijn een black box. Je kunt niet weten of de encryption écht E2E is, en je kunt niet weten wie de private key van die encryption bewaart. Je kunt dus nooit weten wat de server precies opslaat, en dus of de server en/of medewerkers van de vendor de berichten kunnen decrypten.

Ze kunnen het alleen beloven. Maar beloftes van commerciele bedrijven zijn meestal eigenbelang, en moet je dus altijd vanuit hun perspectief bekijken.

Alleen als zowel de app als het protocol als de backing services opensource zijn, en je de backing services zelf draait (of kunt draaien), kun je redelijkerwijs stellen dat de E2E encryption ook echt E2E is, en alleen jij en de partij aan de andere kant de berichten kunnen inzien.

[Reactie gewijzigd door _Thanatos_ op 23 juli 2024 19:36]

[Bender]

Dat mag sowieso niet, je mag als werkgevers niet meegluren op de computers van je werknemers maar ook niet email meelezen zonder medeweten (toestemming?) van de ontvanger.

[firest0rm]

Het klopt dat een werknemer recht heeft op privacy.
Echter mogen werkstations wel in de gate gehouden worden wat betreft software applicaties.
Verder kan en mag een Security Officer binnen een bedrijf audits afnemen om te kijken of een gebruiker zich houd aan de afspraken waar een werknemer voor tekent als hij of zij de laptop in gebruik neemt, dit betekent ook inzage tot de laptop.

Er zijn genoeg bedrijven die dit wel gewoon doen en waar het de normaalste zaak van de wereld is.
De ISO27001 norm vraagt hier ook om en daar voldoen behoorlijk wat bedrijven aan.

Mails kunnen en mogen met de juiste redenen ingezien worden.
Denk dan aan het in lezen van een mail waarbij de gebruiker van mailbox niet meer in dienst is maar die mailbox nog wel informatie bevat voor contract afspraken met klanten.
Of het controleren van misbruik in mailverkeer.

[Reactie gewijzigd door firest0rm op 23 juli 2024 19:36]

[Bensimpel]

Nogal lastig als je voor de overheid werkt en gesprekken standaard worden opgenomen vanwege de WOB

[Yoshi]

die worden opgenomen, maar niet systematisch beluisterd. En daar zit hem het verschil. Die worden ook opgeslagen, maar niet systematisch gelezen en je baas heeft er (als het goed is) niet zomaar toegang toe.

[YoMarK]

Bij de overheid worden echt niet by default alle telefoongesprekken opgenomen en bewaard.

[t link]

in nederland niet nee. maar dit gaat niet over nederland noch europa specefiek.

[Bender]

Ik weet niet zeker of ik je goed begrijp, want er zijn veel bedrijven in Nederland, of Europea, die Teams gebruiken.

[t link]

het gaat erom dat dat niet echt de markt is waarop microsoft zich vooral richt. die markten kunnen zelf besluiten of ze het niet willen meekijken. de optie om dat wel te doen is belangrijk in grote markten als de USA.

[Bender]

Europa is geen markt voor Microsoft? Ik denk dat je het erg onderschat..

[t link]

Dat is letterlijk compleet wat anders dan wat ik zei.

[sOid]

Ik weet niet bij wat voor bedrijf jij werkt, maar dat lijkt me een behoorlijk verziekte werkomgeving dan. Vraag me ook af of het überhaupt mág.

[firest0rm]

Genoeg bedrijven die aan bepaalde eisen moeten voldoen volgens wet/regelgeving waar dit de norm is.
Heeft niks met verziekte werkomgeving te maken maar meer met veiligheid.

[sOid]

Wat, de norm dat HR en/of je manager zomaar mogen meekijken? Dat betwijfel ik echt. Meen me bijvoorbeeld rechtszaken te herinneren over managers die zomaar meekeken met mail van werknemers. Mocht niet. Daarnaast geldt de AVG ook binnen een werkomgeving. In zekere zin nog strenger, omdat je als werkgever een 'machtsverhouding' hebt tegenover je werknemer.

[firest0rm]

De security officer van het bedrijf mag met de juiste redenen jou documenten in zien.
Heb in een vorige post al wat voorbeelden gegeven maar met de juiste redenen mogen zeer zeker je mailtjes bekeken worden. Denk dan aan crimineel misbruik van IT middelen of het inzien van gemaakte afspraken met klanten waarbij de werknemer niet meer in dienst is.

Om bijvoorbeeld samen te kunnen werken met een instantie zoals de overheid moet je in beschik zijn van certificaten zoals ISO27001... dit certificaat eist interne audits waaronder inzage tot gedeelde bestanden en gebruik van IT middelen.

[sOid]

Dank voor je uitleg!

[HSG]

Ja met de juiste redenen. Dat is iets anders als "goh zou hij zijn werk wel doen?".

[Facerafter]

In essentie gebeurt dat ook wel, heeft microsoft een heel mooi product voor..
https://www.microsoft.com...iness/workplace-analytics

[HSG]

Dat is op basis van je prestaties en dat hebben wij ook op het werk. Men kan bijvoorbeeld in Topdesk zien hoeveel meldingen je hebt behandeld en wat er allemaal in is geformuleerd. Dat is niet erg want iedereen die een ticketnummer en Topdeskrechten heeft kan in een ticket kijken.

Maar dat is iets anders dan op de achtergrond in iemand zijn documenten of mail zitten loeren of zelfs op afstand op zijn scherm meekijken.

[Yoshi]

die mag dat, maar sOid heeft het over HR en je manager en dat zijn veelal niet de rollen die jij beschrijft. en wederom zo hoort het ook. Ieder zijn taak. als je manager dat doet, dan is iet niet goed bezig en zomaar even een reden om wat zaken aan het rollen te brengen.

[Reactie gewijzigd door Yoshi op 23 juli 2024 19:36]

[SinergyX]

Het is niet opeens dat een videocall anno 2020 'nieuw' is binnen bedrijven, gros wat bij zulke bedrijven werken weten al lang (en hebben getekend voor) dat alles wordt opgeslagen. De top van bv zakelijk verzekeren (met name juridische kant) werkt op zo'n manier, waar het vroeger papier en telefoon was, is dat nu chat en videocalls.

Dat is weinig verziekt, maar 100% vastlegging wat er wordt gezegd, dat is 9 van de 10 om jezelf in te dekken, en niet omdat je baas zo graag wil meekijken.

[Yoshi]

dat ze dat willen wel, maar dat mag net niet van HR of de juridische afdelingen. En zo hoort het ook.
Als het over ongewenst gedrag gaat, dan kan je ook zelf even de chat delen met de vertrouwenspersoon binnen je bedrijf. Zelf daar hebben bazen en HR eigenlijk bitter weinig controle over, en wederom: zo hoort het ook. De wet staat wat dat betreft (gelukkig) aan de kant van de werknemer. (ik weet niet hoe het in NL zit, maar in BE is het alleszins ongeveer zo)

[Reactie gewijzigd door Yoshi op 23 juli 2024 19:36]

[t link]

microsoft oppereert dan ook niet alleen in nederland en belgieen.

[K-aroq]

Als dat bij jou op het werk zo gaat, moet je snel een andere werkgever zoeken.

[t link]

neehoor. maar ik weet wel dat dat de reden is. in de USA etc is dat vooral een ding.

[CAPSLOCK2000]

Wanneer medewerkers met elkaar of met klanten een eind-tot-eindversleuteld voip-gesprek willen voeren, moeten zowel de deelnemende gebruikers als de IT-afdeling hier toestemming voor geven, schrijft Microsoft. Als twee medewerkers een gesprek voeren en een van deze gebruikers heeft geen toestemming gegeven voor de eind-tot-eindversleuteling, dan wordt het gesprek niet eind-tot-eindversleuteld.

Wat een manier van denken zeg. Het is de omgekeerde wereld. Misschien zie ik spoken en zegt het meer vooral iets over mijzelf, maar ik krijg het gevoel dat ze privacy maar eng en onhandig vinden. De baas moet wel mee kunnen kijken want het personeel is niet te vertrouwen, zo'n wereldbeeld.
Ik zie dit als gevolg van dat de gebruiker van de software niet de doelgroep van de ontwikkelaar is.

Mag ik dan op z'n minst ook een knopje om gesprekken te weigeren als die geen eind-tot-eindversleuteling gebruiken?

[PolarBear]

Heel simpel, Microsoft levert Teams wereldwijd, niet overal is e2e encryptie toegestaan.

[CAPSLOCK2000]

Precies, dat zijn keuzes he. Geld > gebruikers.

[_Thanatos_]

Of wetgeving.

[Verwijderd]

Zou het niet komen doordat eDiscovery niet werkt met E2EE calls, en met reguliere calls wel?

[Glorix Jim]

Heeft meer te maken met wet en regelgeving dan privacy "eng" vinden.

[the_shadow]

[...]

Wat een manier van denken zeg. Het is de omgekeerde wereld. Misschien zie ik spoken en zegt het meer vooral iets over mijzelf, maar ik krijg het gevoel dat ze privacy maar eng en onhandig vinden. De baas moet wel mee kunnen kijken want het personeel is niet te vertrouwen, zo'n wereldbeeld.
Ik zie dit als gevolg van dat de gebruiker van de software niet de doelgroep van de ontwikkelaar is.

Mag ik dan op z'n minst ook een knopje om gesprekken te weigeren als die geen eind-tot-eindversleuteling gebruiken?

Het punt is vrij simpel: in een werkcontext heb je privacy, maar die is niet absoluut. Sommige wet- en regelgevingen eisen simpelweg dat je bepaalde controle moet hebben over data binnen je organisatie, en wil je als bedrijf zelf mogelijkheden hebben om lekken op te sporen. Dat ga je niet willekeurig doen, maar de mogelijkheid moet er wel zijn.

[CAPSLOCK2000]

Het punt is vrij simpel: in een werkcontext heb je privacy, maar die is niet absoluut. Sommige wet- en regelgevingen eisen simpelweg dat je bepaalde controle moet hebben over data binnen je organisatie, en wil je als bedrijf zelf mogelijkheden hebben om lekken op te sporen. Dat ga je niet willekeurig doen, maar de mogelijkheid moet er wel zijn.

Ik snap dat er situaties zijn waarin bedrijven dat willen, maar dat zouden uitzonderingen moeten zijn, niet de standaard.
Privacy by default, tenzij er een reden is om van af te wijken.

Het is niet anders dan alle andere vormen van veiligheid of betrouwbaarheid. De standaard optie moet de optie zijn waarin je geen probleem hebt om de default te veranderen. Bij alles wat met security en privacy te maken heeft is de enige zinnige keuze om te beginnen met een systeem dat potdicht zit en dan selectief stukken te openen. Andersom werkt niet, dan woren alleen de stukjes beveiligd waarvan mensen weten dat ze veilig moeten zijn, en de meeste mensen en organisaties hebben daar gewoon geen goed beeld van.

Zo werkt het overal.
De voordeur is dicht tenzij er iemand binnen gelaten moet worden, we doen de voordeur niet pas dicht als er een inbreker komt.
Er hangen geen camera's op je werkplek, tenzij daar dringende reden voor is. We gaan niet zomaar iedereen de hele dag filmen.
Stroomkabels zijn over de hele lengte verpakt in isolatiemateriaal. We isoleren niet alleen de stukjes waarvan we denken dat ze kortsluiting kunnen maken.

Het mantra 'secure by default' is al sinds de jaren 80 bekend in de IT maar het is duidelijk nog steeds niet doorgedrongen.

[the_shadow]

[...]

Het mantra 'secure by default' is al sinds de jaren 80 bekend in de IT maar het is duidelijk nog steeds niet doorgedrongen.

Je gaat hier voorbij aan het feit dat dit momenteel niet zo ingesteld is (kan worden). Het is dus een verandering van de manier van werken. Voor nieuwe klanten/tenants ben ik het met je eens, maar dit doorvoeren voor alle bestaande klanten, waarna de klant het uit kan gaan zetten kan tot problemen leiden. Ik gok dat dit de reden is voor deze aanpak.

[CAPSLOCK2000]

[...]
Je gaat hier voorbij aan het feit dat dit momenteel niet zo ingesteld is (kan worden). Het is dus een verandering van de manier van werken. Voor nieuwe klanten/tenants ben ik het met je eens, maar dit doorvoeren voor alle bestaande klanten, waarna de klant het uit kan gaan zetten kan tot problemen leiden. Ik gok dat dit de reden is voor deze aanpak.

Als dat de aanpak was geweest had ik er meer begrip voor gehad, maar nog steeds niet helemaal.
Dat "alles moet wel altijd blijven werken, alle verandering is eng en onwenselijk" denken is deel van het probleem. Alsof een chauffeur die z'n auto niet snapt en daarom niet aan het stuur durft te draaien omdat de gevolgen niet te overzien zouden zijn. Als je daar niet mee om kan gaan dan moet je niet in de auto stappen want snel reageren op een veranderende situatie is gewoon noodzakelijk op de snelweg.

In een professioneel beheerde omgeving zou zo'n verandering geen probleem moeten zijn. Professionals kunnen dat vooraf beoordelen en de boel goed configureren. Als het niet goed is dan merken ze dat wel in de testomgeving, daar is die voor.

Als het geen professioneel beheerde omgeving is dan moet je gewoon voor de veilige optie kiezen. Zeker bij dit onderwerp (wat uiteindelijk neerkomt op het afluisteren van mensen) vind ik dat er bij twijfel moet worden gekozen voor veilgheid, niet voor functionaliteit. Als dat het echt niet anders kan dan forceer je maar een waarschuwingsscherm tijdens de installatie zodat die niet verder kan tot je een bewuste keuze hebt gemaakt.

Het soort situaties waarin het nodig is om mee te kijken met teams (en dus geen P2P) te gebruiken is ook het soort situaties waarin je geen fouten kan permiteren. Rekening houden met organisaties die wel afluisteren maar geen professionele beheerders hebben vind ik eigenlijk onverantwoord. Dat soort clubs moet je tegen zichzelf beschermen. En misschien wel extra bij SAAS-producten die vooral populair zijn bij clubs die zelf geen IT willen doen maar het willen overlaten aan een diensverlener.

[GekkePrutser]

Hoe werkt dit dan met gesprekken die via de cloud van MS opgenomen worden? (Die komen namelijk op de clouddienst Microsoft Stream terecht).

Ik neem aan dat het in dat geval dan uit gaat.

[Osxy]

Of die recording wordt clientside gedaan voortaan.

[GekkePrutser]

Zou wel mooi zijn op zich, persoonlijk zie ik dat veel liever.

Maar met Microsoft's focus op client diensten denk ik dat dat niet gaat gebeuren. Hun cloud diensten zijn juist een selling point.

[the_shadow]

Hoe werkt dit dan met gesprekken die via de cloud van MS opgenomen worden? (Die komen namelijk op de clouddienst Microsoft Stream terecht).

Ik neem aan dat het in dat geval dan uit gaat.

Niet geheel on-topic, maar ik begreep van een Microsoft engineer dat opgenomen gesprekken op korte termijn niet langer in Stream worden gezet, maar in Onedrive. Als dat door de client wordt gedaan, dan is dat natuurlijk goed mogelijk. Hoe dat dan zou moeten werken met delen binnen de organisatie zou ik dan weer niet weten.

[_Thanatos_]

MS belooft plechtig en heilig dat ze die bestanden niet zullen aanklikken

@the_shadow Het maakt voor MS natuurlijk geen bal uit waar die bestanden gestald worden. Zolang MS erbij kan (en dat kunnen ze, want het zijn hun eigen blackbox diensten) geeft je "veilige" OneDrive omgeving niets meer dan schijnveiligheid.

[Reactie gewijzigd door _Thanatos_ op 23 juli 2024 14:11]

[Jace / TBL]

Maar Teams is toch geen open source? Dus er is geen enkele manier om uit te sluiten dat er toch een backdoor in zit. Al dan niet door Microsoft er in gestopt onder druk van Amerikaanse inlichtingendiensten.

Als individu of bedrijf dat enigszins maalt om privacy zou ik dit risico nooit nemen.

[K-aroq]

Als je ziet hoeveel mensen er aan een product als Teams werken moet er toch wel een keer iemand lekken over dat ze onder druk gezet zijn door de inlichtingendiensten. Zogenaamde invloed van inlichtingendiensten is grotendeels broodje aap en aluhoedjes denken. In de praktijk is het zo dat inlichtingendiensten gebruik kunnen maken van interfaces die ook voor normale operatie nodig zijn.

Dat is een beetje vergelijkbaar met de ophef 2 jaar terug over dat Huawei toegang had tot KPN systemen via zogenaamde achterdeurtjes. Dat was gewoon SSH wat nodig is voor de O&M en support van de systemen. Niks achterdeurtjes.

[_Thanatos_]

Sterker nog, er is geen enkele reden om aan te nemen dat er uberhaupt E2EE in komt. Je kunt immers niets daarvan verifiëren. Zelfs niet als het opensource is*, omdat er dan nog steeds de backing services zijn waar je niet bij kan komen.

* Als de app opensource is, kun je dus alleen verifieren dat er encryptie plaatsvindt, maar je kunt niet verifieren of alléén de ontvangende partij dit kan decrypten.

[Reactie gewijzigd door _Thanatos_ op 23 juli 2024 19:36]

[Jace / TBL]

Sterker nog, er is geen enkele reden om aan te nemen dat er uberhaupt E2EE in komt. Je kunt immers niets daarvan verifiëren. Zelfs niet als het opensource is*, omdat er dan nog steeds de backing services zijn waar je niet bij kan komen.

Hoe bedoel je, de backing services waar je niet bij kan komen? Als ik mijn communicatie encrypt met de public key van de beoogde ontvanger, maakt het verder niet uit via wat voor backing services dat allemaal gaat. Al sturen we onze (encrypted) berichten in het openbaar via facebook, dan is het nog steeds e2ee.

Bijkomend dingetje is dan wel dat ik zeker moet weten dat ik ook echt de public key van de ontvanger heb. Om dat zeker te weten moet je het eigenlijk eenmalig via een ander kanaal verifiëren (bijvoorbeeld door IRL een QR van elkaars device te scannen).

* Als de app opensource is, kun je dus alleen verifieren dat er encryptie plaatsvindt, maar je kunt niet verifieren of alléén de ontvangende partij dit kan decrypten.

Nou, strikt genomen heb je gelijk, maar dat is alleen omdat je niet kan uitsluiten of de ontvangende partij misschien slordig is met zijn key en deze heeft laten lekken. Als beide partijen ieder hun eigen private key niet hebben gelekt, dan kun je op basis van de open source wel uitsluiten dat een derde partij kan meelezen.

Nu is dat uitsluiten van gelekte keys nog niet zo triviaal als je ook hypothetische risico's meeneemt als malware in je telefoon, een ingebouwde keylogger in je OS (zoals Windows 10 op enig moment even leek te hebben), een verborgen Intel Management Engine in je processor die een backdoor op het laagste niveau zou kunnen geven, of dat de app die je uit een play store downloadt niet dezelfde binary is als wanneer je de source zelf zou builden, enzovoort.

[Reactie gewijzigd door Jace / TBL op 23 juli 2024 19:36]

[_Thanatos_]

[...]

Hoe bedoel je, de backing services waar je niet bij kan komen? Als ik mijn communicatie encrypt met de public key van de beoogde ontvanger, maakt het verder niet uit via wat voor backing services dat allemaal gaat. Al sturen we onze (encrypted) berichten in het openbaar via facebook, dan is het nog steeds e2ee.

Hoe verifiëer je dan dat MS of diens server die keys niet hebben?

Bijkomend dingetje is dan wel dat ik zeker moet weten dat ik ook echt de public key van de ontvanger heb. Om dat zeker te weten moet je het eigenlijk eenmalig via een ander kanaal verifiëren (bijvoorbeeld door IRL een QR van elkaars device te scannen).

Dat is al een stap ik de goeie richting, maar een drempel voor veel gebruikers zonder al te veel verstand van IT. Die hebben zoiets van "waarom moet het nou weer zo omslachtig, het mot verdomme gewoon werken". En zo ontstaat het compromis tussen veiligheid en gemak.

Nou, strikt genomen heb je gelijk, maar dat is alleen omdat je niet kan uitsluiten of de ontvangende partij misschien slordig is met zijn key en deze heeft laten lekken. Als beide partijen ieder hun eigen private key niet hebben gelekt, dan kun je op basis van de open source wel uitsluiten dat een derde partij kan meelezen.

Heeft niets met slordigheid te maken. Het kan heel goed opzettelijk zijn. Je kunt prima E2EE claimen terwijl de vendor nog steeds de keys in handen heeft. Dit kunnen ze dan als "smoes" gebruiken om je berichten op een webinterface doorzoekbaar te maken ofzo.

Nu is dat uitsluiten van gelekte keys nog niet zo triviaal als je ook hypothetische risico's meeneemt als malware in je telefoon, een ingebouwde keylogger in je OS (zoals Windows 10 op enig moment even leek te hebben), een verborgen Intel Management Engine in je processor die een backdoor op het laagste niveau zou kunnen geven, of dat de app die je uit een play store downloadt niet dezelfde binary is als wanneer je de source zelf zou builden, enzovoort.

Dat is idd wel heel hypothetisch, want het gaat hier om een chatapp. Door de encryption te compromitteren, sta je niet opeens bloot voor virussen en whatnot. Dat is nu zonder E2EE ook niet het geval.

[Reactie gewijzigd door _Thanatos_ op 23 juli 2024 19:36]

[Jace / TBL]

Hoe verifiëer je dan dat MS of diens server die keys niet hebben?

Ik bedoelde in een open source scenario. Dus niet MS Teams, daar kan je dat inderdaad niet verifiëren.

Dat is al een stap ik de goeie richting, maar een drempel voor veel gebruikers zonder al te veel verstand van IT. Die hebben zoiets van "waarom moet het nou weer zo omslachtig, het mot verdomme gewoon werken". En zo ontstaat het compromis tussen veiligheid en gemak.

Klopt. Maar daar valt best een goede middenweg in te vinden. Bijvoorbeeld dat wel gewoon meteen werkt zonder gezeik. Maar dat er klein in de hoek 'not yet verified' staat, en als je daarop klikt een notificatie van yo let op, je moet nog een keer elkaar IRL ontmoeten (of via een webcam op een ander apparaat) en deze QR scannen, dan ben je 'verified'. Of zoiets, je snapt wat ik bedoel, dat valt best wel in te richten op een redelijk newbie-proof manier.

Heeft niets met slordigheid te maken. Het kan heel goed opzettelijk zijn. Je kunt prima E2EE claimen terwijl de vendor nog steeds de keys in handen heeft. Dit kunnen ze dan als "smoes" gebruiken om je berichten op een webinterface doorzoekbaar te maken ofzo.

Ehhh, nu heb je het over de vendor. Van de chat app neem ik dan aan. Nee dat kan niet met een open source app, want daarin kun je verifiëren dat je private key lokaal wordt gegenereerd en je apparaat nooit verlaat. Als je een private key van de vendor krijgt, of op enigerlei wijze met de vendor of wie dan ook deelt, is het geen E2EE.

Dat is idd wel heel hypothetisch, want het gaat hier om een chatapp. Door de encryption te compromitteren, sta je niet opeens bloot voor virussen en whatnot. Dat is nu zonder E2EE ook niet het geval.

Nee sure, ik bedoelde alleen dat zelfs als je E2EE solide is, en beide chatpartners voldoende capabel en te goeder trouw, dat dat op zich nog steeds geen absolute 100% garantie is dat er niks lekt. Maar het wordt dan al wel een heel stuk onaannemelijker.

[Woefdramcx]

Cool! E2EE! Briljant idee van ze, hoe zouden ze op dat idee zijn gekomen?