They are sometimes required. Say you are on a mailing list for some company you gave your email to at some checkout counter one time, and you want to unsubscribe. You probably don't have an actual account with a login with that retailer, they just have your email address.
In this case, what alternative is there than having a magic link in the footer of that email that says "unsubscribe" that includes a token unique to that email address that acts as proof of owning an email account when you then click that link and ask to unsubscribe?
There are many options where such links are a reasonable option. I'm okay to receive such a link to validate my e-mail for an account creation, or to unsubscribe from a mailing list at a place I don't have an account at, or to display an order status page at a shop where I ordered as a guest without creating an accoung.
But using them as the only option to login is really, really annoying. Mails can get trapped in spam filters, delayed by intermediate server overload or spam filters that sometimes take 10 minutes, servers doing graylisting... Plus all the other annoyances listed in the article (e.g. multi-device users, in-app browsers). At the very least, support passkeys if you really don't want to store (hashed) passwords. And no, SMS is not an alternative: I was several times barred from logging in to a service because SMS wasn't properly working (can happen easily while roaming abroad).
Yes, sorry. I mean in the same way as the other person who's replied to you.
Don't give me an "account" somewhere I'm expected to use on a regular basis but require me to use magic links.
The California Attorney General ruled that if a user presents a GPC signal, the company should update all of their backend systems to opt out of tracking in the same way as if the user clicked a "Do Not Sell My Personal Information" button.
You mention hiking several times, I assume it is something you enjoy. Now, imagine, instead of regularly having to travel to Yosemite from your local suburban area, you instead go live in Yosemite and use your headset to do the things you did in your suburban area. More hiking, less time spent in transport.
Well when you account for the time spent travelling, the time spent socializing and shmoozing, the boxed lunch hour, etc, that adds up to a whole lot of wasted time on top of what could have easily been a 45 min zoom meeting, or an email. Its fun I guess if you get all your social outlet from your coworkers, but if you get it from anywhere else it probably feels like you just got drafted when you get sent to meet the distributed team in person.
You are missing the point here. Plenty of things can’t be a 45 minutes meeting. Sometime what you incorrectly call schmoozing and I call building a bond is the point and is extremely necessary. People are not machine.
It's almost certainly for the companies to pay less money, but with a more generous reading, I think it could be argued that that doesn't necessarily have to come out of employee salaries. That data could be used to:
- Set reasonable ranges to find the right candidates they are looking for faster and minimize hiring friction
- Standardize payment levels in a way that reduces legal liability in certain states like Colorado/California. Or the most generous reading of "reduces legal liability" would be "promoting fairness".
- Reduce the time spent by HR/other teams of negotiating or setting salaries, as they can simply target some target like "we want to pay more than 60% of companies like us"
- For budgeting/forecasting with new hires, this allows companies to have more confidence in their estimates as they plan hiring.
They shouldn't. Microsoft should have APIs that enable security vendors to work in userspace.
The EU didn't say that Microsoft couldn't kick vendors out of the kernel, just that they couldn't do so without having the APIs available that would let security vendors operate outside the kernel.
Mac and Linux have such APIs, so CrowdStrike operates in user-mode on those platforms, so those platforms do not give security vendors the ability to crash the operating system.
I suppose I was expecting something more authoritative here. They confirm that there was an attempted read-out-of-bounds, as CrowdStrike said, but that's not really new information at this point. I suppose we'll need to wait for more detailed analysis from CrowdStrike at some point.
This post explains why security software has historically run in kernel-mode, and really seems to be pushing new technology that Microsoft has that would push security vendors into user-mode (with APIs that attempt to assist with many of the reasons why they have historically used kernel-mode).
Crowdstrike already runs in user-mode on both Mac and Linux (from what I can tell), and it seems like running in user-mode on Windows would significantly lessen the risk of catastrophic failures like a blue-screen-of-death. I know the bulk of the failures here belong to CrowdStrike, but I can't help but think about the fact that Apple kicked security vendors out of kernel-mode a ways back, and that if Windows had done similarly, an issue like this probably wouldn't have been possible. By even offering kernel-mode options to external vendors, I believe Microsoft is creating risk for themselves.
> I can't help but think about the fact that Apple kicked security vendors out of kernel-mode a ways back, and that if Windows had done similarly, an issue like this probably wouldn't have been possible
Like others already said, Microsoft already tried to do that with PatchGuard in 2006 with the launch of Windows Vista and the likes of Symantec and McAfee complained to the EU about this would harm the sales of their products, so the EU told Microsoft to not do it in 2009[1].
Apple has the luxury of a small market share on the desktop PC space to not attract the attention of the regulators, plus a user base that's used to Apple constantly rewriting the OS, deprecating APIs, switching CPU architectures, etc. without giving a fuck about breaking backwards compatibility or cutting off developers access to OS features their products use and getting away with it, luxuries that Microsoft doesn't have.
IMHO, sticking with Window's default security and not using third party anit-malware has made Windows vastly more secure and rulabile than it was in the days when you'd be looking on installing the likes of Symantec or McAfee for your "protection" which ended up acting like malware after a while throwing dark patterns at you to milk more subsection fees, so as much as it hurts their sales, it's important for the regulators to understand that security is far more important than the regulations they put on Windows for Internet Explorer and Media Player and just like Apple's apps-store, it's sometimes better to let the original product maker handle security and not leave the product open at all points just so some of these bandits can make a living selling security for it. It's like foxes complaining to regulators how chicken wire is a threat to their existence.
I work in a heavily regulated industry (healthcare) and I can tell you that if anti-virus products weren't required to pass audits we wouldn't be using them. I'm not super familiar with Windows built-in security anymore but macOS (our platform of choice) is pretty secure without any additional products. In fact, I'm pretty sure that adding A/V "solutions" makes us more vulnerable, not less.
Microsoft sells endpoint security products and it would be unfair if third party solutions couldn't leverage the same APIs, it makes a lot of sense that a regulator steps in.
I'm not aware of Apple selling security products or competing with third party security products.
Cars are sold with integrated radios and players. But at the same time
there were independent companies selling car radios back in times when
they were exchangable. Now external players are gone, everything is
integrated, and the market for custom car players is dead. And nobody
cares! One could say that car manufacturers don't offer the same API for
car player companies.
I think that Microsoft is the king of their system, and can do whatever
they please. If that doesn't sound practical or trustworthy for a
company, then maybe the company just shouldn't release the product on
their system. Use a different platform. Because if you release a product
on their platform, then you're saying that you're okay with their rules.
Wasn’t the whole regulatory argument that Microsoft was using kernel mode in their security software, while trying to relegate third party security software to user land? In that case, regulators stepped in and made Microsoft open up kernel mode to level the playing field.
Apple provides the kernel implementation and the API. They don't offer a real competing alternative for the user mode side of the equation. They leave that to the ecosystem. It's a fair trade-off. They can focus on keeping the kernel secure and stable, and the ecosystem can work on all the different ways you can implement anti-malware policy and integrate it into a larger system of endpoint security.
MS offers a full competitive product, and they allowed that product to use features and capabilities that wouldn't be available to others. At their scale, you can't do that without drawing scrutiny from regulators. They could have at least kicked their own product out to userland, or just stopped offering one and focused on kernel stability the way Apple has.
Since this is all spitballing, perhaps they even suggested that the EU, and the EU said "no, it must be kernel access" and capitulated because this served their own interests while also letting them blame the EU for the lack of kernel stability.
If you are in the market to sell EDR tools and you can’t find a way to provide value beyond what XProtect offers, you probably shouldn’t be in the market.
The difference between XProtect and Defender, is that XProtect utilizes the same kernel interface that Apple provides to other EDR solutions, whereas Microsoft was / is only willing to implement Defender using an in-kernel solution.
As a result, it would be anti-competitive for Microsoft to deny that level of access to third party EDR solutions.
I do wish that the EU would offer a "grace period" for "platform owners" or "gatekeepers" that would allow them to use non-public APIs for their first-party solutions while they stabilize and work out the public API offering. I think there should be some requirements for them to "earn" that grace period, such as allowing interested third-parties to get early access and provide feedback on those APIs. Regardless, it takes time to stabilize those APIs, and the current EU approach of requiring all new APIs to be fully public on day one just isn't workable.
I don’t understand this world well enough to describe it well, but my understanding is that the security features in the kernel are different in purpose from the security features of something like an antivirus.
Your operating system by definition has to have complete control over things your operating system can do. Do you want third parties to have access to for instance the Secure Enclave in iPhones? The same permissions the Settings app has?
Lots of allegations here. Can you share examples with sources of other operating systems following practices which you mention here? I presume Mac allows the same level of access for CRWD through user mode access only and that’s the only way they do it too. Same goes for Linux.
I genuinely want to understand this - how everyone else got it right and this entity got it wrong.
> Can you share examples with sources of other operating systems following practices which you mention here?
Well, both dominant mobile operating systems already enforce a very strict security model. Too strict if you ask me because on neither you as the person actually owning the damn thing can become root without anything in the system throwing wrenches in your way, but hey.
The result is, most people don't even need a virus scanner, and the blast radius of a bug in an application is usually limited to whatever data that application can access. It's been ages since I heard about the last major mobile OS malware in the wild that didn't involve one of the world's secret services or their civilian suppliers - and that way, one can argue, all the security theatre actually works: it's driven the price of successful attacks so high that only nation states can afford it, and even these have to restrain themselves to only use these exploits against targets of extremely high value.
The reason mobile OS don’t have such a problem is because of the ‘walled-garden’ for App Store. Essentially, every binary being run on all Apple and likely most Android has been ‘blessed’ by the manufacturer App Store.
Is it possible to rootkit phones? Yes; does a typical user do it - heck no.
The app store does some pre-checks, yes. But it can’t catch all the security vulnerabilities that might be unknown. It’s only a small piece of the pie. Largely it exists to make sure apps work, don’t have malicious UX patterns and don’t use private APIs.
iOS (and to a lesser degree, macOS) use notarization to be able to pull apps found of being risky as needed.
Additionally they implement much stricter levels of sandboxing so that even if something slips by all detection, it’s heavily limited in what it can do without a users explicit permission or a catastrophic vulnerability.
Android supports third party app stores and sideloading out of the box without rooting. There's a separate apk scanning feature that works with sideloading.
(There's a big android user population without access to the Android app store at all)
> Crowdstrike already runs in user-mode on both Mac and Linux (from what I can tell),
Crowdstrike provides a Linux kernel module, and expects users to manually install an extra Secure Boot key for it, as part of their corporate laptop setup procedure.
This has always seemed inadvisable to me, but checkbox checkers gotta check checkboxes I guess.
I agree. Microsoft's core competency has traditionally been backwards compatibility, but if each security vendor can tamper with windows at the deepest level and is allowed to continue explore all of the ways that they can leverage that... What you end up with is a fleet of different windowses, each diverging further with time. It dilutes the benefits brought by investment into the stability of the system because whatever fights are won in one fragment must be refought in others before you can have confidence in the stability of all fragments.
This is fascinating, thank you for the info! If I am understanding, it would have then been difficult/impossible for CrowdStrike to create a user-mode only sensor without these equivalent APIs.
So I guess I'm not sure I see validity in the claims of those blaming the EU here. It seems as though the EU would have allowed Microsoft to kick users out of kernel-space if they had APIs that allowed making security products in user-space. Like Linux/Mac already appear to have.
I don't think they would have had to provide those APIs in the EU, so long as their own security products were "kicked out" as well. That's kind of complicated to achieve in a permanent and provable way. Though, windows has had support for eBPF for about two years now.
This seems to be only partially true when I read into it. The EU said that Microsoft would need to move their security tools into user-space (or at least to use the same APIs as are available in user-space). If they did that (like Apple has done), they could kick everyone out of kernel-space if they wanted.
A kernel-space watchdog (that checks integrity of the image) would be much easier than a filter that updates from the internet.
Sure, the whole thing is definitely a hard problem, but CS fucking up even the most basic QA **and** error handling ... it just shows how ridiculous their whole claim to having super fancy technology is.
I used to like using homebrew on personal machines. But then as the person in charge of the dev environments at my company, I tried using homebrew packages for our devs but it just went horribly because homebrew don't have old versions.
- Different folks ran `brew install <foo>` at a different time? They may see different behavior
- I ran `brew install <foo>` after a coworker did? I may not be able to replicate whatever issues they are facing
- Someone new ran `brew install <foo>` on their new laptop? They may have an entirely separate major version of that library with breaking changes.
- Do I know if folks are using vulnerable, old packages? Nope!
- Does production use some database with version X, but homebrew only supports a client for version Y? Eh whatever, just have folks locally use version Y. What could possibly go wrong with using a different version locally vs in production.
I kept our own homebrew tap for a while and pinned versions. That was fine. But then I had to maintain that tap, and there wasn't any easy way I found for checking if the versions we kept in that tap had any vulnerabilities on any registry I could find.
Then I found Github Codespaces / devcontainers, switched everyone to use Linux inside Docker, used linux package managers to install pinned versions of everything we needed (using the same exact packages as we bundle into production), and scan my containers using a container vulnerability scanner nightly.
Instantly, 10+ hours of work per week for me vanished and I can now at least reproduce problems and fix them for everyone when they come up.
Because of docker performance issues on osx, I’m not looking to do that same for my engineering team and instead am looking at using nix.
I’m already using it for my personal work laptop and it is working well. Also nix allows me to configure host/user level tools such as shells or AWS-sso where docker would not. Building modules allows users to customize there configuration without blocking our tooling team from making changes to configs as Nix will just merge it all together.
In my case, my wife has an iPhone, so I was able to setup an Apple Watch as my primary phone, while I do not have any phone other than my watch. So if you're on a family plan, maybe that's an option
Beautifully shown, thank you for making this. As a full-time RVer that spends a lot of time in national parks, this is quite useful.
Fun things I noticed:
- All the mountain parks are summer focused, which stinks a bit as I want to see them all but have limited time
- Great Smokey Mountains and Shenandoah have nice fall weather/leaves, and it's cool to see a bump in fall for them
- People go to Great Sand Dunes most in summer, which is when the sand is so hot it's painful to touch. There's great opportunity to camp there during the less busy seasons
- Likewise, it seems like too many people go to Zion when it's crazy hot. It's wonderful for a lot of the year, I just wouldn't go in Summer
- I'm shocked at how busy Isle Royale is compared to other parks, never would have guessed that
> - All the mountain parks are summer focused, which stinks a bit as I want to see them all but have limited time
It makes sense; you can't drive there when it's covered under feet of snow. And when all that snow melts, the ground is still soggy, flooded, and can't deal with the masses.
Many mountain locations open their campgrounds in June, some roads are not drivable until late June -- and then everything closes again mid-October.
In this case, what alternative is there than having a magic link in the footer of that email that says "unsubscribe" that includes a token unique to that email address that acts as proof of owning an email account when you then click that link and ask to unsubscribe?