Plenty do display arbitrary _content_ thought. Mail clients, RSS readers, various messaging (twitter, mastodon, ...) clients, etc use it. Obviously these days many apps instead just ship a 400mb out of date copy of chrome instead of using the builtin frameworks, so it's less of an addressable problem, but so it goes.
A mail client is partway there, but is probably significantly filtering the html it allows.
An RSS reader would be one of those few apps that might have the full risk.
Messaging platforms have to worry about unicode bugs and image bugs, but almost all html or javascript exploits don't matter to them. If there is a safari-specific problem, it's very likely they don't care about it.
Mail clients do not filter html, that's a losing strategy, they use APIs on the rendering engine they use to prevent the engine from doing anything "bad" e.g. you don't try and filter JS, you tell the engine to not enable JS, you don't try to filter urls or resources by regex on the source, you use the engine APIs to manage resource loading yourself. Then it doesn't matter what absurd syntax or encoding is being used, if the engine thinks it should do a load, or run some scripts, it asks the host app.
But it doesn't matter what proportion of the app ecosystem is or is not using the system webkit framework, we both know that if Apple does update only Safari say, and then people are compromised through their RSS reader, the HN comments will be asking why Apple didn't update the system framework.
Don't get me wrong - I do get annoyed at having to reboot, but I'm not sure what the better solution is given the constraints of macOS and iOS (at least iOS apps are better designed in terms of saving and restoring state).
> Mail clients do not filter html, that's a losing strategy
I mean that whitelist-style, which isn't a losing strategy.
But that's a side issue. I'm trying to argue that the vast majority of programs that use webkit aren't affected by the vast majority of webkit-specific bugs.
> But it doesn't matter what proportion of the app ecosystem is or is not using the system webkit framework, we both know that if Apple does update only Safari say, and then people are compromised through their RSS reader, the HN comments will be asking why Apple didn't update the system framework.
I'm not suggesting not to update. But yes it does matter how many programs are vulnerable.
> I mean that whitelist-style, which isn't a losing strategy.
What are you trying to filter with your "whitelist"? Anything you'd want to filter can be controlled directly via browser embedding APIs, without any vagaries or guesswork.
> I'm trying to argue that the vast majority of programs that use webkit aren't affected by the vast majority of webkit-specific bugs.
I'm not sure what you mean here. The whole point of a security bug is that an entity is trying to compromise the system. We aren't talking a "webkit specific rendering bug", we're talking about the goal being code execution. So "affected by" is "displays untrusted content".
RSS apps, Mail apps, Messaging, and Social media apps are all subject to that. Messaging isn't arbitrarily constrained - any properly encrypted messaging system requires the client to assume that any received message is completely attacker controlled. Even in these hypothetically constrained messaging and social media apps, if nothing else, often allow you to just view web content from within the app. The goal of an attacker is to get some specific content to hit a web view. They do not necessarily care what application is driving that web view - arguably they'd prefer non-safari as 3rd party apps generally aren't sandboxed, so gaining code execution in the host is yet more powerful.
> I'm not suggesting not to update. But yes it does matter how many programs are vulnerable.
What matters is how many users would be exposed, which is a function of the number of apps, the number of users of all of those apps, and the degree to which those apps are exposed to arbitrary content. WebKit on macOS is widely used, and it is often (if not typically) used for untrusted content.
> Anything you'd want to filter can be controlled directly via browser embedding APIs, without any vagaries or guesswork.
Then they'll already be immune to many exploits, great. You're not really arguing against my point here.
> I'm not sure what you mean here
Sorry. What I meant by webkit-specific was basically a bug that is in webkit but not a more general text or image rendering bug that affects the entire system.
> any properly encrypted messaging system requires the client to assume that any received message is completely attacker controlled
I disagree. Many messaging systems don't send html. If they do send raw html, for most of those apps it's not unreasonable to trust the server, because if the server is compromised they could just send a malicious update. So you only care about things that can make it through the system, which is a tiny percent of html, and renders 90% or whatever of web engine bugs unreachable.
> Even in these hypothetically constrained messaging and social media apps, if nothing else, often allow you to just view web content from within the app.
Now that is an app that is vulnerable! But only some do that, especially on desktop.
> What matters is how many users would be exposed, which is a function of the number of apps, the number of users of all of those apps, and the degree to which those apps are exposed to arbitrary content.
I agree. I just don't want to overstate the degree.
I guess it depends on what the bug is.