DEV Community: Jakub Gawlik

A Privacy Policy is a promise. Zero-knowledge is a property.

Jakub Gawlik — Mon, 26 Oct 2026 20:41:44 +0000

Why we built a team workspace around one question: what does a fully compromised server learn?

Most “private” workspace tools protect your data with a promise. The promise lives in a privacy policy: we will not look, we will not sell, we will not share. It may be sincere. But a promise is only as strong as the people keeping it, the staff who can reach the database, and the next attacker who gets in.

lockORG takes a different approach. It is a workspace app (notes, kanban boards, tags, todos and a journal) for small teams and individuals, and everything in it is encrypted on your device before it is sent. The server stores it, syncs it, and never reads it. Nor can it.

That is the difference between a promise and a property. A promise can be broken. A property is how the system is built.

The one question asked of every change

Every change to lockORG is judged against a single question:

What does a fully compromised server learn?

The answer must not grow. Here is what it is today. Imagine someone has the whole database, the image files, the logs and the server configuration.

Look at the left column carefully. It is not empty, and we do not pretend it is. More on that below.

Why a weak password does not sink you

Most encrypted products have a quiet weakness: if your key comes only from your password, a stolen database can be attacked offline, guessing passwords as fast as hardware allows.

lockORG’s vault key is derived from two things: your password and a 128-bit account secret key. That secret key is generated on your device at sign-up, printed once in a recovery kit, and kept on your devices. The server never stores it. So even with a weak password, offline brute force against a stolen database is hopeless.

Your password is never sent to the server either. Signing in uses a separate value derived through a different path, so a leaked login credential says nothing about the key that opens your data.

Private means private, even from your admin

In a team workspace, the natural question is: can my admin read everything?

Shared material (notes, boards, tags) is encrypted under a workspace key that every verified member holds. But your todo list and your journal are encrypted under your personal key. Other members, admins included, hold no key for them. The server will not even address another member’s personal rows.

What we do not claim

Honesty about limits is part of the design, so here is the list we would rather say before anyone else does:

Not “military-grade”, “bank-level”, “unhackable” or “100% secure”. Those phrases do not describe anything checkable.
Not anonymous. The server knows your email, who is in which workspace, when you write and how much.
Not protected against a malicious operator shipping malicious JavaScript to your browser. This is the known limit of any web client. Native clients with pinned cryptography are the long-term answer.
Not recoverable without you. Lose your password and your recovery kit and your data is gone. Nobody, operator included, can bring it back. (An optional recovery key gives you a second way in, if you create one.)
No two-factor sign-in at launch. It is planned, not shipped.
No real-time co-editing. That is deliberate: it would mean either a server that sees content or a far more complex protocol.

Every claim is a test

A security page is easy to write. What makes lockORG’s claims worth something is that each one is backed by a test that fails when the property breaks: published cryptographic test vectors, an authorisation test covering every API route, generated tests that try to reach across workspaces through every endpoint, tests that search browser storage for secrets after sign-in, and mutation testing on the security-critical code.

The security model, the threat model and the protocol will all be published. The threat model lists, item by item, the risks that are accepted and cannot be fixed.

lockORG will also be open source once a solid foundation is in place and the basic functionality has been brutally tested with early users. Opening the code is not a substitute for good engineering; it is a way to make the engineering inspectable. You will be able to read what the application does, verify the claims against the implementation, and hold us to the promises we make.

When the time is right, we would rather be checked than trusted.

How to Conduct Effective Code Reviews

Jakub Gawlik — Sun, 05 Jan 2025 14:28:27 +0000

Code reviews are an essential part of the software development process. They ensure that code adheres to best practices, is maintainable, and works as expected. However, conducting an effective code review can be challenging, especially for teams balancing speed and quality. In this article, we’ll explore best practices for code reviews that can help you and your team improve code quality and foster better collaboration.

Why Are Code Reviews Important?

Code reviews help developers:

Identify bugs early: Catching errors in code before it reaches production saves time and reduces costly fixes.
Improve code quality: Reviews help ensure adherence to coding standards, maintainability, and readability.
Knowledge sharing: Code reviews enable team members to learn from each other’s work and improve their understanding of the codebase.
Team collaboration: It’s a great opportunity to collaborate, mentor, and keep the entire team aligned on coding practices.

1. Focus on the Big Picture, Not Just the Syntax

When conducting code reviews, it’s easy to get caught up in the details—variable names, formatting issues, or small coding quirks. While these things matter, the big picture is even more critical. Focus on:

Architecture: Is the code designed in a way that scales well? Does it fit within the overall application structure?
Logic flow: Does the logic make sense? Are there any redundant or overly complex operations that could be simplified?
Performance: Will this code create performance bottlenecks? Could it be optimized for speed or memory usage?

By focusing on these high-level concepts first, you can ensure the code works as intended without being distracted by minor issues.

2. Be Kind and Constructive with Your Feedback

Giving feedback is one of the most important—and sometimes difficult—parts of code reviews. It’s important to keep the following in mind:

Avoid criticizing the developer, critique the code: Say, “This approach could be improved by…” instead of “You did this wrong.”
Praise where appropriate: Positive feedback on clean code or a smart solution goes a long way in building team morale.
Be specific: Instead of saying, “This doesn’t look right,” explain why something might be a concern. For example, “This loop might cause a performance issue when handling large data sets.”

The goal is to create a collaborative and supportive environment where everyone can improve.

3. Use Tools to Automate Tedious Parts

Automated tools can handle many of the repetitive and objective parts of a code review, such as:

Linting and style enforcement: Use tools like ESLint, Prettier, or RuboCop to catch styling issues.
Unit testing: Ensure all tests pass before even starting a review. CI tools like Jenkins, CircleCI, or GitHub Actions can automate this.
Static code analysis: Tools like SonarQube or CodeClimate can find common errors, security issues, and performance bottlenecks.

By automating these aspects, the human reviewer can focus on more complex and nuanced issues.

4. Review Smaller, More Frequent Code Changes

Large pull requests are time-consuming and harder to review effectively. A massive block of code makes it difficult to focus on key areas, and reviewers can easily miss important issues. Encourage frequent, smaller pull requests (PRs). This approach has several benefits:

Faster reviews: Smaller chunks of code are easier and quicker to review.
Easier to spot issues: Reviewers can dive deeper into smaller changes and catch potential problems.
Less merge conflicts: Merging smaller changes more frequently reduces the chance of complicated merge conflicts.

Make reviewing part of the team’s regular workflow so that it doesn’t build up into unmanageable tasks.

5. Ask Questions, Don’t Assume

If you’re unsure about a particular piece of code, ask questions rather than assuming the developer made a mistake. This approach leads to better understanding and open dialogue. For example:

"Why did you choose this approach?"
"Could you explain how this method works with the existing feature?"

By asking questions, you may uncover a new perspective, or you may point out something that was overlooked. Either way, it promotes healthy collaboration and learning.

6. Ensure Test Coverage

Code that isn’t tested properly is a recipe for future bugs. Make sure that:

Unit tests are included to verify individual pieces of code.
Integration tests are present to ensure new features work well with existing systems.
Edge cases are considered to avoid unexpected behaviour in uncommon scenarios. If tests are missing, suggest that the developer add them before approving the review.

7. Limit Review Time to Stay Focused

Code reviews can be mentally draining, especially if they take too long. Studies show that reviewers are most effective when they spend between 30 and 60 minutes reviewing code. After that, attention and focus can drop significantly. Encourage short, focused review sessions to avoid fatigue and ensure better results.

8. Leave Comments In Context

Most code review platforms, such as GitHub, GitLab, and Bitbucket, allow you to leave comments directly on lines of code. Make sure you’re using this feature to leave contextual comments instead of vague, general feedback. This practice makes it easier for the developer to understand what you’re referring to and speeds up the review process.

9. Approve Changes with Clear Communication

Once the review is complete, it’s important to communicate your approval or requests clearly:

Approve the PR if everything looks good.
Request changes and leave comments detailing the specific areas that need work.
Leave follow-up instructions for what needs to happen next, like adding tests or fixing a specific bug.

Clear communication prevents confusion and ensures that reviews move forward smoothly.

Conclusion

Code reviews are a crucial part of producing high-quality software. By focusing on the big picture, offering constructive feedback, leveraging automation, and maintaining regular, manageable reviews, you’ll not only improve the code but also foster a stronger, more collaborative team culture. When done right, code reviews become more than just a task—they become an opportunity for growth and learning.

Fork, Pull, and Push: A Step-by-Step Guide to GitHub

Jakub Gawlik — Sat, 02 Nov 2024 23:18:01 +0000

Originally published here

GitHub is the go-to platform for version control, collaboration, and open-source contributions. Whether you’re working on your own project or contributing to someone else’s, mastering the basics of forking, pulling, and pushing is essential. These core concepts allow developers to collaborate efficiently, manage project versions, and contribute to the open-source community.

In this article, we’ll walk through the process of forking a repository, making changes locally, and pushing those changes back to GitHub, all while using the pull request (PR) workflow.

What Are Forking, Pulling, and Pushing?

Before diving into the guide, it’s important to understand these three terms:

Forking: This is the process of creating a personal copy of someone else’s repository. Forking allows you to make changes to a project without affecting the original codebase.
Pulling: This involves retrieving updates from the original repository (or a remote branch) into your local codebase to ensure you're working with the latest version.
Pushing: Once you’ve made changes to your fork, pushing refers to sending those changes to your remote forked repository on GitHub.

Together, these steps form the basic workflow for contributing to a GitHub project.

Step 1: Forking a Repository

Why Fork a Repository?

Forking a repository is useful when you want to:

Contribute to an open-source project.
Experiment with the codebase before submitting your changes.
Create your version of a project that you don’t own.

How to Fork a Repository:

Find the repository you want to fork on GitHub.
In the top-right corner, click the “Fork” button. GitHub will create a copy of the original repository in your GitHub account.
You now have a forked version of the project that you can modify without affecting the original repository.

Step 2: Cloning Your Fork Locally

Now that you've forked the repository, you need to clone it to your local machine to make changes.

Navigate to your forked repository on GitHub.
Click the “Code” button and copy the HTTPS URL.
Open your terminal or command prompt and run the following command:

git clone <your-forked-repository-URL>

This command will clone the repository to your local machine.

Change to the repository directory:

cd <repository-name>

Step 3: Making Changes Locally

Now that you have the project on your machine, you can start making changes.

Create a new branch: It’s best practice to make changes on a separate branch, especially when contributing to a shared project. To create and switch to a new branch, run:

git checkout -b <new-branch-name>

Replace <new-branch-name> with a descriptive name for your changes.

Make your changes: Edit files, add new features, or fix bugs in your local environment.
Check the status of your changes by running:

git status

This command shows which files have been modified. 4. Stage your changes for commit by running:

git add <file-name>

Or, to add all changed files:

git add .

Step 4: Committing Your Changes

After making changes and staging them, the next step is to commit those changes locally.

Run the following command to commit the changes:

git commit -m "Your detailed commit message"

Replace the placeholder text with a meaningful description of the changes you made.

Step 5: Pushing Your Changes to GitHub

Now that you’ve committed the changes locally, you need to push them to your forked repository on GitHub.

To push your branch to GitHub, run:

git push origin <new-branch-name>

This command pushes your changes to your forked repository under the new branch you created. 2. After the push is complete, GitHub will display a link in your repository where you can open a Pull Request (PR).

Step 6: Creating a Pull Request (PR)

A pull request is the process of notifying the original repository’s maintainers that you’ve made changes and want them to review and potentially merge those changes into the main project.

Go to your forked repository on GitHub.
You’ll see a message prompting you to create a pull request for the branch you just pushed. Click the “Compare & pull request” button.
In the pull request form:
- Write a title and description of your changes.
- Include any necessary context to help the maintainers understand what your PR addresses.
Submit the pull request by clicking “Create pull request.”

Step 7: Updating Your Fork with New Changes

Over time, the original repository may receive new commits. It’s important to keep your fork up to date with these changes.

Syncing Your Fork:

Add the original repository as a remote in your local repository:

git remote add upstream <original-repository-URL>

Fetch the latest changes from the original repository:

git fetch upstream

Merge the changes into your local fork:

git merge upstream/main

Replace main with the correct branch name if the project uses a different default branch (e.g., master).

Push the updated changes to your forked repository on GitHub:

git push origin main

Conclusion

Forking, pulling, and pushing are fundamental GitHub concepts that allow developers to contribute to projects in an organised and efficient way. By following this guide, you’ll have the necessary skills to fork repositories, make changes locally, and submit pull requests to contribute to open-source projects or collaborate on private repositories.

The more you practice this workflow, the more seamless it becomes, making you a more effective and confident contributor to any GitHub project.