one possibility is that some heavily indebted AI infrastructure company will be unable to meet its dept obligations, which will cause banks that become heavily exposed to AI-infrastructure related dept to tumble
This is just an implementation detail, a feature flag can very well be implemented with a Boolean in a database.
To me the main appeal of feature flags is that they allow to work on large features that often require months and many commits to finish in a main branch. This, at least to me, results in a more lightweight and more iterative development process. This contrasts with maintaining a separate branch, with perhaps separate deployment target for a large in-development features.
When I was doing Fast.AI Deep Learning course, I was surprised by the number of Python dependencies machine learning projects bring. Web front-end projects were always considered very third-party dependencies heavy, but to
me, the machine learning ecosystem looks much more entangled. In addition, unlike web development, which is considered security critical and has over the many years accumulated a lot of wisdom and good security-related practices, machine learning development looks much more ad-hoc, with many common software engineering practices not applied.
For example, at that time, one way to distribute machine learning models was via Python pickles. Which are executable objects with no restriction built in. Models in this format could do anything on a computer where the model was imported. Such an early 'wild-west' ecosystem can definitely make security compromises easier and resulting supply chain attacks more common.
There are many people in that ecosystem, who are not primarily software engineers. Some just learned some coding along the way. Some are mathematicians. Some are devs who are AI drunk or something. Some have the mindset of "code doesn't matter any longer, if it works it works". For many proper dependency management is just a chore, that they don't want to care about. These things come together in various ML projects, even though ML projects should be amongst the projects most focused on reproducibility.
An interesting variant of a web phishing attack is to combine the back button hijacking with information that comes from the HTTP referer header. HTTP referer discloses from which website the user is coming from, when the user click the back button, the malicious site can take the user to the site that looks identical (except for the URL), but is attacker controlled.
Recently I was wondering how viable it is to launch a niche, paid tool for Linux. I found that this is a very rare model, most tools are either just free, supported by sponsorship, supported by some paid cloud-based service that accompanies the tool, use an open-core model with paid add-ons.
I wonder if the decision of Little Snitch to make the Linux version free forever was also informed by this "no way to make money selling tools on Linux" wisdom or if there was another motivation. It seems that if any tool has chances of making decent money on Linux, a product like Little Snitch, which is already well established, with working payment infrastructure would be a good candidate.
Many from linux crowd are slightly paranoid and ideological.
I'm as a linux user very reluctant to install anything proprietary that has such sensitive info as my network traffic and would rather use opensnitch or any other foss fork.
The same time I don't mind to pay for open-source, I donate several thousands USD per year to FOSS projects. But I guess I'm in a minority here and if you make the whole stack open-source you're not going to make many sells really.
You call it paranoia, I call it zero tolerance for enshitification.
It's like the Nazi bar problem. You need to be vigilant to prevent the thing you rely on becoming yet another platform for Microsoft to exfil your personal data to NSA servers.
As the author of Little Snitch for Linux, I can tell you what drives us: we are a small company where people (not investors) make the decisions. It was a personal choice of mine, driven by a gut feeling. I'm curious about the outcome...
The Wikipedia page for Little Snitch indicates that it's written in Objective-C. Is that still the case? Before going with the new implementation, did you attempt (or consider) to port the current codebase (using e.g. Cocotron or GNUStep libraries)? If so, how good or bad of an experience was that?
Why is Little Snitch for Linux™ so hard to find from the company homepage[1] and the product page from the legacy app[2]?
Did the fact that you knew it was going to be made partially open source factor into your decision to develop a new, JS-and-DOM-based UI rather than having build targets for a shared, cross-platform codebase? (E.g. so that you wouldn't end up disclosing the source for the proprietary Mac version?)
Sorry, I overlooked that. I actually checked the license only to the point whether we can include it without other obligations and then downloaded what was offered as a download on either the web site or github, can't remember. I decided for the minified version because it's smaller. That's the purpose of minification, after all.
It's somewhat strange that they require the license to be reproduced in every copy, but then offer a download without it. But anyway, I'll prepend the license to the next public release.
> I decided for the minified version because it's smaller. That's the purpose of minification, after all.
Mm... the purpose of minification, when it's not (also) being used for obfuscation purposes, is tied directly to the execution model of Web apps—constraints that don't apply for desktop applications (even if they are implemented in e.g. the same programming language or using the same or a similar runtime).
App makers and browser extension developers who shoehorn all of the (frankly already very bad or at least questionable) "best practices" associated with the tooling that was created to deal with creating/maintaining/delivering SPAs and other browser-based products into applications loaded from disk are just fundamentally not thinking things through.
For a security-sensitive application like this one, where a show of nothing-up-the-sleeve is only a benefit, one should expect there to be _no_ minified blobs in use.
I'll post in our blog about the development background later. The Linux version shares no code with the Mac version. Only concepts. It's written in Rust and JavaScript (for the Web UI).
Our site is primarily aimed at Mac users, and most visitors skim rather than read carefully. If the Linux package were more prominent, Mac users would likely click it, struggle to install it, and blame us for the confusion.
And regarding your third question: No. The decision was made when I wanted to run it on our headless servers.
As a paying customer, I wasn't expecting this so thank you! Can you expand more on your gut feeling? Also, I have different security expectations on Linux vs MacOS. Would you ever consider open sourcing the daemon?
It's hard to expand on the gut feeling. I wanted to have the app myself. Adding licensing to the code, limiting functionality for a demo mode, and then wait whether Linux users would pay for it just did not feel right.
Regarding daemon open source: The future is hard to predict, even more with AI being just invented. I would love to make it open source, but if you can feed it into Claude and tell it to convert it to a Mac version, we could lose our income.
For the moment, we prefer to keep it closed because we cannot estimate the consequences of making it open source.
When OpenSnitch already exists and is free and open source, a paid tool that does essentially the same thing with a slightly different (perhaps more polished) UI would be quite a hard sell.
Both for the obvious cost reason, but also because manu of us don't like having code ok our computers we can't inspect, especially not in privileged positions like a firewall is. I.e. I don't care much if a game or the Spotify app is closed source, but neither of those run privileged, in fact I run them sandboxed (Flatpak).
I'm not a Little Snitch or Open Snitch user, I wonder if these firewalls are able to block requests done with the use of some other, allow-listed program.
Say I run a script `suspicious.py' and I deny this script from making any network requests. I also have firefox which is allowed to make any HTTPS requests. If suspicious.py does something like:
It depends. Little Snitch for Linux has a two level namespace for processes. It takes the process doing the connection and its parent process into account when evaluating rules.
Also: If an interpreter is run via `#!/bin/interpreter` in the script binary, it makes the rule for the script file path, not the interpreter. This does not work when running the script as `interpreter script`, though.
With the literal rules described it would not be blocked. A more detailed rule (in Open Snitch at least, not as familiar with the other variants) could match e.g. whether the process's parent tree contained the python binary rather than just if python is the process binding the socket.
Not necessarily (with Open Snitch at least), it just depends how complex you want to make your firewall rules and what the specific goal is (block this specific script, block scripts which try to do this activity, block connection to evil.net, block python scripts, etc).
The more granular one gets the more likely they aren't really meaning to ask how to do it in the firewall layer though. E.g. if we take it further to wanting to prevent python -c "specific logic" it's clearer what you can do in the firewall is not necessarily the same as what's practical or useful.
The allow rule for Firefox is what would suppress the prompt. You probably don't want to have a prompt for every Firefox connection though, so you'd need to come up with some kind of ruleset (or get very annoyed :D).
This gets even more involved when you consider things like loading libraries, there's also the impact of calls like OpenProcess/WriteProcessMemory/CreateRemoteThread (Windows-land versions, though I'm sure similar exists elsewhere).
The "good" Windows firewalls like Outpost and Zone Alarm used to have features to catch this, they'd detect when a process tried to invoke or open a running process which had internet access. They'd also do things like detect when a process tried to write a startup item. This went by names like "Leak Control" but it was basically providing near-complete HIDS features with local control.
The SELinux MAC policy should restrict which files and ports each process may access. In general, most modern distro have this feature, but normal users do not go through the rules training and default enable flag setup. =3
reply