Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 59 reacties
Submitter: _David_

Google begint met het invoeren van een visuele waarschuwing wanneer Gmail-gebruikers e-mail versturen of ontvangen naar of van een e-maildienst die geen tls-encryptie ondersteunt. Ook worden ontvangen e-mails die niet door de authenticatie komen voorzien van een vraagteken.

De waarschuwing die getoond wordt als e-mails niet voorzien kunnen worden van tls-encryptie, bestaat uit een afbeelding van een rood slotje dat niet gesloten is. Door hierop te klikken is een korte uitleg en een waarschuwing te zien waarin staat dat het betreffende adres geen encryptie ondersteunt.

Ook gaat Google een icoon met rood vraagteken tonen in plaats van een afbeelding van een gebruiker of logo van een bedrijf, bij e-mails die niet door het authenticatie-proces van Gmail komen. Volgens Google worden de waarschuwingen vanaf deze week getoond in de webversie van Gmail. Of en wanneer de waarschuwingen in de diverse Gmail-apps terechtkomen is niet duidelijk.

Google benadrukt dat e-mails zonder encryptie niet per definitie onveilig zijn, maar gebruikers zouden bij dergelijke e-mails beter op moeten letten en niet zomaar op links moeten klikken. Google maakte de komst van de waarschuwing in november 2015 al bekend, maar gaf toen nog niet de exacte details over hoe dit zou werken en wanneer het ingevoerd zou worden.

Moderatie-faq Wijzig weergave

Reacties (59)

Erg fijn. Alleen gebruik ik de browser versie van gmail niet zo vaak. Iemand enig idee in hoeverre deze waarschuwing zichtbaar word in mn mail programma. Of weet iemand of er een mail programma van Google aan zit te komen?
Ik heb zo'n flauw vermoeden dat de functionaliteit niet in je mailclient zichtbaar zal zijn, maar uitsluitend in Google Mail zelf. Inhakend op je andere vraag: Google zal er niet bij gebaat zijn een desktop applicatie te ontwikkelen. Een desktop applicatie houdt automatisch in dat het verdienmodel van Google (het tonen van relevante advertenties) niet mogelijk is en bovendien is het fenomeen 'desktop applicatie' ook op z'n retour. Gelukkig maar zelfs.
Jammer van dat laatst "gelukkig maar zelfs". Er zijn genoeg mensen die dankbaar gebruik maken van een mail client om specifieke redenen die waarschijnlijk niet toepasbaar zijn op jan met de pet. Een mail client heeft nog altijd de voorkeur als je veel verschillende mail adressen tegelijk gesegregeerd wilt beheren.

Daarnaast leg je een niet veel zeggende assumptie voor op waarom Google mail clients zou weren.
  • Ten eerste: doet Google dat niet. Gmail integratie met Thunderbird werkt bijvoorbeeld perfect.
  • Ten tweede: als Google een mail client zou ontwikkelen, zou het juist voor Google winstgevender kunnen zijn, dan via webmail (want eventueel geen adblocking applicaties -- even slimmeriken uitgezonderd die het blokkeren niet vanaf de router o.i.d. doen).
  • Ten derde: de eerste priority voor Google is dat je überhaupt Gmail gebruikt, en niet een andere mail provider. De hoogste prioriteit voor Google is om je data te krijgen. Die data reserveren ze echt niet alleen voor Gmail's webmail omgeving hoor, maar voor alle Google ads waar dan ook.
Edit: weet trouwens ook niet waarom je een +2 (informatief) beoordeling hebt gekregen, aangezien de inhoud niet informatie is, maar een gok + mening bevat.

[Reactie gewijzigd door PostHEX op 9 februari 2016 22:27]

Het is wel degelijk mogelijk om meerdere emailadressen te beheren vanuit gmail. Je kunt meerdere accounts toevoegen of, als je helemaal lui bent, alle mail naar 1 account forwarden en die adressen ook toevoegen als adressen waar vandaan dat ene account mag sturen. Op die fiets kun je alles gesplitst houden, maar toch bij elkaar
Laatst dat ik had gekeken (lange tijd terug) kon ik het nooit zo overzichtelijk krijgen als Thunderbird. Ik heb dan ook hele specifieke eisen aan m'n layout, waar ik zelfs met standaard Thunderbird niet aan kom, maar met verschillende addons daar bovenop.
Klopt. Maar het "toeval" wil dat dit erg makkelijk gaat met een ander Gmail adres, voor andere adressen is het toch een stukje irritanter en moeilijker schakelen.
Een mail client heeft nog altijd de voorkeur als je veel verschillende mail adressen tegelijk gesegregeerd wilt beheren.
Ik beheer momenteel ruim 20 verschillende mailaccounts in Google Mail. Dat red ik in Outlook of Thunderbird niet zonder mijn systeem plat te leggen.
Daarnaast leg je een niet veel zeggende assumptie voor op waarom Google mail clients zou weren.
Ik heb nergens in het verhaal de stelling geplaatst dat Google Mailclients zou weren. Stick to the facts mate!
Ten eerste: doet Google dat niet. Gmail integratie met Thunderbird werkt bijvoorbeeld perfect.
Ik heb ook niet iets dergelijks gezegd.
Ten tweede: als Google een mail client zou ontwikkelen, zou het juist voor Google winstgevender kunnen zijn, dan via webmail (want eventueel geen adblocking applicaties -- even slimmeriken uitgezonderd die het blokkeren niet vanaf de router o.i.d. doen).
Dat zie je verkeerd ben ik bang. Google heeft er absoluut geen belang bij om een mailapplicatie voor de desktop te ontwikkelen. Googles verdienmodel komt uitsluitend tot z'n recht als de gebruiker het internet op gaat, de Google zoekmachine of één van de andere producten van Google gebruikt. Een desktopapplicatie - waarbij je de gebruiker juist zoveel mogelijk op de desktop houdt - past daar niet bij.

Die desktopapplicatie gaat er vanuit Google hoe dan ook niet komen. Het bewijs? Gmail bestaat nu 12 jaar en trust me... als jouw plan echt zo'n goed plan was, dan had Google het wel ontwikkeld. Daarnaast zie je dat Google juist haar eigen desktopapplicaties aan het uitfaseren is. Denk aan Google Talk bijvoorbeeld, ook intussen een webapp geworden. En last but not least zie je ook de stap die Google zelf gemaakt heeft met Chrome OS. Weg van de Windows Desktop en dus ook weg van de Desktop applicaties.
[...]

Ik beheer momenteel ruim 20 verschillende mailaccounts in Google Mail. Dat red ik in Outlook of Thunderbird niet zonder mijn systeem plat te leggen.
Dan moet je wel super-duper low-end systeem draaien. Heb in totaal ~38 mail adressen in Thunderbird, en ook een 500¤ laptop uit 2011 met AMD Fusion E-450 draait daar prima.

[...]
Ik heb nergens in het verhaal de stelling geplaatst dat Google Mailclients zou weren. Stick to the facts mate!
Touché.
[...]

Dat zie je verkeerd ben ik bang. Google heeft er absoluut geen belang bij om een mailapplicatie voor de desktop te ontwikkelen. Googles verdienmodel komt uitsluitend tot z'n recht als de gebruiker het internet op gaat, de Google zoekmachine of één van de andere producten van Google gebruikt. Een desktopapplicatie - waarbij je de gebruiker juist zoveel mogelijk op de desktop houdt - past daar niet bij.

Die desktopapplicatie gaat er vanuit Google hoe dan ook niet komen. Het bewijs? Gmail bestaat nu 12 jaar en trust me... als jouw plan echt zo'n goed plan was, dan had Google het wel ontwikkeld. Daarnaast zie je dat Google juist haar eigen desktopapplicaties aan het uitfaseren is. Denk aan Google Talk bijvoorbeeld, ook intussen een webapp geworden. En last but not least zie je ook de stap die Google zelf gemaakt heeft met Chrome OS. Weg van de Windows Desktop en dus ook weg van de Desktop applicaties.
https://play.google.com/s...m.google.android.gm&hl=nl

P.S. voor de duidelijkheid: de stelling voor een door Google ontwikkelde mail client voor Windows was hypothetisch. Heb niet bepaald een interesse naar een dergelijke applicatie. :)

[Reactie gewijzigd door PostHEX op 10 februari 2016 22:04]

Dan moet je wel super-duper low-end systeem draaien. Heb in totaal ~38 mail adressen in Thunderbird, en ook een 500¤ laptop uit 2011 met AMD Fusion E-450 draait daar prima.
Dat valt best mee. Mijn pc was ook van 2011, met een goede Intel Processor en 4GB geheugen en meerdere accounts. Maar ik was gewoon niet tevreden over de performance. Wat je ziet is dat - zeker - Outlook het gewoon niet meer trekt zodra de PST boven een paar gig uitkomt. Thunderbird zal het ongetwijfeld beter doen. En dan heb ik het dus nog niet gehad over die ene keer dat de PST corrupt was. Bij Google Apps heb ik dat gedonder niet meer.
https://play.google.com/s...m.google.android.gm&hl=nl
P.S. voor de duidelijkheid: de stelling voor een door Google ontwikkelde mail client voor Windows was hypothetisch. Heb niet bepaald een interesse naar een dergelijke applicatie. :)
Ik heb het de hele tijd niets anders gehad dan over een desktopapplicatie. Waar die Android applicatie dan ineens vandaan komt is me niet geheel duidelijk. Het is namelijk volstrekt logisch dat Google wel een Android applicatie voor mail heeft, aangezien het platform en het gebruik ervan beduidend anders is dan dat van een PC-gebruiker.
Niets houdt Google iets tegen om een webinterface voor mobiel te bouwen (want men pakt de GUI van de Gmail app, en maakt er webmail van). Dezelfde argumenten die je voor een desktop omgeving bied, zijn ook toepasbaar op een omgeving met kleiner scherm. Dat gezegd is de werkelijke reden waarom Google Gmail voor de PC als webmail implementeert, dat het makkelijker te beheren is voor Google, als dat het veel makkelijker is om crossplatform te maken. Het gebruik van Gmail in de browser is never nooit een aanstichter voor mensen om Google zoekmachine en/of Chrome te gebruiken. Zoals eerder gezegd: Google vindt het alleen belangrijk of je linksom of rechtsom Gmail gebruikt, zolang ze maar jouw data kunnen inzien en dat kunnen koppelen aan hun netwerk. Hoe je Gmail gebruikt is voor Google niet van belang, alleen dat de ervaring zo gemakkelijk mogelijk is.
Waarom gelukkig? Ik heb zelf de voorkeur voor desktop apps waar mogelijk omdat de bediening, interface en vooral snelheid vaak veel beter zijn dan webapps. En grootste plus natuurlijk offline beschikbaarheid.

Natuurlijk hebben ook WebApps voordelen zoals platform onafhankelijkheid (sucks equally well on all platforms geld dan helaas vaak wel) en update gemak aan de leverancier/beheerder kant.
Bediening, interface en snelheid beter? Dat ligt toch echt aan de app, en niet of het een web-app is. Dat is toch zó achterhaald. Het woordje 'vaak' kan kloppen, maar de uitzonderingen zijn er.

Bekijk bijv. maar eens een webapp als Inbox nu. En ook offline beschikbaar.

Ik heb de voorkeur voor de beste app waar mogelijk, en regelmatig is dat een webapp.
Dat ligt toch echt niet alleen aan de app, ook aan de onderliggende techniek. Op het web heb je doorgaans veel meer lag in de interactiviteit. Dat is terug te brengen naar het feit dat Javascript single-threaded is, en sowieso vele malen langzamer dan een gecompileerd C/C++ desktop programma.
Lag op het web? Dat heb ik zelfs niet op de goedkoopste telefoon met een zelf gemaakte web-app. Diezelfde lag heb je als een native-app een applicatie aanroept. Draait je UI gewoon clientside in de browser, is er echt geen input lag. En sowieso niet 'vele malen', het verschil is vaak nog maar minimaal. Bijv: https://blog.mozilla.org/...n-dalvik-vs-spidermonkey/

En deze, om JS erbij te zien:
http://ffp4g1ylyit3jdyti1...s-ASM-vs-Native-vs-JS.png

[Reactie gewijzigd door RielN op 10 februari 2016 15:49]

Waarom gelukkig? Ik heb zelf de voorkeur voor desktop apps waar mogelijk omdat de bediening, interface en vooral snelheid vaak veel beter zijn dan webapps. En grootste plus natuurlijk offline beschikbaarheid.
Zaken als bediening en interface zijn natuurlijk betrekkelijk. Ik vind bijvoorbeeld Outlook ook fijner werken als Thunderbird, maar er zullen hele volksstammen zijn die daar anders over denken. En ik vind Outlook.com er ook mooier uitzien dan Gmail, maar dat is niet relevant.

Waar het mij om gaat is dat ik toegang heb tot mijn e-mail, met de hoogst mogelijke beschikbaarheid en onafhankelijk van locatie of device. Online diensten scoren hier natuurlijk beter in dan jouw lokale desktop applicatie. Natuurlijk kun je die lokale desktop applicatie aan een IMAP account koppelen, maar het blijft altijd een beetje behelpen. Helemaal vervelend wordt het als je een corrupt PST bestand hebt, je e-mail mist, je pc crasht of vastloopt. Dan ben je pas echt de Sjaak.

De grootste plus die je noemt is de offline beschikbaarheid. Maar dat is allang geen argument meer. Google Mail kun je ook gewoon offline gebruiken. En mag ik daar tegenover zetten dat als je pc gecrasht is jij op dat moment niets aan die offline beschikbaarheid hebt, terwijl ik gewoon inlog en het belangrijke mailtje direct kan ophoesten?
Natuurlijk hebben ook WebApps voordelen zoals platform onafhankelijkheid (sucks equally well on all platforms geld dan helaas vaak wel) en update gemak aan de leverancier/beheerder kant.
De overgang van Outlook (op Windows) naar Google Mail heeft mij heel veel buikpijn bezorgd, maar ik ben nog elke dag blij met de keuze die ik gemaakt heb. Ik ben er van overtuigd dat 'de desktopapplicatie' zoals jij 'm vandaag de dag gebruikt op z'n retour is.
Ik ben benieuwd wat je redenatie is dat bij een desktopapp van Google het niet meer mogelijk zou zijn om relevante advertenties te tonen? Die snap ik ff niet. Zeker niet in de context "Applicatie van Google zelf".
Ah, je hebt gelijk. Het was iets te kort door de bocht. Natuurlijk kan Google in een desktop applicatie ook advertenties tonen.
Google zal er niet bij gebaat zijn een desktop applicatie te ontwikkelen. Een desktop applicatie houdt automatisch in dat het verdienmodel van Google (het tonen van relevante advertenties) niet mogelijk is
Hoe kom je daar nou bij?
Als ze zelf een desktop applicatie ontwikkelen, dan kunnen ze er JUIST reclame in stoppen, ze bepalen helemaal zelf hoe de applicatie werkt en het zou JUIST een optie voor hun zijn om geen last meer te hebben van add blockers in browsers.
Volgens mij heb ik dit elders al uitgelegd. Dit komt nu een beetje als mosterd na de maaltijd.
Je kunt al lang kijken in desktop-email programma's naar de headers. Daarin staat of het via een SSL/TLS channel ging of niet.

Dat is dan ook wat nu gebeurd. De header wordt gelezen en een icoontje verschijnt wel of niet.

Overigens slecht nieuws voor KPN, Nederland's trotst die anno 2016 nog steeds nul-komma-nul encryptie toepast op inter-SMTP verkeer. Alle email van en naar KPN, inclusief dochters (muv XS4ALL) en schrikbarend inclusief alle zakelijke relays zijn lekker onversleuteld over het internet vrij voor iedereen om mee te lezen. |:(

KPN en klanten van KPN krijgen nu dus een rood open slotje.
wat ik me afvraag is hoe je zeker weet dat de HELE verbinding TLS is.
Het ophalen van de mail (ik bij mijn provider) hoeft natuurlijk geen TLS te zijn wanneer er tussen de verstuurder (google) en mijn provider wel TLS gebruikt wordt.

Kortom: Google kan niet garanderen dat mijn provider ook tussen zichzelf en de ontvanger versleuteling toepast.
Dus zelfs zonder rood slotje kan het zijn dat je email (een stukje) plain tekst over het interwebs vliegt
Tussen de provider en ontvanger moet wel versleuteld zijn, anders krijg je dus dat rode slotje. Intern verkeer, bijvoorbeeld relay of injectie van scanner naar mailque, daar kan je inderdaad niet van zien of dat encrypt gebeurt of niet.

Vandaar dat je ook het liefst de e-mails gewoon lekker encrypt voordat je ze verstuurd.
Google kan niet garanderen dat mijn provider ook tussen zichzelf en de ontvanger versleuteling toepast.

Geheel waar, doch convenanten tussen providers en RFC 'SHOULD's stellen dat er geen onversleutelde client-server meer mag plaatsvinden. Meeste providers op aarde houden zich daar doorgaans aan (muv KPN 8)7 ).

Meeste providers verbreken simpelweg de verbinding als de client onversleuteld probeert te verbinden over het internet (intranet is een ander verhaal).

Dus het rood slotje is meer een 'ik weet zeker dat het fout gaat' dan garantie dat het niet fout zal gaan. Wil je 100% zeker encryptie moet je SMIME of PGP gebruiken.
Kortom: Google kan niet garanderen dat mijn provider ook tussen zichzelf en de ontvanger versleuteling toepast.
Dat klopt, en dat garanderen ze ook niet, ze geven aan of de verbinding tussen Google en de email-service aan de andere kant.

If you receive a message from, or are about to send a message to, someone whose email service doesn’t support TLS encryption, you’ll see a broken lock icon in the message.
Kortom: Google kan niet garanderen dat mijn provider ook tussen zichzelf en de ontvanger versleuteling toepast.
Dat klopt, maar ze kunnen het wel aangeven als het zeker niet goed is. Dat zullen sommige schijnveiligheid noemen maar ik vind het vooruitgang.
De huisarts kan ook niet bewijzen dat je helemaal gezond bent, hij kan alleen bewijzen dat er wel iets mis is.
Als een paar grote jongens (zoals KPN) zich nu beginnen te schamen en eindelijk een keer TLS doen dan zou dat een enorme vooruitgang zijn voor heel veel mensen.

Laat "goed" niet de vijand zijn van "perfect". Ergens is de oplossing van Google nogal kneuterig omdat er inderdaad maar naar één, onvolledig, aspect gekeken wordt. Toch denk ik dat het al veel goeds gaat doen. Het huidige niveau is zo laag dat alles een vooruitgang is. Ik ben blij dat ze beginnen het probleem op te lossen, ook al is de oplossing verre van volledig of afdoende, je moet ergnes beginnen.
Je kunt al lang kijken in desktop-email programma's naar de headers. Daarin staat of het via een SSL/TLS channel ging of niet.
Aan de headers kun je inderdaad zien of een mail via SSL/TLS binnen is gekomen, maar Gmail gaat het ook tonen bij het verzenden van de mail, en dan zijn er nog geen headers.
Goed punt. Ik denk dat het dan de database van het eigen safer email project gebruikt.
Bij mails van kpn klanten krijg ik al heel lang deze melding "Gmail couldn't verify that this message was sent by kpnmail.nl." in een opvallende gele balk.

Maar dat wordt nu dus dat slotje?
Nee, die melding betekent enkel dat KPN zijn email smtp servers of relays niet op orde heeft. GMail kan daardoor niet goed controleren of de email die bijvoorbeeld afkomstig is van @planet.nl ook echt verzonden is via email servers van die domein-eigenaar.

Bijvoorbeeld omdat DKIM en/of SPF niet goed geconfigureerd is.
Als je gevoelige berichten verstuurd moet je eigenlijk helemaal Gmail niet gebruiken. Google kijkt namelijk sowieso mee. Google heeft met heel veel zaken niets te maken die mensen in hun mail en kalender zetten alleen daar hoor je Google niet over.
Dit geldt voor letterlijk iedere dienst die e-mail aanbiedt, zowel gratis als betaald. Toch moet je een keuze maken bij welke dienst jij je het meest gemakkelijk voelt (of alles zelf aanschaffen/installeren/hosten).
Er is iets dat Google Apps heet, waarvoor totaal andere voorwaarden gelden :)
Nou, die voorwaarden van Google Apps zijn anders ook behoorlijk niet inzichtelijk. Een feest van omhullend taalgebruik en grote vaagheid.
Er is erg veel kennis nodig van de juridische kant en van de technologie om te zien waar de gaten zitten. Ik denk dat menig instelling in Nederland daar veel te makkelijk overheen gestapt is.
Vertel, wat is er onduidelijk en waar zitten de gaten volgens jou? Of is dit meer FUD?

De contracten zijn helder, en toch behoorlijk grote partijen kiezen voor Google tegenwoordig. Er zitten ook geen 'rare gaten' in. Het enige wat discutabel is is het feit dat het US servers zijn, omdat wetgeving en transparantie ontbreekt. De contracten bij Google zelf zijn solide.

Ik denk juist dat er nu goede afwegingen worden gemaakt.
In essentie kun je voorwaarden voor Cloud dienstverlening heel kort opschrijven.

"Wij zullen uw data nooit, op geen enkele wijze, lezen of gebruiken. Tenzij het moet voor de overheid in het land waar u actief bent. Tenzij het nodig is om de service aan u te kunnen blijven aanbieden, vanuit technische motivatie. In alle andere gevallen treden wij eerst met u in overleg. Wij zullen deze voorwaarden alleen in overleg met u wijzigen, want uw bedrijfsbelang is net zo belangrijk als het onze."

Dit is zo'n beetje de kern. Nu de praktijk van Google. Extreem complexe formuleringen die wel openingen laten.
Veel mensen laten zich zand in de ogen strooien wanneer Google zegt geen data te verkopen. Dat hoeft Google ook helemaal niet te doen, zou ook tamelijk dom van ze zijn. Waar Google minder helder over is of ze je data gebruiken om zelf gerichte advertising/ profiling etc te doen. Dan verkopen ze je data niet, maar bieden aan Calvé aan 100.000 views te realiseren aan kinderen in de pindakaas etende leeftijd.

Zelf geef je het al aan: US servers, transparantie en wetgeving... ontbreekt. Ik vind dat geen klein punt, zeker als je meeneemt dat bijvoorbeeld universiteiten nogal strak beheerde data centers hadden en gevoelige onderzoeksdata.

Ik heb zelf laatst de voorwaarden van Google Apps doorgelezen omdat mijn dochter naar een middelbare school gaat waar ze het gebruiken. Ook omdat ik er professioneel interesse in heb. Mijn conclusie: het is niet inzichtelijk dat het wel deugt, de gezonde zakelijke wijsheid is dan: het deugt niet.

Het is voor veel grote partijen verleidelijk om voor Google te kiezen. Van de eigen IT-afdeling wordt men vaak niet blij. Er kan een kostenbesparing worden gerealiseerd. En de externe dienstverlening staat niet ter discussie terwijl dat bij de interne afdeling wel voortdurend het geval is. Anders geformuleerd: als Google het niet levert dan heb je pech, terwijl de interne afdeling wel op van alles wordt aangesproken.
Ik begrijp je samenhang niet helemaal.

Google gebruikt die data niet voor gerichte profilering. Zoals je kunt lezen:
"De services van Google Apps for Education verzamelen of gebruiken geen gegevens van leerlingen voor advertentiedoeleinden. Ook worden geen advertentieprofielen gemaakt."

Zoals veel e-mailproviders maken we in Gmail gebruik van scannen om onze klanten veilig te houden en hun productervaring te verbeteren. In Gmail voor Google Apps for Education bieden we virus- en spamdetectie, spellingcontrole, relevante zoekresultaten en functies als Postvak Prioriteit en automatische detectie van agenda-afspraken. Alle binnenkomende e-mails worden volledig automatisch gescand om productfuncties te kunnen bieden. We scannen GEEN e-mails van Google Apps for Education voor advertentiedoeleinden.

Daarnaast verzamelen of gebruiken we geen informatie die is opgeslagen in de Google Drive of Documenten (of Spreadsheets, Presentaties, Tekeningen, Formulieren) van gebruikers van Google Apps for Education voor advertentiedoeleinden.

Lijkt mij helder.

Daarnaast heeft Google mbt Patriot Act / Safe Harbour de verplichte modelcotnracten voor hun apps-pakket al een poos (werken op Amerikaanse servers was voorheen illegaal ...)

Waarom deugt het niet, wat mis je?

Over 'als google het niet levert heb je pech', dat valt best mee. Google werkt met partners, zoals ons (disclaimer!), en wij helpen de gaten te vullen. Google heeft mooie API's en koppelmogelijkheden. De interne afdeling ondersteunen wij hierbij. Die worden overigens vaak wel blij hoor, zij zijn met regelmaat de partij de de knoop doorhakt.

het is niet alleen kostenbesparing, of alleen privacy. het is een compleet plaatje, waarbij alle voors- en tegens afgewogen moeten worden. Maar Google levert een veilige, goede dienst, die je intern écht niet krijgt nagemaakt in veiligheid en betrouwbaarheid, en beheersbaarheid.
Ik vermoed - maar dat is een aanname - dat je citeert uit de veelgestelde vragenpagina. Die is door een heel andere afdeling geschreven dan de juridische tekst.
Ik heb nu even niet de tijd om daar inhoudelijk in te duiken.
Wil je suggereren dat de vragenpagina iets anders zegt, dan de juridische overeenkomst?
Aluhoedje nodig? Wat jij roept en beweert kun je ook in één zin vermelden in combinatie met een Outlook-account, Yahoo-account of om het even elke andere mail/organiser dienst die z'n servers en services aanbiedt.

Er zijn betaalde diensten te over die je voor een vast bedrag per maand een totale versleuteling op je email en agenda bieden. Maar als het er op aan komt, dat worden ook die door de opsporings- en veiligheidsdiensten net zo open gezet als dat zij wenselijk achten.
Er is wel een heel groot verschil tussen onveilige communicatie en wettelijke bevoegdheden om mee te kijken.
Voor Google Apps geldt dat niet.

Bovendien gaat bij Gmail deze data niet naar derden.
Persoonlijk zie ik geen link tussen "een email niet veilig zijn" (niet over TLS verstuurd) of een e-mail waarin spam staat. Een spammer kan toch ook zijn emails over TLS versturen? (laatste stukje)

Dit is hetzelfde als dat veel mensen denken dat als je een slotje ziet in je adresbalk, dat de website per definitie veilig en "oplichter-proof" is (niet kijkende naar de naam in het SSL certificaat).
Het gaat erom, dat de mail niet onderschept kan worden in het verkeer tussen mailservers. Wanneer er door de ontvangende mailserver (poortje 25) geen TLS wordt afgedwongen en/of wordt ondersteund, kan er geen garantie worden geboden dat de mail versleuteld verstuurd wordt. Op die manier is de mail voor iedereen te onderscheppen die in het pad zit: elke ISP, elke NIC/switch/hub.
Testen of je mailserver OK is doe je op http://www.checktls.com 😉

[Reactie gewijzigd door Hans van Eijsden op 9 februari 2016 21:30]

In theorie wel maar in praktijk doen de meeste spambots dat niet. Als mailserver TLS gaan eisen dan zullen de spammers zich wel aanpassen maar nu doen ze het nog niet.

Het helpt wel goed tegen fishers die namens een bank ofzo mailen.

[Reactie gewijzigd door CAPSLOCK2000 op 9 februari 2016 23:39]

Het zegt wel of er uberhaupt over veiligheid wordt nagedacht bij een bedrijf. Ieder middelgroot bedrijf dat geen TLS heeft, heeft ook geen effectief beveiligingsbeleid. Dat is dus ook KPN idd (maar dat wisten we al, omdat veel van de ING phishing mails gewoon niet eens in hun spamfilters komen omdat ze te lui zijn om de DMARC check aan te zetten).
Je eigen mailserver veilig maken doe je met de instructies op https://cipherli.st - je ziet er o.a. de instructies voor Postfix en Exim. Op die manier zorg je ervoor dat je mailserver TLS-encryptie ondersteunt.
Dit werkt uitstekend samen met bijvoorbeeld de ISPmail guide voor Debian Jessie op https://workaround.org/ispmail/jessie en met http://www.checktls.com test je je complete setup.

[Reactie gewijzigd door Hans van Eijsden op 9 februari 2016 21:31]

Het belangrijkste is dat de gebruiker zich bewust wordt van of iets wel of niet veilig is.

Opportunistic TLS zit tegenwoordig standaard in de MTA's, beetje apart dat men het dus nog niet massaal aan heeft staan. Zichtbaarheid van techniek zal dus langzaam de markt in beweging brengen. Zie ook https://www.google.com/transparencyreport/saferemail/

Ik weet niet of mensen goed gekeken hebben, maar er staat bij de 2e afbeelding (in bron) een mooi rood vraagteken. Vanuit de markt (professionele verzenders) zal er dus vanuit de marketing afdelingen de vraag komen waarom deze daar staat. Met als gevolg dat er in vanuit de marketing een driver ontstaat richting de techniek.

In lijn hiervan is o.a. Google is bezig met het Authenticated Received Chain (ARC) project. Zodra de specs hiervan live gaan kan iedereen eigenlijk met authenticatie aan de slag en kun je dus de originele authenticatie bewaren. Vermoedelijk zal Google dan ook de authenticatie gaan "verplichten" richting Gmail.
Vermoedelijk zal Google dan ook de authenticatie gaan "verplichten" richting Gmail.
Dit lijkt me heel sterk
Geweldig nieuws dit want met encryptie tussen mailservers is het momenteel treurig gesteld. Technisch is het allemaal prima mogelijk maar in praktijk zijn er zoveel slecht geconfigureerde servers dat je veilige encryptie niet kan afdwingen want anders komt er te veel mail niet aan. Je moet ook onveilige opties aanbieden en dat maak "downgrade"-aanvallen mogelijk.

Deze actie van Google lost het probleem niet op maar het helpt wel om het zichtbaar te maken. Gmail is zo groot dat ze met zo'n beetje alle (externe) mailservers ter wereld communiceren. Als 10% z'n leven betert dan is dat al een enorme vooruitgang.

Ik hoop dat DANE/TLSA een uitweg biedt. Dat geeft een extra communicatiekanaal (DNS) om andere mailservers te vertellen welke encryptie er gebruikt moet worden.

Uiteindelijk is hop-to-hop beveiliging tussen mailservers niet genoeg, het wordt pas echt veilig met end-to-end encryptie tussen mail-clients (bv pgp of smime) er bij maar dat lijkt nog ver weg.
Begin een beetje moe te worden van al die opdringerige meldingen van Google: privacy notificatie, ingelogde apparaten en nu dit weer.
Ik zeg het niet vaak, maar Google dit het in dit geval toch echt in jouw belang.
Tja, weer een melding waar een modale gebruiker niet gaat weten wat hen overkomt. Hoe ga je uitleggen aan je 55-jarige buurvrouw wat TLS-encryptie is? En wat moeten ze doen wanneer ze die melding krijgen: geen e-mail versturen omdat "er een kans bestaat dat het niet veilig is".

[Reactie gewijzigd door biglia op 10 februari 2016 09:32]

Daarom is het ook geen in your face melding, maar een subtiel slotje.
Tja, weer een melding waar een modale gebruiker niet gaat weten wat hen overkomt. Hoe ga je uitleggen aan je 55-jarige buurvrouw wat TLS-encryptie is? En wat moeten ze doen wanneer ze die melding krijgen: geen e-mail versturen omdat "er een kans bestaat dat het niet veilig is".
Het is een klein beginnetje, net zoals we 20 jaar geleden een klein en grappig slotje hadden in Netscape. Het heeft 20 jaar geduurd om uit te groeien tot de groene of rode balken die we nu hebben en we zijn nog steeds niet klaar.
Ik vind het prima dat gmail begint met een klein icoontje dat door de meeste gebruikers genegeerd zal worden. Laten we eerst het laaghangende fruit laten plukken door een paar fanatieke nerds. Als de 100 grootste e-mail-bedrijven om zijn is waarschijnlijk 90% van het werk gedaan. Daarna kunnen we opzichterigere waarschuwingen in gaan zetten om al die kleine partije in beweging te krijgen.
eindelijk,
voor mijn werk reis ik regelmatig naar verdachte landen zoals Romenie,
zelf reageren hier kost me vaak al enige moeite.
zoals deze;
[small]Beste bezoeker,

Tweakers beperkt de functionaliteit van de site voor bepaalde landen om zo de spam, oplichting en misbruik te beperken.

Jouw IP-adres (92.39.60.146) is herleid tot landcode MD en dat land valt onder deze beperking. Jouw IP-adres is daardoor uitgesloten van het plaatsen van reacties op Tweakers. Lees voor meer informatie ook deze uitleg.

Als je inlogt kunnen we bepalen of dit ook daadwerkelijk voor jouw account geldt.

In veel gevallen kunnen we persoonlijke uitzonderingen maken, stuur daarvoor een mail naar frontpage@tweakers.net. Vermeld in die mail je gebruikersnaam en IP-adres.
[/small]

Internet is niet overal veilig, ook nu als ik inlog op mijn gmail account wil google een sms verificatie.
Als je gebruik maakt van een openbare wifi zou ik sowieso een VPN gebruiken. Een abonnement bij een VPN dienst is niet zo duur en je kunt dan anoniem en veilig surfen. Ook kun je bijvoorbeeld een server in Nederland kiezen om zo bepaalde beperkingen te omzeilen, bijvoorbeeld NPO gemist kijken :). Als je in het buitenland niet veel data verbruikt kun je een account aanmaken bij https://hide.me/en/pricing daar kun je 2GB per maand gratis gebruikmaken van een VPN verbinding. Ik weet niet of er nog meer van dit soort gratis diensten zijn overigens, de voornoemde werkt ook met Blackberry toestellen. Voor meer info over VPN's check dan dit topic: [VPN] Internetten via een VPN-provider

[Reactie gewijzigd door ChicaneBT op 9 februari 2016 23:26]

Internet is niet overal veilig, ook nu als ik inlog op mijn gmail account wil google een sms verificatie.
Dat is standaard als je 2FA aanzet. Wat wel zo slim is.

Mbt al je andere problemen: als je het niet vertrouwt, gebruik dan een VPN op je laptop. ;)
A John doe. Grappig das mijn gmail naam.
B google geeft ook via ingress aan of je verbinding veilig is. Bijvoorbeeld ziggo hotspot is niet veilig.
C onder de zoek balk in chrome kan nu ook een beveiliging check gedaan worden.

Algemeen google doorvoer functionaliteit ??
Ik zal blij zijn als ze eindelijk die privacy-waarschuwing van de zoekmachine verwijderen. Die staat daar al maanden in. Maar dat is uiteraard een heel ander onderwerp.

Op dit item kan niet meer gereageerd worden.



Nintendo Switch Google Pixel Sony PlayStation VR Samsung Galaxy S8 Apple iPhone 7 Dishonored 2 Google Android 7.x Watch_Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True