WhatsApp és realment segur? El problema dels extrems que no controles

Sèrie sobre WhatsApp, 2/2. En el primer article vaig contar com vaig estar a punt de perdre onze anys de missatges per una còpia de seguretat que WhatsApp no sabia restaurar. Quan vaig demanar la clau del meu propi fitxer, el suport em va contestar amb la publicitat del xifratge d'extrem a extrem: «nadie más, ni siquiera WhatsApp» pot llegir els teus missatges. D'eixa frase tracta este article.

TL;DR — No tinc temps per a llegir un text tan llarg en este moment

WhatsApp repetix que les nostres converses estan protegides mitjançant "xifratge d'extrem a extrem" i que, per tant, "ni tan sols WhatsApp" pot llegir-les.

El xifratge d'extrem a extrem és real i és una protecció molt important. Però eixa afirmació amaga una condició fonamental:

el xifratge protegix la comunicació entre els extrems, però no garantix que els extrems mateixos siguen fiables.

I "l'extrem" no eres exactament tu. És el programa que s'executa al teu telèfon o ordinador.

Si el proveïdor controla eixe programa, pot actualitzar-lo, pot decidir quines versions continuen funcionant amb el seu servei i tu no pots auditar independentment el binari que executes, aleshores continues necessitant confiar en el proveïdor.

La tesi d'este article és, per tant:

Cap sistema E2EE pot proporcionar una garantia forta contra el mateix proveïdor si l'usuari no pot saber exactament quin codi executen els extrems, verificar-lo i, en el model més exigent, compilar-lo i controlar quan l'actualitza.

Això no demostra que WhatsApp espie els nostres missatges ni que existisca una porta posterior per a governs o servicis d'intel·ligència.

Demostra una cosa més modesta però important:

No podem convertir l'afirmació "WhatsApp diu que no pot llegir-los" en la propietat tècnica "WhatsApp no podria fer que el nostre endpoint els entregara".

La diferència és entre confiança i verificació.

"Ni tan sols WhatsApp pot llegir els teus missatges"

Una de les principals promeses de privacitat de WhatsApp és el xifratge d'extrem a extrem, habitualment abreviat E2EE, de l'anglés "end-to-end encryption".

El principi és excel·lent.

Quan Alícia envia un missatge a Bernat, el missatge s'hauria de xifrar al dispositiu d'Alícia i no desxifrar-se fins que arriba a un dispositiu autoritzat de Bernat.

Simplificant:

Figura 1

Açò protegix contra amenaces molt importants.

Una persona que intercepte el trànsit no hauria de poder llegir-lo. Una intrusió en determinats servidors tampoc hauria de proporcionar directament el contingut de totes les converses. I el servidor que transporta els missatges no necessita conéixer el plaintext.

WhatsApp afirma, a més, en la seua política de privacitat que els missatges entregats s'esborren dels seus servidors i que els pendents d'entrega es mantenen, xifrats, durant un màxim de 30 dies.

Tot això és una millora de seguretat enorme.

El problema comença quan transformem esta afirmació:

"Els servidors de WhatsApp no disposen normalment del contingut ni de les claus necessàries per a desxifrar-lo."

en esta altra:

"WhatsApp no podria obtindre les meues converses."

No és exactament la mateixa afirmació.

Què és realment "l'extrem"?

En la nostra imaginació, E2EE significa:

jo  <====================>  tu
          E2EE

Però, tècnicament, és més paregut a:

Figura 2

El xifratge no comença directament en el meu cervell ni acaba directament en el teu.

Comença i acaba en programes.

Per tant, després de preguntar:

"Està xifrada la comunicació?"

hauríem de preguntar immediatament:

"Qui controla el programa que constituïx cada extrem?"

Eixa segona pregunta és la que desapareix quasi sempre de la publicitat sobre E2EE.

En algun moment el missatge ha d'estar en clar

Hi ha una limitació inevitable.

Si jo puc llegir un missatge en la pantalla, el meu dispositiu ha hagut de desxifrar-lo.

Per tant, en algun moment tenim:

Figura 3

La criptografia ha acabat la seua faena.

A partir d'eixe moment la seguretat depén de l'endpoint.

I això significa que una aplicació hipotèticament maliciosa no necessitaria trencar el protocol criptogràfic.

No necessitaria descobrir una clau mitjançant força bruta.

No necessitaria atacar matemàticament el Signal Protocol.

Conceptualment, bastaria que fera:

decrypt(message)
display(message)

i, a més:

send_copy(message)

És a dir:

Figura 4

El protocol E2EE podria continuar sent impecable.

El servidor podria continuar sense saber desxifrar el ciphertext.

Les claus podrien fins i tot continuar sense abandonar formalment el dispositiu.

Però el plaintext ja ha sigut obtingut per l'aplicació.

No s'ha atacat el xifratge. S'ha atacat l'extrem.

I si el mateix proveïdor controla l'extrem?

Ací apareix el conflicte conceptual interessant de WhatsApp.

WhatsApp ens diu:

"El nostre servidor no pot desxifrar els teus missatges."

Però és el mateix proveïdor qui distribuïx el programa que:

• genera o gestiona les claus;
• rep els missatges;
• els desxifra;
• accedix al seu contingut;
• consulta la base de dades local;
• mostra les converses;
• i es comunica amb els seus servidors.

Per tant:

Figura 5

L'E2EE impedix que el servidor ataque directament el canal criptogràfic.

Però no garantix per si mateix què farà demà el software que arriba a un dels extrems.

"Però l'aplicació està firmada"

Sí.

I això és molt important contra un adversari diferent.

La firma criptogràfica d'una aplicació ajuda a impedir que un desconegut cree un APK modificat i el faça passar fàcilment per una actualització legítima de WhatsApp.

Però la firma respon aproximadament a:

"Prové este software de la cadena autoritzada?"

No respon a:

"Fa este software exactament el mateix que feia la versió anterior?"

Si és el mateix desenvolupador autoritzat qui publica una nova versió, el nou programa continuarà estant perfectament firmat.

Figura 6

Firma i confiança funcional són conceptes diferents.

"Doncs no actualitze WhatsApp"

A primera vista podria semblar una solució.

Si confie en la versió 2.X i no vull que ningú me la canvie, desactive les actualitzacions.

El problema és que això només et dona un control parcial.

Pots impedir temporalment que Google Play instal·le automàticament una versió nova, però no controles el servidor ni el protocol de WhatsApp.

El proveïdor pot modificar:

• els protocols acceptats;
• les versions mínimes compatibles;
• els requisits de registre;
• les funcionalitats que necessiten suport del servidor.

Per tant, no tens garantida la possibilitat d'utilitzar indefinidament una versió antiga que tu has decidit congelar.

Eixa diferència és essencial:

"Puc desactivar les actualitzacions automàtiques" no equival a "controle quina versió del client continuarà sent funcional".

En un sistema realment sota el teu control podries decidir:

Figura 7

En un servei centralitzat, el servidor manté sempre l'última paraula sobre què continua sent interoperable.

Podrien enviar una versió especial només a una persona?

És una possibilitat que requerix matisos.

Google Play disposa de "staged rollouts", és a dir, desplegaments graduals on una versió nova arriba inicialment només a un percentatge dels usuaris.

Però segons la documentació de Google, en els desplegaments graduals ordinaris els usuaris són triats a l'atzar dins del percentatge corresponent. No seria correcte, per tant, dir que el sistema normal de Play permet simplement ordenar:

"Instal·la este APK especial exactament al número de telèfon X."

Però això no resol el problema general.

Un programa pot contindre funcionalitats el comportament de les quals canvie segons informació proporcionada pel servidor:

• "feature flags";
• configuració remota;
• experiments A/B;
• activacions graduals;
• paràmetres associats al compte.

Figura 8

Naturalment, una configuració remota només pot activar funcionalitat que el programa ja siga capaç d'executar.

I no tenim evidència que WhatsApp continga un mecanisme destinat a exfiltrar secretament converses.

No és això el que estic afirmant.

El punt és un altre:

Auditar el protocol E2EE no ens diu automàticament tot el que pot fer el client.

Tampoc faria falta robar la clau de la base de dades

A vegades imaginem un atac complicadíssim:

1. robar la base de dades local;
2. extraure'n la clau;
3. enviar-la al servidor;
4. desxifrar les converses allí.

Però una hipotètica versió maliciosa del client probablement tindria una opció molt més senzilla.

L'aplicació legítima ja necessita llegir les seues pròpies dades.

Si WhatsApp pot mostrar-te una conversa de fa sis mesos, alguna part del client té accés a eixa informació en una forma utilitzable.

Per tant:

Figura 9

El xifratge "en repòs" és molt útil contra altres programes, contra determinats accessos físics o contra la còpia directa dels fitxers.

Però no protegix les dades contra el mateix programa que legítimament necessita desxifrar-les.

I, en el cas de WhatsApp, la clau de la còpia de seguretat normal ni tan sols és només del mòbil: com conte en el primer article, la guarda WhatsApp als seus servidors i la lliura a qualsevol mòbil que verifique el número. A l'aplicació, sí. A l'usuari, no.

I ni tan sols faria falta enviar-ho tot

Un hipotètic atac dirigit tampoc necessitaria transferir 30 GB de fotografies, vídeos i àudios.

El text és molt barat.

Es podria seleccionar, en abstracte:

• els últims missatges;
• una conversa concreta;
• només text;
• missatges a partir d'una data;
• dades d'un determinat interlocutor;
• determinades metadades.

Això importa perquè un hipotètic atac d'endpoint ben delimitat podria generar molt poc trànsit respecte del trànsit ordinari d'una aplicació de missatgeria.

WhatsApp Web multiplica els extrems

La situació és encara més interessant des que WhatsApp disposa d'una arquitectura multidispositiu real.

WhatsApp Web ja no és simplement una pantalla que depén permanentment del telèfon principal.

En l'arquitectura multidispositiu, cada dispositiu vinculat té la seua pròpia clau d'identitat i manté sessions E2EE independents. Quan es vincula un dispositiu, el mòbil principal li envia xifrada una part de l'historial recent, i després el dispositiu manté la seua pròpia base de dades local.

Per tant:

Figura 10

Açò és molt còmode.

Però des del punt de vista del model d'amenaça significa que ja no tenim necessàriament un únic endpoint.

Tenim diversos dispositius amb:

• claus o estat criptogràfic propi;
• dades locals;
• credencials;
• capacitat de rebre i desxifrar missatges.

Per això WhatsApp permet consultar els dispositius vinculats i eliminar sessions.

La lliçó general és:

E2EE reduïx molt la confiança necessària en el servidor, però cada dispositiu autoritzat es convertix en un nou lloc on el contingut existix en clar.

"Però WhatsApp diu que no pot donar els missatges ni a la policia"

I efectivament WhatsApp presenta públicament eixa posició.

Però té una porta reservada a les autoritats. Literalment: el Law Enforcement Online Request System de WhatsApp és un portal on només poden entrar agents de les forces de l'ordre per a demanar dades en el marc d'una investigació oficial o d'una emergència. Meta en té un altre d'equivalent per a Facebook i Instagram.

Té la seua gràcia: hi ha una finestreta exclusiva per a demanar informació a una empresa que diu que no té la informació. No és una contradicció, perquè el que entrega són dades del compte i metadades, no les converses. Però il·lustra bé que «no tenim els teus missatges» no vol dir «no tenim res».

El funcionament l'expliquen elles mateixes:

• La pàgina de WhatsApp per a les forces de l'ordre: dins d'una investigació penal oficial, WhatsApp preserva les dades d'un compte durant 90 dies mentre arriba el requeriment judicial formal.
• Les pautes de Meta distingixen tres tipus de petició: de preservació (90 dies), d'emergència (dany imminent a un menor o risc de mort o de lesions greus, pel mateix portal) i de registres, que exigixen el procediment legal corresponent.

I el volum no és anecdòtic. En novembre de 2024, en el cas Shabana v. Govt of NCT of Delhi, l'Alt Tribunal de Delhi va recollir el que Meta mateix li va explicar. El seu sistema de peticions (LEORS) va rebre més de cent mil sol·licituds de dades en un any (2023), i les d'emergència les respon en qüestió de minuts: 18 o 30, en casos de menors desapareguts. WhatsApp també rep «un nombre substancial» de peticions ordinàries i d'emergència. Fins i tot ha arribat a entregar informació sobre activitat terrorista 12 minuts després de rebre la petició. El que lliuren, segons el tribunal, és la informació bàsica del subscriptor: nom, correu, telèfon i data de registre.

A Europa, l'informe SIRIUS de 2024 d'Eurojust i Europol compta WhatsApp, a banda de Meta, entre els proveïdors que tenen portal propi per a les peticions policials.

Açò no té res d'extraordinari: les grans empreses tecnològiques disposen habitualment de procediments per a respondre a requeriments legals.

Segons el model públic de WhatsApp, el que poden proporcionar depén de les dades que efectivament posseïxen.

La qüestió interessant per a este article és una altra.

Podem distingir:

A) "WhatsApp afirma que els seus servidors no poden
   desxifrar les converses E2EE."

B) "Podem verificar independentment que cap client
   controlat per WhatsApp podria obtindre el plaintext."

A no implica automàticament B.

Ens ho hem de creure?

Ací és important no confondre escepticisme amb acusació.

No tinc evidència que WhatsApp distribuïsca versions especials destinades a permetre que una agència d'intel·ligència llija converses.

Per tant, seria irresponsable afirmar que ho fa.

Però tampoc és raonable convertir:

"No tenim proves que ho faça"

en:

"Està tècnicament demostrat que no podria fer-ho."

Són tres graus epistemològics diferents:

Figura 11

Una bona arquitectura de seguretat intenta avançar tant com siga possible de la confiança cap a la garantia verificable.

No perquè qualsevol empresa siga necessàriament maliciosa.

Sinó perquè un sistema segur intenta minimitzar les coses que hem de creure per pura confiança.

Ací apareix la diferència entre "segur" i "verificable"

WhatsApp pot ser extraordinàriament segur contra molts adversaris.

Per exemple:

• algú que escolta una xarxa Wi-Fi;
• un operador de telecomunicacions;
• un atacant que captura trànsit;
• una intrusió determinada en infraestructura de servidor;
• determinats administradors interns.

El problema d'este article és molt més específic:

Quina garantia tenim contra el mateix proveïdor que controla el nostre endpoint?

I ací la situació és diferent.

Podem resumir-ho:

Signal: codi públic i compilacions reproduïbles

Signal oferix un bon exemple d'un model més verificable.

El client Android té el codi públic i suporta compilacions reproduïbles.

Les instruccions oficials expliquen com:

1. obtindre exactament el codi corresponent a una versió;
2. reproduir l'entorn de compilació;
3. compilar-lo;
4. extraure els APK instal·lats al dispositiu;
5. comparar-los.

L'objectiu declarat és precisament verificar que la versió baixada de Google Play correspon al codi font publicat.

Açò és una diferència enorme.

No cal que cada usuari de Signal siga programador.

El fet que qualsevol investigador independent puga comprovar-ho ja fa molt més difícil distribuir massivament un binari que no corresponga a les fonts públiques.

Ara bé, fins i tot això té un límit important.

Si el teu model d'amenaça inclou un atac extraordinàriament selectiu només contra tu, el més fort seria verificar el teu propi APK instal·lat.

L'escala seria:

Figura 12

Cada pas elimina una part de la confiança cega.

Delta Chat: encara una altra manera de separar confiança

Delta Chat és programari lliure.

En Android hi ha, a més, un cas interessant quan s'instal·la des d'F-Droid: la fitxa d'F-Droid indica que cada versió és compilada i firmada pel mateix F-Droid i que està garantit que correspon al paquet de fonts publicat.

Això introduïx una separació:

Figura 13

No elimina tota confiança.

Has de confiar també en F-Droid, en la seua infraestructura, en Android, etc.

Però evita almenys el model més simple de:

"La mateixa empresa escriu el codi, compila un binari opac i m'entrega exactament allò que ella vol."

Telegram: una comparació especialment interessant

Telegram necessita una distinció important.

Els seus xats al núvol no són E2EE. Segons les preguntes freqüents de Telegram, usen xifratge client-servidor i es guarden xifrats al núvol de Telegram perquè estiguen disponibles en tots els dispositius.

Els xats secrets, en canvi, sí que utilitzen xifratge d'extrem a extrem.

Per tant, Telegram no és "més privat" que WhatsApp per defecte.

Però és interessant per a la qüestió que ens ocupa perquè els seus clients són de codi públic i Telegram publica instruccions per a verificar que les versions de l'App Store i de Google Play corresponen al codi publicat.

A més, TDLib permet construir clients propis, i també suporta els xats secrets.

Això possibilita un model com:

Figura 14

Telegram podria canviar el protocol.

Podria acabar rebutjant el teu client.

Podria deixar de donar-te servei.

Però si tu controles l'executable que estàs executant, el servidor no pot simplement reescriure'l remotament perquè faça una altra cosa.

És una diferència important.

L'E2EE també és molt convenient per a WhatsApp

Hi ha un altre aspecte que rarament es comenta.

La narrativa habitual presenta E2EE com si fora una concessió que l'empresa fa exclusivament en benefici de l'usuari.

Però una arquitectura en què el proveïdor no conserva normalment una còpia llegible de totes les converses també és extraordinàriament beneficiosa per al proveïdor.

Com hem vist, WhatsApp diu que els missatges entregats s'eliminen dels seus servidors i que els pendents es conserven temporalment en forma xifrada.

Això té conseqüències empresarials molt favorables:

Figura 15

Açò no demostra que WhatsApp adoptara E2EE per eixos motius.

No podem atribuir-li eixa intenció.

Però els avantatges objectius existixen.

"Eixa informació no la tenim" és una posició molt còmoda

Imaginem que una editorial descobrix que determinats usuaris s'envien llibres piratejats per WhatsApp.

O que una autoritat vol conéixer el contingut d'una conversa antiga.

Si WhatsApp realment no conserva eixe contingut i l'arquitectura normal impedix al servidor desxifrar-lo, pot respondre:

"Eixa informació no la tenim."

És una bona notícia per a la privacitat.

Però és també una situació molt convenient per al proveïdor.

No necessita:

• decidir sistemàticament què és legal dins de cada conversa privada;
• mantindre sistemes que inspeccionen tots els fitxers;
• conservar durant anys el contingut;
• respondre a cada petició entregant dades que ja no posseïx;
• custodiar una base de dades central extraordinàriament comprometedora.

No utilitzaria ací la paraula "denegabilitat", perquè té significats tècnics específics en criptografia i podria confondre.

Parlaria més bé de no-custòdia del contingut.

La mateixa característica que diu:

"WhatsApp no pot veure-ho"

també diu:

"WhatsApp no ha de custodiar-ho."

I, com vaig comprovar en pròpia pell, també permet dir: «no podemos ayudarte a restaurar tus chats».

Però WhatsApp no és cec

Tampoc hauríem d'anar a l'altre extrem.

Que el contingut d'una conversa siga E2EE no significa que WhatsApp no dispose d'informació relacionada amb l'ús del servei.

La seua política de privacitat descriu, entre altres coses:

• informació del compte;
• informació del dispositiu i la connexió;
• registres i diagnòstic;
• informació necessària per a operar el servei.

També diu que conserva informació relacionada amb la transmissió, com el número, la data i l'hora d'un missatge o la duració d'una telefonada, mentre calga per a transmetre la comunicació, operar el servei o complir obligacions legals.

Per tant:

Figura 16

"E2EE" no significa "WhatsApp no sap res sobre mi".

Significa una propietat específica sobre el contingut.

El proveïdor pot entregar les dades que efectivament posseïx. El que no hauria de poder entregar, segons l'arquitectura publicada, és el plaintext d'una conversa E2EE que no conserva.

La pregunta d'este article continua sent, però:

És eixa incapacitat una propietat que nosaltres podem verificar independentment en l'endpoint, o una propietat que depén també de confiar en el client que WhatsApp ens proporciona?

I ahí tornem al principi.

No és el mateix "no ho fan" que "no poden fer-ho"

Esta és probablement la distinció més important de tot l'article.

Podem tindre tres situacions:

1. El proveïdor diu que no ho fa

És una afirmació.

2. No tenim evidència que ho faça

És una observació sobre el que sabem.

3. El sistema està construït de manera que nosaltres mateixos podem verificar que no pot fer-ho silenciosament

Això és una garantia tècnica molt més forta.

Figura 17

El software lliure no és màgicament segur.

Una compilació pròpia tampoc és màgicament segura.

Però cada capa de verificabilitat reduïx el nombre d'afirmacions que necessitem acceptar perquè sí.

Ni tan sols compilar-lo personalment elimina tota confiança

Podríem continuar baixant indefinidament.

Si compile l'aplicació jo mateix, continue confiant en:

• les fonts;
• el compilador;
• les dependències;
• el sistema operatiu;
• el kernel;
• el firmware;
• el hardware.

Figura 18

No existix la confiança zero.

La pregunta útil és:

Quanta confiança puc substituir per verificació?

I en eixe sentit no tots els sistemes són equivalents.

Llavors WhatsApp és insegur?

Esta pregunta està mal formulada.

Cal preguntar:

Insegur contra qui?

WhatsApp amb E2EE pot ser molt segur contra una persona que capture el trànsit de la xarxa.

Pot ser molt segur contra un operador de telecomunicacions curiós.

Pot protegir extraordinàriament bé contra una intrusió determinada en un servidor.

Però si el teu model d'amenaça inclou:

"No vull haver de confiar en el mateix proveïdor del servei"

aleshores el control del client passa a ser fonamental.

I l'E2EE, per si sol, ja no és suficient.

I per què continue utilitzant Telegram per a coses poc sensibles?

Precisament perquè la seguretat no existix en el buit.

Depén del que intentes protegir.

Telegram em permet:

• tindre tot l'historial sincronitzat;
• utilitzar molts dispositius amb facilitat;
• recuperar immediatament les converses;
• emmagatzemar una enorme quantitat de dades al núvol;
• accedir-hi independentment del dispositiu concret.

Els xats al núvol de Telegram no són E2EE, i Telegram ho explica obertament: els guarda al seu núvol perquè siguen accessibles des de qualsevol dispositiu.

Però per a parlar de:

• gramàtica;
• esperanto;
• classes;
• una afició;
• una reunió;
• una activitat social ordinària;

puc arribar perfectament a la conclusió que eixes propietats són més valuoses per a mi que eliminar un risc que, per a eixa informació concreta, considere poc rellevant.

Això no significa que Telegram siga més segur.

Significa aplicar un model d'amenaça proporcional.

Per a una conversa altament sensible, triaria unes garanties diferents.

Per a discutir si l'acusatiu en esperanto toca o no toca després d'una determinada construcció, probablement no.

Què hauria d'exigir un sistema amb garanties molt fortes?

Si realment volguérem reduir al màxim la confiança en el proveïdor, buscaríem almenys:

1. un protocol criptogràfic públic i auditable;
2. codi complet del client públic;
3. compilacions reproduïbles;
4. possibilitat de comparar el nostre binari amb les fonts;
5. possibilitat de compilar el client nosaltres mateixos;
6. capacitat de controlar quan actualitzem;
7. possibilitat d'utilitzar implementacions alternatives;
8. mecanismes de transparència contra tractaments selectius;
9. minimització de metadades;
10. un sistema operatiu i una cadena de compilació també raonablement verificables.

No tots els sistemes populars complixen tot això.

Però hi ha una diferència qualitativa entre:

"El fabricant m'assegura que no pot fer-ho."

i:

"La construcció del sistema em permet comprovar independentment que no pot fer-ho de la manera que estem considerant."

La pregunta correcta: de qui són els extrems?

Quan apareix el conegut cadenat de WhatsApp, la pregunta habitual és:

"Està xifrada la conversa?"

Sí.

És una pregunta important.

Però immediatament n'hauríem de fer una altra:

"De qui són els extrems?"

Perquè la representació correcta no és:

jo  <============= E2EE =============>  tu

sinó:

Figura 19

L'E2EE protegix magníficament el tram entre B i C.

Però no certifica B ni C.

I si B i C són programes que el mateix proveïdor pot desenvolupar, distribuir i modificar, la confiança en eixe proveïdor no ha desaparegut.

Simplement s'ha traslladat.

Conclusió

El xifratge d'extrem a extrem de WhatsApp no és fals ni inútil.

Al contrari: és una mesura de seguretat importantíssima.

El problema és convertir una propietat concreta:

"els nostres servidors no necessiten poder desxifrar els missatges"

en una afirmació absoluta:

"nosaltres no podríem obtindre mai els missatges".

Això exigiria confiar també en el comportament dels endpoints.

I els endpoints són software.

Software que algú escriu.

Software que algú compila.

Software que algú distribuïx.

Software que algú actualitza.

Software que, finalment, té el plaintext davant.

Per això, davant de qualsevol aplicació que presumisca d'E2EE, jo ja no em conformaria amb preguntar:

"Està xifrat d'extrem a extrem?"

Preguntaria també:

"Puc llegir el codi dels extrems?"

"Puc demostrar que el binari instal·lat correspon a eixe codi?"

"Puc compilar-lo jo mateix?"

"Puc decidir quan canvie de versió?"

"Puc continuar utilitzant eixa versió sense que el proveïdor m'obligue a substituir-la?"

"Pot el servidor modificar selectivament el comportament del meu endpoint?"

I sobretot:

"L'extrem és realment meu, o continua estant sota el control del proveïdor?"

El cadenat de l'E2EE ens diu que el trajecte entre els extrems està protegit.

No ens diu, per si sol, en qui hem de confiar quan arribem als extrems.