321–330 of 335 posts
Earlier quoted context omitted.
Ah the good old days when nobody except the experts cared to buy, never mind install, third party software.
We made it work and didnt have to ask IBMs permission to install software on its devices.
Earlier quoted context omitted.
Is that actually true? How many people, when installing Photoshop, actually look at who issued the cert?
In Windows, the name of the publisher in the cert shows up on the UAC prompt whenever the program asks for elevated privileges. That's the point of this whole thread -- the author isn't paying for a cert because he can't make the UAC prompt say Notepad++ instead of his real name (which, he could, and I have no idea why he thinks it's so complicated, but there it is).
Earlier quoted context omitted.
This could be easily achieved by Microsoft running a free signing service. Lowering the cost of signing to zero would significantly increase the proportion of signed apps.
Apps submitted to the Microsoft Store are signed by Microsoft (only), iirc. Although it costs $19 or $99 to sign up, one time.
They could enable this for win32 apps but they want to push things towards the walled garden.
Earlier quoted context omitted.
The parent statement was that having signed apps made them easy to disable. If all apps had to be signed, everything would have a reputation hook, and also be easily disabled. It's the hang-up of using the for profit 'verified' code signing ecosystem that makes signing ineffective. Of course, MSFT/Apple etc will abuse it to kill apps they/govt don't like.
I don't really understand how any of this makes signing ineffective.
Code signing is a bit like gun control. It really doesn't solve the problem at all. It just pushes it up a level, and makes things more difficult for legitimate users.
It also lines up incentives such that the preferred model of software distribution shifts in the grand scheme of things toward for profit code.
While code signing is a neat technical solution, it's still a technical solution parading about as a solution to a social problem. And the social problem it is a solution to (that of untrustworthy folks existing) is not in any way mitigated by the act of signing as mentioned previously.
Earlier quoted context omitted.
I don't really understand how any of this makes signing ineffective.
If the only way to play is to go through entrenched gatekeepers, who watches the watchers, hmmm? If anything this should be seen as a power grab by entrenched interests to have a cryptographic lever to pull to shut people out of what should be a user's discretion decision pre-emptively. Walled gardening at it's finest. Code signing is a bit like gun control. It really doesn't solve the problem at all. It just pushes…
Earlier quoted context omitted.
> A signed app can be distributed from anywhere with the assurance it's the same app - it can't be maliciousified This is only true if there is some trust in what is signing them. If anyone can get one then anyone can sign the malicious version of the app with their own key, or one they stole from someone else. The user doesn't know who is supposed to be signing the app -- and if they did then you could be using TOFU…
I think if you don't like code signing for ideological/process reasons, you can argue that, preferably in reply to someone who wants to argue about it. But trying to work backwards from there to technical arguments that show how signing is the same thing as AV is futile, it just makes you type up longer versions of obviously technically inaccurate things.
And the technical arguments in favor of code signing are weak. They started off claiming a major benefit -- globally disable malicious code. Except that AV can do that too. The argument in favor of having code signing on top of that then becomes weaker -- AV can stop identified malicious code but it can't stop other malicious code from the same malware author. Except that code signing can't do that either since the malware author can sign other versions with different keys. So then the argument becomes, well, at least it rate limits how many different versions there are. Except that is only meaningful to the extent that getting a new key is arduous and not a lot of people have them, otherwise the attacker can get arbitrarily many more by either just applying for more under false identities or by compromising a moderate number of machines to capture more keys from the large number of people who have them. Moreover, using domain validation would already capture the case where you want to get the incremental benefit achievable from a minimal imposition on the developer.
Meanwhile the process of obtaining a code signing key has to be sufficiently easy and non-exclusive that even individual developers can reasonably do it, so making it purposely more arduous than that is a directly conflicting requirement.
The explanation is long because the details are relevant, not because anything "obviously technically inaccurate" is there.
Earlier quoted context omitted.
I think if you don't like code signing for ideological/process reasons, you can argue that, preferably in reply to someone who wants to argue about it. But trying to work backwards from there to technical arguments that show how signing is the same thing as AV is futile, it just makes you type up longer versions of obviously technically inaccurate things.
There are good ideological reasons to not like code signing. But people present technical arguments in favor of it, which then need to be addressed so that people don't erroneously find them convincing. And the technical arguments in favor of code signing are weak. They started off claiming a major benefit -- globally disable malicious code. Except that AV can do that too. The argument in favor of having code signing…
Windows signing is a ripoff, $500/year you're getting nothing. Your certificate is not trusted. You have to "get reputation for it" before Windows Defender would stop giving users warnings. Also, renewing certificate is not a thing. Every time you have to get a new one, with same story of "reputation" again. [1] https://www.digicert.com/order/order-1.php
Wait are you saying that Apple Developer program for 99$/year is actually quite a good deal in comparison? I will definitely pull this thread out next time someone complain that Apple is too expensive and that they are milking the poor developers...
Other companies also milking their developers does not invalidate this argument.
Earlier quoted context omitted.
The good scammers absolutely will not be scared off by the need to pay a penny to steal a dollar. You have to buy a cheap watch/violin/purse if you want to pass it off as an expensive one. You have to pay off in the back of the operation if you want to keep cash coming in through the front. Indeed, one of the easy ways to short-circuit human trust defenses is to make a show of trust first, such as by placing personal…
I don't disagree with your reasoning. But: I posit there are fewer "good scammers" than "scammers." Added friction probably reduces the total number of active scammers.
People might forget that "caveat emptor" still applies, even in a walled garden.