The "interventions" are basically the forming and supporting of work groups / special interest groups around a specific organized crime phenomenon, with the intent of devising an approach to deal with the specific phenomenon. They publish a report of those so-called interventions here: https://www.riec.nl/documenten/publicaties/2024/12/18/interv...

I'd not bring everything in-house at once unless you really have to. Your fear that the devil is in the details is very much justified (I have stories, boy, do I have stories ...). However, in your position I would definitively start building a dedicated tech team. That allows you to start developing real solutions to solve pain points in a way that feels less like "filling the gaps" and more like "the first steps towards a better future". It also may make you a better, more informed customer which may perhaps help with your current vendor as well. It also gives you something to fall back on if the proviable shit really hits the fan with your current vendor.

Do not underestimate the importance of product management. Product management drives your development team. If you now use a basically off-the-shelf product, this is likely taken care of for you. Or not, given you describe the vendor as stagnant. In either case, you need to have that covered well.

One-is-zero: do not rely on single individuals, build a team. At the leadership level you'd want at least a product lead, business analyst, cto and a senior software architect. Make sure they work together as a team and that there is healthy cross-over in expertise/experience so that people can cover for eachother. In-house, not contracted.

I'd advice against fully outsourcing to an agency. You can contract a development team, and depending on where you are located that may be the most realistic option, especially in the beginning. But make sure you are at the steering wheel and have the people and experience in-house to use that wheel well (see previous point).

Invest in boring things like documentation and testing right from the beginning. It will pay for itself many times over. If you let it slide, you'll never catch up and you'll pay for /that/ many times over.

Other than that there's probably a lot I've learned from my adventure so far, but I find it typically difficult to assess what the lessons learned are unless someone pokes me with the right questions. Feel free to reach out at my HN username @ mailbox.org.

You can also mix and match sync/ascync options within a cluster and even between individual transactions.

Recent versions of Postgres have a really flexible replication configuration to cover a whole range of requirements. See e.g. https://www.postgresql.org/docs/current/warm-standby.html#SY...

As explained in the docs you link to, Postgres has both synchronous and asynchronous replication modes.

In asynchronous mode availability is favored over durability. Which means commits can get lost when the primary goes down in an uncontrolled fashion.

In sync mode that will not happen at a cost to some performance.

It’s the same trade-off any distributed system has to make, and the user gets to make the choice.

  def fn(x, my_dict=None):
     if my_dict is None:
         my_dict = {}
      ...

And that whole Dutch East Indies and Indonesia thing still has some repercussions till this day.

All those things by themselves could be considered trivial and could be gotten from many individual libraries - the level of integration and polish you encounter with Django is anything but trivial though and takes real time and effort.

I've recently had to make a choice for a Python based application platform/environment and have chosen Django (again) despite having no use for the ORM and ORM-using contrib modules. Simply because all the other things are there and work together beautifully without me spending any time on code that is not directly related to my goals.

Still, I think that "but here we are aiming for practical applications not a philosophical debate about how everything is just an illusion." is a dangerous statement. Some people would say the same about something like sql injection, or cross-site scripting (Really? Yes, really, I encounter them on a regular basis).

With security issues the border between 'practical' and 'not practical/philosophical' depends on your threat model. If the kind of adversary that is able to compromise your JS engine does not appear in your threat model you can ignore the possibility of your JS engine being compromised and your solution may be good enough. If however that kind of adversary does appear in your threat model you do not have that luxury and your solution is not good enough.

That's not philosophical, that's real world practical.

And I think that localStorage is indeed literally no better than server-side storage. Whether it is any worse depends on the situation - but better it is not.

"This ignores the scenario of app deployment models like Chrome Packaged Apps, in which the JavaScript code gets downloaded up-front and then is only used locally. Since you don't re-download the code every time, you only depend on the security of the code once, up-front, instead of on a continuous basis. You aren't affected by server compromise (well, no more than compromise of your OS vendor, but surely you aren't arguing that we might as well send all our keys to Microsoft, Apple, and Canonical)."

It's true that you do not re-download the code every time. Still, the trustworthiness of the code you received initially depends on the trustworthiness of the server you received it from.

So you say, "but what if I have reason to trust it initially and not later on?", e.g. when the government comes knocking.

Well, there are two things to keep in mind in that case:

a) you download other stuff with your browser. Stuff that can influence the environment where your secure and trusted packaged app runs in. See also comment of zimbatm - even if it is not formally meant to be that way, in practice there are bound to be ways around any limitations - sandboxing in browsers is still nowhere near perfect unfortunately. Server security is not entirely peachy either, but at least on a properly secured server only a limited, carefully screened set of applications is allowed to run which makes things hell of a lot easier.

b) Chrome packaged apps support auto-updating, so unless you take steps to prevent that from happening, you're never sure you're running the same version today as you did yesterday. Again, trusting the server to serve you a trustworthy version of the app repeatedly. And if you're trusting the server already, local storage is no better than server side storage.

So I guess you could say local storage is better than server side storage (for some definition of better) if you run one and only one packaged application ever in a specific installed browser in an isolated environment. The browser + locally installed web app then effectively becomes a natively installed application without an Internet dependency. More secure indeed, but kind of defeating the purpose of that whole web thing ;-)

If that native C application runs on a server that is fully under your control you stand a far, far better chance then when that native C application (say a web browser) runs on some computer not under your control. Especially if that native C application is explicitly written to accept run-time addition of random third-party code (aka browser extensions).

Of course it may be possible that one day there is a way around that issue, but currently there is not. Not even academically let alone practically. Hence Thomas's next remarks about the impossibility of 'graceful degradation' for crypto-in-the-browser issues.

And it was not my intention to 'bash' anyone - if it came across as such I apologize.