His interpretation of “industries that are allowed to innovate vs those where it’s illegal” is laughable.
Has Marc considered that there might be some other fundamental difference between the inflation-positive sectors of health, education, food and housing, vs the inflation-negative ones of TVs, cars and software subscriptions? I’ll give you a hint Marc: some of these are essential to life and society and some are not.
Because housing is essential to life does not mean it should double in price every ten years.
Because education is valuable it doesn't mean the amount of student debt in the country needs to double like it has in the last two decades.
At least in these two examples, these "industries" are flying off the charts in the last two decades not because of how essential they are, or how technologically progressive they are, or how the value they bring to people's lives has correspondingly doubled just now (nope, same essential value as before), but because there are large groups of people who have figured out how to milk the shit out of these parts of society, and technology (which didn't start with ChatGPT yesterday) doesn't seem to be helping with that.
> Because education is valuable it doesn't mean the amount of student debt in the country needs to double like it has in the last two decades.
If we change the basis of our model to financial pain, for things that are purchased with significant leverage, the cost going up as the interest rates go down would keep the financial pain relatively constant.
> Because housing is essential to life does not mean it should double in price every ten years.
I agree, and didn’t mean to imply that the price rising is inherent to these services. What I should have spelled out is that a capitalist market can only self regulate when the buyer has the ability to say no. Largely a customer of health, housing and food has limited ability to opt out.
They're not though - the regulations keep getting stricter. Housing (building), for instance is expensive because the requirements tighten to match what people can afford. Remember when single glazed windows were legal? 2000 standard healthcare would probably be cheaper today if we were allowed to use it. But now we have newer more expensive (and better) treatments. Cars go like that too with safety growing.
The flaw in this argument is assuming that you could do a good job of diagramming a system without describing the use cases of the system. My web dev skills are not proprietary, but the processes and systems I have worked on are.
Would love to hear from the "I don't think we need it on Linux" folks. What is it about antivirus that we don't need? Is it the wrong solution to securing a workstation?
AV as a concept needs reconsidering: the problem is that attackers can test to see if their malware is blocked and tweak it until it isn’t, so there’s always a lengthy period where they can launch attacks which aren’t detected. AV also doesn’t help with the common case where something runs entirely in memory in an exploited process - the vendors will blather about behavioral checks but that doesn’t seem to do more than keep marketers employed.
Where I’d prefer to see time going is basically two areas: rather than trying to catch every possible bad thing, only allow know okay binaries to run (the hard part being supporting software developers), and extensive sandboxing to catch up with Apple. It’s hard to block every possible bit of bad code but we can minimize a lot of the damage if, say, a malicious PDF file didn’t mean the attacker could just read AWS credentials or SSH keys.
The other benefit is that AV software has a history of security problems. Most of that is that the vendors still use C like it’s the 90s and putting complex binary decoding logic into a privileged context is a recipe for bugs.
Most software used comes from repositories. Most of the time the user is not logged in as root. Any virus would have to exploit a system vulnerability, if that is common and serious enough to cause harm then anti-virus software will take longer to catch than it will take to be automatically fixed by updates.
> Any virus would have to exploit a system vulnerability,
I'm not sure if by virus you mean some specific definition, but malware can still result in a very long and painful day/week/whatever with just access to your home directory and nothing else.
What would happen if your ~/.aws folder was piped to pastebin? Even if you're using short-lived STS sessions with ephemeral keys, I imagine most people would still find themselves in a world of hurt.
How about sending interesting files from your browser's userdata directory? All your cookies, your browser's password manager, possibly copies of your third-party password manager's cache (even if it's all encrypted), copies of cached files, your Downloads directory.
calling home or exfiltration is indeed a serious threat. otoh, it's fairly straightforward to partition / reduce / sandbox environments in Linux. do you need to touch AWS infrastructure from the same account, host, vm as you read email or surf the web? do these environments need full, direct internet access?
What percentage of desktop Linux users do that? Most distros don't do any sandboxing and those that do typically have easy ways to run binaries outside of a sandbox.
>Most of the time the user is not logged in as root
Why does this matter? Most malicious things someone would want to do don't require root. eg. VNC, DDoS, mic / webcam capture, token stealing, keylogging, ransomeware, stealing ssh / pgp keys, adware, backdoored web browsers. And for the small percentage that do you can just backdoor sudo or make a fake system update dialog that captures the user's password to let you have root whenever you want.
Two of the most ubiquitous categories of malware today are ransomware and agents used to steal secrets such as web browser sessions. Because both of these categories interact with files the user has access to anyway, privilege separation (especially only the basic form of privilege separation traditional on Linux) is of little help. The attack surface is all owned by the user anyway. Both sandboxing (such as kernel capabilities) and mandatory access control (SELinux) are helpful in reducing this possibility, but both of these are relatively difficult to use and so not common on workstations.
It's also reasonably common for an exploit to become known by AV vendors and have signatures released before it's been widely patched. Turnaround time from a major exploit becoming known to the industry to a signature release by AV vendors can be as short as a day, especially with the significant intelligence sharing that now happens in the AV industry. AV vendors sometimes release signatures before the exploit is publicly known as a result of information-sharing agreements, although this is a touchy issue because the signatures themselves become a form of public release. While keeping software up to date tremendously reduces risk, there is still a window of opportunity.
> Any virus would have to exploit a system vulnerability
XKCD 1200[0] disagrees:
> If someone steals my laptop while I'm logged in, they can read my email, take my money, and impersonate me to my friends, but at least they can't install drivers without my permission.
That’s one of my favorite xkcd comics because it describes the (very dire) situation so well. Unfortunately the linux userspace really doesn’t seem to care about security even a tiny bit, as if they were still living in the early days of computing where you could be naively trusting everything. And fortunately open-source software is indeed well-mannered for the most time, but that is no reason to be delusional.
Mobile OSs are way ahead in terms of security and the other two major desktop Os also does at least some mitigation against potential attacks. Yet our .ssh folder, web cache, backups everything can be read/written from the same user account one uses for npm installing any random package which has the potential to just encrypt your whole home directory..
I'm hopeful about efforts like bubblewrap, but widespread adoption is very tough. As long as policies are delegated (like AppArmor), I don't see that improving.
TPMs and Passkeys are also a good refuge - Just keep private material off the device.
What I'd like to see is a boundary between system installed packages (which I implicitly trust, but worried about malicious commits upstream, as others have noted) and other code, such as installed via pip, npm, cargo etc.
While it's feasible for me to audit a single shell script, or a PKGBUILD from AUR, it's pretty impossible for modern lanaguage package managers.
Well there's a couple problems. A) virus companies feed the FUD to make it seem really important and worthwhile B) virus writing folks have figured out how to make an arbitrary number of binaries that the virus checkers don't catch for days or weeks C) if attackers are running binaries on your system, you have problems than antivirus is not going to catch or fix.
Virus companies seem to focus much more on marketing then technical excellence. They typically run with full privs, regularly download code/rules from a central server, and are often written poorly. Seems like the industry is awash in security issues: buffer overflows, false positives, false negatives, not checking signatures on downloaded rules/code, and breaking various APIs, network protocols, etc by playing man in the middle. Even things like proxying SSL to scan traffic for SSL downloads ... but failing to check the cert.
So I see little value in running a closed source daemon from a anti-virus company to catch binaries that no serious attacker would use anyways. I trust the binaries from the OS's repos MUCH more than the antivirus programs. Similarly I don't trust IBM's BigFix that was malware Gateway used to help profit from tracking users and showing ads with their special "dock" that came installed on Windows systems. They of course made it very hard to uninstall, since that maximizes their profits.
Generally it seems like the wrong approach. If you want to do it right, have a whitelist for approved binaries. Ideally hooked up to your local mirror/repo so you can have approved signatures for all binaries BEFORE said binaries land on your Linux boxes. Spend whatever resources you would on anti-virus on patching, reporting, monitoring, firewalls, training, etc.
Most of it comes from a philosophical perspective, rather than a technical one. In many forms, viruses usually find their way in from software vulnerabilities, leaving deliberately (albeit unknowingly) installing in the minority. With the open source/free software development cycle, it should be possible to eliminate most avenues of vulnerability.
So in short, the questions we should be asking are:
1. How do viruses find their ways in?
2. And, what can be done (as a user or developer) to prevent that?
These are obvious, I know, and the software devs for Windows aren't deliberately writing insecure software, but these questions are ones better seen from a behavioural point of view.
Kind of infuriating that the blog post doesn't mention what "Wickr Me" is. The link in the page footer to "Wickr Me" only goes back to the same blog post.
Wickr is/was one(or the only) privacy oriented chat app that didn't require your phone number or your phone book. For some reasons there is no replacement. All the "privacy" messaging apps want your phone number and phone book.
Briar is another anonymous, fully decentralized chat app. It rides atop Tor rather than reimplementing an anonymous network protocol like Session does.
That's not true. https://status.heroku.com shows that the incident is ongoing, that they've disabled the GitHub integration, and don't have plans to reenable it until full assessment is complete
You have to actually click on the general advisory of the email from Salesforce (which isn't obviously actually useful to click, there's no arrows indicating it'll expand or anything) and then you have to scroll down to an entry which isn't signposted.
Additionally, in two browsers, if I clicked to expand it, then clicked the 'back to current status' button, it errored out with the console full of errors and couldn't be clicked again, which doesn't fill me with too much confidence.
What a mess. I have fond memories of Heroku (or rather, how little I had to think about anything deployed to it. Liberating.)
In the sense that people shouldn't let themselves be convinced by arguments they don't fully understand, that seems somewhat related to DK, in that people shouldn't be believing they are more competent than they are.
(That's not to criticize OP - when someone makes an argument that sounds convincing, it can be pretty convincing! It's just different than actually being valid.)
They immediately reached a conclusion about something upon reading about it and now as they learned more, they understand that there might be more nuance to it
