Request #1: Make it clear how to move your notes over to ADP
You should make these instructions about how to move existing notes over to ADP more clear for users. Right now, you suggested pinning/unpinning every note. I think that’s a rather hacky method. If that’s going to be the solution, then it should be documented. Ideally, there would be an option in the right-click menu that says “update these notes over to latest ADP format” (but with better wording that will make sense to non-technical users).
Request #2: Clarify which notes have been moved to the new ADP
I think users need a way to determine whether notes are synced via ADP or synced the old way. My ideal solution to this would be a special search tag that would let me determine which notes have not been moved over to the new “ADP type.” ADP is mentioned in the release notes, but there’s no way for a user to determine whether they are getting that functionality.
These two together are a current “hole” in the system. Enough so that I’d actually call this a bug rather than a feature request. If a user sees the release notes and sees that ADP is now supported, they will likely think that all their notes are now end to end encrypted. There’s no user feedback to tell them otherwise. And this could be a big security risk if someone is counting on end to end encryption but never got the memo that they need to pin and unpin (or otherwise update) all their notes. And they have no way to check if it took effect since there’s no user feedback.
The best way to move all your notes and be sure they are covered by ADP is to export a backup from Bear and restore.
This will trigger a re-sync of all your notes and the cloudKit ADP fields will be used to store your notes.
If you have 2.4 installed all new notes and notes edited with this version are covered by ADP. I don’t think having an “ADP marker” for notes is necessary but it’s open to discussion.
I feel it was an oversight to not clearly define within the App Store release notes, the distinction of which notes are in ADP and which are not, along with information on how one can ensure they move into ADP, all prominently displayed. Or better yet, as a dialog within the app itself for anyone that already has or newly enables ADP.
I imagine the typical Bear user does not follow discussions in this community, and if they have ADP enabled, may have already been under the impression that all their notes are covered. Or upon reading the current release notes have the impression that they are now covered, when they are not.
There should be never be any ambiguity when it comes to the security such data.
It is my understanding that export and restore changes the unique note-IDs, which would destroy my (many) internal and external note links. So the best solution for me (I think) is to create a new tag called #ADP and apply it to groups of “old” notes, which would preserve all the IDs and also preserve the created and modified dates.
[Some background for the 3 people who might be interested, haha]. When I started using Bear several years ago I migrated from evernote, which used unique note IDs for links. I came up with a multi-step process to migrate thousands of notes and preserve these links and all sorts of other metadata and formatting in bear. (I actually chose bear over obsidian because bear had unique note IDs). I have since created probably a couple thousand more notes. I mistakenly assumed the unique note-id in bear would remain constant. Thus a backup and restore would be quite the undertaking, so I it seems I must use the above mentioned tag-based “migration” to ADP…
Question for the devs (@trix180 / @matteo / etc) - If someone turns on ADP, triggers a change on all notes to get them to the new format, then turns ADP off, then turns ADP back on, will all the notes automatically go back to being encrypted? Or do they have to trigger a change in all them again to get them to update to ADP-enabled encrypted?
We, as third-party developers, don’t know if the ADP flag is on for your account so it’s not possible to know if a note is encrypted with or without ADP. What we know is if it’s using CloudKit secure fields or not but those can or cannot use ADP according to your iCloud preferences.
In that scenario, it’s not required to trigger changes inside the notes because the data is already online in the secure fields, and Apple takes care of re-encrypting all the data similarly to what happens to iCloud files.
You can also select all your notes in Notes, Trash, and Archive (separately) Unpin then pin all of them, and wait for the sync. Then you can unpin.
Thanks for the clarification! That’s one less thing to worry about, which is great.
I still advocate pretty strongly that not letting a user know whether their note has been moved over to the the new format (and is therefore E2EE under ADP) is a big shortcoming that needs to be resolved.
Some scenarios I’m thinking about:
What if there was an error in the migration process while pinning and unpinning a bunch of notes and some didn’t get converted?
What if I thought I highlighted all my notes for pinning/unpinning, but I actually missed some? How do I find?
What if I have a LOT of notes (10s or 100s of thousands) and I want to do them in batches? How do I make 100% sure I didn’t miss any?
Those are the kinds of things on my mind.
And again, pinning+unpinning is A) undocumented (except on the forum) and B) a really unintuitive user experience.
I think most existing Bear users are going to experience:
Reading in the documentation (that I imagine will be published on the site eventually) that ADP is supported.
Turning on ADP
Thinking that their notes are new E2E encrypted, when in fact none of them (except newly created ones since 2.4 release) are
So I think all four of the following are essential:
Clear documentation of how to get your notes over to the new ADP-enabled format
A clear user interface option for doing the migration
A way to view if notes were migrated.
A search operator to see if any notes were missed that you intended to have included.
That would fully address the problem.
Or alternately you could just require that everyone migrate their entire database over when they open Bear. So there’s no more uncertainty. But you’d have to warn them that this could take many minutes or multiple hours in some cases. So that’s probably less-than-ideal.
The client app (Bear for macOS or iOS) doesn’t have access to that information, ADP is a server-side feature, not something managed by the client. Even if we wanted to, we couldn’t provide that kind of detail. Bear can’t even detect whether a user has ADP enabled on their account (that’s Apple’s decision, not ours).
While ADP is a great feature, the reality is that most users don’t have it enabled or aren’t particularly concerned with it. We implemented support for it because it was the right thing to do, and for users like you who do care, migrating notes to take advantage of ADP is straightforward.
This limitation is intentional, and we are confident in the decision behind it.
This would trigger a full database sync, creating significant disruption for all users with little to no benefit. So we decided against it.
This might not be the outcome you were hoping for, but our decisions are guided by what benefits the majority of our users. Adding complexity to support niche features isn’t something we typically do.
I’m happy to provide any further information you might need on this topic
