Ver 1.5 now encrypts the database?

Am I right in thinking that the Hook (sqlite) database is now encrypted ?

What is your thinking on that ?

I personally use Hook more to copy Markdown links than to create two-way links, but if I thought I were excluded, by encryption, from any two-way link data that I created, I would certainly feel rather disinclined to create any.

Perhaps I have misunderstood ? Presumably the intention is not to prevent users from directly accessing their own data ?

I remember that Hook had a data export function, but my limited capacity seems to be outgunned by the cognitive processing costs imposed by the GUI :slight_smile:

Could you remind me where the export function is found ?

PS, a secondary problem with 1.5 is that it seems to have lost track of my license (purchased through Paddle in July)

How do I attempt to reactive or re-register ?

(I can see buy buttons, but I’m failing, so far, to find an activate mechanism for existing licenses, and I can’t find the trick for getting the dialog above to reappear - the closest I can get is the buy button below:

Ah … got it.

You have to:

  • root out the original email received at the time of sale
  • click on the activation link in that
  • receive a message to the effect that the activation link is expired
  • wait for a fresh activation link to be sent
  • use that.
2 Likes

Yes, it is.

A previous version of your database is kept in the same folder.

Preferences > General

we’ve had two reports of license issues. We’re suspending downloads of Hook 1.5 (fortunately only a very small % of users have downloaded so far; which is not consolation to those affected) until we sort these issues out. Very sorry for the inconvenience.

I suspect that the license issues are due to the database issues reported by Rob, but I have asked the dev team to figure this out.

The user still has access to their own data via export and now with automation. It is common for apps to store data that is implementation specific and not user-facing.

Having said that: this is something that was (is) hotly debated in the company. One view here is:

2). Database and the format in which the data is stored constitute a part of IP of CSA.

3). The format of data is subject to change as features and requirements of Hook evolves. Automation serves the API, a contract between user and Hook.

the other view here is that encrypting the database buys nothing for the user, and is not in the spirit of openness that characterized OS X (if not macOS). And it takes away an automation benefit that was nice for an automation tool to provide – we do after all wish to appeal to automators. Database access is faster than AppleScript. If users want to take the risk, why prevent them? Etc.

@quorm wrote:

locking user data away completely only leads to suspicion that CogSci is up to something with our data that we cannot monitor. May be as innocent as can be, but why hide?

a CogSci Apps response is that the data is stored on user’s computer. Hook’s connections to the CogSci Apps server are for license activation and script updates. Hook can be used on a standard alone machine without connection. Script updates can also be obtained via the app installer. We cannot control suspicion or attitudes; but you can learn about the founders on the website : we have been committed for nearly 20 years to understanding and promoting cognitive productivity on macOS. And we work hard to earn our users’ trust (the candor of this post is an example of that).

We can also point to Hook scripts being available in the app’s Script Editor as an example of the openness of Hook and our collaborative spirit. And now to Hook itself being automatable.

To take one example: OmniFocus encrypts its database. However, that provides users with value: protection of their data on a server. Since Hook does not store data on servers, the encryption of the database provides no value to the user, except to the extent they want to help CogSci Apps thrive in a competitive environment.

We recognize that there are different views on this topic given that we have experienced diversity on this issue ourselves.

No. The local sqlite cache of OmniFocus is:

  • unencrypted
  • visible to the user

Always has been, and is the basis of various utilities.

~/Library/Group Containers/([installation dependent character string]).com.omnigroup.OmniFocus/com.omnigroup.OmniFocus3/com.omnigroup.OmniFocusModel/OmniFocusDatabase.db

thanks for letting me know, Rob. I hadn’t peeked into it. When they said end to end encryption I thought it was local as well.

are you aware of any reputable (innovative) Mac software developer that encrypts their local database?

You are thinking of sync communication between devices.

The local db is not encrypted.

are you aware of any reputable (innovative) Mac software developer that > encrypts their local database?

No.

To reiterate what I mentioned above, we have decided to remove the encryption of the database. The next release of Hook 1.5 again . Because very few users had installed Hook 1.5 before we suspended it, we think it is better to release Hook 1.5 without code to export the 1.5 DB and re-import it. This will get Hook 1.5 out faster and reduce the risk of error. Those users will be able to use Hook’s export and import mechanism to recover any recent links.

To be clear, it is not for technical reasons that we are removing encryption. As far as we know, the code for that is fine. @RobTrew has reported loss of data which at this stage does not seem to us to be an issue with Hook. We will report about that in its forum topic and continue the investigation. As noted, we were internally ambivalent about encryption. We’re grateful to Rob and @quorm for initiating discussions on the subject.

2 Likes

Thank you for making this decision.

1 Like

And thank you for the kind words, @taonmatt . For the record, we released the update in Hook 1.5.1 Friday (day after this topic started).

As an aside to @RobTrew’s comment here, I do find the current license setup irritating to use, having just reformatted a few times. Would much prefer a straight up license key locally validated.