3 ms·

It'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

by jka 5y ago

It'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 ago
Roughly 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.