jvdongen's comments

As far as their public website tells (https://www.riec.nl/) the RIEC is about a targeted bundling of knowledge, experience and resources to better deal with the effects of organized crimes, instead of everyone working in their own little silo.

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...

My comment is made from the background of someone who has led the effort of bringing software development in-house, building a 20-odd FTE dev team, and is still leading it 3 years in.

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.

Postgres has a similar feature, if you chose ‘remote_write’ for the ‘synchronous_commit’ setting.

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...

This is a disingenuous comment at best.

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.

There was once actually an active effort to remove magic from Django: https://code.djangoproject.com/wiki/RemovingTheMagic

Exactly this. For the docker images we use in production, we fork the corresponding git repo, build our own image and push it to our own local docker registry and pull it from there. It's fairly easy to setup in fact.

You might be able to proxy the dictionaries from your own server? Unless something in the t&c's of the dictionary providers prohibits you from doing that of course.

Hmmm I've a distinctly different experience. In my experience their support is good and their engineers quite knowledgeable. Tickets are dealt with within reasonable time frames. If I really do need something to happen quickly, I can call in and have someone knowledgeable on the phone within 10 minutes, who often will do whatever is necessary right away. During a recent issue they had two engineers in two time zones working on it, to shorten the time to fix as much as possible (still took a long time, but it was a difficult issue so ...).

Basically. The idiomatic solution for this in python is:

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

Well, that's the million dollar/euro question isn't it? It's a bit hard to verify with all the secrecy going on. And arguably without some level of secrecy you cannot have effective intelligence. It's a bit of a catch-22.

In fact the Dutch owned New York once (then called New Amsterdam ;-) until they effectively traded it with the British for Suriname and some spare change.

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

Yes - it is called the "apple 12w usb power adapter" and costs $19 ;-)

"Non-intrusive" is the most important part here I think. Measuring productivity does not produce anything that adds to your bottom line directly. An often overlooked aspect of performance/productivity management is that there should be a nett benefit ...

In addition to templating, orm and routing there is also highly integrated i18n toolchain/workflow, built-in csrf protection, good session handling, well integrated caching and many more of such 'details'.

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.

Yes, I know, it's turtles all the way down, of course.

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.

I was not referring to your comment per se, but indeed your comment fits the general sentiment I was referring to.

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 ;-)

You're technically correct - it's all a matter of degrees of certainty. That does however not invalidate any of the points made in the article.

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).

True - but how is a web server with certainty going to decide which clients can be trusted (because they've a truly capable browser)and which are not to be trusted (because they have a vulnerable and compromised browser that just pretends to be capable and secure)?

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.

My point is relevant as he considered the problem of availability of a CSPRNG 'solved' - and it isn't until you also solve most of the other problems Thomas identifies.

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

This piece has surfaced before. Then and now I see people coming out of the woodwork with seemingly smart ideas about how it still should be possible to safely use crypto in the browser one way or another.

One of the things my company does is security testing of web applications. Regularly we encounter 'creative' use of cryptographic techniques (both in the browser and server-side) and each time it makes the hacker in us smile, because we know it is not a matter of 'if' we'll crack it but 'when' we'll crack it. Good crypto is a roadblock, bad crypto is just a challenge. And although it is very hard to decide if the crypto is 'good (enough)', the 'bad' is usually glaringly obvious.

With the current state of crypto in the browser - just forget it. That's what Thomas is trying to get across: forget it - if you think you've found some smart way around one of the weakness he addresses, you're very most likely wrong. And even if you seem to have got it right, you're probably wrong still without anyone realizing it (yet).

Same is true for building a crypto-system from primitives. Use what's out there, designed by the few people who know what they're doing.

Remember: from the defensive side you need to get everything right. As an attacker I only need 1 hole. That's what makes it "capital-H Hard".