"The full feature set, including connection blocking, extended traffic history time ranges, advanced display and filtering options and more is available as an in-app purchase."
So this means as a company using MDM, I cannot purchase it for all my employees.
MacOS devs who see IAP and subscriptions as the only purchase paths are leaving corporate purchases on the table.
We choose software we can pay for. We are fine if it's priced fairly to support the developer and the work to get to the next version. We are fine paying for the next version too.
But IAP or subs paid for by company? Apple itself doesn't support that on Macs managed using their corp device management. (And no, the user cannot buy it and expense it either, IAP/subs are disallowed on managed Apple IDs.)
Indie MacOS devs, all you have to do is also list a full retail version. You will have buyers. $2.99/month sub also sold $79 full price and a major update each 2 years with a new full retail version number? You will still have buyers, and you'll have the cash now, instead of over the 2 years.
The problem is: you can't do upgrade pricing in the app store. So your users would have to pay full price for a 2.0 upgrade.
You could of course buy outside the app store - but you don't want that. And I don't want that, too (as a dev selling my software). Purchase orders are a PITA and I have been shafted by enterprise more than once. They get their licenses, I'm not getting my money because they just don't pay. Sucks to be me.
As much as I don't like what apple is doing with their app stores I hate enterprise even more. I don't want enterprise as a customer - no matter how much they promise to pay me. (And that sentiment is pretty universal with anyone who had to deal with enterprise customers). Sucks to be you, I guess.
> The problem is: you can't do upgrade pricing in the app store.
That is not a real problem.
Many apps handle this by checking for a prior version and giving a discount (see Omni or Affinity approach), by having an upgrade window (e.g. 1Password approach before switching to subs outside app store), or by just charging full freight again (which nobody who values software actually minds, and enterprises that budget full retail software per person/year anyway definitely don't even think about).
If you charge $X a month over time and think that's fair, you can charge $X * 24 every two years, and let people who dislike the upgrade treadmill just sit on the old version till iOS APIs shift out from under them.
In the meantime, you had the two years cash up front which funds future development.
> They get their licenses, I'm not getting my money because they just don't pay. Sucks to be me.
What are you talking about? The Apple Business Manager UI is a web based app store, one searches for the app, clicks to pay full retail, and you get your full money, immediately, the same as you get your IAP or sub. Meanwhile, the app is bought in bulk, assigned to the employee base, and you just sold 15,000 copies at retail by having a full price version when you otherwise couldn't sell any.
You don't talk to the enterprise and more importantly, I don't have to talk to you, or any other indie dev with weird bespoke purchasing processes not already approved by the enterprise procurement and expense systems.
> you just sold 15,000 copies at retail by having a full price version when you otherwise couldn't sell any
That's wishful thinking. No business buys 15,000 copies of an app just like that.
My experience from the point of view of an independent software developer is that:
1. The company will email you to fill out some forms because they are considering a bulk purchase. You get all excited and jump right into filling out their forms.
2. They will ask for a volume discount.
3. They will ask for some more forms to fill out. They'll casually mention that they are looking at competitors as well. Okay, maybe now they can finally make the purchase...
4. Ultimately they will order 5 licenses and move them around between employees as needed.
In the mean time, 50 private customers will have bought a license without ever contacting you.
If there's a market where businesses randomly buy 15,000 copies of an app let me know and I'll switch to making apps in that market.
(Also, in my experience, most bigger companies don't use Apple Business Manager, they buy software via resellers like Software One)
Can't agree more. Been through the "please fill out those forms to register with our software reseller" thing too many times. In the end they order 2 licenses.
Then there's those who absolutely need to send a purchase order with a 90+ days payment goal for what amounts to be $150 or so. 75% of the time I agreed to that I have never seen any money.
The worst are K12 districts who expect you to fill out government forms (+ extra forms because I'm not from the US) then to order 1 copy they share between all their students. I just resort to sending them a free license they can legally use for all their students.
Then there's the notable exceptions. A social network site for professionals somehow manages to just order 20 licenses with a credit card. Same goes for a search engine company. Or a certain operating system vendor. No fucking PO required. No forms. They just get a corporate credit card and use the Fast Spring webshop I set up.
I'm really done with corporate/enterprise bullshit. They can go to my competition and shower them with stupid purchase orders for 15,000 units. I prefer to keep my sanity.
It is to me. I don't want the app store full with different versions of my software that will confuse any prospect buyer.
I also don't want my main customers to feel shafted because every N months I just push out a new app at full price. What happens to the people who bought like 2 weeks ago? I have only 100 promo codes I can send out - and those who use promo codes can't write a review.
Ah yes, reviews. My $50 Mac App has over 700 reviews (4.8 avg rating). It took years to build that up. I'm not throwing this away just because some corporate admin waves the idea of someone purchasing "15,000" units (which is never going to happen anyway). Heck if you really intended to give me $750k you could contact me and I'd put up a special version of the app just for you. But guess what: You're never going to buy 15k units from me. Neither is anyone else.
So, my main customers are single users who are not in a corporate setting. They are my main source of revenue. I'm not going to fuck with them to get into the "maybe corporate is going to give you a million dollars" lottery. I've been doing this software business shit for too long to be that naive.
You're barking up the wrong tree here. Go to Apple and complain why you can't purchase IAPs with your magical Apple IDs.
But is this possible with a one-time-full-price app in the App Store? It’s not, right? Once someone pays for your app, they get all updates forever. I think that’s what the person you were replying to was getting at.
Basically, there are 3 major purchase models for software:
1) I’m buying a forever license
2) I’m buying this major version only
3) I’m subscribing to this software on a monthly/yearly basis
The App Store only seems to support 1) and 3), but not 2). If you want to do 2), you have to roll it yourself outside of Apple’s infrastructure. Which means sending your own invoices, setting up your own key mechanisms, and all of that associated pain
Happens all the time. You rename v1 to 'AppX 1', and publish v2/latest as just 'AppX'. Would be much better if the App Store had paid major updates built in, but this is good enough.
[Except when they decide to spam the legacy version with upgrade nags, gray out the app icon and put a bright red 'OLD' tag on top - looking at you, Blinkshell]
If you think corporations will buy from the third party store that isn't built into the Apple Business Manager (plus MDM of choice) that lets you open shrink-wrapped Macs and hand them to the employee with all their apps self-installed, think again.
This is one of the things that bothers me about Apples app install process; I reinstall my OS often and when I start installing software via App Store, Apple displays the price and the notification that you will be charged never giving the user prior indication of whether the app is a new version that you will or will not pay for. With all the brilliant heads behind Apple you would think they would be able to get the UX right on this.
I have the same exact same issue. Managed Apple IDs are a joke, the only use I have for them is to backup the contacts of my users so that when they get a new device they get their email autocompletion back. Keychain sync is disabled. Using the App Store in any capacity is impossible. There's absolutely no way to use in-app purchases/subscriptions. I got almost laughed at by an Apple rep the other day when I asked if it was somehow possible, as an Apple Business administrator, to purchase extra iCloud storage space for a user.
This is a great article to send to those developers that only use IAP to license the complete version of their apps:
Yeah managed Apple IDs don't work for most enterprises as they require the email and UPN to be the same. In our configuration this is different for a very good reason. We're not going to change 200.000 users just because Apple doesn't support something.
Also manually resolving duplicate accounts at this scale is impossible.
Managed Apple IDs were a nice idea but the implementation sucks. I was hoping they'd fix them after release but it's been like 4 years now and it hasn't happened.
> turn his company into a very specific type of enterprise software
They would just need to release a pro version of their app you can pay upfront in the App Store, and then release paid updates later following the same model. No need to "turn a company" into anything.
You just release a new version of the app at full price. Like Silvio Rizzi has been doing with Reeder for 5 major versions since 2010, pretty successfully.
So you litter the App Store with N + 1 versions of your app — where N is the number of major versions you’ve released plus the subscription version for non-enterprise end users. I mean sure, that may work, but it’s really ugly and it’ll probably confuse end users when they search for your app. Apple should account for this model in a better way.
I searched the app store and was only able to find "Reeder 5". As someone who hasn't purchased 4, it doesn't show up, so new users aren't confused. Old users are presumably able to figure out that the idea that the bigger number is the one they want.
As for "littering" Apple's app store, it's just rows in a database, of which there are millions. Waste sucks, but we're not talking about a meaningful amount here.
What OP is talkin’ about is “The Way” that Apple requires such devs to interface with its (not their) Business customers via its AppStore. Mac-only devs do have to cater to those customers whether they have them direct or resell thru MacAppStore, or they don’t make it very long. The problem with selling direct is that the Business customers all want the conveniences of only dealing with a single vendor (the Apple) since that’s possible now (via the MacAppStore).
Platform gatekeepers in 2023 should simply vet third-party app stores and award them a Certificate once they pass anti-Fraud. The hardware itself should otherwise run open source firmware that only enforces UL/FCC certification requirements and basic UI standards (be they audio, video, or network). If Apple wants to go beyond that, they can setup Claris or something with its own such Certificate to compete with Amazon and all the other potential third-party ecosystems. This hunk of garbage may look ridiculous, but cast it in an Al custom NC enclosure with miniLED and an m2ultra and…
https://www.worthpoint.com/worthopedia/brother-geobook-nb-80...
People are probably going to be confused between this and the "full" version of Little Snitch. My take on it is that Little Snitch Mini is something you can install on a non-technical friend or family member's computer whereas power users may want to stick with the existing offering.
I say this as a long time heavy user of Little Snitch. It's very annoying when you first get it installed, but it provides really useful control over what installed software is getting up to. After a time you settle into a natural rule set for your personal patterns and only see alerts when new or updated software tries a network connection that hasn't been seen before.
"Mini" strikes me as much more of a fire-and-forget product, which I appreciate but won't personally use.
I've always thought this should be a feature in an OS for advanced users. Combined with some OS level security optimizations it could be quite a powerful security feature for the paranoid and at-risk.
I haven't tried mini but there's probably plenty of UX gains in between the standard Little Snitch fine control approach and the UBlock Origin style community curated defaults where control/customization is optional/on-demand.
Completely agree. Occasionally I run Charles Proxy[1] on my iPhone to analyze network activity and am disturbed by what I see. Software shouldn't be able to open arbitrary network connections without user consent/control, but we're not there yet to a large enough degree on mobile unfortunately.
The reality is that this sort of control would only be attractive to a very very small fraction of users, and no, not just because ‘people don’t care about privacy’ or whatever. There are just very few situations where someone is going to be able to look at this sort of data and do anything meaningful with it, especially when a) most apps are justifiably internet-connected, and b) the homogeneity of public cloud infra means you can’t really tell anything apart from endpoint alone.
A good set and forget option for the non-tecnical or those that can't be bothered is https://www.iantispy.com, basically just does it's thing and doesn't nag to upgrade.
Yeah nice one... Little Snitch is made in Austria and has email for support. The one I suggested is made in Australia and also has email for support. They are both offered by registered companies with their relevant registration numbers shown on their respective sites. Both have a privacy policy and a terms of service. Both "have complete control of your system" (whatever that even means, neither requires elevated privs). Seems pretty standard. iAntiSpy is also on the App Store, so there's that too.
Yes, but these days commercial OSes are seeing a hefty uptick in "first party malware," so to speak, making a third party audit attractive for reasons completely independent from technical integration.
Anything external to the OS level is doomed anyway, from the security standpoint. APIs offered to the good guys can be misused by the bad guys. You see this with all those snakeoil virus scan offerings which dramatically increase attack surface (exploited regularly, but that's not what Symantec an friends are telling you).
Plus, anything external to OS level is easier to trick into not seeing what you are doing. And again, if sth external can install itself so deep into the OS that that's hard, then the bad guys can do that too and hide.
> I've always thought this should be a feature in an OS for advanced users. Combined with some OS level security optimizations it could be quite a powerful security feature for the paranoid and at-risk.
I agree, by integrating it with an OS with good sandboxing you can provide some powerful security benefits, otherwise the main use cases I see are marginal privacy improvements by blocking telemetry from non-malicious apps, or reducing bandwidth usage.
Android does a pretty good job of this with its sandboxing and the network permissions for apps, and you can view the data usage per app in your settings.
Little Snitch is great, but it does a bit too much for my liking. I've been using LuLu [0] which is a free product from Patrick Wardle, and I'm pretty happy with it. It mostly stays out of the way and I just need to approve new connections the first time I run an app.
I've seen this recently, but only in the last few months, after years of using Little Snitch with Spaces, so I think it's a new thing either with the most recent version of Little Snitch, or macOS Ventura.
I wrote w LS support, it is a Ventura-related issue. They've made a request, but it appears Apple has yet to address the problem.
This, unfortunately, is a major problem for my use of LS. Interrupted connection attempts happen silently and result in different behavior for each app they affect.
I've had the most problems with requests from pycharm, where the binary is updated regularly and needs a bunch of re-authorizations.
I'm ready to give up on Spaces, it is so poorly supported by Apple at this point.
I think so? If that's what the thing is called when I swipe between desktops. I've only used LuLu on this machine though, and it seems to have no problem (though I guess I wouldn't notice if it wasn't popping up sometimes).
One thing I have noticed with LuLu is that the connection attempt sometimes shows the address of my VPN server rather than the actual upstream destination address of the request. But sometimes it shows the upstream - I'm not sure what the pattern is there.
Yup. They have an FAQ on the subject, and claim it's a Ventura bug and not one of theirs.
I've filed a bug report with Apple, for all the good that will do.
What's weird, annoying, and frustrating is that it will work correctly for the first day or two after a reboot, then start exhibiting the bad behavior. Once the "wrong desktop" popups start, they continue until the next reboot.
I was like "ohhh good reminder, need to install that again". Then I remembered and checked that I already have it installed ... it asked me for a connection today as well. Speak of automatisms in your daily life haha
I have been a Little Snitch user for a long time, but I am still very much interested in Mini. When an App Store version of something is provided, I prefer that because of the mandatory sandboxing.
The most important property is that the app cannot read/write arbitrary files/directories in your home directory [1]. All access is mediated through privilege-separated open/save dialogs or drag and drop (which creates a link to a file/directory in the app's sandbox).
I do trust Objective Development (the makers of Little Snitch), but with any application processing untrusted input, there is always the risk of compromise and its good if the compromise is limited to the sandbox of the app.
[1] Though access to certain directories also requires confirmation for non-sandboxed apps in recent macOS versions.
I bought Little Snitch long ago but managed to squander my license a couple of years later. Mini is unfortunately a subscription app, which is something I these days consider a hostile/unfriendly business pattern. I won't be going back. LuLu is a free alternative.
That's surprisingly modest. 3-4 years of subscription approximately being equal to a license sounds reasonable.
The real question is, is little snitch rent seeking? Given what happened after Catalina, I am giving them the benefit of the doubt at the moment. Paying for updates before receiving them definitely creates a conflict of interest.
Having looked at their website and seeing SKU-ification (Cutting a product different ways to try to hit different price points) and other business over product decisions, I am definitely feeling shaky about the future of little snitch. SKU-ification is 10x the red flag that a subscription model is.
It's worth considering that viruses now days will check and see if programs like this are running and then delete themselves rather than execute the payload.
> 3-4 years of subscription approximately being equal to a license sounds reasonable.
Which is probably why the apps on the App Store which offer both subscription and lifetime pricing tend to have the latter at about 3 times the cost of the former. But Little Snitch Mini does not offer that choice.
I’d be willing to pay more than 40$ for a one-time purchase of Little Snitch Mini, but there’s zero chance I’ll do it as a subscription.
Lifetime pricing / one-time purchases seem to be a double-edged sword for app sellers.
You satisfy users who are happy to pay a large amount upfront by they are also likely your most enthusiastic customers. So in essence they would be the customers who would probably pay more than 3 years of subscriptions over the period the lifetime payment covers.
Users who aren't that enthusiastic are more likely to not use the app for long periods and also unlikely to pay a large upfront cost.
Your most enthusiastic users are also the ones who help you get more users. They hype your app to others and get the less enthusiastic to buy or subscribe. So by not satisfying the most enthusiastic you’re denying one of the strongest word-of-mouth and recommendation channels, which also makes you lose the less enthusiastic.
Well, back in the day the FF devs said "no" to background-position-x and y in CSS (when we didn't had HTTP 2 and we used CSS sprites as a way to load websites faster by decreasing the number of connections).
My reaction was to "sabotage" FF users by prioritizing IE and Chrome and not actively testing my websites in FF, but only waiting until users reported bugs.
My thinking back in the day was: Why would I write N times more lines of code for a browser that had way less market share than Internet Explorer, especially when Chrome was faster and worked better?
By the time Firefox corrected course and prioritized parity with other browsers (ie. the -webkit fiasco), their market share was already an order of magnitude smaller.
15 years later, I don't feel proud of my actions, but my own conclusion is that every individual action added up. Now I feel sad to see Firefox with less than 3% market share because the damage is irreparable now.
Those are massively different scenarios. Off the top of my head:
- Mozilla doesn't derive its revenue directly from users.
- Mozilla is/was competing with a corporation with vastly more resources on every level. More engineering resources, ability to leverage other parts of its business to promote/favor Chrome, and fairly direct financial control over Mozilla.
- Mozilla's wrong moves aren't related to asking people to pay - they have at various times alienated or disappointed developers and end users.
Also worth noting that Firefox has artificially been blocked from competing on iOS (as has Chrome, but Google has its own mobile OS...) - so that's been a factor in their declining share that has little to nothing to do with their "neglecting" anybody.
There is value in advocates, but I'll say again: it tends to be overstated. And I hardly ever see self-professed enthusiastic users actually arguing for price increases / changes to support the development that generates the products.
It would be so refreshing to see self-professed enthusiastic users actually lobbying for people to pay for what they use instead of constantly tearing down companies trying to stay afloat.
I know the subscription model is a problem for end users as it spreads to more and more apps and services. The lifetime license model is a problem for the vendors. Especially for something like macOS where Apple releases a new OS every year. Right now shops that support macOS have to support like three macOS releases + two hardware architectures + the upcoming macOS.
Just how many users can an "enthusiastic user" convert to paid to make it worthwhile, if it ties the company's hands in terms of changing its revenue model as the world changes? Especially when that user is actively advocating against revenue?
It’s a tricky one. I feel like enthusiastic users’ recommendations (browser tabs!!) is what grew Firefox in the first place, but also what killed its market share as users became enthusiastic about Chrome instead (fast! crashes limited to one tab only!!).
These days, Firefox just isn’t better than it’s competition in ways that large numbers of people care about, alas. In fact, there doesn’t seem to be any big cohort of users enthusiastic about any browser in particular right now. I doubt Mozilla can fix that easily. I think it’ll take the next revolution in browser tech (whatever that is).
Furthermore, people who paid a lifetime subscription are presumably less likely to switch to a competing product without a good reason, because they already paid for one.
I see both sides. This dilemma is capitalist hell.
Why is obdev sku-ifying their product? Because the incentive model for selling a license means that the market can saturate and there is a lack of recurring or stable income/income safety for the dev. In order to get new spikes of income, a new product is generated. If the market for a particular license becomes saturated, how will they make more money?
Licensed based sales incentivizes creation of new product and disincentivizes incremental improvements on already complete products.
On the other hand, subscription models incentivize rent seeking. If money is coming in, there is no reason to do more work. Income is not dependent in any way for work done, except maybe compatibility adjustments.
So a license is a wonderful model for the buyer and not so great for the seller. A subscription is awful for the buyer, but too good for the seller.
So what kind of payment method/pricing scheme, keeps the developer engaged in improving the product, but doesn't incentivize rent-seeking?
How would you price things if you were the seller?
A subscription model is not rent seeking. Most developers continue to work on their products and continue to provide customer support etc. If they don’t, you can simply stop paying your subscription.
The lifetime value per customer isn’t infinite either. Most people don’t use a single software forever. A subscription kinda slices the LTV up and puts a premium on it for long-term users. It is an increase in price, hence every company loves it, but this isn’t rent-seeking.
> If they don’t, you can simply stop paying your subscription.
No, you cannot, because you completely lose access to the app. If it outputs a proprietary file format (e.g. Adobe apps), your data becomes hostage to the subscription even if you do not need new features, can no longer afford the price, or the developer changes the terms.
I didn't say it is rent seeking, I said it incentivizes rent seeking. It incentivizes taking money without creation of new value. Subscriptions weaken the relationship between receiving money and creation of value. Money is received whether value is created or not.
You can look at the app store to see all kinds of rent-seekers, so it is happening. Not all subscriptions are rent seeking, but I have a hard time imagining how someone would rent seek without charging via subscription.
>So what kind of payment method/pricing scheme, keeps the developer engaged in improving the product, but doesn't incentivize rent-seeking?
We had that. And it worked for decades. Paid major updates. Users got support and bug fixes for their paid version and devs were hell motivated to add new features for the next update.
I'm not sure if the Jetbrains model backfired with the Ukraine war, considering most of the dev team was Russian and they decided to close the Russian offices.
I remember that the launch of the 2022 versions had a drop in quality, I don't remember when was the last time I had crashes in a Jetbrains product, but with the launch of 2022 versions crashes occurred on a daily basis to the point I really considered cancelling my subscription, and I activated for the first time the option to block updates in Jetbrains Toolbox.
Months later they launched their promotion to keep the current pricing for 3 more years and I renewed. I acknowledge that promotion was a genius move by them, but I'm unsure if that promotion was a result of a drop in income for them.
I like this post. It is honest. Are you OK with no upgrades and no new features? That is one advantage to the subscription / cloud-y model. That said, I agree with your sentiment. I usually stay away from subscription products.
It is so interesting to see this line of thinking. I am sure it comes with purchasing power or local spend vs saving culture. I mean I genuinely find it interesting. Because subscriptions pile up. They do.
I saw this phenomenon, with horror, devour/take-over note-taking and journal app scenes in almost entirety (except some open source react native/hybrid apps).
> It's worth considering that viruses now days will check and see if programs like this are running and then delete themselves rather than execute the payload.
Wait, is this true? Do you have any resources backing this up. This would be a good protection mechanism if you can distill it to the minimum footprint to trigger this self destruct on viruses.
For windows it is true. I don't know if there are mainstream osx trojans, but I don't see why they wouldn't have the same behavior.
There are services like crowdstrike where you can upload a trojan, it will then run the trojan in a VM to try to see what it does. In response, trojans try to detect if the system they are on is a vm and if it has sufficient power (lots of ram, lots of cpu, age of installation/uptime) rather than minimal power as well as try to detect of the machine is capable of malware analysis or detecting it through installed tools (is python installed, etc.).
From first hand experience manually reverse engineering some e-mail trojans for fun, I can tell you it is true that at least some e-mail trojans will:
1. Check the resources of a machine to be reasonably confident it is not a honey pot/profiler
2. Check what is installed to be reasonably sure the owner is not technical
If you want to do the same, go to your spam folder and find a VBS trojan and start reverse engineering it. It's surprisingly easy and kind of fun, I estimate that an engineer with 1 year of experience and a solid handle of the command line could probably take apart a simple trojan in 1-8 hours.
I tried to use google to find a nice article to read of a breakdown of a trojan, but google seemed determined to return general population level results rather than technical/professional ones.
I think the point is that after 3 to 4 years, a new version of the perpetual license version would be released and you would spend that amount to upgrade anyway. Of course you could choose no to upgrade, but that’s not always an option when support for new macOS versions are not available in the older version.
That business-centric and artificial way of "shedding skin" is sometimes the case. In my experience the move to a new software piece just to get a reason to drop previous licenses - e.g. "BigApp 2" - is thankfully still not the common rule.
I've been using Little Snitch for years, and it's probably the most important software on my computer. However, I've noticed a problematic trend in modern software development: developers are using the same hostname to serve both functional and non-functional web APIs.
For example, let's say that Apple's Xcode sends harmless data to their telemetry service at telemetry.apple.test. Even though the data is anonymous, I still choose to block it because I believe in protecting my data. But then, I realize that some features of Xcode, such as CI/CD, no longer work. It turns out that Xcode is also using the same domain to host an API for their cloud CI/CD offering. (hypothetical example)
I've been trying to solve this problem by routing my network traffic through my own software and manually inspecting the traffic from time to time. I redirect non-functional HTTP requests to /dev/null and functional requests to the corresponding website. It works, but it's not a scalable solution.
So, I have a feature request for the Objective Development team. Could they please implement an option to view the raw HTTP request in the alert window, especially if the network connection is to send an HTTP request? Sometimes, it's hard to decide whether to click “Allow” or “Deny” based solely on the hostname and port.
This isn't some new "problematic trend". A website serving all kinds of requests from a single domain name has been how things have worked forever.
Pages making cross-origin requests is in fact a new phenomenon, and has been widely adapted by the ad industry simply because the ad server cannot trust the content host to report its own ad view/click-through numbers. If the server doing the data collecting or ad serving is the same as the one providing the content, there's zero reason for them to be on different domains. And for all these cases any kind of network-level blocking is always going to be ineffective.
> Could they please implement an option to view the raw HTTP request in the alert window,
This would be very, very hard to do well. First, for anything that doesn’t use standard libraries for TLS it’s simply not possible. And for things that do, you’re putting this software in a phenomenally trusted position. And then actually maintaining and using a deny/allow list based on something more granular than host:port will be so high that it’s a 0.1% of users type feature.
"It turns out that Xcode is also using the same domain to host an API for their cloud CI/CD offering. (hypothetical example) ..."
By "domain" I think you mean a full FQDN and not a top-level "apple.com" and I agree that this is troublesome and then go further and suggest that this is by design.
I would happily pay $20 or $30 for a version of this, but I will absolutely not pay a subscription fee for extra features. I have too many subscriptions...
I want to support this developer but not this way. Uninstalling :(
Please let’s stop comparing software subscriptions to coffee. It misses the point about the recurring cost and lock in, and not everyone lives in the USA and pays high prices for coffee every day (or ever).
I like Jetbrains licensing. Essentially you pay for updates and once you stop paying you’re locked in at that specific version, but you can use it indefinitely.
Are non-paying customers no longer eligible for support?
Yeah, basically. "If you pay nothing, you get nothing."
The last paragraph is brilliant foresight. I guess apps will need to move towards the AAA gaming market where Internet connection is required to verify license, plus a bunch amazing anti-cheat/-hack stuff. Assuming EU does crack open the app stores (pun intended), it sounds like a great small business to offer some libraries that mobile app devs can use for these new needs.
"Pay once" is sustainable as long as people keep buying your app. Which works out just fine, since you are never going to saturate the market as a small app developer. There's always going to be new people who buy your app.
I've made a living from non-subscription app sales for a decade, and revenue is pretty constant. As long as your app stays useful, people will continue to buy it.
Honest question, and I'm asking because I want to know your take, not because I'm trying to be a dick: why should an app developer have a sustainable income stream from a single app no matter what?
Isn't it possible that an app is simple enough that doesn't justify getting a full salary out of it?
Again, I'm not trying to be a dick here, I'm just trying to figure out what is the reasoning behind the subscription model.
I'm a freelance web developer. When I'm done with a project I have to move to something else. Is it unreasonable to expect app developers to do the same?
And I know, not all apps are created equal, some apps require constant work. I get that. For some apps is reasonable to expect a subscription. But for all apps? I'd say no.
And this developer, from what I can see, is doing the "right thing" by working on multiple products. Which is great.
I completely agree, many apps don’t justify being a subscription. It depends on the complexity, the frequency of expected updates and new features. Also if there is a cloud storage or paid API component to the app, then a subscription model is practically essential to keep an app running due to the developer’s own recurring costs.
I think like many things it’s not one size fits all.
In this particular case, I think that keeping a firewall utility up to date with changes to macOS and emerging threats would require a modest sustainable income source to make it worthwhile for the developer.
Well, I was looking at the change log of the non mini version of this app and the releases are dated
- October 12, 2022
- May 2, 2022
- April 25, 2022
- November 17, 2021
Just to grab the most recent. Reading the change notes a solid % is bug fixes which is expected.
This looks like a “traditional” piece of software. Doesn’t require constant new features that could be eventually bundled in a major paid release and the updates are primarily big fixes.
And in fact the non mini version of little snitch is not a subscription. As it should.
I agree with you that if an app has running costs (cloud storage or other services) or it requires constant work then a subscription is justified. But these days developers are trying to convert everything into a subscription.
Every minor utility app wants to be a subscription. Which is just insane.
But if the developers live in the USA then they are paying high prices for coffee, and thus require a commensurate level of return on their work to survive.
In all fairess, you don't go out every morning to buy three dozens of cups of coffee.
Currently everyone and their mother want to sell you a subscription. Netflix, Amazon, Apple, Spotify, $NUM of app developers, Disney, $FORMER_TV_STATIONS
That's the problem with subscriptions. They pile up.
Not disagreeing with you here, but buying full licenses adds up too. And you will likely have to buy "upgrade" licenses when new versions are released.
That being said, I do like the license model that JetBrains uses for their products: if you pay for the subscription for more than 12mo, when you stop, you get to keep a perpetual license for the latest version that was released during the last 12 months of paid subscription (I hope I got it right).
Yeah some, and a lot of the time you'd be running it with gaping security holes. There's no way little snitch can keep on top of OS and network updates without a decent amount of ongoing maintenance.
As far as I am concerned, subscriptions are an unreasonable hassle. You need to keep track of what subscriptions are active and where you can manage them. And when subscriptions are running, a “did I remember cancelling all the stuff I’m currently not using” is always in the back of my mind somewhere. That’s just annoying noise that I can easily avoid by not using subscription services.
Subscriptions add up. And there’s no guarantee they won’t jack up the price at the most inconvenient time and leave you hanging (LastPass, for example, has done that). For users, a subscription mean loss of control.
Smart move to go for the more casual user, it suggests Obdev has been doing their homework and proactively talking to regular users, rather than just blindly building feature requests. Tools like this so often get sucked into serving the loud minority of expert users with ever more esoteric use cases, which leads to a death spiral of audience capture where the tool gets more and more complicated and harder to approach for casuals.
Little Snitch Mini looks great, I'm going to recommend it to friends!
I've been beta testing Little Snitch Mini for the past 6 weeks and I have to say it's exactly what I wanted. Really happy with it, the development team should be proud of such a great product. It does a few things, and it does them very well.
However I don't love the SaaS nature of the product post-release, because tying my security posture to a credit card payment isn't something I love. Sure, I can make it so I only have to worry about it once per year - however what value does this continue to bring me beyond the current capabilities?
It seems the last iteration of Little Snitch from 4 to 5 added a CLI, some of the traffic stats we can see in Mini, but was mostly compatibility-related updates. MacOS went through some pretty major changes going to Ventura and all of the Extension-level changes which affected so many security tools, so I feel like the work there was substantial and justified the new license. For $69 (or $30 on-sale) every few years, it definitely makes me question the value the original version provides a power-user or technical user, over a monthly subscription which I'd need to monitor over the years in this new product, LSM.
Now I'm unsure what market segment the LSM product addresses. uBlock Origin seems to serve the majority of use-cases for a typical casual user, and network-level filters really don't seem relevant for the everyday user - particularly with the increasing adoption of DoT/DoH, making DNS-level filtering less useful. I originally assumed this product was for power-users who didn't need the full suite of LSM, and liked the MVP-style interface. But just for the sake of not having to worry about an on-going fee - I think I'll be hard-pressed to adopt it.
As a workaround - I'd love an option to pre-purchase 3 years up-front.
As someone who's been paying for Little Snitch for a long time this is an odd move, as this seems to do everything I would want.
Sure, I've availed of some of the more advanced features in the paid version, but they definitely never seemed essential to me. What I mainly need is the basics they've included in the free version now.
I wonder if this is a direct response to Lulu (have been meaning to try it but migration is friction)
> The network monitoring functionality, including the real-time connection list, traffic diagrams and the animated map view can be used for free!
> The full feature set, including connection blocking, extended traffic history time ranges, advanced display and filtering options and more is available as an in-app purchase.
I guess if you are just doing an investigation to see if there is any unusual traffic, the free version can be useful. Since it's not actually preventing any of the traffic, it doesn't make the paid for version useless. For those that want to stop the data flow but continue using the chatty software, upgrading to the paid version would still be a thing. If you're the type to just stop/remove chatty software, then this free version will help find them. Seems kind of cool.
I used to use Little Snitch quite a lot, but eventually I gave up. Two things contributed to it: (a) a lot of apps started using nsurlsessiond to load URLs, obscuring the real originator; (b) a lot of apps started making requests to ec2-xx-xxx-x-xx.us-west-2.compute.amazonaws.com and making the server essentially anonymous except that it's hosted on AWS.
At some level you have to trust whatever you install on your computer. There's no way to ever prove that it is safe or not. If the developer's reputation, recommendations by the community, quality of the product etc. aren't enough then it's best to just not use it.
Beyond that, Little Snitch (and Little Snitch Mini I assume) operates as a network firewall. It can see the domain where the traffic is going, and block it if it wants, but can't see or decrypt the contents of the message. The OS itself will not allow it to.
LuLu + LS makes any app using telemetry shriekingly obvious and selectively denyable.
Work additionally deploys YARA, MS MDE, Malware Bytes, and an MDM. There are other internal tools for password projection, DLP (anti-exfil), and pre-execution binary allow/denylisting.
This is why I pay for LS. The whole point of the software is to avoid nonconsensual phone-home; if it does it itself, how or why would you ever trust the developer?
I'd literally rather pay for proprietary software than maintain a fork of LuLu.
It transmits telemetry non-consensually before you even get a chance to tell it not to. That is, unless you know of this beforehand and are also tech-literate enough to understand this can be circumvented by disabling your internet connection before you first open the application - something you cannot reasonably expect from all users, seeing as how this telemetry gathering is not advertised anywhere and had to be found in the source code.
This is false in multiple ways (one of which would be legal for this - I believe - Spanish organisation), but I suspect you know this and are simply just trolling now.
They have no terms of service or privacy policy. As I said, their telemetry collection remains entirely undisclosed and on top of that collects much more data than you might expect it to, as the Sentry SDK they use is wrongly configured to be in debug mode. It's a complete shitshow.
This page is somewhat misleading. It pretends Little Snitch Mini supports blocking but that is not true and only works in the paid version. It does clarify this at the very bottom but weird to have your free app's landing page list features from the paid version. At least put a "premium" sticker on those screenshots or something.
How does this compare to the "LuLu" app from Objective-See? IIRC that one was open source, while this isn't.
A few years ago there was a concern that Apple was exempting itself from some of these firewalls. Were these concerns ever addressed in any meaningful way by any of these apps since then?
> IIRC that one was open source, while this isn't.
Yes. Little Snitch has been around for for a long time, though, something like 20 years. The developer Obdev is trustworthy, and I wholeheartedly recommend Little Snitch (the full version; I haven't tried the Mini version).
> A few years ago there was a concern that Apple was exempting itself from some of these firewalls. Were these concerns ever addressed in any meaningful way by any of these apps since then?
I think I saw that Little Snitch itself doesn't show all its own connections as far as I know
EDIT: Source was old posts on alt.hackintosh saying that you have to block one specific IP to prevent the call home and another one regarding LS4 saying that you have to nullroute some some Hetzner hosts.
My guess was that if you had to add some hosts to prevent LS to check its own license online, that it means that LS has its own way to go around the firewall rules.
EDIT2: Genuinely no idea, I guess we have to ask someone who uses a cracked version
The non-Mini version was such a hassle to maintain¹ that I stopped using it². This looked like a great middle ground, until the subscription part.
¹ I don’t want to become a networking expert and babysit everything. I already practice good security regarding what I install and run, I just want a little more control.
² And if it was a bother for me, there’s zero chance any of my non-technical friends would last an hour.
I forget what it's called but there's a mode you can put Little Snitch into that it allows whatever goes through and you can monitor it by opening and reviewing when you want. I think that's fairly similar to what mini does. This turns off all the nagging.
This is actually what I did last time I used Little Snitch, it helped a lot. When I installed a new app I'd use it for a bit, then review in LS and see what it was doing. From there I could allow or disallow whatever I needed.
It's sort of the reverse of "block everything until allowed"
Any thoughts on using this (or software like it) to beef up the security of old MacOS versions? I have an old MacBook Pro that can’t run the latest macOS anymore. I would rather not toss the machine but I’m skittish to use it without security updates.
But I might be willing to use it if I could secure it “enough” by monitoring what it does on the Internet, and by not putting sensitive data on it - for example I wouldn’t log it in to my iCloud and would only use it for some non-sensitive tasks (I use TaskWarrior as a task tracker. This works fine on an old Thinkpad but that thing has a miserable screen.)
Two questions from someone who genuinely considering paying for "Little Snitch Mini":
1) Can I install this myself, without the app store ? Is there a binary or .dmg (or whatever) with published checksums that I can just download ? I assume the answer is "no" but ... surprise me.
2) What network traffic does LSM itself send home to LSM developers ? Can I disable all traffic as a specific preference or do I need to configure LSM to watch LSM itself ? (A specific preference would, in my mind, be preferable).
Ahh BlackICE, Kerio Personal Firewall and ZoneAlarm Pro. Those were the days!
Plus the rise of the anti-spyware applications such as GIANT AntiSpyware which Microsoft bought and is now known as Windows Defender (although I don't much if any of the GIANT code is still around).
Sure was a fun time in the late 90s and early 00s for client side security software.
When Microsoft introduced the Windows Firewall with XP SP2 a lot of things sort of died out and then we had a rise in things like CCleaner for system "cleaning". While things like CCleaner started out with a few useful features they long ago turned into crap and should be avoided.
One of the things I do enjoy about Little Snitch is it gives me that early 2000s nostaltia every now and then when I new pop-up reminds of me ZoneAlarm :)
I love Little Snitch (full). This looks like the best parts and easier to use! Big congrats to Objective Dev on the launch. I’ll use this on my slightly slower computers.
One of my favorite use cases is making sure when I’m traveling abroad that my computer only connects to work apps over a VPN but blocks them otherwise. The auto profile switching supports vpn connections for this purpose.
I had great success with NetLimiter. Just like Little Snitch, it's a pain to set up, but it's very revealing.
Also makes you wonder why your Logitech App is talking to all these servers and why it needs to have 4 applications running in the background to... do what exactly?
simplewall[0] is my #1 install on a new machine. Little different, but it'll still alert you to the requests, allow for timers, per application/route rules etc.
A good question. I looked it up. The AlternativeTo site offers a few PC alternatives to Little Snitch:
"Little Snitch is not available for Windows but there are plenty of alternatives that runs on Windows with similar functionality. The best Windows alternative is GlassWire, which is free."
It's not as bad as the vine says, but one thing that drives me crazy, is widgets.exe seems to get a new hash /often/ and I constantly get prompts for it.
It's all the installers that phone home at some point, and video drivers needing access etc. (Wireless displays come at a cost I guess).
sorry, that should have been "Windows version". I wasn't meaning to imply windows itself (although, yeah, from the stories it could be bad too with telemetry crap). i just meant Windows being such a large target for malware and what not
I like this app. It's very similar to an app I already use to restrict which apps are using data called Trip Mode. With Trip Mode, I can automatically block all connections by default and only allow whitelisted apps. I don't see that mode for Little Snitch Mini, but if it had that mode, I might completely replace Trip Mode with it.
Unfortunately, if you're on a multi-user computer, MacOS networking (as far as I know) prevents Little Snitch to pass the "wife acceptance factor". Every rule/block I set in LS, applies to all users on the computer.
For people who don't want to or can't pay the subscription fee, you can install Pi-Hole on a Docker container on your local machine and get almost the same functionality with the cost of a little more battery usage.
Love this tool! I upgraded to premium so that I could see which apps are the most chattiest... it turns out to be Tailscale. It connects to a lot of random places across the whole(!) world. See: https://imgur.com/a/Gc5pnih
The monitoring is super useful for metered connections (looking at you, Comcast/Xfinity) and I happily paid for the full Little Snitch for that feature. Super glad to hear it’s free now! I’ve tried to recommend it to people and it was a bit of a big purchase for most to stomach just for the monitoring features.
I know from personal experience of making and selling an App Store app [1] that it can be difficult to show accurate pricing on your products website.
There can be 175+ different territories that you may sell an app in, each with a different local price point. You also can't expect to simply show a converted $US dollar amount either as you may want to do price discrimination (so that the app is cheaper for regions that cannot afford the exact $US equivalent).
Overall options seem to be:
1. Don't show pricing and leave it for the App Store to display - the most common approach
2. Only show $US pricing on the website and let non-US customers manually translate to their local pricing - not a great experience for non-US users
3. Manually or automatically sync pricing on the website display with the actual current App Store pricing. This is quite a labour or integration intensive task and I've only seen this been done by large vendors
Sounds like an excuse to just not display the price.
> 2. Only show $US pricing on the website and let non-US customers manually translate to their local pricing - not a great experience for non-US users
It's a worse experience for someone to convert USD to their currency (instant mentally or 2 seconds on Google) compared to launching the app store, installing the app, getting to the purchase menu, and seeing the price?
You don’t need to install the app, the prices are displayed on the product page in the App Store, towards the bottom. It’s listed automatically for all apps.
Will not help if you use Parallels. (Read the Privacy Policy of Parallels to see why.)
Realtime connection info, logfiles and control arefeature of Murus, a frontend to the BSD pf that is included in macOS.
This kind of tool really belongs in your routers not your Max though. Any VC on here should consider writing a check to a startup making coreboot/linuxboot or libreboot routers using hardware that doesn’t originate in China’s sphere of influence. (Even some routers recently sold at Walmart retail have been shown to have CCP backdoors!)
[The ability to Notify a consumer’s Apple devices from their routers (using APNS command line utilities or CURL) has been around for a while so they can just as easily alert when That Guy in St Petersberg is launching a DDOS attack or whatever from the consumer’s p0wnd smartbulbs (as well as whatever trust is being violated by devs on their interactive computers) just like LittleSnitch/SOB/etc.]
Not liking the direction Apple took with OS X user interfaces and stuff in the later years, I generally stuck with Mojave on my macs. I wish I could try this without upgrading to ah, what was it, Monterey? but alas, alas.
> Any thoughts on the difference between using this vs DNS (e.g. nextdns) with blocklists?
Little Snitch is process-based, so you can block a specific process from connecting to a specific domain while allowing other processes to connect to the domain, whereas with DNS you have to block every process from the domain. And of course Little Snitch gives you process-level info too, which DNS doesn't.
Theoretically LS could tell you if some malware was connecting to, say, a strange IP address, which wouldn't ever hit DNS.
Obviously a smart/sophisticated Russian hacker wouldn't be connecting directly to a Russian IP, rather using a local-to-you cloud server as an intermediary, but still.
I think LS is more oriented toward someone who wants disclosure, as opposed to someone who wants specifically to minimize telemetry and trusts a blocklist to do a good enough job.
So, from a user's viewpoint, if your app talks to blah.serv.direct.data.com how do you know whether it actually needs that server for its main functionality or not?
I don't see how this snitch tool will not just generate a lot of noise.
It all depends on the application. If there is no reason for it to talk to various servers then blocking them usually is fine. If it actually breaks something then you can proceed to uninstalling it.
Most of it is telemetry you didn't agree to, or worse.
I wrote picosnitch [1] which has the same notification and bandwidth monitoring features, however it doesn't block traffic for a couple reasons: avoiding scope creep so I can focus on more reliable detection and do things like hash every executable, which makes it harder to block traffic in a timely fashion.
What is your threat model, and what type of traffic are you hoping to block?
I never claimed picosnitch to be a firewall. My use case involved running it on servers with a minimal OS where all applications are containerized. My goal was purely monitoring to see if any containers had rogue executables, and go from there.
Without the containers, it would be trivial for a malicious program to stop or modify picosnitch, and the same goes for firewalls hoping to block programs on Linux due to its security model [1]. You need to use some sort of sandboxing [2].
I never claimed you claimed it. I was just pointing out the huge deficiency that makes picosnitch not an alternative to the broader use case littlesnitch supports
To sidestep the more complicated discussion re. how poor the security architecture of Linux is, let's limit that use case to blocking legitimate apps' connections for privacy reasons
I apologize, that's a fair question given that I named it after Little Snitch. One reason I used the prefix pico is because it's extremely little, supporting only a subset of Little Snitch's features.
On Linux there's already a number of great apps for blocking legitimate apps' connections, however they all still support only a subset of Little Snitch's features, and there wasn't one that offered the subset I provided with picosnitch. Which of those features you consider most important is subjective and dependent on your use case. I consider picosnitch a valid alternative and the core feature to be snitching on programs, the same goes for the new free tier of Little Snitch Mini.
Also like I said above, it is difficult to hash executables and block them without introducing delays the first time anything connects to the internet. If you're only concerned about blocking legitimate apps' connections you don't need them to be hashed since you can trust them not to do anything too nefarious. Personally this was more useful to me, since if I see an unexpected new program or hash during updates, or a new hash outside of updating my containers, I can intervene or have another script stop my containers and alert me. I also get some value from this on my desktop since I do all my development inside containers, and use another drive with Windows solely for gaming.
I noticed this is pretty new and a couple things caught my attention
> the primary advantage is that it has direct access to the pid, executable, and commandline of the process making the request.
Does this mean it is guaranteed to be able to open a copy of the executable no matter how short lived it is? This was quite a challenge for me when trying to grab it in time for hashing. I ended up settling on simply opening /proc/pid/exe as early as possible, marking it with fanotify, then putting it in a queue to read later and reporting it if it was modified before being read.
> the systems fails closed. when snitch isn't running, network requests are not possible.
This is a pretty impressive feature which I haven't seen elsewhere. I'm not familiar enough with lsm to know what's possible and I see you use a custom kernel. What sort of guarantees does this provide and have you come across any limitations?
> Does this mean it is guaranteed to be able to open a copy of the executable no matter how short lived it is? This was quite a challenge for me when trying to grab it in time for hashing. I ended up settling on simply opening /proc/pid/exe as early as possible, marking it with fanotify, then putting it in a queue to read later and reporting it if it was modified before being read.
no, it just means it knows the name and path as reported by the kernel at that time.
i originally had wanted to monitor the filesystem in addition to network, since lsm allows that. however the filesystem implementation was tricky, and i couldn’t find a good solution to the problem you described: verification by hash or some other means that the path being executed is a known trusted binary.
all mighty snitch knows is the path of the executable and the argv array as reported by the kernel at the time the lsm hook is called. it’s not the best, but it’s better than nothing.
> This is a pretty impressive feature which I haven't seen elsewhere. I'm not familiar enough with lsm to know what's possible and I see you use a custom kernel. What sort of guarantees does this provide and have you come across any limitations?
i think failing closed is more inconvenient than difficult, which is why things often fail open. when using a mighty-snitch kernel, the network is inaccessible until you start the userspace process. better security might involve only allowing userspace to start once, or other such restrictions.
then again you also have to secure the filesystem, since that is where permanent rules are stored.
in reality, it depends on your threat model. i find network monitoring to be tremendously useful both for debugger and for more feeling secure. hopefully also for being more secure.
nfq, which tinysnitch uses, can also fail closed. then again you have to use iptables or nftables for that, which may in fact fail open.
> I'm not familiar enough with lsm to know what's possible and I see you use a custom kernel. What sort of guarantees does this provide and have you come across any limitations?
lsm is only usable with a custom kernel, which probably why most people don’t. basically it returns block unless it can talk to userspace, in which case it returns block or allow depending on which userspace chose.
as for limitations, currently we can’t reliably read the remote ip for inbound connections. it would be nice to have that information as well.
just looked up your username. picosnitch is cool! email me if you want to discuss further, and keep building cool things!!
> i originally had wanted to monitor the filesystem in addition to network, since lsm allows that. however the filesystem implementation was tricky, and i couldn’t find a good solution to the problem you described: verification by hash or some other means that the path being executed is a known trusted binary.
The most promising approach I've come across which may accomplish this is using fs-verity or bpf_ima_file_hash. However I haven't looked too much into it since I'm mostly working on other things now and my current approach works well enough. Also I have yet to take into consideration shared libraries and things like LD_PRELOAD rootkits.
> then again you also have to secure the filesystem, since that is where permanent rules are stored.
I've worried about this too, it's a little easier for a server if you minimize what you have on the host, bonus points if it's immutable, and run everything in containers. This is a little harder to do on a desktop without creating too much inconvenience though.
> in reality, it depends on your threat model. i find network monitoring to be tremendously useful both for debugger and for more feeling secure. hopefully also for being more secure.
Yep I agree, and it's also useful for learning about your system and networking, to help make better decisions when it comes to security.
> just looked up your username. picosnitch is cool! email me if you want to discuss further, and keep building cool things!!
While Little Snitch can do general blocking from a block file, its main use is per-process blocking. With PiHole, you can't see what process on your computer is making the request, just that your computer's IP is making it. Little Snitch (and LuLu) are great, because you can see what program is actually making the request, and block/allow/setup rules for it.
I use Little Snitch on my MacBook Pro and love it. I’m a privacy nut and don’t relish the idea of behemoth corporations making money off me by exploiting my computer. It can be a pain to check every connection your browser tries to make but it’s worth it. Yesterday I shopped on three sites. None of them were Amazon. In that 24 hour period Amazon attempted to connect 259 times.- not their web services. To a lesser degree Google and then the social media sites. Facebook was the worst.
I use an IP identification site to look up each IP that attempts to connect on Firefox and see what company it belongs to. After awhile you learn which sites the first 2-5 numbers belong to. It is one of the finest security programs on the market and well worth the money.
Last week I did some holiday shopping for my granddaughter on the GAP site on my iPad and within 48 hours ads for GAP and all of their affiliated sites started showing up in my Twitter feed. I only use Firefox in private browsing mode now. Hope this helps!
> within 48 hours ads for GAP and all of their affiliated sites started showing up in my Twitter feed
That's called "retargeting". The advertising network tracks your web activity across multiple sites, and advertisers pay extra to target you because you've visited their site previously.
Ad blockers break the code that tracks you around the web and the display of ads, whether new or retargeted. There are some decent options for iOS.
I know that talking about the site design itself is discouraged, but that was terrible to read.
I wanted to see what was new (why is this "mini"?) but as I scrolled down I had to wait as it fetched content and slowly made it appear. Instead I closed the tab and hoped to learn that from the HN discussion page.
When I think of little snitch I think of something that makes my computing better. This page was the opposite -- off brand.
So this means as a company using MDM, I cannot purchase it for all my employees.
MacOS devs who see IAP and subscriptions as the only purchase paths are leaving corporate purchases on the table.
We choose software we can pay for. We are fine if it's priced fairly to support the developer and the work to get to the next version. We are fine paying for the next version too.
But IAP or subs paid for by company? Apple itself doesn't support that on Macs managed using their corp device management. (And no, the user cannot buy it and expense it either, IAP/subs are disallowed on managed Apple IDs.)
Indie MacOS devs, all you have to do is also list a full retail version. You will have buyers. $2.99/month sub also sold $79 full price and a major update each 2 years with a new full retail version number? You will still have buyers, and you'll have the cash now, instead of over the 2 years.