[GH-ISSUE #1164] Setting passphrase does not encrypt bookmarks #776

Closed
opened 2026-02-25 22:38:04 +03:00 by kerem · 3 comments
Owner

Originally created by @Seirade on GitHub (May 14, 2022).
Original GitHub issue: https://github.com/floccusaddon/floccus/issues/1164

Which version of floccus are you using?

4.14.0

Sync method

{"label"=>"WebDAV"}

Which browser are you using? In case you are using the Android App, specify the Android version please.

Firefox 100

Which version of Nextcloud Bookmarks are you using? (if relevant)

No response

Which version of Nextcloud? (if relevant)

No response

What kind of WebDAV server are you using? (if relevant)

LoFloccus v1.2.3 (https://github.com/TCB13/LoFloccus)

Describe the Bug

Securing account credentials and setting the passphrase does nothing to encrypt the bookmarks. The resulting XBEL can be opened in a text editor and read plainly.

Possibly relevant: I'm using Firefox with the History privacy setting of "Never remember history", which is equivalent to having private/incognito mode on by default. I'm not sure if this prevents the browser session from temporarily storing the passphrase, but the extension seems to only prompt me for it once and is able to sync normally, just without encryption.

Other observance: Testing with an older browser, Firefox Portable 64 with the same settings, I noticed that the bookmarks are also kept in the extension's storage (Data/profile/browser-extension-data/floccus@handmadeideas.org/storage.js) without encryption. I'm not too familiar with how extensions work, but this would seem to suggest that when the extension loads the bookmarks into its storage from the file, that it also does not encrypt them. This can be problematic with non-portable (regular) installations leaving unencrypted data behind on devices when the browser is uninstalled. I could not reproduce this part with my regular installation of Firefox 100, though I may have been looking for the storage.js file in the wrong location.

Expected Behavior

The XBEL file where bookmarks are kept should contain unreadable encrypted data, and anywhere else they are kept, such as extension storage (storage.js).

To Reproduce

From a fresh installation of Floccus:

  1. Create a new account
  2. Choose the "XBEL file in WebDAV share" option for syncing
  3. Choose the Bookmarks file path and Local folder
  4. Use default settings for syncing (15 minute interval, Merge local and cloud changes, Yes include this account's folder in other accounts)
  5. Next, secure credentials by setting a passphrase
  6. Open Floccus and start a sync

When syncing is done, open the XBEL file in a text editor and you should be able to see the bookmarks in plaintext.

Debug log provided

  • I have provided a debug log file
Originally created by @Seirade on GitHub (May 14, 2022). Original GitHub issue: https://github.com/floccusaddon/floccus/issues/1164 ### Which version of floccus are you using? 4.14.0 ### Sync method {"label"=>"WebDAV"} ### Which browser are you using? In case you are using the Android App, specify the Android version please. Firefox 100 ### Which version of Nextcloud Bookmarks are you using? (if relevant) _No response_ ### Which version of Nextcloud? (if relevant) _No response_ ### What kind of WebDAV server are you using? (if relevant) LoFloccus v1.2.3 (https://github.com/TCB13/LoFloccus) ### Describe the Bug Securing account credentials and setting the passphrase does nothing to encrypt the bookmarks. The resulting XBEL can be opened in a text editor and read plainly. Possibly relevant: I'm using Firefox with the History privacy setting of "Never remember history", which is equivalent to having private/incognito mode on by default. I'm not sure if this prevents the browser session from temporarily storing the passphrase, but the extension seems to only prompt me for it once and is able to sync normally, just without encryption. Other observance: Testing with an older browser, [Firefox Portable 64](https://sourceforge.net/projects/portableapps/files/Mozilla%20Firefox%2C%20Portable%20Ed./Mozilla%20Firefox%2C%20Portable%20Edition%2064.0/) with the same settings, I noticed that the bookmarks are also kept in the extension's storage (`Data/profile/browser-extension-data/floccus@handmadeideas.org/storage.js`) without encryption. I'm not too familiar with how extensions work, but this would seem to suggest that when the extension loads the bookmarks into its storage from the file, that it also does not encrypt them. This can be problematic with non-portable (regular) installations leaving unencrypted data behind on devices when the browser is uninstalled. I could not reproduce this part with my regular installation of Firefox 100, though I may have been looking for the `storage.js` file in the wrong location. ### Expected Behavior The XBEL file where bookmarks are kept should contain unreadable encrypted data, and anywhere else they are kept, such as extension storage (`storage.js`). ### To Reproduce From a fresh installation of Floccus: 1) Create a new account 1) Choose the "XBEL file in WebDAV share" option for syncing 1) Choose the Bookmarks file path and Local folder 1) Use default settings for syncing (15 minute interval, Merge local and cloud changes, Yes include this account's folder in other accounts) 1) Next, secure credentials by setting a passphrase 1) Open Floccus and start a sync When syncing is done, open the XBEL file in a text editor and you should be able to see the bookmarks in plaintext. ### Debug log provided - [ ] I have provided a debug log file
kerem 2026-02-25 22:38:04 +03:00
  • closed this issue
  • added the
    bug
    label
Author
Owner

@marcelklehr commented on GitHub (May 14, 2022):

I cannot replicate this off-hand. It seems likely to me that you only followed the account setup flow (which currently doesn't ask for an encryption passphrase) and didn't fill in the passphrase in the settings afterwards. Could this be the case? A way to improve this situation would definitely be to ask for an encryption passphrase during the account setup.

EDIT: Oh you wrote "5. Next, secure credentials by setting a passphrase" -- this is not for encrypting bookmarks. For encrypting your bookmarks you need to enter a passphrase in the settings of the respective account.

<!-- gh-comment-id:1126719682 --> @marcelklehr commented on GitHub (May 14, 2022): I cannot replicate this off-hand. It seems likely to me that you only followed the account setup flow (which currently doesn't ask for an encryption passphrase) and didn't fill in the passphrase in the settings afterwards. Could this be the case? A way to improve this situation would definitely be to ask for an encryption passphrase during the account setup. EDIT: Oh you wrote "5. Next, secure credentials by setting a passphrase" -- this is not for encrypting bookmarks. For encrypting your bookmarks you need to enter a passphrase in the settings of the respective account.
Author
Owner

@Seirade commented on GitHub (May 15, 2022):

I did later set the passphrase in the account options, but it made no difference, even after forcing a new sync (using the "Upload & Overwrite Once" option). Restarting the browser did ask me to enter the passphrase before a sync could begin, so I assumed that it was set, but the bookmarks still weren't being encrypted.

I tried again just now, but this time I also changed the XBEL path, and that seems to have worked. It seems like setting the passphrase doesn't work unless it creates a new XBEL. I tested this with the old path, and that appears to be the case. The bookmarks are not encrypted unless you delete the existing XBEL. This makes it difficult to encrypt the bookmarks by default, since during account setup, there is no option to set the passphrase first, but also the bookmarks are synced immediately after creating the account. Overwriting cloud changes does not encrypt them.

Also: If at a later stage you do not wish to encrypt them, there doesn't seem to be a way to remove the passphrase from the account settings. Would you just save with a blank field? That seems dangerous, as the field is blank by default, so the user may accidentally remove their passphrase if that's how it's done.

Overall, it seems like the functionality is there and it works, but there are many ways that the user could accidentally be leaving their bookmarks unencrypted. Some UX improvements would be very appreciated :)

<!-- gh-comment-id:1126832041 --> @Seirade commented on GitHub (May 15, 2022): I did later set the passphrase in the account options, but it made no difference, even after forcing a new sync (using the "Upload & Overwrite Once" option). Restarting the browser did ask me to enter the passphrase before a sync could begin, so I assumed that it was set, but the bookmarks still weren't being encrypted. I tried again just now, but this time I also changed the XBEL path, and that seems to have worked. It seems like setting the passphrase doesn't work unless it creates a new XBEL. I tested this with the old path, and that appears to be the case. The bookmarks are not encrypted unless you delete the existing XBEL. This makes it difficult to encrypt the bookmarks by default, since during account setup, there is no option to set the passphrase first, but also the bookmarks are synced immediately after creating the account. Overwriting cloud changes does not encrypt them. Also: If at a later stage you do not wish to encrypt them, there doesn't seem to be a way to remove the passphrase from the account settings. Would you just save with a blank field? That seems dangerous, as the field is blank by default, so the user may accidentally remove their passphrase if that's how it's done. Overall, it seems like the functionality is there and it works, but there are many ways that the user could accidentally be leaving their bookmarks unencrypted. Some UX improvements would be very appreciated :)
Author
Owner

@github-actions[bot] commented on GitHub (Jul 6, 2023):

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

<!-- gh-comment-id:1622809461 --> @github-actions[bot] commented on GitHub (Jul 6, 2023): This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/floccus#776
No description provided.