|
|
|
| Authored by: Anonymous on Thursday, July 05 2012 @ 01:16 AM EDT |
"Security by authority" as you put it is - or was at least - more
about trying to provide enough information so that users can actually make
decisions. How do you make trust decisions now... based on the source of the
code/binary? How is that not security by authority?
The basic problem this can help with is "do you trust program X?". Or
website X for that matter. That's not enough information to make a reasonable
decision on of course. Do you trust program X that <signing authority>
says is signed by Red Hat? Still not enough information and code signing is of
course not perfectly reliable (and signing authorities much less so - crypo is
usually bypassed, not broken), but that's an improvement if the authority can
usually be trusted.
Having said that, there's a major tradeoff here as the trusted authority are
both the obvious flaw and the most important link in the entire chain. Maybe
there's a better option, but it's not obvious to me. How do you help a user to
make a reasonable decision to trust or not trust program X?
Restricted boot as the FSF is calling is (when a user is not allowed to make
their own trust decisions but instead gets told "thou shalt trust Microsoft
and no other") is a different beast entirely of course.[ Reply to This | Parent | # ]
|
|
|
|
|
