Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Permanent error message - DB is not “available” #357

Closed
O35dE opened this issue Apr 8, 2024 · 5 comments
Closed

Permanent error message - DB is not “available” #357

O35dE opened this issue Apr 8, 2024 · 5 comments
Labels
enhancement New feature or request

Comments

@O35dE
Copy link

O35dE commented Apr 8, 2024

For databases that are not stored on the iphone, such as users who prefer to store them in an external encrypted folder, as an additional measure of privacy and security, a permanent and unnecessary error message is presented in red under their name saying that the file is not “available”, even if they are at rest. This message, in addition to the inconvenience, presents some information about the place of origin from which it was last accessed.
Would it be possible to delete this message, not least because this information is naturally known to the user who chose to save the database in a place apart from the iphone, leaving it to present it, if the case, when the file is actually triggered, that is, the user tries to access but for any reason it cannot be found, in other words, just when the file is not actually available?

@O35dE O35dE added the enhancement New feature or request label Apr 8, 2024
@keepassium
Copy link
Owner

I'm afraid I would need some specifics to understand the issue. What exactly does the message say, verbatim? What is the "external encrypted folder", how can we test it?

Would it be possible to delete this message, not least because this information is naturally known to the user who chose to save the database in a place apart from the iphone, leaving it to present it, if the case, when the file is actually triggered, that is, the user tries to access but for any reason it cannot be found, in other words, just when the file is not actually available?

This is a 72-word sentence. I cannot parse that, please rephrase.

@O35dE
Copy link
Author

O35dE commented Apr 8, 2024

The message is displayed in red under the name of the database and in relation to one of my DBs it specifically says that "Cryptomator is not available. Please check if ...".

Ok sry, I will rephrase.

Would it be possible to eliminate this permanent “error” message in red, in relation to the databases that are stored in a external place i.e. a cryptomator folder, particullarly when they are on stand by ?

The reason for this request is that this information is naturally known to the user who chose for some reason to save the database in a place apart from the Files app in the iPhone.

When this same user intends to open this database, he will naturally make the connections that allow the application access to the DB, so a permanent message in this regard is unnecessary while the database is on stand by.

In addition, this error message contains information, even if partial, about the location of the DB (that the user chose to hide), which would not otherwise be easily identifiable.

In the event that it is not possible to delete this permanent error message, would it be at least possible for it to be replaced by a simple disconnection symbol or even by some sentence but that does not mention the place or application in which the DB is stored? Preferably this error message could then be shown, in case the file cannot be reached, only after the user tries to open the DB.

@keepassium
Copy link
Owner

Thank you for the clarification.

In addition, this error message contains information, even if partial, about the location of the DB (that the user chose to hide), which would not otherwise be easily identifiable.

Exactly for this reason KeePassium has app protection (app settings → App Protection → Enable AppLock). It ensures that only you can see the list of files, app settings, etc.

Would it be possible to eliminate this permanent “error” message in red, in relation to the databases that are stored in a external place i.e. a cryptomator folder, particullarly when they are on stand by ?

Well, KeePassium has to report that there is a problem with the database, and it should provide enough info for the user to identify and fix the problem. So no message would be bad (hides the problem) and generic message would be bad, too (no info about the cause).

The reason it is permanent is because of how Cryptomator integrates with the system. Whenever you mount the vault, it becomes a new storage location (even though the name is still "Cryptomator"). The dismounted one is gone forever.

a simple disconnection symbol or even by some sentence but that does not mention the place or application in which the DB is stored?

File location would still remain visible via Databases → long-press database → File Info → File Location.

In summary, if you want to protect info about file location, activate KeePassium app protection.

@O35dE
Copy link
Author

O35dE commented Apr 10, 2024

Thanks for the reply, well I am certainly aware of your app protection, but KeePassium’s solution do not delete local db files and all references to remote files, like I suggest here - #356 , it will simply close the DBs and delete all keys from the keychain.
Btw it seems you misunderstood my suggestion in #356 , it is not related to duress pin, I cleared that in the request.
Thanks.

@keepassium
Copy link
Owner

well I am certainly aware of your app protection, but KeePassium’s solution do not delete local db files and all references to remote files

Just to be clear, nuking the data is a separate topic (which you filed as #356).
#356 is unrelated to #357 (current issue, hiding file location)
App protection does cover #357, so let's consider this one solved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants