Computer Old Farts Forum
 help / color / mirror / Atom feed
From: Dan Cross <crossd@gmail.com>
To: Nevin Liber <nevin@eviloverlord.com>
Cc: coff@tuhs.org
Subject: [COFF] Re: [TUHS] Re: Intel ME, UEFI, User Control was Re: Question about BSD disklabel history
Date: Thu, 4 Jan 2024 21:35:35 -0500	[thread overview]
Message-ID: <CAEoi9W5AWoBzwqvL4x2NS9AkpRNbwg1pUvr+GnsdE8E5qHBczA@mail.gmail.com> (raw)
In-Reply-To: <CAGg_6+NVMFrORBqzrvAYvZMYjL7CKsppiuPFZPJ4BHeusLOr_w@mail.gmail.com>

On Thu, Jan 4, 2024 at 5:15 PM Nevin Liber <nevin@eviloverlord.com> wrote:
>[snip]
>> I get wanting to protect users from say bricking the most basic firmware on a board, but if I want to risk that, I should be completely free to do so on a device I've fully paid for.
>
> Now scale it.  How do you keep bad actors from bricking *my* device, especially if my device is on the internet?

The obvious answer is, "by preventing bad actors from getting access
to the means to manipulate your firmware."

> Then scale it to all the security threats besides DoS.  You can disagree with the solutions to these threats, but please don't minimize that these are very real threats.

This is a false dichotomy, as one must bear in mind that the
_existing_ firmware may already be vulnerable. We saw this with the
infamous `strncmp` bug on the Intel ME a few years ago, and we saw it
again just the other day with the JPEG parser bug in a number of UEFI
installations in the wild. _An_ issue with closed and hidden firmware
blobs is that you just don't know; that is, it's not just about
abstract notions of freedom but also about transparency.

>> Unfortunately the general public just isn't educated enough (by design, not their own fault) on their rights to really get a big push on a societal scale to change this.
>
> That is a pretty arrogant statement.  It is far more likely that, instead of the rest of us not being as educated as you, we just value different things.
>
> Traditional Unix systems have, at best, focused on the developer experience, and have been dwarfed for decades by systems companies focusing on the *user* experience.   I'm old enough to remember the decades when Unix was always just a year away from doing better than being a distant third behind Windows and Mac OS on the desktop.
>
> I want devices that are easy to get things done, don't require much futzing, and isn't a nightmare for my life (due to my data that it can access) if I happen to break it, lose it or it gets stolen.

One of the reasons I use a Mac is because macOS _is_ Unix on the desktop. :-)

> For example:  last year when I was hiking in the AZ desert, I got an email about winning a lottery that I had entered for inexpensive show tickets for the next day, and I bought tickets securely with Apple Pay before the deadline expired.  All of that was performed confidently and securely with my iPhone (well, I possibly got the email notification on my watch).  While it may not be the world you want to participate in or care about, that is the kind of amazing experience that I value, and it seems the kind of experience that lots of people value, as evidenced by the size of the smartphone market compared with the size of the computer market.
>
> The open source world and hackable hardware world don't offer this kind of experience.

Ironically, the systems you mentioned are built on Unix and open
source software as a foundation.

>>   People just want I push button I get Netflix,
>
> Why wouldn't you??  While Netflix isn't perfect, are you seriously arguing people should want a far worse user experience?
>
>>
>> they'll happily throw all their rights in the garbage over bread and circuses....but that ain't new...
>
> It isn't about happily throwing away "rights" (whatever that means).  It's about we aren't willing to pay for it.  It's a tradeoff, and those who want everything hackable haven't shown much value to the rest of us, and there are very real concerns about the costs both in terms of security threats and monetary costs.

I get the whole "different strokes for different folks" argument, but
I think you may be underestimating the impact that the whole hackable
thing has had.

The whole industry seems to be over a barrel with the way that things
have evolved.  In many respects, we have amazing technology that lets
us do really cool things (cf your examples above) and that's both
valuable and important. On the other hand, in a lot of ways, it feels
like we're just waiting for the other shoe to drop with something
going really wrong in a hurry because we've undervalued investment in
the foundations for too long. UEFI is a train wreck; ACPI is a train
wreck; a lot of binary-only firmware is of dubious (at best) quality
and provenance, but the industry writ large doesn't have a better
solution to the real problems with these specific technologies. It's a
real problem waiting to happen, and it does us as engineers,
researchers, computer scientists, etc, no good to minimize that.

        - Dan C.

      parent reply	other threads:[~2024-01-05  2:36 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-04 19:10 [COFF] " segaloco via COFF
2024-01-04 21:20 ` Dan Cross
2024-01-04 22:14 ` [COFF] Re: [TUHS] " Nevin Liber
2024-01-05  2:03   ` segaloco via COFF
2024-01-05  2:35   ` Dan Cross [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAEoi9W5AWoBzwqvL4x2NS9AkpRNbwg1pUvr+GnsdE8E5qHBczA@mail.gmail.com \
    --to=crossd@gmail.com \
    --cc=coff@tuhs.org \
    --cc=nevin@eviloverlord.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).