3 ms·
Yep. The pushback against FLOSS software could be seen as a delay tactic to allow the continued distribution of software with known flaws (even in commercial e
by jka 5y ago
Yep. The pushback against FLOSS software could be seen as a delay tactic to allow the continued distribution of software with known flaws (even in commercial environments with source-available agreements, as other commentors have alluded to. if you don't have both the public code and reproducible build of it that you can verify independently, then you may have been provided with human trust, but you do not have software trust).
I'd expect that once software trust reaches a sufficiently high-quality baseline, we'll begin to see tricksters retreat (or bolster) network-level traffic gathering and interference. Not all tricksters are hugely sophisticated -- but many of them do get themselves into increasingly complicated situations, often with significant access to resources of finance and leverage -- so that movement would probably be accompanied by a lot of braying for attention and FUD-style tactics (they'll need to find ways to cover their tracks -- something that is often purely about producing distracting noise and search results nowadays, in the era of search engines).
- Seirdy 5y agoHave you noticed a pushback against FLOSS? I'd be interested if that's the case. I went out of my way in this post to make it clear that I'm vehemently in support of FLOSS for a solid list of reasons; it's just that "security" is far lower on that list than some readers would think. There's a reason I only decided to post this months after two of my previous posts in support of FLOSS gained traction ;). Unfortunately, "FLOSS doesn't imply security, but it's certainly helpful. Just set your expectations straight and remember that security isn't a checklist but an emergent property that stems from a variety of factors uncovered through detailed analysis" is a bit too long of a title so I had to make one that looked like I was picking a side before making it clear that I wasn't. Titles aren't good at capturing nuanced views.
- jka 5y agoIt's OK, this was me jumping on my usual soapbox, and not a direct response to your article (I should do better at staying on-thread-topic, in general). In the venn diagram of source-code-related security properties, the fact that proprietary code can be secure and that FLOSS software can be insecure aren't controversial to me, so I think I'll tend to be aligned with your core arguments. The pushback that I notice (or perceive? maybe they're different?) is that most large tech companies - regardless of background - seem stubbornly opposed to offering their products and services as FLOSS through-and-through, despite what I think are fairly apparent, technically sound, morally conscious and defensible arguments that the code for the products everyone relies on in life could and should be FLOSS. But: I'll go away and read your post in a bit more depth before adding any further thoughts.
- jka 5y agoRoughly speaking: yes, you make fair points that source code isn't required for a number of different security research approaches (and, as you indicate, many research practitioners essentially isolate the software they're investigating and then attempt to see what it does at a binary level and/or at runtime). Although I suspect that I'm missing other things to add to the conversation, I'd argue that availability of source code -- at least in the Zoom and Intel ME cases -- would reduce the overall time-and-monetary-cost of identifying suspected flaws. And also of nullifying invalid insecurity claims! So that's another argument for FLOSS: let's try to dissuade vendors from (appearing to?) waste our researchers' and defenders' valuable time.