Bij email er is geen garantie dat de gegevens versleuteld (transport versleuteling) over de lijn gaan. (Terug)mailen van persoonlijke data zonder dat je in kunt staan voor versleuteling is daarom geen goed idee. Ook al zou het mogen, dan nog moet je het niet zo doen. Richt het in zodat er geen privéinformatie over email wordt verstuurd of zorg desnoods voor versleuteling (maar dat is niet praktisch realiseerbaar).

Wat je wel zou kunnen doen is de gegevens op de server plaatsen (beveiligd met https op je eigen domein), zodanig dat alleen de respectievelijke ouders van het kind en jijzelf erbij kunnen. Daar kun je dan een akkoord bij vragen. Beperk de blootstelling op Internet. Laat de server actief beheren. Zie toe dat de software ondersteund wordt, van goede kwaliteit is en dat security updates voortdurend worden geinstalleerd. Zodra dit stopt, moet je alle data al hebben verwijderd.

Er zijn diverse bestanddeelsystemen (file sharing) die dit (grotendeels) voor je kunnen regelen. De meeste aanbevolen oplossingen werken met cloud opslag. Dat zou ik niet doen tenzij het een onafhankelijk Europees bedrijf is die niets uitbesteed aan Amerikaanse bedrijven.

Voordat je persoonlijke gegevens gaat verwerken moet je uitdrukkelijke toestemming verkrijgen van de ouders met het minderjarige kind.

Als je je echt zorgen maakt dan zou je in plaats van e-mail whatapp kunnen gebruiken. Dat is end-to-end versleuteld.

Dat was toch gekocht door Facebook? Privacyschender Nr. 1

Als je je echt in de AVG en de gevolgen wilt verdiepen moet je inderdaad voor het bos oppassen, je verdwaald voordat je het weet. De privacy fanaten zullen alles afkeuren want privacy. Dat is niet de bedoeling van de GDPR het moet ook werkbaar blijven. Dat gaat met het woord proportioneel en met de stand der techniek.
Ik neem aan dat er een wettelijke grondslag dan wel opdracht voor het werk ligt. Krijg je een opdracht om iets te doen vanuit de ouders dan ligt dat heel anders dan je dat je zelf iets bedacht hebt om te gaan doen.

Je noemt geen verder achtergronden dan "voor mijn werk". In de verschillende beroepsgroepen zijn er vaak ondersteunende site die uitstekende handvatten bieden.

Verander de naam van het kind in [NAAM] en de geboortedatum in [XX-XX-XX]. De ouders kennen de naam van hun kind, en de geboortedatum ook wel. Zonder die informatie kunnen ze de review ook uitvoeren. En hoef je niet moeilijk te gaan doen met encryptie. Een paar dozijn ouders overtuigen PGP te gebruiken ofzo lijkt me ook lastig worden.

Vaak wordt Email opgehaald via pop3 en verzonden via SMTP. Vaak zonder encryptie is dit gedeelte. De meeste clients ondersteunen wel ecnryptie, maar staat standaard niet aan in de mail client

Een lastige is dat jij het document verzend maar ook moet ontvangen. Verzenden zou via een URL gedaan kunnen worden vanuit een webinterface. Nadeel hiervan is wel weer, dat dit ook goed geschermd moet zijn.

Terug ontvangen van het document levert eigenlijk het zelfde probleem op. Je moet het eigenlijk goed en veilig ontvangen.

Om het ook werkbaar te houden voor onze medewerkers adviseren we vaak om de documenten met 7Zip o.i.d. in te pakken en te versleutelen met een wachtwoord (uiteraard voldoende karakters enz.), en het versleutelde zip-bestand te mailen. Het wachtwoord wordt vervolgens verstuurd via SMS of WhatsApp.

Nee alleen text berichten zijn end to end, afbeeldingen en bestanden worden niet encrypt.

Dat is niet waar. En dat blijft niet waar ook als die "fanaten" toevallig alles blijken te hebben afgekeurd van wat jij te zeggen had omdat het inhoudelijk zo rammelt.

Ok whatsapp is versleuteld en e-mail niet, als je er niet zelf stappen voor neemt.
Maar de oude directeur van whatsapp heeft recentelijk ontslag genomen omdat hij moe is van facebook die voortdurend pushed om de encryptie te verzwakken. Dus of dit nou de beste suggestie is i.v.m. encryptie.....

Anoniem, zet eerst een een stap terug: Je verwerkt persoonsgegevens van kinderen in jouw rapport. Hoe gevoelig zijn die gegevens en is de beveiliging van de rapporten (op jouw computer) in overeenstemming met de privacy-gevoeligheid van de rapporten? (Vraag twee: Worden er back-ups gemaakt en zijn die ook voldoende beveiligd?)

Als je weet hoe gevoelig de gegevens in het rapport zijn, dan weet je ook welke eisen je mag stellen aan de andere verwerkers (email providers in dit geval) die de rapporten opslaan. Je moet in ieder geval van jou eigen email provider weten dat hij de privacy van jouw e-mails respecteert, misschien heb je wel een verwerkersovereenkomst nodig.
Dat je naam en geboortedatum van een kind noemt maakt op zichzelf het rapport niet zo privacygevoelig dat het niet via normale email kan, het gaat om de gevoeligheid van de andere gegevens die in het rapport staan. Ik kan me rapporten voorstellen waarbij ik de ouders slechts (na legitimatie) op kantoor inzage zou verschaffen.

Misschien is https://schriftje.nl/ interessant voor je. Heb er zelf geen ervaring mee, maar weet dat het gebruikt wordt in het basisonderwijs. Zelf een eigen server optuigen voor dit doel lijkt me niet verstandig als dit niet je expertise is.

Heeft niemand in de gaten dat het hier om een nepverhaal gaat!!

In princiepe gaat het al goed: door te mailen gebruik je geen gesloten standaard en wordt de informatie niet bij meer partijen en langer dan nodig opgeslagen. Het enige probleem is dat hostigproviders regelmatig met succes gehackt worden waardoor jouw mailbox (of de mailbox van je correspondent) op straat ligt. Ook weet je niet wat er tijdens het transport met het mailtje gebeurd. Dit beveiligingsprobleem zou je kunnen oplossen door S/MIME of PGP toe te passen: voordeel is dat je je correspondenten ook de documenten digitaal kan laten ondertekenen waardoor uitprinten en opnieuw scannen niet meer nodig is. Ook kost het vrijwel niets (hooguit een certificaat bij S/MIME) en is het verder onafhankelijk van commerciële partijen. Nadeel is dat het voor leken moeilijk te begrijpen is: je zal het dus zelf moeten snappen en het ook telkens je correspondenten moeten overhalen het correct te gebruiken.

Ga in ieder geval geen cloudopossingen van derden gebruiken. E-mail is een open standaard waarbij het bericht niet door een derde partij wordt bewaard en verwerkt. Gebruik je een derde partij dan moet je daarmee een verwerkingsovereenkomst afsluiten. Whatsapp heeft aangegeven de encryptie te gaan verzwakken zodat Facebook inzicht kan krijgen in de berichten en reclame kan injecteren. Gezien de recente ontwikkelingen ben je echt (bewust) fout bezig als je whatsapp hiervoor gaat gebruiken. Bovendien zijn centrale oplossingen zoals berichtenboxen veel gevoeliger voor storingen en DDOS aanvallen dan het decentrale e-mail. Bij een storing van zo'n dienst kan geen enkele gebruiker bij geen enkel bericht.

Zelfs als het niet lukt e-mail te beveiligen kun je mbt tot de AVG nog het best bij e-mail blijven. Berichtenboxen (webportals) hebben namelijk het grote nadeel dat de postbus/brievenbus van de ontvanger, in beheer is van de verzender of een derde en niet van de ontvanger. Dat kan juridisch een probleem zijn.

Bij menige mail provider blijft de mail gewoon op de servers staan van de hoster. Denk aan imap of een webmail variant. Dat is bijna tegenwoordig over al het geval.

Dat is bijna altijd de webserver en niet de mail omgeving. Meestal is de site gehacked en niet de server (maar het is wel een risico). Echter bij de meeste cloud mail providers is de beveiliging juist het hoogste. 2FA mogelijken, goede hack detectie.

Je geeft het zelf al aan... Het is voor leken eigenlijk onmogelijk te begrijpen. Je oplossing is dus eigenlijk niet mogelijk. Nog afgezien mogelijke juridische issues, vaak is een handtekening ook nog nodig.

Wat denk je dat Email is? Dat is ook gewoon een cloud oplossing.

Klopt ook niet helemaal.... Er zijn juist veel betere methodes mogelijk met cloud providers.

Ik durf niet direct te zeggen of dit nodig is als je alleen een dienst afneemt en de derde partij er helemaal niets mee doet.

Interesant statement. Op basis van welke statements doe je deze conclusie?

Daarnaast bestaat er ook de aanbieder "zorgmail" voor het veilig mailen van- en naar zorgverleners.

Kan je het stukje niet gewoon in een word document plakken en die versleutelen? Voeg je die toe aan de mail.

Jij lijkt het in de gaten te hebben. Ik niet. Kan jij uitleggen hoe je dat weet?

Bij WhatsApp staat E2E encryptie 'default' aan, volgens de policy. Wat impliceert dat er ook nog een 'non-default' mode is ;)

Ga je op een zorg forum mensen die in de zorg werken, en daar een mening over hebben, ook afzeiken ? Natuurlijk hebben mensen die beroepsmatig bezig zijn met ICT beveiliging een mening over dit soort zaken.

Vragen met AVG zouden moeten zijn.
- Welke persoonsgegevens er in het spel.
- Wat is het doel van de verwerking
- wat zijn de risico's als deze gegevens bij derden terecht komen.
Daarna komt
- Wat zijn de mogelijk gaps en andere zaken voor de techiek
- Welke technisch maatregelen zijn proportioneel en welke moet je als rest risico accepteren
Een ICT-er mag een mening hebben, hetis heel goed het wil niet zeggen dat die mening ook adequaat voor de situatie is.

Ja, waarom dacht je dat ik het raar vind om
- inhoudelijk functionele vragen zonder referentie achtergronden op een forum te gooien
- een forum van techneuten die gebruikers en hun werk maar lastig vinden.

Zo'n verhaal van Hans zou een situatie kunnen zijn van de uit besteedde indicatie jeugdzorg dan wel kinderbescherming.
Dat ligt hypergevoelig met allerelei procedures voor dat soort rapporten. Vanuit die hoek kan zo'n vraag niet komen.
Een andere optie zou kunnen zijn de school of de naschoolse kinderopvang. Ietwat minder gevoelig maar daar is weinig reden om het via afstand mail te doen. Fysiek bezoeken is eenvoudiger in te regelen.
Ik mis de eerste tappen voor een AVG vraag.

Er is inmiddels Jurisprudentie dat whatsapp niet gebruikt mag worden voor bv medische doeleinden niet doen dus.


Er staat duidelijk "verslagen met een stukje levens verhaal van een kind" dat is per definitie gevoelige informatie, daarin kan nl. heel veel staan oa over ouders en leef en medische omstandigheden.


[qoute]
Zo'n verhaal van Hans zou een situatie kunnen zijn van de uit besteedde indicatie jeugdzorg dan wel kinderbescherming.
Dat ligt hypergevoelig met allerelei procedures voor dat soort rapporten. Vanuit die hoek kan zo'n vraag niet komen.
[/quote]
Of die regels en procedures er zijn of niet boeit niet, de praktijk leert dat dit gewoon per mail verstuurt wordt zonder na te denken over eventuele gevolgen ( de meeste werknemers in de (jeugd)zorg hebben niet de awareness die wij als ITérs hebben laat staan de kennis )

Voor de medische wereld zijn er speciale apps (zoals bv. Siilo) in gebruik: https://www.rtlnieuws.nl/technieuws/de-strijd-begint-wat-wordt-de-whatsapp-voor-artsen. Maar daar kan je als leek geen gebruik van maken.

Ok let op:hier hebben het punt waar we het eens zijn.
Stel nu de vraag waar hans zijn werk voor doet, niets verteld uitgelegd enkel dat hij wat email-ed
In de scenarios die ik noem zijn er ook strakke procedures en processen om die reden. Dat het nodige is uitbesteed en soms in pilot met hippe buzzwoorden in nieuw techniek gedaan wordt is wat anders.

Als ik naar het Haga verhaal kijk waren niet de medische die alles in het nieuws brachten. Vermoedelijk een ict-er die zijn gelijk via de media wilde halen, totaal niet nagedacht over de gevolgen. Juist ICT-ers verblind in de techniek halen onbewust de grootste flaters uit.

Ten eerste deze opmerking in het artikel "Vervolgens mailt de ouder met een handtekening het verslag terug"
Hoe mailt de ouder een email met een handtekening van hen of haarzelf daarin.

Ten tweede vermoedelijk Trollengedrag, waarin meerdere artikelen maar één doel lijken te hebben, namelijk zoveel mogelijk zichzelf herhalende reacties te genereren, terwijl het artikel op zich inhoudelijk en duidelijk voor ieder geen enkele relevantie heeft.

Een afdruk maken van het verhaal, dat ondertekenen, vervolgens scannen en terug mailen.
Bij gebrek aan een scanner een foto maken met een telefoon en die terug mailen.
Is een vrij gebruikelijke procedure hoor.

Was niks mis mee hoor. Er is een schok door die wereld gegaan en men zal de volgende keer wel nadenken alvorens
weer nieuwsgierig in een dossier van een BN'er te gluren. Doel bereikt en geen negatieve consequenties.

Een afdruk maken van het (email) verhaal, maar geen scanner of printer bezitten, leg dat nu eens uit.

@ Tha Cleaner

1. De IMAP inbox is de eindbestemming waar de mail bewaard wordt. Die staat onder jouw beheer als je dat wil. Of je gebruikt pop3fetch. Ook kan je een mdir of mbox gewoon vrij migreren naar een andere mailserver en zonder de indeling of bijlagen te verliezen.

2. Je zegt het zelf al: het beschermen van een centraal punt als een portal tegen downtime kost investeringen en dus geld dat aan de gebruikers wordt doorberekend.

3. Zorg dat je het zelf snapt en zorg voor een goede handleiding. Juridisch een probleem; waarom dan? De belastingaangifte met je digid ondertekenen is toch ook gewoon geldig, terwijl dit ook door je grootmoeder gedaan kan worden als ze je code weet...

4. E-mail is geen cloudopossing maar een peer-to-peer oplossing. Indien je IMAP gebruikt, gehost bij een derde partij dan zou je het cloud mogen noemen.

5. Bedoel je hier nu iets als Whatsapp mee..? Of iets anders dat vendor-locked is?

6. Sluit je geen verwerkingsovereenkomst af en lekt die cloudpartij gegevens van jouw klanten dan ben je zelf aansprakelijk. Uiteraard kun je het juridisch gevecht met je cloudclub aangaan om te bewijzen dat het hun fout was. Veel succes.

7. Zeker interessant. Ontvangen documenten kunnen als bewijsstukken dienen. Als je bijvoorbeeld iemand eerst een toezegging doet toekomen en je komt daar later weer op terug dan ligt het bewijs inmiddels al bij de ontvanger en is het dus niet mogelijk dit ongelezen bericht in een berichtenbox, in te trekken. Bij ouderwetse post was dat ook zo: het stuk ligt al in de woning van de ontvanger. Documenten in 2-voud wil zeggen 1 exemplaar in beheer van elk individue. Dat gaat niet op als jij je klanten een postvak laat 'huren' waar alles in gestopt en bewaard wordt. Ga eens praten met een jurist die kan het misschien nog duidelijker uitleggen.

De bovenstaande case van TS is misschien niet authentiek en/of relevant, maar het vraagstuk in zijn algemeen is wel degelijk serieus met betrekking tot alle bedrijven en particulieren die nu ineens wakkerschrikken en op zoek gaan naar informatie zoals in deze thread. We snappen allemaal dat IT-ers hier berichtenboxen lopen te promoten omdat hun werkgever daar rijk van denkt te worden maar je kan het ook omdraaien: als je secure mail als dienst kan aanbieden dan kan deze oplossing gewoon 1:1 compatibel zijn met de open standaarden gebruikt bij... secure mail. En als je al aangeeft dat het voor veel mensen moeilijk is dan heb je het antwoord al: een gat in de markt. Bovendien werk je als IT-er dan mee aan de beste oplossing in plaats van het achterhaalde VHS te promoten. Niemand zit te wachten op 80.000 berichtenboxen waar je op moet inloggen als het ook gewoon via e-mail kan.

Dank je voor de bevestiging van het gebrek aan ethiek. Bij ict ers. Nee het doel heiligt niet de middelen.

Het is gewoon fout om iemand privacy ongewenst groot in het nieuws te brengen ook al is het een bn.
Dan heb je de gdpr echt niet begrepen ne de rol en mogelijkheden van de fg niet. Het betekent tevens een bevestiging dat het Haga bestuur fout zit.

Nou ik moet zeggen dat ik niet de pulp journalistiek volg maar ik heb het beeld dat er alleen naar buiten gekomen is
dat de medewerkers van het ziekenhuis massaal over de schreef gegaan zijn en in haar dossier geloerd hebben, en
niet naar buiten is gekomen (in ieder geval niet in die berichtgeving) wat ze daar dan precies hebben aangetroffen.
Ik zie dit niet als het ongewenst schenden van iemands privacy. Van de medewerkers is geen lijst van namen oid
gepubliceerd, dus die hebben ook niet met privacy te maken.

Weet je karma4, het komt vaak voor (de laatste tijd wat minder gelukkig) dat privacy gebruikt wordt als een reden
om misdaad niet aan te pakken. De dader zou privacy moeten hebben. Nee, de daad moet worden aangepakt en
als de dader dan privacy verliest dan had hij/zij dat moeten meewegen voor hij de daad beging. Hier zijn overtredingen
gepleegd die op geen enkele wijze goed te praten zijn, en dus moet er ook niet gezocht worden naar redenen om
het toe te dekken. Want dan doet men het de volgende keer gewoon weer. Nu waarschijnlijk niet, en een boel
anderen waarschijnlijk ook niet. Daarmee is de privacy 10 keer meer gediend dan met geschutter rond de AVG
met betrekking tot mailtjes tussen 2 partijen.

Nou de pulp pers had een uitgebreide toelichting wat er allemaal zou spelen wegens die opname. Alsof het hele dossier gepubliceerd werd. Dat werd daarna vervolgd met een verhaal omdat ze waargenomen was bij een andere ziekenhuis (maastricht). Behoorlijk privacy schenden. Bedenk dat enkel de waarneming van ophouden op een locatie al zeer privacy gevoelig kan zijn in een context.

De medewerkers hebben van alles over ze zich heen gekregen. Geen idee of dat enkel kijken naar de naam was of meer. Weet jij het, het is nergens genoemd. Wel dat er al een intern proces liep waardoor elke noodzaak tot datalekken als "klokkenluider" niet proportioneel is. Als je wat afrekenculturen gezien hebt wordt je zeer wantrouwend met dat soort berichtgeving.

Wat dat laatste betreft dat men niet aan de verplichtingen en verantwoordelijkheden wil voldoen onder het mom van privacy daar zijn we het eens. De hele commotie met kvk en andere beroepsorganisatie is zo'n voorbeeld van te ver doorgeschoten anoniem willen zijn.

Dat zal allemaal best maar dat heeft dus NIETS te maken met het publiceren van het FEIT dat ONBEVOEGDEN
haar dossier hebben bekeken, hoeveel er dat waren, en hoe daar mee zal worden omgegaan.
DAT was geen privacy issue en dat is waar het hier om gaat.

Het is ook niet relevant. Je hebt je als ziekenhuismedewerker gewoon niet met dat soort dingen bezig te houden.
Er is hier kennelijk een cultuur van "eigen onderzoek doen kan nooit kwaad" waarmee ook het peuren in andermans
spullen gerechtvaardigd wordt ("white hat hackers" en dergelijke) maar echt dat is allemaal een eigen wereldje waarin
dat soort dingen zelf gedefinieerd wordt als gerechtvaardigd. Ook het verzinnen van allerlei onwaarschijnlijke scenario's
is populair in die kringen. Maar in werkelijkheid moet men dat gewoon niet doen en moet men ook geen eigen
initiatieven nemen waarvan men zelf wel kan bedenken dat dit niet gewenst is ("de naam op zoeken om haar een
kaartje te sturen" of dat soort larie)

Dat is de overtuiging van die "klokkenlyider" die juist alles naar de pulp pers gebracht heeft en daarmee zelf dd grootste privacy schender is geworden.
Recht in eigen hand nemen is net zo fout. Persoon is ongeschikt als fg of wat dan ook.


Ze gaan echt niet zo maar namen van bn ers intikken. Het gerucht deed al de ronde. Hoe kan dat want dat is het beruchte kip ei verhaal. Wie heeft er van alles lopen rond te bazuinen en degenen die dan even kijken of dat waar is zijn de sigaar.
Alsof zoiets opzettelijk bedacht is. Het zou de zelfde persoon kunnen zijn.

Bij IMAP blijft de Email gewoon op de server achter.

Ben ik nog niet zo zeker van. De definitie van SAAS kan hier ook heel goed opgebruikt worden. Als je het zelf host, is het natuurlijk wat anders. Maar als je een leverancier gebruikt (gmail, O365 of je hosting provider) is het ook gewoon Software as a Service.

indien je geen eigen server draait of POP3 gebruikt dan is het in theorie inderdaad een cloudopossing. Maar wel een verspreid over veel providers die al maatregelen nemen om hun servers en continuïteit te beschermen, dus waarom het wiel opnieuw uitvinden? En als een provider aangevallen wordt, kunnen klanten van andere providers nog gewoon bij hun post. Reeds opgehaalde mail via POP3 kun je helemaal niet uit de lucht krijgen met b.v. een DDoS. Punt is dat je vrije keuze hebt in hoe je e-mail gebruikt en bij een berichtebbox ben je gebonden aan weer een losse (slechte) oplossing waarvoor je altijd afhankelijk bent van een actieve internetverbinding.

Jammer dat de overheid weinig doet om secure mail op de rails te krijgen. Als bedrijven en burgers secure mail gericht gebruiken om aan de AVG te voldoen is niet alleen (door brede acceptatie) een groot deel van de phishing problematiek opgelost, ook is het voor inlichtingen- en opsporingsdiensten gemakkelijk om verdachte berichten te herkennen. Berichtenboxen kunnen gehackt worden om ze als interne chatdienst in te zetten en zo verdachte communicatie te verbergen door de afwezigheid van nuttige meta-data.

Waar trek je die nou weer vandaan. Je dacht ik wil een kritiekpuntje opperen dus ik roep maar weer wat over de overheid?
De overheid is hardstikke actief met secure mail maar daar is de goegemeente hier nou juist niet van gediend.

Ik weet niet wat voor humor je hier op los laat maar de overheid is zelfs zo actief met secure mail dat ze een berichtenbox voor alle Nederlanders bouwen in plaats van een App en handleiding voor secure mail publiceren. Communiceren als bedrijf of burger met de overheid via secure mail is niet mogelijk waardoor het dus ook nooit breed geaccepteerd zal worden en bedrijven en burgers onderling maar blijven aanprutsen als het gaat om vertrouwelijke gegevens uitwisselen.

Ahh de GDPR en de zorggegevens.... waarin je een email met daarin dat iemand een rollator heeft mag zomaar mag opslaan... maar iedereen in de wachtkamer wel kan zien dat iemand met een rollator loopt..

POP3 is gewoon gewoon een cloud oplossing.

Tja.... Als je laptop crashed of je moet even op een ander device bij je data kopen, dan werkt een berichtenbox juist weer een stuk beter. En er zijn voldoende berichtenboxen die zowel online als offline kunnen werken.
En POP3 kun je ook gewoon met een DDOS uit de lucht krijgen hoor. Is niet zoveel voor nodig, mogelijkheden genoeg.

Securemail is ook een hele lastige. Als je het echt secure wilt doet, moet je of S/MIME of PGP gebruiken. De eerste zou nog redelijk uit te leggen zijn, maar eigenlijk al veel te complex en veel te veel afhankelijkheden. En PGP is voor de meeste een paar bruggen te ver dus helemaal niet te implementeren.
Securemail is best complex om in te richten, uit te leggen en zeer belangrijk te onderhouden. Een berichtenbox is daarin veel gebruikers vriendelijker en wordt daarom door de overheid actief ondersteund en verder uitgewerkt.
Overheid is dus juist goed bezig met de berichtenbox aangezien dat een stuk beter werkt dan gewone Email communicatie. Dat is namelijk niet echt geschikt voor veilig communicatie (zonder lastige aanpassingen(

Best Hans, vraagje:

waarom vermeld je er ook een geboortedatum bij?

Perfect toch? Veel beter secure te houden dan wat jij voorstelt. En het is ook een vorm van secure mail, waarbij er
dan pull ipv push gebruikt wordt.

Als je hier gaat beweren dat een berichtenbox veiliger is dan secure mail dan moet je toch even terugkomen naar planeet aarde en je gaan verdiepen in IT:

- Een berichtenbox gebruikt SSL/TLS: kwetsbaar voor o.a. POODLE, Heartbleed, MiTM aanvallen, etc, etc. End to end RSA op het bericht zelf heeft geen last van de gaten die met grote regelmaat in de onderliggende cryptografische protocollen voorkomen en kan ook geen sleutels lekken.

- Een berichtenbox verzend veelvuldig e-mail notificaties, ideaal om als phishing mail op mee te liften en het gewoontedier naar een malafide site te lokken. Het signen van secure mail voorkomt phishing juist.

- Van de portal van een berichtenbox kan plots een phishing website opduiken, bij secure mail is dat niet van toepassing o.a. door het decentrale karakter en web of trust.

- Weer extra login gegevens die iemand in de webbrowser van zijn smartphone moet invullen om mobiel zijn berichtenboxmail te bekijken. Leken gaan dan briefjes meenemen of zwakke wachtwoorden gebruiken terwijl secure mail gewoon in hun mobiele mailclient verschijnt, welke tegenwoordig op alle mobiele platformen standaard ondersteund wordt. En als je nu met het argument van een app komt dan kun je dus ook gewoon een app voor secure mail bouwen...

- Bij POP3/IMAP/Exchange heb je automatisch een lokale kopie zodat zelfs als alle providers worden aangevallen en het hele internet offline gaat, je nog bij je mail kan, zonder dat je daar zelf iets voor hoeft te doen.

Bichtenboxen zijn alleen veiliger in de ogen van onwetende vertegenwoordigers die onzinnige en nutteloze producten proberen te verkopen en nooit geleerd hebben wat maatschappelijk belang of vooruit denken is. Geen enkel normaal mens zit te wachten op een wirwar aan inherent onveilige berichtenboxen.

En als je onverhoopt toch een ITer bent die onveilige en gebuikersonvriendelijke oplossingen als berichtenboxen verkiest boven een betere en toekomstbestendigere oplossing; ga eens oplossingsgericht te werk ipv 'gaat niet, te moeilijk, brug te ver'... Dus overheid bouw een functie om via digid een public key te registeren, gebruik S/MIME voor de rest, maak een goede handleiding en bouw voor de leken een app en je bent niet alleen klaar voor de toekomst maar dient ook nog eens het maatschappelijk belang.

Heb je het nu over je eigen denkwijze? Probleem is namelijk dat jij alleen in IT denkt, waarin al diverse denk fouten zitten.

Maar een hele belangrijke is... Gebruikers ervaring en gebruikers kennis. Je kan de mooiste technische oplossingen bedenken. Maar geen gebruiker snapt er dan iets van of gaat het gebruiken.
Een veel gemaakte denk fout in de IT, namelijk denken dat wij als ITers wel even kunnen bedenken dat de technisch beste oplossing ook de beste oplossing is voor de gebruikers. En weer een gedoemd mislukt project. En juist jouw argumenten zijn daar het schoolvoorbeeld van. Blijkbaar heb je weinig echte gebruikers ervaring, waarbij gebruikers helemaal geen ervaring hebben met computers.

POODLE, heartbleed.... Leuk, maar daar zijn al lang updates voor. En bij een goede webserver configuratie waren ze al niet vulnerable. En laat hearbleed nu ook eens op SMTP actief kunnen zijn.
MiTM.... Kan ook gewoon op basis van SMTP gebeuren.
Lekkende sleutel... Kan ook met s/mime gebeuren, nog even afgezien dat intrekken van een stuk lastiger is geworden met een decentraal systeem.
Het zijn wel goede argumenten... En zijn ook zeker eigenschappen van een berichtenbox oplossingen, maar erg sterk zijn ze niet, en alles is vrij gemakkelijk centraal te mitigeren.

Daarom geen link versturen in de Email? Zoals steeds vaker gedaan wordt.

Haal je nu juist niet je hele argument van Securemail onder uit? Wat is dan de toegevoegde waarde van securemail? Nog afgezien gebruikers geen enkel idee hebben, hoe zie een securemail kunnen zien of het onderscheid kunnen maken tussen een signed goede of phishing Email. Vergeet niet dat gebruikers helemaal niets van computers snappen.

Net zoals phishing Emails? Berichtenbox heeft veel meer mogelijkheden om security aan te bieden. Al dan niet met een huidige beveiligingsmaatregelen.

Eventueel is dit ook gemakkelijk op te lossen icm een app aan te bieden. En een berichtenbox bied daarvoor al de juiste infrastructuur.

Securemail.... S/mime wordt nog redelijk ondersteunt door clients, afgezien dit ook gewoon vervalst kan worden en stelt dus niet zoveel voor. En geen enkele gebruiker hiervan de kennis heeft, om dit te analyseren of de e-mail juist is, of een phishing s/mime signed Email.
Nog even afgezien dat niet alle mailclients s/mime ondersteunt, ook een klein mogelijke probleempje in je oplossing. Niet alle webclients ondersteunen securemail. Heb je toch een "probleemje" als jou cliënt het net niet ondersteund. Best lastig..... Meerdere mailclients is eigenlijk niet te doen voor eind gebruikers. Terwijl meerdere webbrowsers vrij gemakkelijk te ondersteun zijn.

PGP is zo exotisch, dat de meeste gebruikers hier nog nooit van gehoord hebben, en dus eigenlijk geen idee hebben hoe dat werkt. Nog afgezien bijna geen enkele mailclient dit standaard ondersteund. Dus helemaal geen oplossing.

Voor UserID wachtwoorden, dat is een lastige. Daarom heeft de overheid DigiD bedacht, maar dat mag niet gebruikt worden voor alle authenticatie verzoeken. Alternatief is de nieuwe iDIN als alternatief voor.

Maar het is inderdaad een eigenschap van de oplossing, die niet ideaal is.

Daarbij ga je er vanuit dat de meeste gebruikers bijvoorbeeld backups maken van hun Email. En geloof mij, dat doet bijna niemand. Dus bij een crash of diefstal van het device, ben je dan je lokale kopie kwijt bij pop3 Email en je berichtje. En bij IMAP moet je ook maar voldoende ruimte hebben op mailbox. Of ze slaan de documenten op.
Dat is een goed alternatief, wat net zo goed werkt vanuit de berichtenbox....

En laat nu net zo'n berichtenbox bedacht zijn voor..... Opslaan van documenten.
En als het hele internet offline gaat..... Tja.... Wat als er een stroomstoring plaats vind? Gebeurt gelukkig niet zo vaak. Dat een computer crashed gebeurd veel vaker.

Hoe wil je er trouwens mee omgaan, als de Email niet aan komt? Kan zo maar gebeuren, virusscanners, spam filters of mogelijk (mail) servers die offline gaan. Kan zo maar gebeuren..... En gebeurt vrij vaak, email geeft geen garantie dat het werkelijk aankomt. Zonder dat je als verzender daar enige informatie over heeft. Email is dan weg, inclusief de informatie.

Bij een berichtenbox blijft het bericht wel bestaan (best een belangrijk punt), alleen je notificatie Email kan bij een gebruiker niet aan komen.

Dat is de gedachte vanuit iemand die alleen maar vanuit de techniek denkt. Die denken wel even voor gebruikers de beste oplossing te kunnen bedenken. Maar hebben eigenlijk geen enkel idee hoe gebruikers werkelijke een computer gebruiken. Ofwel een onwetende ITer denk wel even de oplossing te hebben. Gedoemd om te mislukken......

Een veel gemaakte denk fout, een heel veel gemaakte denkfout zelfs. Net zoals dat Management wel even exact weet hoe jij je werkzaamheden moet uitvoeren. Dat gaat dus niet werken. Stap eens uit je ivoren toren en kijk eens hoe iemand er echt mee werkt. Dan zie je dat securemail juist ongeschikt waarvoor gebruikt moet gaan worden.

Nog afgezien jij even iets wil adviseren waar gebruikers echt nog nooit van gehoord hebben. Dat kost jaren en jaren voordat iedereen er iets van snapt. Nog afgezien spam filters Email kunnen filteren, ook een mogelijk klein issue in je oplossing. En dan spreken nog nog niet eens over dat alle clients niet securemail ondersteunen. En Email mogelijk niet aan komt, als een aflever adres even niet beschikbaar is?
Of hoe wil je er mee omgaan, in ondersteuning? Ik gebruik namelijk Email client xyz, maar die werkt er niet goed mee, en ik gebruik pop3 email. Ga jij deze gebruiker nu even helpen over de telefoon?

Je oplossing mag technisch misschien beter zijn, al heb ik daar ernstig mijn twijfels over, er zijn veel te veel grote issues die niet even opgelost kunnen worden.

Jij hebt dus echt totaal geen idee hoe dit soort oplossingen bedacht worden en wat voor een requirements hierbij allemaal komen kijken. Je kijkt weer alleen vanuit de techniek,en techniek is maar een klein onderdeel van de oplossing.

Public key registeren, s/mime, begrijp je nu misschien dat dit voor 95% van de gebruikers dit echt leken taal is?

Juist een berichtenbox, bied de een architectuur en infrastuur die geschikt is voor een app mogelijkheid. Juist iets wat veel van de onvriendelijkheid oplost. En dus veel meer toekomst gericht dan securemail. Dus toekomstbestendig.....

Goh. Echt waar? Vertel, waar heb je deze informatie vandaan? Want WhatsApp zelf zegt namelijk dat afbeeldingen en bestanden wél worden versleuteld.

Privacy and security is in our DNA, which is why we have end-to-end encryption. When end-to-end encrypted, your messages, photos, videos, voice messages, documents, status updates and calls are secured from falling into the wrong hands.

https://faq.whatsapp.com/en/android/28030015/

Dus eigenlijk lulde je gewoon uit je nek. Nietwaar, scriptkiddie?

Stop de persen. PGP en S/MIME probleem gevonden, wordt aangeraden je automatische decryptie tools te de-activeren
en voorlopig berichtenboxen te gebruiken.

Daar ga je dan als secure mail fan...

Klopt geheel


Kan je je punt niet maken zonder dit soort ordinaire taal / beledigingen ? Inhoudelijk heeft het namelijk geen enkele waarde.

Even de pudding uit de ogen halen en nog eens goed lezen wat er staat: het gaat om een (achterhaalde) foute implementatie / in (sommige) mailclients, niet een probleem met een van de 2 standaarden.

https://www.security.nl/posting/561940/Onderzoekers+waarschuwen+voor+ernstig+lek+in+PGP+en+S_MIME

@ Tha Cleaner

Wat een verhaal zeg. Kort samenvat lees ik het volgende: secure mail is een solide oplossing voor digitale post maar een (goede) implementatie is te ingewikkeld en onoverzichtelijk voor leken.

Nou...

Waarom maakt men het dan niet gemakkelijker door alle losse (open source) componenten in 1 applicatie of app te bundelen en daar eens een echt heldere en duidelijke handleiding bij te maken? Een goede applicatie kan bijna alles uit handen nemen: sleutelbeheer, distributie en backup ervan. Het enige wat gebruikers nog zelf hoeven is optioneel vingerafdrukken verifiëren bij persoonlijk contact (bv huisarts of op kantoor bank etc) en dat zou voor die leken zelfs met een QR code kunnen.

Denk verder dan een oerwoud aan berichtenboxen en uitwisselingsplatformen: als iedereen straks secure mail gebruikt op dezelfde wijze als men nu mail gebruikt dan heb je als implementerende ITer meegewerkt aan een universele, niet-commerciële, vrije standaard voor digitale post. Nu nog even je manager overtuigen.

Dan heb je het verkeer gelezen. Securemail is GEEN solide oplossing voor digitale post, een implementatie is complex en totaal niet geschikt voor gewone gebruikers.

Bij een goede app heb je eigenlijk geen handleiding nodig.En hoe veel gebruikers lezen de handleiding eigenlijk?

En blijkbaar heb jij ook geen ervaring met IT in een grote organsiatie, want uit deze opmerking heb jij geen idee wat er komt kijken om zo iets centraal neer te zetten voor meerdere bedrijven. Als je alleen als een kijkt hoe complex het voor de overheid is om de berichtenbox goed neer te zetten en hoe langzaam dit gaan. Om dit dan centraal voor alle bedrijven neer te zetten, is nog complexer.

Technisch zou dit wel kunnen. Maar de complexiteit moet je hievan niet onderschatten.

Icm met een berichtenbox zou dit zeker kunnen. Maar je maakt het met deze bedrijven in eens nog complexer ivm verschillende beveiligingsniveau voor de applicaties.

Securemail is juist geen oplossing, Email is niet betrouwbaar genoeg er voor en heeft veel teveel afhankelijkheden. Daarnaast, niet iedereen heeft Email of wil zijn Email hiervoor gebruiken, of wil die applicatie voor Email gaan gebruiken.

Een Centrale berichtenbox zou wel een goede oplossing zijn, en daarop sluit een App perfect aan. Maar als je ziet hoe lastig het al voor de overheid is om dit neer te zetten.....

Die hoeft ik niet te overtuigen. Managers en Architechten snappen namelijk direct waarom securemail geen oplossing is en een berichtenbox mogelijke oplossing wel.

@ Tha Cleaner

Wat een verzet zeg, en dat om iets als berichtenboxen te verdedigen, waar mensen telkens naar toe moeten gaan om te kijken of ze al post hebben; want volgens jou heeft niet iedereen e-mail dus notificaties werken dan ook niet. Buiten dat notificaties misleidend zijn en ze leren goed/veilig gedrag van gebruikers weer af. Nee, berichtenboxen zijn een omslachtige gebruikersonvriendelijke en in de toekomst onbeheersbare oplossing. Schuif het probleem niet voor je uit maar los het nu op een solide manier op.

Secure mail is gebruikersvriendelijker en veiliger. Mits bedrijven een oplossing bieden voor de implementatie aan de kant van de thuisgebruiker en niet-technische werknemers. Dat kan als volgt:

- Een virtuele werkplek waarin je als beheerder secure-mail implementeert, dat kan met Outlook (standaard al S/MIME en plug-in voor PGP) maar hoeft natuurlijk niet: er bestaan genoeg andere mailclients die met Exchange kunnen praten. Exchange ondersteund ook IMAP dus desnoods een text based mailclient ernaast voor secure mail indien je echt perse Outlook wil hebben icm Exchange en de plug-in een brug te ver is. Om aan de GDPR te voldoen hoef je overigens niet alle mail te beveiligen, alleen als er gevoelige gegevens verzonden worden. Men moet in het meest ongunstige geval dus af en toe eens een ander icoontje aanklikken. Hoe moeilijk is dat..?!

- Voor thuisgebruikers kun je een frontend maken in de vorm van een applicatie of app. De backend is open source vrij te verkrijgen, dat werk is al voor je gedaan. Als je kan programmeren heb je dus maar 2 executables die beide geen admin rechten nodig hebben. En als jouw veilig-mailen-app universeel is en daardoor vleugels krijgt, dan gaan ook mensen waar je niet mee communiceert hem installeren. Tel daar het logo van je bedrijf bij op en je beseft ineens dat dit uitstekende marketing voor je bedrijf is. Mensen die de app niet men gebruiken hebben een alternatief in bestaande implantaties en je kan ze ook nog helpen met een handleiding (met het logo van jouw bedrijf). Doe er je voordeel mee of wacht tot de concurrent ermee komt.

- Als je ergens een obstakel ziet dan los je dat op ipv van het als argument aangrijpen om niet te hoeven vernieuwen.

Maar goed als je als architect alleen maar overweg kan met kant-en-klare Microsoft paketten dan moet je vooral gaan meewerken aan een wirwar van berichtenboxen. Je moet er zelf maar achter komen dat dit een onhoudbare situatie wordt en men toch meer terug komt op het alom bewezen princiepe van basale post.


@ Iedereen die aan de AVG wil voldoen

Berichtenboxen hebben als enige doel om gebruikers abonnementen te laten afsluiten en er rijk van te worden, met de AVG als drukmiddel. Als je als ondernemer op zoek bent naar een een oplossing om aan de AVG te voldoen, laat je dan geen stroop om de mond smeren door bedrijven die deze boxen verhuren, maar ga naar een concurrent die secure mail aanbied of weeg de kosten af tegen aangetekende post. Door massaal in deze valstrik te trappen zitten we er later allemaal aan vast en kunnen we niet meer communiceren met mensen die deze prutsoplossingen (volledig terecht & conform de AVG) weigeren te gebruiken.

Berichtenboxen complex ? In vergelijking met encrypted email ? Voor een berichtenbox hoeft de klant niets in te stellen op de eigen PC; werkt direct.


Secure email is helemaal niet gebruikersvriendelijker. Lastiger voor de klant om te implementeren. Daarnaast moet je dan als bedrijf gaan voorschrijven wat voor encryptie er gebruikt moet worden, zoals bijv PGP.

Heb jij straks voor een aantal verschillende bedrijven diverse encrypted mail oplossingen geimplementeerd ? En verwacht je dat iedere burger dat gaat doen, op basis van instructies van allerlij bedrijven ?


Ook niet iedereen heeft internet, of wil internet gebruiken. Alle genoemde alternatieven kunnen dus ook de prullebak in ? En hoe zit het dan als je ook nog eens mensen hebt, die zaken niet via de post willen doen ?

Het wordt zo allemaal wel erg lastig. Overigens heeft iedereen zo'n beetje email, anno 2018.

Geen verzet, maar er is al een goede oplossing. Dat is een berichtenbox. Een centrale versie zou beter zijn, maar dat is weer wat anders.

gebruikersvriendelijker => Zie ik nog weinig van in je oplossing. Alleen maar zeer lastige, slecht te beheren, gebruikers complexe/onvriendelijke oplossingen.
veiliger => Tot een zekere hoogte is het veiliger. En het is maar hoe je veiliger definieert.

. Oke.... Nog even de basis issues (dus nog niet eens de complexe issues met je oplossing) herhalen.....

Ga je er even vanuit dat het met de hand gedaan wordt. 99,99% is dit niet het geval. Dit soort dingen gebeuren volledig automatisch. Je hebt alleen maar SMTP Email nodig vanuit de "dienst". Rest is overbodig voor de funtionaliteit.

Voor TS zou het in theorie kunnen, afgezien sleutel beheer, VDI, imap, plugins of andere mail clients gaan gebruiken. al best lastige punten zijn die je even zelf moet gaan onderhouden. Een simple webbrowser icm een berichtenbox is dan toch wel in eens simpel geworden.

Zoals veel van je oplossing, het staat ver van hoe bedrijven werken of hoe gebruikers werken. Je denkt veel te veel vanuit de techniek in je oplossing. En daarom kom je met een oplossing die totaal niet geschikt is.

Dat kan....

De backend is open source vrij te verkrijgen, dat werk is al voor je gedaan. Als je kan programmeren heb je dus maar 2 executables die beide geen admin rechten nodig hebben. [/quote]2 Executables? Even snel denken, Windows, Mac, Linux, Chromebook, IOS, Android.... Hoop beheer om dit allemaal te onderhouden voor het bedrijf. Ook voor toekomste updates. Misschien moet je hiervoor maar een abnomeent afsluiten?
Afgezien je bij veel bedrijven niet zomaar even executables kan en mag installeren.
En waar bewaard die eventueel mijn Keys, Emails / informatie die ik wil bewaren of opslaan of wil printen? Of als ik 30.000 Email in mijn mailbox heb staan?

Heeft een berichtenbox toch wel een voordeel, dat ik tegenwoordig gewoon mijn eigen gekozen browser kan en mag gebruiken welke ik niet hoef te onderhouden als bedrijf.

1 van mail providers ondersteund alleen een imap op pop3. Ik heb alleen maar webmail geconfigueerd staan. Daarnaast mag je vanaf veel bedrijven vanaf interne netwerken dit soort protocollen helemaal niet gebruiken. En ook niet altijd op publieke hotspots.
Ik moet dus een vreemde applicatie toegang geven tot mijn mail accounts? Waarna deze applicatie al mijn Email ophaald? Of krijg ik een nieuwe Mail adres? Als ik toevallig wel een pop3 mailbox heb, haalt die dan mijn mailbox leeg, en of wat doet doe met andere mail die er toevallig in staat?
Nu nog even dat ik misschien verschillende mail adressen gebruik, of verschillende PGP keys, die ook nog ergens in die applicatie bewaard worden. Trouwens die in alle applicaties bewaar moeten worden, misschien ergens centraal op slaan? Bijvoorbeeld in een cloud oplossing, of een berichtenbox achtige oplossing.

Weet je in iedergeval wie ze gaan bellen, als het net werkt.... En dan mag jij als bedrijf gebruikers ondersteuning gaan verlenen. Wat trouwens vaak een hele grote kosten post is voor bedrijven. Juist omdat er zoveel fout kan gaan, wat de servicedesk op afstand moet oplossen.

Je snapt de achtergrond juist niet. EMail is niet geschikt voor, Email kan bijvoorbeeld niet aankomen, verwijderd worden slecht te archiveren of te bewaren.
Hele belangrijke punten voor dit soort systemen. En Email is daarom juist NIET geschikt voor dit soort communicatie.
Er is niet een obstakel, het is er technische niet voor geschikt. Dat is het probleem. Je ziet dat zelf alleen nog niet, omdat je vanuit de techniek alles bekijkt.

Wat heeft MS hiermee te maken? Er draait bijna geen berichtenbox op een Microsoft platform. Je eind gebruikers meestal wel... Of op mobiel..

De vele berichtenboxen zijn zeker niet ideaal. Een centrale zou een betere oplossing zijn. Zoals de overheid nu aan het implementern is.


AVG staat daar eigenlijk los van. Sterker nog, je kan heel gemakkelijk in een berichtebox je bestanden verwijderen of terug zien.

Valt wel mee hoor.

Als je een oplossing nodig hebt, is dit toch een goede oplossing?
Nee je moet zelf alle applicaties voor alle OSsen gaan onderhouden... Hoe wil je dat gaan doen, een abonnoment afsluiten voor ondersteunding / updates?

Volgens mij zijn die er alleen niet zoveel. Misschien met een redenen?

Je oplossing klopt al niet in de basis, je gaat iets gebruiken wat op de basis al niet geschikt is, te veel afhankelijkheden heeft, en waar je totaal geen controle hebt over het transport medium. Hierdoor heb je veel te weinig garanties op een succesvolle communicatie met je eind gebruiker.

Gelukkig een inhoudelijke discussie, maar eens ben ik het niet met je:

- Als de implementatie gelukt is (ofwel de app draait) dan is het wel degelijk eenvoudiger: de gebruiker hoef dan helemaal niets meer te doen om post te ontvangen, het valt gewoon in zijn eigen postvak. Jij ging toch vroeger ook niet elke dag naar het postkantoor om te kijken of er post voor je was? Post moet naar je toe komen, dat moet je anno 2018 niet handmatig gaan ophalen. E-mail is juist wel heel geschikt. Ja 1 e-mail kan niet aankomen maar een berichtenbox die eruit ligt raakt veel meer mensen en als de mailspooler naar je berichtenbox crasht ben je nog veel meer berichten kwijt.

- Waarom kun je niet bij het geautomatiseerd verzenden een SMTP relay bouwen die voordat de mail het bedrijf verlaat deze met een pipe door pgp haalt en dus transparant de beveiligingslaag toevoegd? Of een frontend/module gebruiken die s/mime ondersteund?

- Binnen het bedrijf hoef jij als medewerker niets te installeren, dat doet systeembeheer, die ook de app voor de externen beheert, bijvoorbeeld een zorgverzekeraar die een app aanbiedt die iedereen kan gebruiken maar waar alleen klanten support op krijgen. En als alle mail secure wordt verzonden zullen ook de kleine ondernemingen mee moeten en hun leverancier vragen om implementatie.

- Kant en klare Microsoft producten zijn vaak de oorzaak dat benodigde functionaliteit niet door anderen dan MS zelf kan worden toegevoegd. Gebruik je een ander product dan heb je daar geen beperkingen mits je kan ontwikkelen.

- De AVG staat hier idd los van, maar leken denken dat als ze berichtenboxen huren (of secure mail gebruiken), ze automatisch voldoen aan de AVG. Berichtenboxen worden dus om verkeerde redenen aangeschaft, de vraag is onterecht groot en daar profiteren de knutselaars en cowboys van die ook berichtenboxen in elkaar flansen.

- Je hoeft alleen support te bieden voor je klanten. Maar een overkoepelende organisatie (voor bijvoorbeeld veilig mailen in de zorg) zouden ook abonnementen kunnen aanbieden en zelfs secure mail kunnen combineren met secure webmail (berichtenbox).

- Juist omdat het end-to-end is met slechts 1 schakel hoef je je helemaal niet meer druk te maken om een hele ketting aan beveiligings- en transportprotocollen. Een nieuwe Heartbleed of POODLE aanval heeft hier helemaal geen effect op. Meer afhankelijkheden maar geen single point of failure

Probleem is dat je met een technische oplossing bezig bent, en technische issues aan het oplossen bent, terwijl je de functionele requirements overslaat. Waardoor je voor achterstevoren aan het werken bent, op issues die je later tegen komt, maar wel cruciaal zijn voor de acceptatie door je gebruikers.
Techniek is juist het probleem niet, maar gebruikers gemak. Denk bijvoorbeeld aan dat je oplossing op aan de volgende eisen moet voldoen:
any device
any location (Firewalls, Email komt er vaak niet door heen)
bericht moet altijd aankomen, of er moet een fout gegenereerd worden.


Maar die applicatie moet wel geconfigueerd worden, PGP keys moeten gebackuped worden, de applicatie moet naar de mail server kunnen verbinden. POP3, POP3S, IMAP, secure IMAP, web only, zijn hierin al lastige dingen, om dit even aan een eind gebruiker over te laten.
Een simple website benadering is hierin veel eenvoudiger. Al dan niet met een app.
Een vrij cruciaal iets.... Hoe gaat die app om met al mijn andere Email? Wat als ik met pop3 mij mailbox iedere keer leeg haal met een andere applicatie. Dan kan jou app de beveiligde berichten niet meer ophalen.
De enige oplossing is eigenlijk een eigen Email adres voor deze communicatie, zodat alle het verkeer gescheiden is. Maar dat is een heel hoop werk om in te richten en onderhouden.

Gelukkig niet. Maar de postbode bracht het netjes in mijn brievenbus. En dat was stabieler dan Email afhandeling.

Kans is veel te groot, dat het onderschept wordt, waardoor de email niet aankomt. Zonder dat je als verzender dit weet. Vrij cruciaal voor communicatie richting je eind gebruikers. Nog afgezien er veel meer clients verbinding naar je mailbox, die allemaal jouw oplossing omzeep kunnen helpen. Daar moe je allemaal weer technische oplossingen voor verzinnen, wat het de oplossing alleen maar complexer maakt.
En je mag bijvoorbeeld vanaf veel bedrijfsnetwerken (of client firewalls) niet zomaar Email ophalen. Dus je oplossing is in eens voor any location niet meer geschikt => Gebruikers gaan je bellen dat het niet werkt.

Het kan er inderdaad uitliggen. Net zoals je SMTP Relay server. Maar als je zit zelf in beheer hebt, heb je hier ook controle over. Service desks zijn dan bijvoorbeeld al op de hoogte. Of als een cloud oplossing is, dan heb je hiervoor een SLA afgesproken. Je bent veel meer in control over je oplossing.

Deze snap ik niet? Als het automatisch gebeurt, zit dit gewoon in de fout afvang van je applicatie.

Kan zeker. Wordt hier en daar ook gedaan. Maar eigenlijk wil je dit vanuit de applicatie gedaan hebben. Een SMTP relay is daar eigenlijk niet voor bedoelt (meer afhankelijkheden), maar kan wel heel goed. Afgezien dat met PGP je certicaat beheer afhankelijk is van de ontvangers. En je dus de keys van al je ontvangers nodig hebt. Kan veel beter in je applicatie verwerkt worden.

s/mime is hierin een stuk beter. Wordt veel meer vanuit standaard applicaties gebruikt. MAAR je clients moeten hier ook mee overweg lukken, en lost niet je phishing Email probleem op.

Kan inderdaad. Maar een zorverzekeraar die een app heeft... Die communiceert juist al via het HTTPS naar een backend. API/ SOAP/XML koppelingen zijn hiervoor heel geschikt en als als standaarden gebruikt. Een redenen waarom een berichtenbox zo gemakkelijk is. Het is gewoon HTTPS verkeer. De berichten zouden hierna nog steeds via PGP encrypted kunnen worden natuurlijk. Afgezien je dan het hele key beheer ook weer moet inregelen.
Onderschat niet.... Een Systeem beheerder distributed alleen de applicaties intern. Hij ontwikkeld ze niet.... En beheerd ze niet. En Email.... Mag op veel (bedrijfs) locaties niet verzonden worden, of heeft veel verschillende afhankelijkheden om naar de mail server te verbinden. Daarom is het niet geschikt hiervoor.

Valt mee. Ze hebben juist ook heel veel mogelijkheden. Sharepoint heeft standaard de mogelijkheden voor bijvoorbeeld AVG en GPDR wetgevingen. s/mine zit standard in de producten. Het kan allemaal via API aangesproken worden. Dus technisch gezien kan het allemaal. Maar juist veel van berichtenboxen zitten hierop niet. Er zijn veel te veel afhankelijkheden, daarom niet geschikt voor grote berichtenboxen of securemail omgevingen, dat ben ik met je eens. Microsoft is goed in kantoor automatiseringen.

Het valt of staat met je functionele requirements. Dat moet je daarna op een technische oplossing los laten. En functionele requirements zijn hierin zowel Technische requirements als AVG requirements. En jou oplossing is voornamelijk op technische punten bedacht.

Zorgmail heeft hiervoor al oplossingen voor securemail tussen organisaties, maar dat is voor communicaties tussen bedrijven voornamelijk. Juist richting gebruikers is het een stuk complexer, omdat je zoveel afhankelijkheden hebt, dat het gewoon heel erg lastig is. Email is daarvoor niet de juiste communicatie methode. Mede om de functionele requirements die nodig zijn bij dit soort oplossingen.

Juist wel.... je email moet bij de client aankomen. En juist Email heeft hierin veel afhankelijkheden waar jij als verzender geen controle over hebt. Zelfs de client verbinding heeft zoveel afhankelijkheden dat communictie zeer lastig kan zijn.
Denk hierbij weer aan any device, any location. Firewalls zitten bijvoorbeeld al vaak in de weg. Ik kan bij geen enkel bedrijf prive Email ontvangen of verzenden, tenzij het over https verkeer gaat. Ik zou de seuremail dus ook niet kunnen lezen.
Je verzonden Email kan ook onderschept worden door SPAM/AV filters. Daar moet je dus ook een oplossing voor bedenken.
Hoe hoe los je bijvoorbeeld het issue op de backup / opslaan van bestanden? Telefoons / Computers kunnen crashen, ik gebruikt mijn Email voor meerdere doeleinden op meerdere devices. Oa pop3 op mijn thuis computer kan de Email box al leeg gehaald hebben, zonder dat mijn securemail applicatie de securemail verwerkt heeft. Hoe los is dat op? Vergeet niet dat sommige providers alleen maar pop3 aanbieden.

Je oplossing heeft veel te veel afhankelijkheden waar je als verzender geen controle over hebt, waar je dus iets voor moet verzinnen.

Aan de andere kant, daar heb je wel centraal controle over.
Over securemail heb je dat totaal niet:
Je hebt geen controle over het ontvangen van de Email.
Je hebt geen controle over de mailbox van de eindgebruiker.
Je hebt geen controle over hoe de eind gebruiker de mailbox gebruikt. Vrij cruciaal....
Je hebt geen controle over mogelijke firewalls die tussen je eind gebruikers applicatie en de mailbox hoster zitten.
Je hebt geen mogelijkheid dat de gebruiker zijn documenten goed heeft bewaard.
Je hebt geen controle dat jouw applicatie ook de Email uit de mailbox kan halen.
Als je een applicatie zelf laat ontwikkelen, moet je die ook onderhouden voor diverse OSsen (eigen berichtenbox ook, maar je hebt een afhankeijkheid van de webbrowsers die werken met standaarden).
Je key management moet je gaan inregelen, onderhouden. (berichtenbox heeft ook een UseID / wachtwoord nodig).

Maar als je de oplossing voor 2 vrij gemakkelijke requirements wilt bouwen (any device, any location) valt je securemail oplossing al om.

Securemail is een hele mooie oplossingen moet ik meteen zeggen. Maar het is niet geschikt waarvoor jij het wilt gebruiken, en dat is end user communicatie. Wil je het gebruiken voor specifieke communicatie met bedrijf X of persoon Y. Dan kan het heel goed te gebruiken. Maar voor specifieke doelen.

Techniek is nu eenmaal je uitgangspunt, de techniek is er en werkt op een bepaalde manier, daar zul je het mee moeten doen of het roer moet fundamenteel om. Je kan gebruikers niet gaan vragen wat ze willen omdat ze het zelf niet eens weten. Misschien dat een laag van kunstmatige intelegentie ooit realtime de vertaalslag gaat maken wat een gebruiker wil bereiken en de AI die de beste techniek daarvoor kiest, maar zover is het nog niet. Ik snap je punt, maar snap ook mijn punt: post moet naar je toe komen en daarmee jouw eigendom worden. Jij wil controle over alles hebben en daarom vindt je een berichtenbox belangrijk, maar het is juist niet wenselijk; die controle die jij wil omdat het de ontvanger is een zwakke en benadeelde positie dwingt. Bovendien als een notificatiemail niet aankomt en je klant mist het bericht in zijn/jouw box en het verjaard, waar is dan je garantie... En "controle over de mailbox" van je externe relaties, vindt je dat zelf ook niet een beetje griezelig...?

Any device any location kan door een https tunnel in je app te bouwen of desnoods IMAP naar poort 80/443 te routen. Doe je dan meer werkt als strikt noodzakelijk: ja, maar je zorgt ook voor compatibiliteit met een systeem dat gewoon veel doelgerichter is ontworpen op het beveiligen en onderteken van berichten. Ja als beheerder zul je misschien met je oren gaan flapperen als je de manpages van pgp gaat doorlezen, maar als je het idee achter het systeem begrijp dan zie je ineens dat er wel degelijk heel goed over nagedacht is. Ja je hebt sleutelbeheer, maar dat is geen brug te ver: mensen moeten ook op de huissleutels/autosleutels/etc letten. Het alternatief: complexe wachtwoorden, is blijkbaar ook geen succes. Any location voor vertrouwelijke post kun je trouwens ook zien als een significant beveiligingsrisico ipv een requirement. En elke extra app is ook een risico, noem eens een goede reden waarom een gebruiker gedwongen moet worden voor elke leverancier aparte apps berichtenapps te installeren terwijl het ook met 1 app (naar keuze) zou kunnen die (ook) compatibel is met secure mail?

Nou weet je wat, draai het om: biedt standaard secure mail aan, waarbij voor leken de sleutels door een applicatie worden gegenereerd die ook de publieke key naar jouw smtp relay importeert en verplicht een backup van de privésleutel maakt op een cd of usb-stick. Jouw smtp relay kan ook zo slim zijn om public keys uit mailtjes van je klanten automatisch te importeren waarbij je klanten met een telefoontje (of op locatie) vraagt de vingerafdruk te verifiëren. Mensen die te dwars zijn om een app te installeren of het zelf te regelen kun je na een waarschuwing over een lagere beveiliging alsnog naar een berichtenbox sturen. Qua infrastructuur en services is dat niet veel meer extra.

Soms moet je als architect even verder denken dan "hoe implementeer ik dat zo snel en gemakkelijk mogelijk" en heb je een verantwoordelijkheid richting de toekomst.

Nee, dat is juist de verkeerde benadering , je kijkt vanuit een techneut..... Ik weet niet of je enige ervaring hebt in een Enterprise ICT oplossing? Ik heb een vermoeden van Nee...Want technische oplossingen komen pas veel later.
Je hebt functionele requirements, waaraan moet je product of dienst aan voldoen. Bijvoorbeeld toekomst gericht, garantie dan berichten aankomen, controle dat berichten verzonden worden, geen firewall afhankelijkheden, schaalbaar, koppelinge met andere systemen, 3de partij berichten, gebruikers vriendelijk. Al dan niet met must have, nice to have punten.
Daar kunnen ook technische requirments onderdeel van zijn. Maar geen technische producten, want dan limiteerd je de scope al.
Techniek is dus nog helemaal ondergeschikt, je denkt de andere kant op, en dan loopt je juist vast zoals jouw oplossing. En mag je issues gaan oplossingen, die helemaal niets met je oplossing vandoen hebben, maar wel opgelost moeten worden en de oplossing veel te complex maken.

De beste techniek hoeft ook weer niet de beste oplossing voor je probleem te zijn. Dat hangt van je requirements af.
En daar heb je architecten, specialisten of consultants voor. Die maken de vertaalslag.
En voor dit zijn juist de requirements zo van belang. Je weet in wat voor een richting je moet gaan denken voor je oplossing.

Valt wel mee, ik snap je gedacht ook heel goed. En voor kleinschalige oplossingen kan dit ook werken, met alle problemen en issues die daar bij horen.
Ik denk dat een vrij eenvoude requirement is, controle, garantie, minimale afhankelijkheden, ondersteuning (servicedesk), gebruikers gemak. Vrij basis requirements.

De garantie is nog steeds dat het bericht niet verlopen is gegaan, de notificatie mail misschien wel. Maar de notificatie Email kan ik nog een keer verzenden, of via andere methodes als nog een keer versturen. Denk aan SMS, Whatsapps, browser notificaties, Skype/Lync. Mogelijkheden genoeg, waarbij de communicatie niet secure of gegarandeerd hoeft te zijn.

Nee... Ze generen toch al de data die ik nodig heb?.... Dus....

Waarom dan nog Email gebruiken? Gewoon via PGP een file uitwissen via een webinterface.

Komt nog steeds niet door menige firewall heen. Tenzij je https tunneling gaat doen. Maar dat kan ook zomaar geblockeerd worden door firewalls. Afgezien dat dit geen enkele provider ondersteund. Dus geen oplossing is.
En je bent weer technische issues aan het oplossen, die je helemaal niet moet willen oplossen in je architectuur. (=> Requirements)

Klopt, maar bij PGP mijn je juist jouw public keys uploaden bij een 3de partij. Je prive key moet je dus goed bewaren, eventueel al op meerdere devices configureren.
Autosleutels heb je dagelijks nodig. Ik weet niet op je wel eens thuis PC's herinstalleerd. 95% weet de wachtwoorden niet meer van de ISP webmail of websites (meeste zijn toch in je webbrowser opgeslagenm dus waarom onthouden).

Thuis, werk wifi, guest hotspot, mobile 4g verbinding, buitenland? Vrij standaard voor "any location". Dus geen directe afhankelijkheid van firewalls, applicties of devices.

Support vanuit de leverancier.... Je wilt niet zomaar afhankelijk zijn van een 3de partij. Wie gaat er ondersteuning geven als het dan niet werkt? Wie gaan ze bellen? Wie gaat de app ondersteunen en bouwen, en wat als die leverancier er mogen in eens de stekker uit treks, of een update maakt, waardoor jij ook aanpassingen in eens moet doorvoeren in je intrastructuur? Het kan... Maar => requirements....

Je backups methodes zijn onbetrouwbaar dus niet geschikt. Daarnaast USB op een telefoon? Of zakelijke laptop.... Veel te lastig. CD.... De meeste hebben dit al niet meer, of hebben thuis geen lege CDROMs meer liggen.
Je bent al weer technische oplossingen aan het voor issues die je helemaal niet moet willen oplossen icm met je eind gebruikers. Back to the drawingboard..... Ofwel je requirements....

SMPT komt bijna door geen enkele zakelijke firewall heen. Dus limiteerd je mogelijkheid heel erg voor de communicatie. En wat als ik geen app wil installeren? Ik heb een browser.... Maar dit kan een requirement zijn... Maar dan kom ik er weer op terug. Applicatie via API koppelen aan de backend, waarin (PGP) signed berichten opgehaald / verstuurd kunnen worden. SMPT is nog steeds niet noodzakelijk of gewenst. Op deze infrastructuur kan je ook een webinterface aanbieden.
Ofwel een toekomst gerichte infrastructuur.

SMTP is juist ongeschikt en niet betrouwbaar genoeg. Toekomst gericht is http interfaces, wordt gebruikt binnen applicaties om te communiceren en juist met API/SOAP requests perfect en secure via apps te gebruiken. Al dan niet met certificaten. Gaat goed door firewalls heen en heeft veel standarden welke je kan gebruiken. Zowel voor webinterfaces (berichtenboxen) en applicaties. Juist wat voor een architect van belang is. SMTP heeft gewoon veel te veel afhankelijkheden.... Securemail is heel mooi, maar niet geschikt waarvoor jij het wilt gebruiken. Misschien leuk om met paar vrienden te communiceren, maar niet geschikt voor brede inzetbaarheid.

Je bent probleem na probleem aan het oplossing, terwijl je nog met de basis problemen bezig bent. POP3 kan in 1 keer je mailbox leeg halen vanuit Thunderbird. Daarna kan je securemail applictie er dus al niet meer mee overweg en is je bericht verloren. Bij basic issue wat je nog moet oplossen.... Maar wel heel normaal bij thuis gebruikers.

SMTP heeft vaak een limited van size... 10MB is best heel standaard. Dat betekend maar een 7,5MB attachement. Best wel een groot nadeel..... Ook lastig als je mailbox maar X MB aan Email mag hebben. Ofwel ongeschikt voor breed inzetbaarheid Volle mailboxen, firewalls, SPAM/AV => Ongeschikt.

Voor een techneut / ICT-specialist misschien,
maar de wet zegt dat gevoelige gegevens waaronder persoonsgegevens "adequaat" moeten worden verzonden.
En het best beveiligde verzendsysteem is niet automatisch ook het meest adequate verzendsysteem.

Je kunt tegenwoordig STARTTLS gebruiken om een beveiligde verbinding op te zetten met SMTP naar de mailserver.
Als je dat doet via een hardware verbinding (netwerkkabels) rechtstreeks naar een veilige/veilig ingestelde modem/router naar de smtp server van je Nederlandse internetprovider is dat deel al adequaat gedekt. Je provider stuurt het door naar de mailserver die wordt bepaald door het achtervoegsel van de gegevens emailontvanger (na het @-teken).
Ook het deel tussen de emailserver van de ontvanger en de ontvanger zelf kan veilig zijn. Webmail is het makkelijkst,
maar anders moet je wel eens even in je email client aangeven dat je een beveiligde inkomende verbinding wil.(SSL/TLS)

Blijft over: de veiligheid het stuk internet dat betrokken is bij de communicatie tussen mailservers en
de veiligheid van emails wanneer ze op de server van de emailprovider staan opgeslagen.
Om met dat laatste te beginnen: ik heb al vele jaren geen ellende gehoord die ontstaan zou zijn door gevoelige emails op een emailserver van een Nederlandse provider. (daar zijn wij meestal niet belangrijk genoeg voor)
Vergelijk briefpost. Mensen van de post kunnen in theorie brieven onderweg openmaken en lezen of verdonkeremanen
maar in de praktijk gebeurt dat heel zelden.
Iets anders is toezicht van de overheid.
Maar ook daarvan kun je geen problemen van verwachten als je geen misdaden pleegt.

Ten slotte het stuk internet dat betrokken is bij communicatie tussen mailservers.
Van oudsher is dat deel unencrypted/onveilig, maar dat is aan het veranderen.
https://www.forumstandaardisatie.nl/nieuws/nederland-zorgt-voor-veilig-e-mailverkeer
Geen idee hoe ver ze daarmee gevorderd zijn.

Maar ik kwam laatst uit bij een dienst genaamd "Secumail".
Want i.p.v. het achteraf te ontdekken is het beter iets te gebruiken dat eerst vóóraf automatisch checkt of er een beveiligde verbinding tussen mailservers is. En dat is precies wat Secumail doet, echter het is bedoeld om er een eigen emailserver naar toe te koppelen, dus het loopt niet via de emailserver van je provider.
Maar verder lijkt Secumail me voorlopig een handige, veelbelovende GDPR-complient service.
https://www.secumail.nl/

Dit is al vrij standaard bij de meeste mail providers. Meer een standaard dan een uitzondering.

Ziet er eerder uit al een leuke uit. Het doet inderdaad wat jij zegt. Het check of je securesmtp ondersteund, wat de meeste en zeker de grote providers allang doen. Dus bied eigenlijk geen toegevoegde waarde.

En als je de site leest, hebt ik toch echt mijn twijfels...
Als je inderdaad pop3 of imap onsecure gebruikt, heeft deze dienst niet heel veel toegevoegde waarde.
En de keren dat mails onderschept zijn tussen SMTP servers is ook vrij uniek. Meeste bronnen zijn nog altijd gebruikers fouten, waar deze dienst niets aan verhelpt. En nadat de Email door de SMTP servers verzonden is, dan beginnen de bronnen pas.... unsecure mailbox access, mail niet goed archiveren enz enz enz.

Ik zie de dienst ook niet echt als een goede toegevoegde waarde voor GDPR. Het bied een heel klein plusje... Maar of het nu de oplossing is heb ik mijn twijfels. Maar het is een verbetering....

Daar kan niemand op vertrouwen. (geen GDPR-proof uitspraak)
Waar zegt het NCSC dat iedereen in Nederland al een gegarandeerd end-to-end email-versleuteling heeft?
Je zou bijvoorbeeld soms ook met immigranten te maken kunnen hebben wiens kinderen hier naar school gaan
en waarvan de ouders nog de email van hun geboorteland gebruiken.

De meeste nieuwe email-clients zullen nu wel overweg kunnen met versleuteling.
Maar mailserver - mailserver verbindingen heb je geen zicht op als eenvoudig email-gebruiker.

Secumail doet zo te zien ook daar wat aan. Secumail zegt aan de GDPR-eisen te voldoen.
Dus niemand heeft hier verder nog omkijken naar. Secumail is voor dat deel helemaal zelf verantwoordelijk.
Dat vind ik een voordeel.
Hierbij denk ik dus aan kleine bedrijfjes en scholen die een eigen email server hebben en persoonsgegevens verwerken.


der Putzer

@ Tha Cleaner 17:40

Je hebt een zeer sterke focus op enkel die requirements. Maar wie maakt die, jij of je manager/directie? Neem het voorbeeld van aflevergarantie in de door jou 'verhuurde' postbus. Blijkbaar is het belangrijker dat het is 'afgeleverd' dan dat het ook gezien kan/gaat worden. Dat is typish indek-gedrag en moet geen reden zijn om een toekomstigde standaard te bepalen een uitstekend alternatief uit de markt te houden. Ik kan je vertellen dat bij grote cloudproviders die requirements soms per grote klant verschillen maar meestal vooraf worden vastgesteld aan de missie en visie van het bedrijf: dus als een klant dan andere requirements wil dan wordt geadviseerd naar een andere leverancier te gaan. Concreet: als jij als architect i.s.m. je management besluit dat secure-mail de basis wordt van communicatie, dan bepalen jullie de requirements. Zolang je die klanten een werkende oplossing kan aanbieden dan heb je geen probleem. Sterker nog als een leverancier de stekker uit een onderdeel trekt dan zijn al je klanten hun berichten kwijt, dat gebeurd niet bij mail, omdat die extern afgeleverd is. Met een berichtenbox heb je dus alle controle, maar ook 100% verantwoordelijkheid de berichten in de toekomst toegankelijk te houden.

Je kan wel stellen dat secure mail maar op kleinere schaal gebruikt moet worden om veilig persoonlijke informatie uit te wisselen, maar dat is onjuist omdat (ook kleinere) bedrijven en instellingen het nagenoeg niet ondersteunen. En hoewel klein in omvang zijn deze groot in aantal. Als je als grote aanbieder het niet ondersteund dan zullen de kleinere dit ook niet overnemen. Met gevolg dat veel vertrouwelijke communicatie meer risico loopt dan nodig is. Zelfs indien er afgetapt moet worden zorgt secure mail ervoor dat dit bepekt wordt tot een klein aantal partijen die hier bevoegd voor zijn, in tenstelling tot gewone e-mail waarbij grote groepen buitenlandse actoren alleen maar een intermediate smtp server hoeven te hacken.

Verder kan dit niet anders dan een eindeloze discussie worden, technische problemen kunnen allemaal opgelost worden in een uiteindelijk efficiëntie oplossing. Overigens: jouw secure-mail applicatie kan toch een bevestiging terugmailen naar jouw backend die bij het nalaten hiervan het bericht opnieuw verstuurd? Waarom secure mail gebruiken en geen API? Om een standaard op de kaart te zetten waar iedereen baat bij kan hebben, uiteraard.

Je hebt het jezelf moeilijk maken en het jezelf makkelijk maken.

Voorlopig is de hele GDPR nieuw. De eerste rechters moeten zich dus nog gaan uitspreken over zaken. En dan gaan we meer en meer weten hoe de uitzonderingen moeten gaan.

Dat is afwachten. Eng He?

Er is wat anders met wetten. Veel mensen met websites in Europa hebben zich teveel door Amerikaanse praktijken laten leiden. Waar, als een mevrouw in een McDonalds een beetje te hete koffie knoeit, ze alsnog miljoenen aan schadeclaim toegewezen kan krijgen. Sorry boys and girls, zo werkt dat in Europa niet. Ook niet als het inderdaad heel bloedhete koffie was en iemand dat was vergeten te zeggen.

Het Europese web staat wat dat betreft vol met totaal belachelijk "disclaimers", "gebruikers voorwaarden". Hele lappen tekst. Waar ongetwijfeld menig advocaten kantoor inmiddels al een leuke ski vakantie heeft kunnen boeken. En hopend dat die gekke dingen ook bij ons nu eindelijk eens normaal gaan worden.

Wel eens gezeur gehad met Facebook? Of Google? Het deksel op je neus en bekijk het maar? Vergeet niet, ook die zijn geen land. Ze hebben geen souvereine macht. Ze doen alsof. En ze liegen. En ze durven niet eens in het EUropees parlement te gaan staan. Of even te tussenlanden in de UK. Die daar toch wat achter hun oor krabben of die Brexit vote wel eerlijk gegaan was.

Je kan elk verhaal in je disclaimer zetten. Waar de gebruiker zich aan moet houden en zo. Ik zie er soms zelfs met boetes! Dat zijn de echte sukkels!

Met alle publiciteit en uitleg over de GDPR kan iedereen zich een beeld vormen van wat de bedoeling is van de wet. Ook bijvoorbeeld over prive data van kinderen. Enneh, niet moeilijk hoor, vul bij naam je eigen kind in, en vraag je af wat je moreel verantwoord databaheer zou vinden.

Wat voor alle (meer geciviliseerde) rechtbanken in Europa geldt, is dat als je je duidelijk "aan de geest van de wet hebt willen houden", en er dan formeel toch nog wat puntjes op de i moeten, je een aanwijzing krijgt. Maar geen boete. Of een kleintje. Voorwaardelijk. En een jaar de tijd om het op te lossen.

Je gaat toch zeker geen koffie meer serveren in je webwinkel omdat die McDonalds dame hier ook haar slag gaat slaan? Dat. Kan ze mooi schudden. Een tegoedbon misschien.

Ik ga het niet doen hoor. Maar als ik morgen met een flinke slok op tegen de auto van Mark Zuckerberg knal, denk je dan dat ik een miljoenen boete ga krijgen. Ik dacht ut niet.

Kijk niet te veel Star Wars. En dingen die hele planeten kunnen opblazen. Dat kan hier helemaal niet.

Anders zal ik zelf wel eens eerst blazen. Het zou, eerlijk gezegd niet de eerste keer zijn.

Ondertussen, hou je aan de geest van de wet. Mensen hun privacy respecteren. Kinderen zijn ook mensen. Die speciale bescherming verdienen. Dat ze niet met 12 jaar al moeten mailen om in Google vergeten te worden bijvoorbeeld. En dan nog afgewezen ook.

Daar hoef je niet eens die hele wet voor door te spitten om dat te kunnen begrijpen.

Daar valt of staat je oplossing mee. Anders kan je nooit een goede keuze maken. Functionele requirements zijn daarin van belang.

Dat maakt de business/klant in overleg met een architect.

Ik kan best bedenken dat de business dit best belangrijk vind...

Je alternatief heeft zeer grote nadelen, waardoor het eigenlijk geen alternatief is.

Dat kan.... Je kiest een product of leverancier op basis van requirements. Daaronder kan ook een missie of visie ondervallen.

De basis zo moeten zijn secure bestanden uitwissen niet ik wil secure-mail gebruiken. Je bent nu al met technische requirements bezig. Een goede architect zou vragen, waarom wil je securemail gebruiken, of wat wil je er mee bereiken.... Je zou eerst een paar stappen terug moeten gaan... Wat wil je bereiken functioneel, zonder technisch te denken....

Als het aan alle requirements voldoet kan dat zeker. Je moet alleen wel alle mogelijke problemen beschrijven, en op basis daarvan kan de klant een beslissing nemen.

Daar heb je oa een SLA en contracten voor, waar dit een requirement kan zijn. Maar het zelfde, wat een veel groter risico is... De PC van de gebruiker crashed en hij zijn bestanden kwijt, of pop3 foutje en mailbox is leeg.

Dus moet er een migratie strategie zijn? Kan ook een onderdeel van de requirements zijn (nice to have, must have).

In een kleine omgeving is het nog enigzins beheersbaar, maar de problemen zijn eigenlijk al zo lastig, dan het erg complex is om te onderhouden, zeker niet als al een klein beetje nadenkt over de issues die kan kan krijgen als je het groot gaat neer zetten.


Dit is correct. Bij een berichtenbox heb je daar wel weer controle over, al kan die ook aangevallen worden. Encrypted Email (of berichten) is hier een oplossing van.

Mee eens. Wel een goede discussie :-).

Onderschat ze niet.... Want veel kan je juist niet goed oplossing zonder juiste controle.

Deze snap ik niet helemaal. Via een API kan je inderdaad gemakkelijk terug communiceren. Ik snap alleen niet wat je hier probeert te zeggen.

Daar heeft men juist API's voor bedacht... API's zijn gedocumenteerd en je hebt controle over begin en eind punt, ideaal voor communicatie doeleinden. Daarom wordt het zoveel gebruikt, eigenlijk door alle grote partijen. Het is universeel, centraal/decentraal, gemakkelijk en te standariseren en kan gebruikt worden door 3de partijen.
Je wilt dus eigenlijk een nieuwe standaard ontwikkelen, terwijl er al een hele goede bestaat?

Net zoals waarom iedereen tegenwoordig berichtenbox gebruikt, het werkt goed, universeel en gemakkelijk. Je hebt vrij weinig afhankelijkheden voor je gebruikers.

Nouja jouw oplossing heeft evengoed grote nadelen, scroll er maar doorheen hierboven. Groot nadeel is wel dat post in allemaal aparte postvakken terecht komt, die allemaal niet in jouw beheer of jouw eigendom zijn. Ook omslachtig tegenover veilige post die na een eenmalige setup gewoon naast je normale e-mail in je postvak valt. In een ideale wereld kan een berichtenbox (of een cloudopossing in het algemeen) een prima oplossing zijn. Bijvoorbeeld iedere Nederlander die een virtueel werkblad bij KPN heeft waar zijn volledige digitale bezit gehost wordt en documenten van derden automatisch in de juiste folders verschijnen. Alleen leven we niet in die ideale wereld en wil een ontvanger dus ten alle tijden baas kunnen zijn over zijn exemplaar. End-to-end beveiliging is geschikter in een wereld waarin tussenliggende partijen niet (helemaal) vertrouwd kunnen kunnen worden. Waarom secure mail gebruiken als je alleen bestanden wil uitwisselen: compatibiliteit met het meest gebruikte (vrije) communicatiemiddel op aarde dat ook nog eens peer-to-peer is. Een POP3 probleem binnen jouw supporter customers betekend enige aanspraak op je helpdesk, maar weeg dat af tegen een falende mitigatie bij het inzichtelijk houden van de berichten in de box en je hebt elke gebruiker tegenover je staan. En wat als jouw bedrijf failliet gaat en niemand kan meer bij zijn berichten? Hoe mitigeer je dat dan? Een API is gemakkelijk terugcommuniceren maar is niet compatibel met secure mail, dus wil je afleverzekerheid met secure mail dan zou je met afleverbevestingen kunnen werken en automatishe herverzending en notificatie; geen nieuwe standaard maken maar meer een hack op een bestaande, met als doel uniforme en compatibele beveiliging voor iedereen. Misschien is dat te idealistisch bekeken. Maar toch als je dan ziet hoe implementaties van berichtenboxen in de praktijk werken dan valt het gewoon tegen, neem Zivver als voorbeeld: een dozijn wazige domeinnamen die ge-whitelist moeten worden, verplichting opgeladen gsm en nog werkt de dienst niet op een populaire browser op een populair platform en houd het systeem geen rekening met potentiele beveiligingsmaatregelen waardoor er paginalange codes overgetikt moeten worden. Zeer omslachtig en gebruikersonvriendelijk. Daar gaat je any place any device al.

De vraag is hoe het nu verder moet. Steeds meer bedrijfjes komen met eigen berichtenboxen en veroorzaken een ongecontroleerde wildgroei ervan. Sommige implementaties zijn nog enigszins overdacht, maar andere zijn amateuristisch en bedroevelijk. Mag je onder de AVG zoiets als klant weigeren en een alternatief eisen? In princiepe vereist de AVG adequate beveiliging en TLS tussen SMTP servers onderling en POP3/IMAP zou de lading moeten dekken waardoor een berichtenbox geen argument kan zijn om aan de AVG te voldoen. Probleem met een berichtenbox: als je je ervoor aanmeld/meedoet, je tot in de lengte der dagen zelf verantwoordelijk blijft voor deze extra accounts (o.a. regelmatig nieuwe passwords instellen).

Je kunt natuurlijk een plaat voor je hoofd houden maar ik denk dat e-mail als communicatie middel zijn langste tijd
toch al gehad heeft, dus je er aan vastklampen heeft dan niet veel zin meer. Als eenmaal de trend naar beneden is
ingezet dan wordt de helling steeds steiler. De meeste mensen van vandaag WETEN al niet eens mer wat TELEX
vroeger was, terwijl dit toch lang het enige geaccepteerde middel voor communicatie die juridisch hard te maken was.
FAX was een volgende stap. En wie stuurt er nu nog een FAX? Wellicht weten veel mensen nog wel wat het is maar
zijn al jaren niet meer in de buurt van een faxapparaat geweest. Terwijl dit 10 jaar geleden een heel populair communicatie
middel was.
Zo kan het zomaar zijn dat e-mail er over 5-10 jaar ook niet meer is. Ja je kunt nog wel mailen met een nerd die je
kent, net zoals je nog UUCP kunt doen met zo iemand, maar met "normale mensen" en zeker met bedrijven valt er
dan niet meer te mailen. Mag ik uw mail adres? Nee dat hebben we niet meer.

In de eerste plaats moet je bezien of het wel echt nodig is om persoonsgegevens in je email te vermelden.
Kun je zonder problemen het noemen van persoonsgegevens vermijden zonder dat er verwarring optreedt,
dan kun je in veel gevallen gewoon bestaande email blijven gebruiken.
En anders kun je nog denken aan gewone post, bijv. persoonlijke medische zaken worden vaak per post verstuurd.
Heb je wel te maken met portokosten.

De combinatie e-mail voor oppervlakkige communicatie en aangetekende post voor vertrouwelijke documenten is natuurlijk ook een optie MAAR de eerste gedachte bij Nederlanders is dan: kost geld. En toch sluit men abonnementen af voor berichtenboxen. Het gevaar schuilt dat berichtenboxen e-mail verdringen en als er dan een moment van besef komt dat die berichtenboxen maar lastig en niet-uniform zijn, dat het enige alternatief is om via Facebook te gaan communiceren.

En dan hebben we met z'n allen een vet probleem.

Aangetekend mailen bestaat ook, en is goedkoper dan een postzegel.

De overheid heeft al een uniforme berichtenbox en die zou je kunnen gebruiken voor alle belangrijke persoonlijke
vertrouwelijke communicatie tussen bedrijven en burgers. Burgers hoeven dan maar 1 box aan te houden.
Wel moet er nog echte integratie met de systemen van de bedrijven komen want een bericht in de overheid box
dat er een nieuw bericht van je zorgverzekeraar is wat je daar dan weer uit een andere box moet halen dat schiet
natuurlijk niet op. Het is echter wel een stap in de juiste richting.
(met een extra encryptielaag op de huidige e-mail ga je nooit het vereiste beveiligingsnivo halen als het gebruikt
moet kunnen worden door iedereen)

Hoi Hans,

Je denkt er over na, dat is al half gewonnen.

Email is al 50 jaar zo lek als een mandje. Het is al beter als je het via een eigen provider doet, en niet via hotmail of gmail. Want dan zit dat kind zelf al in een database voordat het tiepen en surfen heeft geleerd. En gaat al opgroeien met "verbeterde gebruikers ervaringen". En wow, eerste dag facebook en magisch hoe facebook al wist met wie dat kind dolgraag bevriend wou zijn. Wat een gebruikersgemak.

Daarnaast zijn ouders voogd en zo. Dus als je ouders eerst vraagt, mag ik het open emailen, dan kun jij er al minder last van krijgen. Kinderen vallen onder ouders. En aders gewoon printen, envelop en postzegel erop. Want briefgeheim is nog altijd het veiligst. Voor teruggestuurde handtekeningen trouwens ook.

Gewoon even vragen. Doen alle websites tegenwoordig ook (proest, beroerte-rolling en flip!) Maar wel zo netjes. Hoe mag ik mijn verhaaltje afleveren. Rest is aan de ouders. Het is hùn kind.

E-mail is niet lek als een mandje. E-mail is niet versleuteld. En daar is een oplossing voor die werkt met sleutels welke je gewoon kan mailen. Het enige wat je extra hoeft te doen is de vingerafdruk controleren en die kun je weer op je visitekaartjes zetten bv. Beveiligingniveau haal je dus wel, de vingerafdruk checken is 2 factor authenticatie.

Maar ook zonder die extra laag heb je in Nederland TLS over bijna alle verbindingen, TLS is niet geweldig maar wel adquaat als het niet om zeer gevoelige gegeven gaat. Zorg dat je niet meer gegevens verstuurd dan nodig en dan beperk je het risico. Een AVG compatible oplossing met garanties kun je vergeten: met voldoende geweld is elke kluis kapot te krijgen. Het idee van de AVG is een normale kluis waar zo min mogelijk in zit dat gestolen kan worden.

Er is nog geen wet die iedereen in hetzelfde mailsysteem dwingt.

Er is ook nog geen wet die mensen verplicht email te gebruiken.

Email is een oud en open protocol. Afzenders of IP's zijn relatief eenvoudig te spoofen. Er zijn wel veel verbeteringen. Maar die rammelen allemaal. Toch minstens wel een beetje. Het blijft post in een transparante envelop. In meerdere of mindere mate. Het trieste is dat om de schijn van meer veiligheid te bieden voor electronische post, dat nu in handen is van de grootste afluistercentrales ter wereld. Zijn er nog hotmail gebruikers bijvoorbeeld die niet gewend zijn om regelmatig in hun spam mapje te kijken? Omdat bijna alles daar inmiddels in terecht komt? Dat geeft enkel maar aan hoe oncontroleerbaar email is. Het is een oud protocol. Met alle risico's van dien.

Er is blijkbaar wel een mindset om mensen te dwingen vendor-locked portals te gebruiken waar een stapel accounts voor nodig is waardoor men er weer een berg zwakke wachtwoorden bij krijgt. Kun je misschien beter een 40 jaar oud protocol gebruiken met een moderne & solide beveiligingslaag. Probeer eens een ondertekende e-mail te spoofen. Dat is tot op heden onmogelijk. Afsluisteren door entiteiten met onuitputtelijke recources kun je simpelweg nergens mee voorkomen, maar door geen altijd-lekke-webportals voor communicatie te gebruiken kun je wel voorkomen dat elke crimineel met een beetje computerkennis bij je post kan.

Overigens dat Hotmail en Gmail met jouw post knoeien heeft niets met e-mail te maken maar alles met Microsoft en Google. Het is jouw KEUZE om hen in jouw post te laten wroeten.

Hoe dan ook, een eventuele nieuwe standaard voor berichtenverkeer, die e-mail zou moeten vervangen, zal vrijwel volledige in handen zijn van een commerciële datareus. Dat moet je niet willen, alle macht bij 1 bedrijf neerleggen.

Toch zie je het steeds vaker:
"Wij willen graag nu uw emailadres hebben anders kunt u de volgende keer niet uw overzicht/nota ontvangen."
Mijn opa vind dat prima. ;)