Improve Openess Score so information architecture focus on empty space and liberation from binary blobs

[pietrushnic]

• Change the architecture of information in the output so free space is promoted; we can use the discussion from this thread to write a justification for that thinking. In general, my opinion is similar to Ron's: about firmware getting out of the way as fast as possible, which means a smaller code base serving the purpose of users is better than a more extensive code base that is fully featured. This could lead to the conclusion of the direction of innovation in the firmware space, which should happen. Here is another exciting perspective on the same problem: https://world.hey.com/dhh/finished-software-8ee43637, which sticks with KISS and UNIX design ideas.
• Code that can generate a comparison table of various firmware already scored on the Dasharo page; I could present that on the next DUG because it could be interesting for the community.

Originally posted by @pietrushnic in #917 (comment)

[miczyg1]

Change the architecture of information in the output so free space is promoted; we can use the discussion from this thread to write a justification for that thinking.

Maybe we could simply introduce "liberation factor" calculated with the formula:

(open source bytes + empty bytes) x 100% / closed source bytes. That way we promote empty space in favor of open source code. We can add an exception: if open source bytes == 0 then liberation factor = 0%. I don't think overcomplicating it will benefit us at all.

Code that can generate a comparison table of various firmware already scored on the Dasharo page

Looks like out of scope of what the utility does and is supposed to do. Sounds more like another utility to gather the data from docs.dasharo.com. Also does not seem to be related directly to focus on empty space and liberation from binary blobs (a separate issue for that would be better).

What exactly we would like to compare? Just the raw percentage of open/clsoed code ratio/liberation factor? Openness Score report contains much more data which does not necessarily needs to be compared, nor will give meaningful data. For now I don;t see what information could such comparison table provide, except openness/liberation percentage or raw closed source size change over the years of CPU evolution.

Another matter to solve is where to gather the data input for these comparisons. It should be something that is easily parsable and can be quickly imported to an array or something. Simplest would be CSV file...

Feeding it with the same platforms over and over does not increase the variety of results (e.g. feeding the utility with multiple releases of the same platform would just give neglectable differences).

@pietrushnic

[pietrushnic]

Maybe we could simply introduce "liberation factor" calculated with the formula:

(open source bytes + empty bytes) x 100% / closed source bytes. That way we promote empty space in favor of open source code. We can add an exception: if open source bytes == 0 then liberation factor = 0%. I don't think overcomplicating it will benefit us at all.

Precisely, although I would use different wording. We decrease TCB for the platform. So, we have three categories of TCB code classification:

• proprietary - worst, we have no idea what is lurking inside,
• open - acceptable because it can be audited,
• exterminated - we essentially removed code to decrease TCB; this is ideal if we do not lose functionality. Also, some users may prefer less functionality and smaller TCB, and users who are not privacy and security-focused may prefer the other way around.

The goal is to show how much we decreased first (proprietary), how much open was added to replace the proprietary one (open), and how much TCB was decreased.

How do you visualize that? We should experiment because I need vision our of the box.

Initially, we have 100% closed source (proprietary). Dasharo splits that into proprietary, open, and exterminated.

For second part separate issue was created:

#1180

[miczyg1]

How do you visualize that? We should experiment because I need vision our of the box.

I'm an engineer, I can only think about providing raw data. The representation layer is not my forte. Whatever we choose, I would probably have problems to give opinion if it is good or bad... Honestly, I don't know how to show that, because it is mostly personal view. One will like it, other not, and the cycle of changes never ends.

[pietrushnic]

Let's try what I wrote here:

#276 (comment)

The pie chart may be the same as before, but it is shown differently (side by side), so when you look at it, you can visually compare what changed in what area. A pie chart with some dotted lines shows how things looked before, and solid lines show the current state.

Engineers have to present results. Drawing charts with good legends is essential for mass consumption.