Política de privacidad

Se aplica al sitio y a la aplicación, ambos en snapfork.app. Actualizado el 24 de septiembre de 2026.

Qué guarda el servidor

Solo aquello sin lo que no pueden funcionar el acceso, la sincronización y la correspondencia con el desarrollador:

Dónde está el servidor. El servidor, la base de datos y sus copias de seguridad funcionan en el proveedor de alojamiento Railway (Estados Unidos), en su región de Singapur. Por eso los datos de las personas de la Unión Europea y del Reino Unido se guardan fuera de ellos.

Qué pasa con tu diario

Tu diario vive tanto en tu dispositivo como en el servidor, pero en el servidor va cifrado. Las entradas, las vistas previas de fotos y los registros de peso viven en el almacenamiento de tu navegador, y una copia sellada viaja al servidor: la clave existe solo en tu dispositivo. El servidor puede ver que se añadieron entradas y cuándo, y no puede ver qué comiste, cuánto ni cuánto pesas.

Nosotros tampoco podemos leer tu diario. No es una promesa de portarnos bien; es cómo está construido el sistema: no tenemos la clave. Lo que trae un precio que conviene saber de antemano: si pierdes tu código de recuperación junto con tu dispositivo, nadie puede recuperar el diario, tampoco nosotros. No habría de dónde restaurarlo. El código se muestra en Ajustes, en «Datos»: apúntalo y guárdalo en algún sitio que no sea tu móvil.

El servidor también guarda las versiones en conflicto, y eso juega a tu favor. Si una entrada se editó en dos dispositivos, gana la edición más reciente, y la que perdió no se tira: se queda en el servidor un mes, sellada igual, y la aplicación puede mostrártela. Si no, «se arregló sola» sería nuestra palabra contra tu memoria. Nosotros tampoco podemos leerla, claro: va en el mismo sobre que todo lo demás.

Los ajustes van al servidor solo si activas su sincronización. Los objetivos, el perfil (nombre, sexo, año de nacimiento, altura, nivel de actividad, objetivo, ritmo, peso objetivo, qué tener en cuenta y qué no comes), el objetivo de agua, el reparto de comidas, las funciones del diario, los ajustes de alimentación, el registro de ajustes de la norma, las acciones rápidas, las unidades, el tema de la tarjeta para compartir y dos interruptores (una valoración de producto oculta y una búsqueda en la base abierta desactivada) viajan en un solo sobre, sellado con la misma clave que el diario. Parte de esto lo nombramos aparte, porque puede insinuar tu fe o tu salud: el conjunto listo y los objetivos de alimentación (por ejemplo, «Vegetal» o «Sin alcohol»), la lista de lo que no comes y tus propias palabras en los ajustes de alimentación (palabras de alerta y excepciones) viajan en el mismo sobre, selladas igual. Se activa con un interruptor aparte en la sección «Datos»; hasta que lo hagas, los ajustes no se envían a ninguna parte. Se desactiva en el mismo sitio: la copia del servidor se borra al momento, y la sincronización se apaga en todos tus dispositivos. El servidor ve que el sobre existe, cuándo cambió, qué tamaño tiene y cuándo se apagó la sincronización, y no qué hay dentro. El tema de la app, el idioma, los recordatorios, la conexión con Apple Salud y tu propia clave de proveedor de reconocimiento nunca salen del dispositivo: son del dispositivo, no tuyos.

Tu país de residencia, si lo elegiste, se guarda en este dispositivo. Viaja en el archivo de copia junto al idioma y se borra con tus demás ajustes personales cuando otra persona pasa a usar el dispositivo. No forma parte del sobre de sincronización de ajustes y no lo deducimos de la dirección IP ni del idioma de la interfaz. A nuestro servidor el código del país va como campo de la solicitud solo con una solicitud de reconocimiento con la clave de Snapfork y solo con el interruptor «Tener en cuenta mi país» activado — de paso, allí no se queda (ver «Adónde sí van los datos»). La línea «Sugerido por el dispositivo» del selector de país se calcula en el propio dispositivo —por la región del sistema, la zona horaria o la región de la configuración de idioma del navegador— y no elige nada por sí sola.

Un archivo de copia lo sigues exportando tú y lo guardas tú. No va cifrado, y es la única forma de leer tu diario sin el código.

A los proveedores de acceso no les pedimos tu nombre, tus apellidos ni tu foto de perfil: solo la confirmación de la dirección de correo. Un nombre que escribas tú en tu perfil llega al servidor solo dentro del sobre sellado de ajustes, y solo si la sincronización de ajustes está activa; no podemos leerlo.

La copia de seguridad de tu propio dispositivo

Esto trata de la aplicación para iPhone. Aún no está en la App Store, y lo que sigue describe cómo se comportará cuando salga. El sitio web no tiene nada parecido: en un navegador no hay contenedor de la app ni una copia así.

Una copia de seguridad del iPhone lleva los datos de las apps a iCloud: así funciona esa copia, no es algo que haga nuestra app. Si tu diario entra en ella es decisión tuya, y por defecto no entra. Se te pregunta en el primer arranque, y puedes cambiar la respuesta cuando quieras: Ajustes → «Datos» → «Diario en la copia de iCloud».

Lo que se describe aquí es el mecanismo, no el resultado, y no es evasiva: una vez que respondes, la frase «mi diario está en iCloud» es verdad para unos lectores y falsa para otros. Si dices que sí, la copia la hace y la guarda Apple con las reglas de Apple: es su copia, no la nuestra; ni la vemos ni podemos abrirla. Si dices que no, o no dices nada, la carpeta de la app se marca como excluida de la copia, así que el diario no viaja allí.

Nada de esto afecta al archivo de copia que exportas tú: ese lo haces y lo guardas donde quieras. Qué entra en él de los amigos se describe en Amigos.

Respuestas de salud

La app tiene una sección «Prevención»: material de referencia sobre recomendaciones publicadas de chequeos preventivos, seleccionadas según la edad, el sexo y tus respuestas. Esas respuestas son datos de salud, y las tratamos con más rigor que el diario. La sección solo se abre tras un consentimiento aparte en su pantalla de inicio; mientras no lo des, no guarda nada.

Qué se guarda. Dónde te atienden (el país); si fumas, lo dejaste o nunca fumaste, con los paquetes-año y el año en que lo dejaste; si planeas un embarazo; qué puntos por órganos te corresponden; las marcas «hecho» con el mes y el tipo de prueba; los puntos aplazados; el interruptor «Nada sobre perder peso» y cuándo diste el consentimiento. Del perfil, la sección lee el año de nacimiento, el sexo, el objetivo y la lista «Lo que no comes», pero no tu peso. No pregunta ni guarda diagnósticos, antecedentes familiares ni resultados de análisis.

Dónde. En tu dispositivo, en el almacenamiento de la app. En la app para iPhone, las respuestas van selladas con una clave que solo existe en ese teléfono y que no entra en ninguna copia: a una copia de iCloud solo llegan selladas, y en otro teléfono no hay nada con qué abrirlas; allí la sección empieza de cero. En un navegador, las respuestas quedan en su almacenamiento, como el diario.

Al servidor, solo selladas y solo si tú lo decides. Las respuestas de salud van al servidor solo si activas su sincronización entre dispositivos, y entonces selladas con una clave que solo existe en tus dispositivos, como el diario y los ajustes. Esa sincronización tiene su propio interruptor y su propio consentimiento; viene apagada por defecto y solo funciona dentro de la sincronización de ajustes, pero activar esta no la activa. Si indicaste que te atienden en Rusia, las respuestas no van al servidor ni con la sincronización activada.

Adónde no van nunca. Ni al modelo de lenguaje, ni a los amigos, ni a los datos del dispositivo que se adjuntan a un mensaje de soporte. En el archivo de copia (el botón «Exportar JSON») no entran por defecto: una casilla aparte las añade, y entonces recuerda que ese archivo no va cifrado.

Ocultar, apagar la sincronización, borrar: tres acciones distintas. «Ocultar la sección» la quita de la vista y no toca las respuestas. «Apagar y borrar las respuestas del servidor» borra la copia del servidor, y tus otros dispositivos borran la suya en su próxima sincronización; en este dispositivo las respuestas se quedan. «Borrar las respuestas de este dispositivo» las borra aquí y, con la sincronización activada, en la próxima sincronización también en el servidor y en tus otros dispositivos; con las respuestas se retira también el consentimiento, y la sección vuelve a empezar por su pantalla de inicio. Eliminar la cuenta se lleva la copia del servidor con todo lo demás; cuánto viven las copias de seguridad de la base de datos se explica en Cuánto tiempo se guarda cada cosa.

Adónde sí van los datos

Las fotografías de comidas, envases o etiquetas se envían a reconocer, y por dónde viajan depende de quién firma la petición con su clave. Hay dos rutas, y la elección es tuya:

La aplicación empieza con tu propia clave y pasa a la nuestra solo cuando la tuya ha fallado, o va directamente a la nuestra si el modelo que elegiste no mira fotografías. Ese es el valor por defecto, y una casilla en los ajustes lo desactiva; entonces la fotografía nunca pasa por nuestro servidor, en ningún caso.

Comida en palabras, y recalcular a partir de una descripción. Cuando describes una comida con texto, el texto que escribiste se envía a reconocer por las mismas dos rutas que una fotografía, para que el modelo estime calorías, proteínas, grasas y carbohidratos. Cuando pides a la aplicación que recalcule los números de un producto a partir de su descripción, la descripción del producto (lo que dice su campo de nombre) se envía al modelo de la misma forma. La descripción de una comida lleva también su peso total, si lo diste, y los nombres de productos de tu biblioteca junto con cuánto sueles tomar de cada uno (la ración en gramos), que ayudan al modelo a reconocer lo que ya conoce y a juzgar el peso; los mismos nombres de la biblioteca, con sus raciones en gramos, van también con la fotografía de un plato. La descripción de una comida, igual que una fotografía, lleva también el idioma de la interfaz, para que el modelo nombre los platos en él. El texto no se guarda aquí, igual que la fotografía: solo queda la fila de números.

Tu país de residencia, si lo elegiste. Una foto, una etiqueta o una descripción de una comida llevan también, junto con el idioma de la interfaz, el código de dos letras de tu país, para que el modelo reconozca los platos locales y el tamaño de las porciones. Con la clave de Snapfork, el código del país va por nuestro servidor hasta la plataforma de reconocimiento; con tu propia clave va directo a la plataforma, sin pasar por nosotros. Nuestro servidor solo lo deja pasar: como con una foto, en el registro de llamadas quedan solo el modelo, los tokens y el coste. El recálculo de un elemento y la clasificación de productos por grupos nunca reciben el país, y tu lista «No como» nunca va al modelo. Se desactiva con el interruptor «Tener en cuenta mi país» en la sección «Reconocimiento de comida».

El texto de tu búsqueda de productos, si tocaste «Buscar en la base abierta». La aplicación tiene una pantalla de Productos: busca en tus propios productos y en el catálogo descargado en tu dispositivo, y todo eso ocurre sin red. Cuando el catálogo no tiene lo que buscas, aparece un botón «Buscar en la base abierta» bajo la lista. Con ese toque, y solo con él, lo que escribiste en el campo de búsqueda sale de tu dispositivo hacia Open Food Facts, sin pasar por nuestro servidor: ni vemos ese texto ni lo guardamos. No hay autocompletar mientras escribes ni peticiones en segundo plano: sin el toque, no sale nada.

Con ese texto no viaja nada más: ni entradas del diario, ni fotografías, ni peso, ni identificador de cuenta; la petición no necesita nada de eso, y la aplicación no añade nada. A partir de ahí rigen las condiciones de Open Food Facts, no las nuestras. Una casilla lo desactiva: Ajustes → Productos por código de barras → «Buscar en la base abierta con un toque»; desactivada, quita el propio botón, y no sale nada en absoluto. Buscar un producto por el código de su paquete, y buscar en el catálogo descargado, nunca salen a la red, ni con la casilla activada ni desactivada.

La aplicación descarga la base de productos de nuestro servidor como el archivo de un país, y la dirección del archivo nombra ese país (por ejemplo, /products/de.2026-09-24.csv). Por eso el país de la base descargada, junto con tu dirección IP, lo ven nuestro servidor, la red de Cloudflare por la que pasan todas las solicitudes a snapfork.app y los registros de nuestro proveedor de alojamiento Railway, que guarda esas entradas de 7 a 30 días. La solicitud sale sin la cookie de inicio de sesión: no tenemos con qué vincular la descarga a una cuenta. La base solo se descarga con el botón de Ajustes; después, buscar en ella no usa la red.

Los correos con el código de acceso pasan por el proveedor de correo que eligió el responsable del servicio. Aparte de lo enumerado aquí, no se pasa nada a nadie: no hay analítica, ni publicidad, ni scripts de terceros en el sitio ni en la aplicación.

En el propio correo el proveedor añade un contador de apertura: una pequeña imagen que se carga desde su servidor cuando se abre el correo. Por ella sabe que el correo se abrió y cuándo; los clientes de correo que descargan las imágenes directamente también le muestran la dirección desde la que se leyó. En nuestro plan esto no se puede desactivar. El correo tal como lo componemos no lleva ninguna imagen ni ningún enlace.

El contador de visitas

El sitio cuenta las visitas por sí mismo, sin cookies y sin scripts de nadie más. Lo que llega a la base son números diarios: página, idioma, de dónde vino la visita. Ni la dirección IP ni el User-Agent se guardan de ninguna forma: se convierten en una clave con una sal diaria, y la propia sal no se escribe en ninguna parte, así que ni nosotros podemos cruzar dos días. Se respeta la cabecera Sec-GPC: con ella, no se cuenta nada en absoluto.

Correspondencia con el desarrollador

Los ajustes de la aplicación tienen una sección «Soporte»: puedes escribir sobre algo roto o algo que falta, y recibir respuesta en el mismo sitio. Es una conversación y no un formulario, lo que significa que se guarda en el servidor: si no, no habría dónde responder.

Lo que se guarda es el texto de tus mensajes y las respuestas del desarrollador, vinculados a tu cuenta. Solo los leen aquellos cuyas direcciones confirmadas el responsable del servicio ha puesto en la lista de desarrolladores: la lista es cerrada, vive en la configuración del servidor, y nadie más ve la correspondencia. Junto a ella no hay ni dirección de correo ni nombre (el servidor de todos modos no los guarda en texto plano), y la conversación se mantiene con un diario, no con una persona.

Los datos del dispositivo se adjuntan solo si marcas la casilla, y antes de enviar se te muestra exactamente el texto que viajará: la versión de la aplicación y de la base de datos, la plataforma y el navegador, el idioma, el tamaño de la ventana, la pantalla desde la que escribes y el código del fallo si vienes de uno, cuántas entradas y pesajes tienes como simples números, si el dispositivo tenía red, si la app se abrió desde su icono o en una pestaña del navegador, si el modo de depuración está activo y si hay una clave de plataforma puesta: «sí» o «no», nunca la clave. Ni una sola entrada del diario, fotografía, registro de peso o campo del perfil va ahí.

El correo de aviso que le llega al desarrollador no contiene ni el texto del mensaje ni tu identificador: solo «hay un mensaje nuevo en la conversación». El contenido de la correspondencia nunca llega al proveedor de correo y nunca aparece en los registros del servidor.

Enlaces de invitación

La aplicación puede darte un enlace de invitación permanente. Si alguien se registra con él, los dos recibís reconocimientos extra con nuestra clave; nada más cambia, y nadie obtiene acceso al diario de otro.

Lo que se guarda es el hecho de que una cuenta llegó por el enlace de otra: qué enlace, cuándo y si la recompensa se ganó. Es un registro de una conexión entre dos personas, así que se guarda lo mínimo y no se le muestra a nadie: quien invitó solo ve números: cuántos llegaron, cuántos volvieron, cuántos reconocimientos recibió. Ni un nombre, ni una dirección, ni un momento de acceso. No decimos quién aceptó, porque sería contarle a un tercero que una persona concreta empezó a llevar un diario de comidas.

El enlace en sí lleva un código y nada sobre ti. Abrirlo lo cuenta el contador de visitas como su propia campaña, solo la etiqueta: el código nunca llega al contador, porque si no, los números diarios se convertirían en una tabla de qué enlaces funcionan.

Borrar una cuenta quita el enlace y el registro de dónde vino esa cuenta; las anotaciones de recompensa se quedan sin el identificador de cuenta, porque con ellas se cuentan los límites de cuánto se puede regalar.

Las anotaciones de recargas se comportan igual: borrar una cuenta las deja en su sitio, pero deja de nombrar a nadie. La razón no es la contabilidad sino tú: un banco puede disputar un pago un mes después de que la cuenta desaparezca, y sin importes no habría con qué responder a esa disputa. El saldo que quede se quema al borrar, y eso se escribe como una anotación propia: el dinero por el que no se prestó ningún servicio queda visible como exactamente eso, en vez de disolverse en los ingresos.

Amigos

Si invitas a un amigo y acepta, algo derivado de tu diario empieza a salir de tu dispositivo, y son exactamente dos datos al día de los últimos siete días: si anotaste algo y, si lo compartiste aparte, si te mantuviste dentro de tu propio objetivo. Además, cuántos días seguidos llevas anotando. Ni qué comiste, ni cuántas calorías, ni tu peso: nada de eso sale, en ningún nivel de compartir.

Compartir es igual en las dos direcciones y en cada nivel: ves la semana de un amigo solo si le has compartido tu semana, y su dato de objetivo solo si también le has compartido tu objetivo; tu amigo ve de ti exactamente tanto como tú de él: tu dispositivo muestra la semana de un amigo solo con consentimiento mutuo. Tu dato de objetivo viaja a tu amigo en un sobre cifrado siempre que le hayas compartido tu objetivo, pero se le muestra solo si él también te ha compartido su objetivo. El consentimiento se pide por amistad y por nivel, y registramos a qué texto accediste: si el sentido de ese texto cambia, volvemos a preguntar en vez de ampliarlo en silencio. Puedes deshacerlo cualquier día, y hay dos botones: «dejar de compartir» mantiene la amistad, «borrar la amistad» quita la conexión y borra lo que cada uno vio del otro.

Hay una excepción: el archivo de copia que exportas tú: no está cifrado, y lleva la semana de tu amigo, exactamente lo que viste de él. Las respuestas no van en él. Borrar una amistad borra lo visto tanto aquí como en el dispositivo, pero no llega a los archivos que ya guardaste: qué pase con ellos depende de ti.

Hay un tercer botón para cuando terminar no basta: un rechazo. Después de eso, una nueva invitación de esa persona no pasará; si no, «borrar la amistad» solo significaría «hasta la siguiente invitación». Para ello el servidor guarda una lista de las personas que has rechazado: identificadores y una fecha, sin motivo y sin una palabra tuya; dura hasta que lo deshagas. No se lo decimos a la otra parte: quien fue rechazado ve exactamente lo mismo que tras un final normal: no hay amistad. Esa lista queda fuera a propósito de la exportación «Qué guarda el servidor sobre ti»: es un archivo que puedes reenviar a alguien.

No podemos leer nada de ello, siempre que la clave sea auténtica. El contenido viaja sellado con una clave que no tenemos, todos los sobres tienen la misma longitud, y ni siquiera el tamaño revela cuántos días hay dentro. Pero algunas cosas sí las vemos, y lo decimos claro:

Lo que no vemos: qué hay dentro, cuánto hay, cómo llamaste a tu amigo en tu propio dispositivo y quién miró la semana de quién.

Esa salvedad sobre la clave no es una forma de hablar. Las claves que se intercambian entre tu amigo y tú pasan por nuestro servidor, lo que significa que, en teoría, podríamos cambiarlas. Puedes comprobarlo: ocho cifras calculadas a partir de las dos claves públicas tienen que coincidir para ti y para tu amigo. Esa comprobación la ofrecemos en vez de exigirla, y hasta que la hagas, confías en que el servidor entregó la clave real. La pantalla de la amistad siempre muestra si se ha comprobado.

La clave que sella tu semana se guarda en tu dispositivo y nunca viaja: ni a nosotros ni a tu copia. Así que en un dispositivo nuevo hay que confirmar de nuevo las amistades.

Cuánto dura cada cosa: una invitación no aceptada vive 30 días y funciona una vez; tu semana está en el servidor hasta la siguiente y se borra al momento cuando termina una amistad; las notas viven siete días; la conexión dura hasta que se termina o se borra la cuenta. Las funciones sociales no se ofrecen a nadie cuyo perfil diga que tiene menos de 16 años.

Puedes tener no más de 50 amigos, y ese techo es nuestro y no del producto: cuanto más larga la lista, más conexiones conoce el servidor. Las invitaciones tienen tope por la misma razón: cinco activas a la vez, diez al día.

Cookies

Exactamente una en todo el dominio: la sesión de acceso. Es técnica, se pone solo cuando entras, vive hasta 180 días desde el último acceso y no la ve nada más que la aplicación. Antes de entrar no hay ninguna, y después viaja con cada página de aquí, esta incluida, porque el sitio y la aplicación responden en una misma dirección. No hay aviso porque no se pide consentimiento para la cookie sin la que no se puede entrar, y no hay nada más por lo que preguntar: ni analítica, ni publicidad.

Base jurídica

Cada finalidad tiene su propia base jurídica según el RGPD (artículos 6 y 9):

También puedes presentar una reclamación ante la autoridad de protección de datos de tu país.

Cuánto tiempo se guarda cada cosa

La sesión, hasta 180 días desde el último acceso. El código por correo, 10 minutos. Los números diarios del contador, indefinidamente, pero no contienen nada sobre una persona. La cuenta, hasta que la borres. La correspondencia con el desarrollador, exactamente lo mismo que la cuenta: se va con ella y no tiene plazo propio. Decidimos a propósito no nombrar un plazo propio: sería una promesa de borrar según un calendario, y no hay calendario, así que la promesa sería falsa desde la primera vez que alguien lo comprobara.

Las entradas del diario en el servidor, mientras viva la cuenta. No tienen plazo propio, y es una decisión, no un olvido. El servidor guarda una copia sellada del diario pensando en tu segundo dispositivo — y una copia que desaparece sola no le sirve de nada a un segundo dispositivo: no tendría de dónde recuperar lo que el servidor olvidó, y el diario en él resultaría, sin avisar, más corto que en el otro. Las entradas se van con la cuenta y solo con ella: bórrala, y la copia sellada del diario sale de la base de datos del servidor al momento, y de sus copias de seguridad a medida que rotan; cuánto tardan se dice al final de esta sección. El diario del propio dispositivo sigue siendo tuyo y se borra aparte.

Los treinta días que se nombran abajo no son de las entradas en sí, y no hay que confundir los dos plazos. Treinta días es la vida de las vistas previas de fotos (en el dispositivo y en el servidor) y de las versiones de entradas que perdieron un conflicto de sincronización. Las dos están JUNTO a una entrada, no en su lugar: lo que se va es una imagen o un borrador anterior de la línea, mientras la entrada sigue donde está. Los dos plazos cuentan en la base de datos de trabajo del servidor; en sus copias de seguridad una imagen o una versión puede sobrevivirles hasta 14 días: mira el último párrafo de esta sección.

Vistas previas de las fotos de comidas: 30 días. La aplicación guarda una copia pequeña de la imagen junto a la entrada y la borra del dispositivo treinta días después de hacer la foto. La entrada se queda: solo se va la imagen. Este plazo sí lo nombramos, precisamente porque aquí sí hay calendario (la limpieza se hace cada vez que se abre la aplicación y justo después de restaurar una copia) y puedes comprobarlo abriendo un día antiguo. La fotografía a tamaño completo nunca entra en el diario: la entrada solo guarda esta vista previa.

Una foto aplazada: en el dispositivo, no más de 30 días. Una foto que apartas para reconocerla más tarde se queda en el dispositivo entera, no como vista previa: hasta que se reconozca y guardes la entrada, y no más de treinta días después de hacerla. Cuando se acaba el plazo la foto se borra, y el recordatorio de la comida se queda, para que la anotes a mano. Sale del dispositivo solo en el momento del reconocimiento, por la misma ruta que cualquier otra foto (mira Adónde sí van los datos), y no se queda en nuestro servidor, igual que ninguna otra foto. Nunca entra en la copia sellada del diario del servidor.

En el servidor la vista previa vive con el mismo plazo: no más de treinta días. Viaja allí sellada, junto con el diario, para poder aparecer en tu segundo dispositivo; no podemos abrirla, igual que no podemos abrir las entradas. El servidor cuenta el plazo desde el día en que llegó la imagen, no desde el día en que se hizo: no sabe cuándo se hizo, eso va dentro del texto cifrado. Así que la vista previa se va primero del dispositivo y después del servidor, y la limpieza se hace con calendario, una vez al día, y no «algún día».

Versiones de entradas que perdieron un conflicto de sincronización: no más de treinta días. Cuando editas una entrada sustituyes su versión anterior; el servidor no la tira al momento, sino que la aparta, para que «se arregló sola» no sea nuestra palabra contra tu memoria. Puedes verlas y recuperarlas en la aplicación, en la tarjeta de versiones en conflicto. Están selladas, como las entradas: tampoco podemos abrirlas. La limpieza se hace con calendario, una vez al día, y por eso nombramos aquí el plazo.

Una versión así puede irse antes del plazo, y es más honesto decirlo claro: por entrada el servidor guarda como mucho veinte, y la vigesimoprimera desplaza a la más antigua. Es un límite técnico contra código desbocado, no una promesa de guardar veinte. La versión actual de una entrada no la toca ni el plazo ni el límite: es tu diario, y se va solo con la cuenta.

Copias de seguridad del servidor: hasta 14 días. Una vez por hora el servidor copia toda su base de datos, un seguro para el día en que un disco averiado o una actualización rota se llevarían las cuentas de todos. De las copias de las últimas 48 horas se guarda una por hora, de las más antiguas una por día, y una copia de más de 14 días se borra en la siguiente rotación horaria. Las copias solo las borra un servidor en marcha: mientras está apagado, se quedan todas, y cuando vuelve, las caducadas se van al momento. Una salvedad: la copia más reciente siempre se queda (incluso caducada, si las copias nuevas han dejado de salir bien) hasta la siguiente que salga bien, porque una copia vieja sirve más que un estante vacío. Una copia contiene exactamente lo que tenía la base de datos a esa hora, y de la misma forma. Lo que va sellado con tu clave (el diario, las vistas previas, los ajustes, las versiones en conflicto) sigue sellado en la copia, y no tenemos clave para ello; lo que el servidor ve abiertamente (la correspondencia con el desarrollador, quién es amigo de quién) lo ve también en la copia. Por eso cada plazo de arriba es un plazo en la base de datos de trabajo: lo que se borró allí, por la limpieza o junto con la cuenta, se queda en las copias de seguridad no más de 14 días después, salvo en los casos de arriba. Catorce días es un límite superior, no una promesa de guardar: una copia puede irse antes, por ejemplo cuando al disco le falta espacio.

Una copia fuera del proveedor de alojamiento: hasta 35 días, aún no activada. La base de datos y sus copias están en un solo proveedor de alojamiento, y perderlo se llevaría las dos cosas. Para ese caso, el servidor puede enviar una copia al día a un almacenamiento aparte, en otro proveedor: la misma copia, de la misma forma. Allí las copias solo las borra la propia regla del almacenamiento, a los 35 días, y hasta entonces nadie puede borrarlas, ni siquiera nosotros; eso es lo que las protege de una clave robada. Lo que se borró en la base de datos de trabajo se quedaría allí hasta 35 días después. Hoy esto no está activado: las copias solo están en el servidor. Antes de activarlo, nombraremos aquí el almacenamiento y cambiaremos la fecha del principio de la página.

Borrado

En la aplicación: ajustes → «Borrar la cuenta». Eso borra la cuenta, todas sus formas de acceso, todas las sesiones y toda la correspondencia con el desarrollador; con el acceso de Apple también revoca el permiso del lado de Apple. Lo que el servidor guardaba para la sincronización también se va con la cuenta: la copia sellada de tu diario, las vistas previas de fotos, la copia sellada de tus ajustes, el registro de versiones en conflicto y la lista de tus dispositivos: nada de ello queda en la base de datos del servidor. Las copias de seguridad horarias aún lo guardan hasta 14 días, de la misma forma, y después también desaparece de ellas (siempre que el servidor estuviera en marcha y las copias nuevas salieran bien); cómo funcionan las copias se describe en Cuánto tiempo se guarda cada cosa. Los números diarios del contador de visitas se quedan: no contienen nada sobre una persona y no se pueden quitar por cuenta, porque en ellos no hay cuentas. El diario de tu dispositivo se borra con un botón aparte: es solo tuyo, y no vamos a decidir su destino por ti.

Cambios

Esta política cambia junto con el servicio; la fecha de arriba de la página es la de la última edición. Los cambios importantes se anuncian aquí y no por correo: el servidor no guarda ninguna dirección a la que pueda escribir, solo una huella de ella.

Contacto

El responsable del tratamiento, quien decide qué se guarda aquí y responde de ello, es una persona física, no una empresa: detrás de Snapfork no hay ninguna persona jurídica. Esa persona es Oleksandr Trifonov. Todo lo relativo al servicio, incluidas las solicitudes sobre tus propios datos, va a la dirección de abajo. Qué significa ese arreglo en la práctica está en la página sobre quién está detrás.

Preguntas, acceso a tus propios datos y borrado: a través de la página de preguntas o escribiendo a hello@snapfork.app.

Condiciones de uso · Abrir la aplicación