How can I trust Day One?
-
I don’t see any technical proof that confirms e2e encryption in Day One app. After asking from the chat bot it shows me an audit by nVisium (the domain does not exist BTW). And in the audit e2e encryption is not even mentioned. So far the proof logic is trust me bro.
Do you have more technical details about this?
-
Thanks for the question! And thanks for pointing out the broken link. The audit was initially done by nVisium, but they have since been acquired by NetSPI so their site is no longer online.
Regarding the request for more technical details, we have added some documents that go into more detail about E2EE in Day One.
Hope that helps!
-
You approving your own product does not add anything in this case. It would work if a credible third party organization does the audit and confirms the way E2EE has been implemented in your software. How can I know this is how the application is implemented and it’s not just a half true claim. I could make a product and not implement e2e but claim it is implemented.
Without a published formal verification how can I be sure that this is the truth? Specially when my data is going to be on your servers. This wouldn’t be the case if I could store the files on iCloud or some other platform
-
That’s a fair question. Our end-to-end encryption design is documented publicly so people can see how it works, but we don’t currently have a formal third-party audit of the implementation.
If that level of verification is something you require, Day One may not be the right fit for you today. We try to be transparent about how the system works so people can make their own call.
-
It’s great that I saw this thread because as a longtime user of Day One, I’m really upset with the direction they are taking with AI and the obvious data protection risks, unless they running everything on local AI models that value privacy.
To add to my concern, I noticed that Day One pushed Android version 2026.3.1. The entire changelog:
‘Fixed a minor security issue”
No CVE number or description of what was vulnerable. No indication of whether user data was exposed, for how long, or which versions were affected. No email to users. Nothing.
Under GDPR (Article 33), if a security vulnerability resulted in any risk to personal data, the data controller is required to notify the relevant supervisory authority within 72 hours. If the risk to individuals is “high,” Article 34 requires direct notification to affected users. A journaling app contains some of the most sensitive personal data imaginable: mental health reflections, relationship details, medical notes, location history. Under GDPR’s classification, this is likely “special category data” (Article 9), which triggers the highest level of protection and the strictest breach notification requirements.
“Fixed a minor security issue” does not meet any reasonable interpretation of these obligations. Who decided it was “minor”? By what criteria? Was a Data Protection Impact Assessment conducted? Was the DPO consulted? Was any supervisory authority notified?
Under the UK GDPR and the Data Protection Act 2018, the same obligations apply.
Under California’s CCPA/CPRA, consumers have the right to know what personal information is collected and whether it has been compromised.
What we deserve to know as loyal users:
– Was this a local exploit where someone with device access could read entries?
– A network or sync vulnerability where entries were interceptable in transit?
– An authentication bypass?
– Something related to the encryption key storage on Android, which uses Google Drive?
– Were versions before 2026.3 affected? How far back?
– Was user data actually compromised, or was this caught internally before exploitation?
You have to understand my concerns here and if I don’t get a satisfactory answer, I will take this up further. -
Maybe you can do this already because their answer to how can I trust you is:
You don’t, just use another app or just trust me without critical thinking
Will talk about this forever as a token of thank you.
-
@mrwebsteradam Thanks for highlighting this!
You’re right that we were too vague in the release notes description – I want to apologize for that. We take security very seriously and that note did not reflect this.
The fix we introduced in Day One Android 2026.3.1 is the inclusion of reCAPTCHA Enterprise – a Google Cloud service that protects websites and mobile apps from bot-based fraud, credential stuffing, and abuse without interrupting legitimate users.
This only affected new account creation. No existing accounts were affected by this change.
To answer the rest of your questions:
What we deserve to know as loyal users:
– Was this a local exploit where someone with device access could read entries? No
– A network or sync vulnerability where entries were interceptable in transit? No
– An authentication bypass? No
– Something related to the encryption key storage on Android, which uses Google Drive? No
– Were versions before 2026.3 affected? How far back? No. We released version 2026.3.1 because our backend now enforces the new API for new account creation. Without this update, new users wouldn’t be able to create accounts on Android. The Android release was needed sooner than our normal cycle to keep up with that backend change.
– Was user data actually compromised, or was this caught internally before exploitation? No user data was compromisedI hope that helps. Thanks again for highlighting this. We will be sure to provide more details about security issues in our release notes going forward.
Day One Forums 