
General Transparency - tosh
http://www.certificate-transparency.org/general-transparency
======
aaronbwebber
It's kind of weird that this is an HTTP link. It's also kind of weird that
certificate-transparency.org doesn't redirect you to HTTPS.

~~~
Piskvorrr
Stranger still as the HTTPS version seems to be in working order.

------
Leace
Key Transparency [0] uses the same model. Too bad the project seems inactive.

[0]: [https://security.googleblog.com/2017/01/security-through-
tra...](https://security.googleblog.com/2017/01/security-through-
transparency.html)

~~~
tialaramex
Humans are nosy. This works out to our advantage in Certificate Transparency,
not a few problems have been uncovered by people who were just browsing either
their own output from CT or [https://crt.sh/](https://crt.sh/) and they said,
as so often, not Eureka but "Huh, that's weird".

Knowing james.johnson.example was issued a certificate does kinda give away
what the Johnsons are calling their new boy baby before they announce it, but
the argument that DNS names in the Internet are supposed to be "private" feels
intuitively implausible, so we just said "Certificates in the Web PKI are
public documents", and it's true because we said so and we meant it. Like
those Inalienable Rights.

But in Key Transparency your nosiness gets you nowhere, the privacy concerns
were too great, and so a Key Transparency system doesn't tell us anything
humans are nosy about. Who has keys? What keys? What can we say about those
keys? Out of understandable deference to privacy we learn nothing of interest
about these topics.

Still it isn't _that_ inactive, it has changes from July or so in the git
repo. Maybe something will yet come of it.

------
voidmain
I'd like to see a transparent ledger for software releases, to make targeted
malicious update attacks detectable.

Similarly, pinning the hash of the index resource for a web site using a
transparent ledger could let web apps be as secure as native apps with auto
update.

~~~
Boulth
Have you seen this:
[https://wiki.mozilla.org/Security/Binary_Transparency](https://wiki.mozilla.org/Security/Binary_Transparency)?

------
mkj
Build this into a LineageOS release and it would make targetted software
replacement quite a bit harder. Thought it would be thankless work that
mightn't be worth bothering with.

------
dane-pgp
"we do not claim to support decentralisation"

What a strange statement to make. I feel like such an apparent preference
should be accompanied by a very clear explanation of the disadvantages of
decentralisation (other than "it's hard and we don't know how to do it").

Ideally, a page discussing the relative merits of centralisation and
decentralisation would start with a threat model too, so the reader knows what
problems are attempting to be solved, and which are out of scope.

~~~
dane-pgp
If the people who downvoted me thought that I was being disparaging with my
comment of "we don't know how to do it", let me clarify that this was not my
intent. What I meant was that there are genuine difficulties in trying to
decentralise trust, and I don't think anyone knows how to solve them all right
now.

For example, we could store transparency data in a blockchain, which might
have independent economic incentives to keep it operating beyond the life span
of any individual log provider (and without an individual log provider being
able to rewrite history), but how does a piece of software check a value on a
blockchain without receiving that piece of information from a trusted
intermediary (or better a configurable list of mutually-independent semi-
trusted intermediaries)?

