Frontend Source

[m-spitfire]

Hello. As far as I can tell the frontend flutter source code isn't available, and instead there's compiled js in the source tree. Is there any particular reason for it?

[swalabtech]

Thanks a lot for your interest and support in Journiv!

You’re absolutely right, Journiv’s core is source available, and it currently includes a built Flutter web version client.
In its current form, Journiv’s core mission is to let you truly own your thoughts and memories, keeping them private, secure, and entirely under your control without relying on any cloud service or third party.

Right now, the focus is on stability, refining the experience, and gathering feedback during the beta phase by enabling user to own their memories. As of now there are no plans of making client's source available.

[GreenTentacle]

Since a major aim of the project is privacy and users often put sensitive things in journals, it'd be great to be able to verify end to end how the internals work. If the client's source won't be made available, maybe an independent audit or certification of some sort would help to ensure the privacy/security of the app.

[swalabtech]

Hello @GreenTentacle

I can understand your concerns so let me answer them in detail.

First thing first, why is frontend code not open source:

1. Open sourcing any code base require extra work and effort. With the limited time to work on Journiv there is only so much which can be done and the goal in this time is to do the stuff which is most impactful and needed and give users most value.
2. Journiv frontend is cross platform and mobile apps are not launched yet due to financially sustainability and support from community. Open sourcing frontend before it is officially launched in app store has risk around copycats see App Store guidelines 4.1. I am not sure how all of this work and I really don't want to spend time in dealing with it rather than building Journiv.

Now regarding trust and audit:

1. What a user puts in their Journal is stored in the database through the backend services. The user has complete ownership, visibility and control on the database. Every operation/access done on the database is in backend whose source is available on github. So the user can clearly see how their journal/content is stored and handled. Unlike a cloud/third party offering where the user has no visibility, ownership or control over their data.
2. The compiled frontend in JS code is what is shipped in docker image and is the client which calls all the backend APIs. This compiled frontend runs on user web browser and served by the FastAPI backend server which run on user instance. So the compiled frontend is totally running in on user machine and their visibility.
3. Because the frontend is a web application, it is not a "black box". Even without the source code, users have full oversight and control. See below how user can audit it.
4. One of the biggest myth around open source is that since something is open source it is trust worthy. For interested reader Ken Thompson's "Reflections on Trusting Trust" is a good paper which substantiate this. The central moral of the paper is that "You can't trust code that you did not totally create yourself". Thompons states that no amount of source-level verification can protect a user from untrusted code because the tools used to manage that code could themselves be compromised. Someone can read a open source repository but even a small script/utility these days depend on n number dependencies and libraries which themselves can be compromised intentionally or unintentionally. Many mission critical softwares purposefully avoid dependencies for such reason for example https://sqlite.org/whyc.html

Regarding

maybe an independent audit or certification of some sort would help to ensure the privacy/security of the app

First of all, most audit or certification possible are of no value as they don't do much. In today's era a user can just take the compiled frontend point any decent AI tool to it and ask it to audit/inspect it and get similar or even better result. AI are very good at reading compiled/minified code. The audits which have any value cost a lot of money. If someone is willing to sponsor such an audit for Journiv, I will jump on the opportunity to get it done. Please let me know if you have any leads.

But the good new is that Journiv doesn't just ask for trust; it enforces security through browser using standard protocols.

1. CSP: Journiv has strict CSP defined users can see it here. If user look closely they can see that all policy are defined strictly. It acts as a set of instructions for the user's browser, telling it which sources of scripts, styles, and data are "trusted. Journiv open-source backend sends a "security contract" to user browser. This policy explicitly tells user browser which scripts and data sources are allowed. For example, the connect-src directive ensures the frontend is physically blocked from sending user data to any domain other than user's own server. This itself end all cases of data exfiltration.
2. Additionally Journiv backend even exposes CSP report API so user can see the report of all activities.
3. Same-Origin Security (CORS): By default, Journiv serves the frontend and API from the same origin. This "Same-Origin SPA" mode is the most secure way to host a web app because it eliminates the need for cross-domain permissions entirely.
4. Trusted Host Middleware: Journiv has trusted host middleware. This is a gatekeeper at the HTTP level. It checks the Host header of every incoming request to ensure it matches user allowed domains (the one they set when configuring env). If a request comes in with a Host header that isn't in that list, FastAPI will reject it with a 400 Bad Request.

User themselves can Audit Journiv right now:
Because Journiv is self-hosted and runs in users environment, user have the ultimate power to monitor it:

Network Auditing: User can open their browser’s Developer Tools (Network Tab) at any time. They will see every single outgoing request. They can verify that Journiv is only talking to their backend and not "phoning home" to a third party.

Container Isolation: Since user is using Docker, they can run the Journiv container with strict firewall rules. They can block all outbound internet access at the network level, and the app will still function perfectly (except for external assets like Google Fonts which are allowed in CSP as mentioned above).

Frontend Transparency: The compiled JS/Wasm code is served directly by user's FastAPI instance. While it is compiled, it is not "hidden." It runs entirely on user hardware, under their visibility.

Self hosting is very powerful :)
Hope this help in providing some clarity.

(P.S. It took me ~2 hours putting all these details and to write this whole comment with references. This is the cost of open source :) )

[GreenTentacle]

Thanks very much for the thorough and thoughtful response !

[swalabtech]

Here is a concrete test case you can test Journiv's frontend to ensure the CSP defined is valid and working and the Journiv frontend cannot talk to any thing beside what is allowed in the config. This will clearly show any user that there is no data exfiltration which can be done by Journiv frontend.

Open your browser dev tool (F12). Open Console and run this

fetch('https://google.com')
  .then(response => console.log('Success:', response))
  .catch(error => console.error('Blocked by CSP:', error));

You will see something like this

A request made for "https://google.com" is blocked. The error clearly states CSP blocks it and why.

[swalabtech]

Another test a user can run

let img = document.createElement('img');
img.src = 'http://example.com/malicious-image.jpg'; 
document.body.appendChild(img);

Here we assume a "hacker" managed to inject a script or an image tag into the page, the CSP would prevent it from loading since the source isn't on the allowlist of CSP. See

[mikesir87]

Curious... are you interested in accepting contributions to this project? You have a fairly flushed out set of contribution guidelines, but those contributions are incredibly limited.

As an example, I've added the ability to import Journey entries (actually already have the API working and unit/integration tests passing), but am unable to add the frontend option to select the new provider. Having the frontend code not available makes contributions almost impossible.

[swalabtech]

Hello @mikesir87
Yes, contributions are welcome. Journey import has been requested here: #155

Journiv has been designed with backend first approach so all logic lives in backend and is accessible in full functionality through rest apis and now a limited set of features through admin-cli for convenience.

Journiv frontend is just a pretty (a guess so? with my limited frontend skills) wrapper on the backend rest api and no logic lives in it beside the minimal required ones and parse and present response. This architectural decision is made to keep the backend open for any client without lose of functionality.

You might be aware of some of the details below so apologies in advance for iterating the known.

You can access all backend APIs for development and contributions through curl, swagger ui, bruno, postman etc. For example you can go to journiv-domain:port/docs which will show you swagger UI and allow you to upload import file like the Journiv frontend does. You can login with your existing credentials. This will allow you test the import completely without making curl rest api calls with a convenient UI.

You can also do through Bruno or other such client.

Also imports are in admin-cli which you can use too https://www.journiv.com/docs/guides/admin-cli if your journey import is large in gbs then using the admin-cli is recommended.

If all works out and you decide to contribute back the code please open a PR. Once that is merged I can add another option box in the UI for Journey.

Thank you.