People who have Advanced Data Protection enabled on Apple devices have Bear content encrypted using this standard. It means end-to-end encryption.
There is one big issue here. The current impilmentation does NOT encrypt the titles nor tags. This means all of one’s subjects and topics are unencrypted, as well as some of their contents.
I urge bear to use identifiers for these, or something, so that all data is properly encrypted! Thanks.
Btw, I remember that one of the reasons for not using E2EE for titles and tags was connected to Bear Web. But according to some of the beta tester posts, Bear Web works with ADP if web access to iCloud data is enabled. I’m definitely interested to know whether this is indeed the case. If yes, I assume this would make E2EE of titles and tags easier.
They claim it’s ADP supported but, there is a good amount that is simply not covered by the encryption.
I am hoping they close these gaps in their encryption support. Imagine if one relied upon this one day, and ALL of the note titles were left out in the open. The entire subject of what they were writing about is in plain text.
I’ve explained this a few times already, but let me clarify again:
If titles and tags were moved under ADP, the web app would no longer be able to query them. This is because the web app doesn’t download your entire database locally, instead it relies on CloudKit to fetch information on demand. Without being able to query titles and tags, features like autocomplete, wiki-links, and other related functionality simply wouldn’t work on the web.
For that reason, at the moment, it’s not technically possible to put titles and tags under ADP.
It’s not really about whether you have Advanced Data Protection (ADP) turned on or off, the limitation comes from how Bear stores data on CloudKit servers.
When we design the database, we have to decide if a field (like a note title or a tag name) should live in the ADP-encrypted part of the database or the standard encrypted one.
Both are always encrypted at rest. The difference is that ADP fields use keys that even Apple itself cannot access. That’s great for security, but it also means developers can’t run queries on those fields at all, regardless of whether ADP is enabled for a specific user.
In practice:
If we put a field in the ADP area, we can’t query it.
If we keep it in the standard encrypted area, it’s still encrypted, but with Apple-managed keys, so queries work.
On top of that, Apple doesn’t provide any API to tell us whether a given user has ADP enabled. Even if they did, dynamically switching where fields are stored would introduce huge complexity and inconsistency in Bear’s codebase.
So the short version: ADP is great for privacy, but it prevents apps from querying certain fields if they’re stored in the ADP section.