Jonas already answered most of the points on another mail. Just one
comment below
On 13/07/2012 12:30, Henri Sivonen wrote:
On Mon, Jul 9, 2012 at 8:04 PM, Jonas Sicking <[email protected]> wrote:
With that, let me start by enumerating the requirements that we have had in
mind for trusted apps:
* They are reviewed in some form.
...
...
Verifying that you are interacting with an entity you "trust" (as
opposed to receiving bytes certified in advance by a third party) is
already a solved problem on the Web: https. I suggest that the B2G
security model attached trust to suppliers of applications rather than
to particular bits of client-side application code. This way, there's
no need to solve the problem of verifying signatures on client-side
pieces of application code and it's possible to instead focus on
hardening https identity verification e.g. by pinning the https
private key of the trusted app so that the app is safe against attacks
leveraging the multitude of CAs.
Plain HTTPS is a bust for trust: there's a huge gap between what most
users (in my experience before someone asks about hard statistics :P)
believe and the reality. Users believe that the lockpad marks a site as
trusted, when it really means that, in the best case, someone has taken
some vague steps to verify that the person or entity that asked for a
certificate also owned the domain that was going to be included on the
certificate. And that information usually isn't even included on the
certificate, not that most users even bother with that.
So users believe https => I can trust this site *content* to be trusted.
While reality believes https => this site is 'vaguely' identified. Very
vaguely on most cases too.
As an example, https://www.bbva.es is one of Spanish biggest banks.
Never mind that there are several ways to reach that page that even give
a name error (try https://www.bbva.net for example). Let's assume you
reach the the correct page by the correct address and don't get an
error. And that you're a security conscious user and don't trust the
lockpad blindly but decide to actually check the certificate. You can
see that the DN is
CN = www.bbva.es, OU = Departamento De Informatica, O = BBVA, L =
Madrid, C = ES
which not only isn't very informative but isn't even correct. The
organization actual name is Banco Bilbao Vizcaya Argentaria, S.A., not
BBVA. BBVA is just a (I assume) registered acronym that could mean a lot
of things. Oh, and even if the identify information were complete and
correct, there's absolutely no implication on the CA part about the
content of the page. It could perfectly be a phishing site, so long as
the phishers had bothered registering the domain and paying for a
certificate.
In fact I think the only reason phishers don't even bother with buying
https certificates on most cases is because they cost money and they
don't get a better ROI when using them :)
So... using HTTPS to warrant extra permissions to run things on my
machine would mean that I believe that someone has actually bother
checking at least the identity of the site owner. Which I don't. Never
mind checking the *content* that I'm going to give permissions.
Best regards,
Antonio
________________________________
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
nuestra política de envío y recepción de correo electrónico en el enlace
situado más abajo.
This message is intended exclusively for its addressee. We only send and
receive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
_______________________________________________
dev-webapps mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-webapps
