Hacker News Reader

Comment by duxup | Hacker News Reader

>I remember the good old days when people were actually trusted to do their own research before downloading a potentially dangerous exe.

Is there any evidence that was ever really a thing / effective?

How could you possibly know?

There are plenty of examples of previously trustworthy software becoming untrustworthy, same with sites you download the code from.

That line reads like the absurd advice that security experts put out about "only download something you trust" and ignoring that nobody has a clue how to evaluate that aside form say limiting them self to FOSS and reading all the code...

View on HN

> absurd advice that security experts put out about "only download something you trust"

This is mostly a meme from the overzealous FOSS and privacy crowd, not the security crowd. Professional security engineers do not, as a rule, encourage software engineers (or end users more generally) to only use open source software because "you can inspect the code for vulnerabilities."

Anyone with legitimate security expertise will understand the benefits of specialization and core competencies. Namely that despite the ideological perspective of many in the FOSS community, it is actually better to trust someone else with the security of your software. Because you most likely can't trust yourself with that task anyway.

The idea that most people can reliably identify security vulnerabilities in the software they use just because it's open source is laughable. They might find trivial low hanging fruit or obvious malicious activity, but they won't have a better picture of the overall security posture just because they can read the code.

As an obvious case in point, consider how few people identify vulnerabilities in Firefox versus how many people use Firefox. The people who write complex open source software don't even reliably find the issues in their own code.

Yeah I didn't intend to tie FOSS advice to the security comment but inadvertently my comment reads like that.

I intended it to just be a comparison of the "only download something you trust" absurd advice you get from "security" people you see on TV or something... and what the user was suggesting about the old days.

My FOSS comment was really meant to reflect the absolute rabbit hole you go down when it is suggested people can simply protect themselves. It's never ending flow of tasks and things you need to know that I don't think anyone can do ...

> Professional security engineers do not, as a rule, encourage software engineers [..] to only use open source software because "you can inspect the code for vulnerabilities."

All else being equal, I'd certainly have more trust in the FOSS version. Yes, i won't audit it myself, but source we can compile ourself is still easier to audit. As such I'd hope more people will have eyes on it than without source access.

Same for a hash of the executable I download being generated by an reproducible build. And I prefer to download and run the same installer as everyone else than someone offering a custom download link just for me.

Non of that means I don't have to trust the project/maintainer. But it is a bit of extra safety I want in some cases, e.g. for a password manager.

> Professional security engineers do not, as a rule, encourage software engineers (or end users more generally) to...

And many 'professional security engineers' ignore core security (e.g. auditing protocols, connections, user access, etc) to push AV software, 2fa tokens, NIDS, version/patchlevel compliance infrastructure, and other 'security tools', because this is easier and comes with 'vendor support'.

I don't argue that these tools are a 'meme' however simply because there are a few people that don't understand the whole picture.

I could just as easily argue:

"The idea that most people can reliably identify security vulnerabilities in the systems they use just because it's protected by vulnerability scanning tools is laughable. They might find trivial low hanging fruit or obvious malicious activity, but they won't have a better picture of the overall security posture just because they can read the audit report."

>>FOSS and reading all the code...

Don't forget, you have to compile from source as well. I'm thinking the parent you replied to forgot how awful sourceforge was, and even trustworthy projects could have garbage bundled in.

And also trust yourself to have a better idea than the devs do about security. Most flaws are accidents and accidents can be hard to catch.

Every good dev knows to stay the hell away from sourceforge!

Only if that's part of your definition of a good dev. I know plenty of good devs who downloaded software from Sourceforge back when it was big.

Let me guess: you also dislike GitHub because it's closed, and wish people would distribute software from their own, self-hosted git repositories?

Devs get better by learning from mistakes.

Sourceforge is a hostile source of malware : https://mail.gnome.org/archives/gimp-developer-list/2015-May...

You mock those who desire freedom at your own risk. Github is microsoft now, and supporting it feeds the beast.

was, not is. Sourceforge has changed hands since then.

Yeah my understanding is after it changed hands they did away with all the nasty stuff that happened in the past.

> You mock those who desire freedom at your own risk. Github is microsoft now, and supporting it feeds the beast.

Oh no, it's the 90s and Micro$oft is evil! They're going to embrace, extend, extinguish all my open source software! I won't be free to develop software anymore!

I'm quite happy with Microsoft, and if supporting GitHub "feeds the beast", then I'm likewise happy to see that beast well-fed.

That was true back in 2015. New owners have been cleaning it up since 2016:

Under new management, SourceForge moves to put badness in past https://arstechnica.com/information-technology/2016/06/under...

Logan Abbott[0] bought SourceForge back in 2016 and has been cleaning it up ever since[1]:

> Hi, president of SourceForge here. Glad this is trending, albeit a few months later. These articles seem to trend on HN every few months, with many people not realizing SourceForge changed ownership in 2016 and that the new team's been working hard on improving. To be clear, we had nothing to do with the bundled adware decisions of 2015, and when we took over in 2016, the first thing we did was remove the bundled adware, as well as institute malware scans for every project on the site. We're working hard to restore trust, so if we win some of you back that would be cool. However, we're just focused on doing right by our million daily users.

[0] https://news.ycombinator.com/user?id=loganabbott

[1] https://news.ycombinator.com/item?id=17592523

And compile your compiler, and ...

(In reference to the classic paper: https://www.archive.ece.cmu.edu/~ganger/712.fall02/papers/p7...)

Also considering the layers of hardware with layers of firmware. ... I should probabbly learn something about that too....

I'm thinking along the lines of google's blog on Meltdown and Spectre recently that basically said if two things are on the same processor.... there's nothing you can do now security wise and be sure about it.

That's why there's been so much work on reproducible builds.

The existence of whole industrial and home computer industry kinda proves that the models were effective and worked. Yes, there were vulnerabilities and viruses but that did not stop the computer industry from growing and proving its worth.

This is true, but "worked" does mean it was secure by whatever we standard we consider good today.

That might be because we (at least on sites like this) are being overzealous about security. Or it might mean that in the modern environment, security is more of the concerns than in the halcyon days of MS-DOS.

Right on.

The security paranoid experts and FOSS zealots have always thought for some inexplicable reasons that if you can download a source and build the program yourself, then it's safe.

It doesn't make it inherently safe, but if you are attempting to prove your builds are safe then it is impossible for anyone else to verify that without the source. See the thread on Debian reproducible builds from earlier this week for more discussion on this topic: https://news.ycombinator.com/item?id=19310638

Code signing is something you can do on both open-source or closed-source, but it doesn't prove anything other than that a particular build was made by a certain person.

"but it doesn't prove anything other than that a particular build was made by a certain person."

But that's what trust actually is. This IRL person or identity, that I trust, vouches for the non-maliciousness of this application.

Except the core problem is key propagation because just anyone can have a key - paid or free if you don't know the source. It says it is from Globe Software and it matches with the provided key. It doesn't tell you if they really are Globe Software, let alone if they are a trustworthy company in the first place.

If your compiler correctly enforces security properties (and many languages do attempt to do this, at least in well-defined "safe" subsets), then of course any source code compiled with it is going to be safe. It's the difference between the JavaScript/WASM JIT-powered sandbox on the one hand, and the ActiveX code-signing-based model on the other. Which is safer?

I can visit a website and my CPU can get hammered to mine cryptocurrency for someone else without my consent.

I'm not sure either is that much better at this point!

What? A compiler can't tell if a given program is "safe" any more than it can tell if the program will halt.

A compiler can tell if some program will halt, for many reasonable cases. For example, if the program comes with a proof that places it in some well-defined computational complexity class, a compiler will be able to tell that it halts. And even if a program cannot be said to halt in general, it can still be said to halt conditional on some "unsafe" assertions being true. Similarly, we can verify safety properties for many useful programs, and we can even use "unsafe" assertions to limit the extent of uncertainty about these properties that we cannot directly verify.

> if you can download a source and build the program yourself, then it's safe.

I think only a loud (very small) minority think that. The rest of us know that's silly, and bringing it up to prove some point against "FOSS zealots" is also silly. FOSS does allow for independent code reviews (which do happen on some projects), but that's not the only reason FOSS > proprietary crap.

> but that's not the only reason FOSS > proprietary crap.

Your use of "crap" to describe proprietary software betrays your bias. It's dangerous to be emotional when we're talking about security, it's important to remain objective and data driven.

Not all proprietary software is crap and not all open source is safe. It's not that uncommon that companies whose very livelihood depends on their code being secure invest much more time and money auditing it, while open source is often a lot more lenient, because there's not real accountability nor negative effects for shipping insecure software.

Eh, it's crap because you have to trust the company pushing it out, it's 100% impossible (by definition) to verify source yourself, at least not legally. You could trust an open source developer, but you could also have a look at the code yourself, or pay for an independent security review of it if your business depends on it.

The problem is that the software itself is not trustworthy, even if signed, certified and delivered with perfect integrity.

Any scum can pay money to get a certificate; you don't have to pass an ethics examination.

It is just a racket.

Of course but all of the above mentioned can still happen and does happen today with all security measures in place. With the added benefit that we must ask permission of a private entity to release an app and we must pay 30% of our profits to the gatekeepers /s

I think I like the old way better.

I don't think I understand what the difference is with the "old way" if as you describe it ... there seems to be no difference. You don't have to pay some cert provider under the old or current way.

You do if you want your app not to be flagged as spam. Users are perceptive. They notice when windows brings up a big notice telling them the app is not to be trusted.

Perception is everything in those first few moments a user get his hands on your software. But now if I dont pay the entrance fee I potentially get abandoned by said user bc they have been scared off.

Its not an app store yet. Give it 5 or 10 years when we no longer have an open web and all we have are walled gardens.

You don't have to do anything you don't want to. No one is forcing you to develop for those platforms.

Your old way still exists. Approximately all real world users demonstrably prefer the new way, but if you're set on your old way you can still write software for macOS and Windows. It will pop a warning, but you can make it run anyway. Give your users instructions for bypassing those warnings. If you trust them to manually verify your software then you trust them to follow those directions.

> Give your users instructions for bypassing those warnings. If you trust them to manually verify your software then you trust them to follow those directions.

If your selling software, this probably isn't a good strategy. However, I consider it perfectly reasonable for software that's being created in one's spare time and offered for free.

(I think the current situation we have on Windows / macOS is a perfectly fine balance, btw—except for drivers, where installing unsigned copies is way too difficult)

Back in the day, you used to evaluate trust by making smarter decisions about how you went about installing things.

You downloaded it to an isolated environment and ran it and proved it didn't cause unexpected side effects. It was run behind a firewall that could log internet communication. If it proved to be good, you ran it in your main environment. If it proved to be bad you warned everyone who would listen to you.

I feel like the more "social" the web appears to be becoming, the less social it actually is. We had tight little BBS and IRC communities where this stuff was all discussed. Social meant we actually had meaningful conversations... okay, not always meaningful, but it was often about the pursuit of something useful.

It's nigh on impossible with the proliferation of the internet to take this approach these days. Things just didn't scale that well. This is why things like DD-WRT and other hacker sites while being more accessible are still very much a niche market.

It's funny how much more technical you had to be back then just to get online. It's as if we're driving the automatic version of the internet now. Back then we had cobble all the pieces together and even when you had, it was like driving with a manual gearshift.

”and proved it didn't cause unexpected side effects.”

and convinced yourself it didn't cause unexpected side effects.

Put a one month timer in your malware, and this would get past many of such attempts to ‘prove’ the software isn’t evil.

Add a few countermeasures against clock shifts (e.g. only be active a few minutes each month or only activate when a) enough time and b) enough user interactions have passed from the first run), and you’ll effectively get past most, if not all, of such black-box testing exercises.

> and convinced yourself it didn't cause unexpected side effects.

To be fair, with virus proliferation in today's age, we were still more successful with the remedial precautions back then than seems to be the case today.

> Is there any evidence that was ever really a thing

Are you asking if software existed before code signing? Yes, it did.

HN has a guideline that you should respond to the best interpretation of a comment, not the least favorable one.

IMO he was clearly reffering to 'thing' being 'an effective thing' for preventing viruses, as opposed to him asking if people downloaded software before code signing.

> Is there any evidence that was ever really a thing / effective?

Of course not, the person who wrote that has absolutely no concept of the modern Internet user, and probably thinks themselves materially better than them.

Reply on news.ycombinator.com