Switching from Security to Identity, do we need evangelism?
Alex Faaborg
A) Information that the user sends can not be intercepted by a third
party (the popular use case being someone not having their credit card
number stolen)
B) Ability to verify who you are connected to (man in the middle
attacks, users who are concerned about phishing).
Our UI for SSL connections has shifted from focusing primarily on A to
focusing primarily on B, for a variety of great reasons. But what I
am worried about is that the rest of the Web is still in the mindset
of only A and is ignoring B.
For instance, consider the major US bank http://www.chase.com/
Their homepage does not redirect to an encrypted connection, and under
the mindset of only A, why should it, the user hasn't submitted any
personal information yet, and the page doesn't contain any personal
information.
Do we need to start evangelizing the fact that SSL is useful for
identity verification. Perhaps write a blog post, or even contact
some of these major sites directly to explain why redirecting their
home pages to an encrypted connection is a better user experience?
-Alex
Mike Beltzner
Shifting the discussion from Security to Identity is not something I
expect will happen over night, but it is something that we need to do.
Our future plans for the site identity button (see: http://people.mozilla.org/~madhava/files/favicon/mockups_2007-07-27/fullmenu_option1.png)
should help by making the button more about the _site_ than the
_connection_, and making the identity of the site one aspect of that
site information.
Johnathan and I have been pressing this message in various working
groups in which CAs and major financial institutions have
representatives, and are seeing a lot of acceptance. Johnathan has
also blogged about it in the past, but it's a message which I do
believe we need to continue to reinforce.
I think as well we should get discussions rolling with internet
security luminaries to broaden this discussion into rethinking online
security into a social component (identity) and an improved technical
component (better underlying mechanisms such as SRP).
cheers,
mike
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
Steven Garrity
> Do we need to start evangelizing the fact that SSL is useful for
> identity verification. Perhaps write a blog post, or even contact
> some of these major sites directly to explain why redirecting their
> home pages to an encrypted connection is a better user experience?
Is it a recommended practice then that a typical e-commerce site, for
example, to redirect all pages to HTTPS?
Steven Garrity
John J Barton
> SSL has two nice attributes:
>
> A) Information that the user sends can not be intercepted by a third
> party (the popular use case being someone not having their credit card
> number stolen)
>
> B) Ability to verify who you are connected to (man in the middle
> attacks, users who are concerned about phishing).
>
Alex, can you elaborate on what you mean by this? Obviously SSL does not
verify "who" you are connected to: it's a not a person neither
technically nor in the user's mental model. Rather SSL plus Firefox UI
gives users some additional information about the URL that increases the
user's confidence that they have reached a site under the control of an
entity they know through another channel. Ok that sounds strained, but
really what is it that user's know about an https site that could be
truly identity?
John.
Alex Faaborg
> not
> verify "who" you are connected to: it's a not a person
By who I mean the URL, which in the user's mental modal is usually an
organization or corporation, not a person.
-Alex
Axel Hecht
I think that having banks have their landing page redirect to https
would be overdoing it. There's loads of plain advertising and news on
many bank sites that I looked at. Like "here's cool whatnot" or "stock
prices for ABC are at ..." or "we aquisitioned whatever" etc. All those
are general news items or advertising, and don't really rely on the
identity of the site that's serving them.
In contrast, on the main page, Chase offers links to safe shopping
guidelines etc.. At that point, I think putting your identity on it is a
good idea, because this is Chase telling you how to protect your money.
And it's totally worthwhile doing some evangelism in that area.
Axel
Gervase Markham
> I think that having banks have their landing page redirect to https
> would be overdoing it.
If they offer a login on their home page, then it's not overdoing it at
all. If the page with the login form on was not transmitted over SSL, it
could have been tampered with in transit to redirect their login
information elsewhere.
Gerv
John J. Barton
>> Alex, can you elaborate on what you mean by this? Obviously SSL does not
>> verify "who" you are connected to: it's a not a person
>
> By who I mean the URL, which in the user's mental modal is usually an
> organization or corporation, not a person.
Ok, so what path B means then is:
B) Ability to verify that you are connected to a URL.
So when I connect to https://www.chaseOnline.com which has exact same
content as http://www.chase.com, I don't have to worry about the
possibility that chaseOnLine.com is actual phishing me? My mental model
is JPMorgan Chase & Co. SSL did what to help me know that my model
matches what I see on the browser?
Wanting to believe,
John.
Justin Wood (Callek)
convenience) publish an update to our phising detector, and warn users
of it aggressively.
in the case that chaseOnline == chase.com then "who cares" which the
user is comfortable with. The "identity" remains intact.
--
~Justin Wood (Callek)
John J Barton
> John J. Barton wrote:
>> Alex Faaborg wrote:
>>>> Alex, can you elaborate on what you mean by this? Obviously SSL does
>>>> not
>>>> verify "who" you are connected to: it's a not a person
>>>
>>> By who I mean the URL, which in the user's mental modal is usually an
>>> organization or corporation, not a person.
>>
>> Ok, so what path B means then is:
>>
>> B) Ability to verify that you are connected to a URL.
>>
>> So when I connect to https://www.chaseOnline.com which has exact same
>> content as http://www.chase.com, I don't have to worry about the
>> possibility that chaseOnLine.com is actual phishing me? My mental
>> model is JPMorgan Chase & Co. SSL did what to help me know that my
>> model matches what I see on the browser?
>>
> If ChaseOnline.com is a phising site, we should (at earliest possible
> convenience) publish an update to our phising detector, and warn users
> of it aggressively.
So you are saying that SSL does not help, its is the phishing detector
that helps. Which makes the evangelism Alex advocates difficult.
John.
Johnathan Nightingale
literal about it, SSL + PKI + CAs doing verification work) does indeed
make identity claims.
You're right that Firefox makes decisions about which of those to
emphasize in the UI, but it is a core aspect of the SSL+PKI model that
you have some assurance you are not only using an encrypted channel,
but that your peer is indeed the entity you're targeting. Obviously,
this comes in degrees: for basic, domain-validated certificates,
confirmation of domain ownership is the extent of the guarantee (still
more than nothing) and for richer kinds of certificates like EV certs,
the guarantee goes as far as "Charles Schwab & Co. Inc., San
Francisco, California, US."
Alex's central point though, is that while we've made this shift from
A to B for good reasons, we need to make sure those reasons are clear
and understandable to other people. How do we do that? Some thoughts:
- As Mike has pointed out - we agitate in various fora for this kind
of thing, generally to positive reception. That includes me and other
members of the community speaking at conferences (I recently spoke at
RSA on this topic, for instance), and in industry and standards groups
like the w3c. This should continue, of course.
- We put it out in the broader technical sphere as well, via our own
blogs and our ability to get those into the tech mainstream. Deb
Richardson's latest post has over 1500 diggs and counting, and is a
great, accessible, introduction to the UI involved. http://www.dria.org/wordpress/archives/2008/05/06/635/
- We reach out to the broader media as well - people speaking to the
media about the impending release of Firefox 3 know about this shift,
and it is included in the materials we're assembling for reviewer's
guides.
- We aren't the only ones on this march either. Believe it or not,
Paypal's whitepaper mentioning EV certs ( http://tinyurl.com/3pdoq5 )
is the kind of thing that may have a big impact on adoption rates,
since it ties better identity information to improved revenue.
There is some component of this that will just take time. The public
visibility of identity information in SSL certificates is pretty low
right now and so users don't really have it in their head that this is
a question their browsers can answer. We should absolutely do what we
can to keep beating the drum, though.
Cheers,
Johnathan
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
---
Johnathan Nightingale
Human Shield
joh...@mozilla.com
Justin Wood (Callek)
No, what I am saying that in such a case of chaseOnline.com vs chase.com
as an example, if chaseOnline is a phishing site. It depends on the
users training and knowledge. if he/she googled for it, or say gets an
e-mail from "chaseOnline" (and said user *has* chase bank, and can
recognize the trademarks/brands itself, but is not web aware enough to
have known chase's website address before now) [s]he'll have no idea of
the difference.
Whereas a case of paypal, ebay, amazon, chase (to a user who allready
knows the address) etc, it does make a difference.
Its a mixture of education and prevention.
Phishing protection helps alot for the less aware user. But users
recognizing SSL enabled sites at all is usually far superior than, say,
my grandmother who barely knows how to check e-mail.
--
~Justin Wood (Callek)
John J Barton
> To further elaborate on Alex's elaboration, SSL (or, I suppose to be
> literal about it, SSL + PKI + CAs doing verification work) does indeed
> make identity claims.
I'd like to understand why you think that this is true. Alex asked for
suggestions on evangelism, I am suggesting that getting a clear story of
what protections this identity conformation offers is the best first step.
>
> You're right that Firefox makes decisions about which of those to
> emphasize in the UI, but it is a core aspect of the SSL+PKI model that
> you have some assurance you are not only using an encrypted channel, but
> that your peer is indeed the entity you're targeting. Obviously, this
> comes in degrees: for basic, domain-validated certificates, confirmation
> of domain ownership is the extent of the guarantee (still more than
> nothing) and for richer kinds of certificates like EV certs, the
> guarantee goes as far as "Charles Schwab & Co. Inc., San Francisco,
> California, US."
But does EV enforce trademark, copyright, or any control over these
strings? If I pay them enough will they let me register "Charles Schwab
& Co, New York, US, Tokyo Japan, and London UK"?
I do think that certificates in general add security, for the imperfect
reason that they are expensive. Is there more?
John.
Mike Shaver
<johnj...@johnjbarton.com> wrote:
> But does EV enforce trademark, copyright, or any control over these
> strings?
Yes.
> If I pay them enough will they let me register "Charles Schwab
> & Co, New York, US, Tokyo Japan, and London UK"?
No, unless you can construct a convincing physical site for them to visit.
> I do think that certificates in general add security, for the imperfect
> reason that they are expensive. Is there more?
They're not really that expensive any more. :)
Mike
Johnathan Nightingale
>> You're right that Firefox makes decisions about which of those to
>> emphasize in the UI, but it is a core aspect of the SSL+PKI model
>> that
>> you have some assurance you are not only using an encrypted
>> channel, but
>> that your peer is indeed the entity you're targeting. Obviously,
>> this
>> comes in degrees: for basic, domain-validated certificates,
>> confirmation
>> of domain ownership is the extent of the guarantee (still more than
>> nothing) and for richer kinds of certificates like EV certs, the
>> guarantee goes as far as "Charles Schwab & Co. Inc., San Francisco,
>> California, US."
>
> But does EV enforce trademark, copyright, or any control over these
> strings?
Yes, extensively more, in fact. The CA has to confirm legal existance
in the appropriate qualified government information sources, ownership
of the domain in question, authority of the requester to make such a
claim on behalf of that business, accuracy of address/location
information, contractual binding on the requester as to the validity
of this information, &c, &c. Read the guidelines yourself, they're...
riveting. http://www.cabforum.org/EV_Certificate_Guidelines_V11.pdf
If you can obtain, for any amount of money, an EV certificate claiming
you are Charles Schwab Co. Inc. USA, UK, Japan without actually being
an authorized agent thereof, that CA should fail their audit and lose
their status as an EV issuer.
Cheers,
Johnathan
Mike Beltzner
> Yes, extensively more, in fact. The CA has to confirm legal existance
> in the appropriate qualified government information sources, ownership
> of the domain in question, authority of the requester to make such a
> claim on behalf of that business, accuracy of address/location
> information, contractual binding on the requester as to the validity
> of this information, &c, &c. Read the guidelines yourself, they're...
> riveting. http://www.cabforum.org/EV_Certificate_Guidelines_V11.pdf
Note that these guidelines to *not* require the CA to establish that
the business practices of the company in question are above board.
They are meant to guarantee *identity* not *safety*. This is another
reason why we must shift the conversation to the topic of identity.
Even if we can guarantee that:
- you are connected to "Money Maker Traders", and that
- no one is eavesdropping on that conversation
we cannot guarantee that you should give your credit information to
that site. That's a decision that you, as a user, must make on your
own based on your relationship with the company. If it's a pump and
dump stock scam company, then you may be pooched.
This is precisely why we don't want to have technological indications
of "safety" or "security". Indications of identity and encryption
(though I prefer the less technical eavesdropping explanation) should
be provided to help users make their own judgements of whether or not
they want to trust the site in question. People aren't dumb. They make
these decisions every day. It's just that in the physical world, there
are usually easy-to-detect implicit trust indicators[1] - our goal is
to provide these indicators in the UI.
cheers,
mike
Tony Mechelynck
> [...] People aren't dumb. They make these
> decisions every day. It's just that in the physical world, there are
> usually easy-to-detect implicit trust indicators[1] - our goal is to
> provide these indicators in the UI.
>
> cheers,
> mike
>
> [1] http://flickr.com/photos/beltzner/2462056298/
Well, Mike, I don't know which "trust indicators", if any, that photo is
supposed to carry, but the photographed object doesn't look like
anything "trustworthy" to me -- much too "amateurish" for a supposed
business which would charge you "$40 and up" for renting a car (with a
driver? without a driver? one way? round trip?) from there to the
airport. Or do I miss something?
Best regards,
Tony.
--
If A = B and B = C, then A = C, except where void or prohibited by law.
-- Roy Santoro
Alex Faaborg
users will go to a site they trust to make a financial transaction,
like chase.com, or ebay.com and since the landing page is not
transmitted over an SSL connection (and they don't have an EV cert),
Firefox indicates that it couldn't verify the identity of the
mainstream site. This is the awkward phase between us switching from
security to identity, but the sites haven't transitioned yet. I have
heard users say "the customs official doesn't work very well, he can't
even identify ebay.com." These sites are working under the mental
model of:
"if you want to protect your users information, encrypt it"
instead of
"if you want your users to trust the information you send them,
encrypt it"
In terms of evangelizing this specific change in mindset, perhaps we
should try to get a short and clearly articulated blog post on digg
aimed at site administrators and IT folks. Deb's post was great, but
the end user focus made the overall change in mindset for sites
implied instead of directly stated. All of the other ways Johnathan
mentioned us evangelizing the shift in mindset sound great as well.
-Alex
> they want to trust the site in question. People aren't dumb. They make
> these decisions every day. It's just that in the physical world, there
> are usually easy-to-detect implicit trust indicators[1] - our goal is
> to provide these indicators in the UI.
>
> cheers,
> mike
>
> [1] http://flickr.com/photos/beltzner/2462056298/
Mike Shaver
to have your guard up the first time you were involved.
Mike
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
>
--
Sent from Gmail for mobile | mobile.google.com
John J. Barton
> To give a more specific example of the problem I am talking about, users
> will go to a site they trust to make a financial transaction, like
> chase.com, or ebay.com and since the landing page is not transmitted
> over an SSL connection (and they don't have an EV cert), Firefox
> indicates that it couldn't verify the identity of the mainstream site.
> This is the awkward phase between us switching from security to
> identity, but the sites haven't transitioned yet. I have heard users
> say "the customs official doesn't work very well, he can't even identify
> ebay.com." These sites are working under the mental model of:
>
> "if you want to protect your users information, encrypt it"
>
> instead of
>
> "if you want your users to trust the information you send them, encrypt it"
>
> In terms of evangelizing this specific change in mindset, perhaps we
But this is exactly my problem: you can't evangelize that phrase because
it does not articulate the critical user value proposition. The
encrypted path buys nothing if the source (site) is bogus. How about:
"If you want your users to trust your site, certify its identity with
Extended Validation".
or for client users:
"Trust sites with Extended Validation".
Don't say
"EV cert", say "Extended Validation". "Extended Validation" operates
here as words with their original meaning, in addition to their
technical meaning as modifiers for a certificate mechanism.
Boris Zbarsky
> Alex Faaborg wrote:
>> encrypt it"
> But this is exactly my problem: you can't evangelize that phrase because
> it does not articulate the critical user value proposition.
It articulates exactly what SSL promises.
> The encrypted path buys nothing if the source (site) is bogus.
Please define "bogus".
> "If you want your users to trust your site, certify its identity with
> Extended Validation".
This is not unreasonable.
> or for client users:
>
> "Trust sites with Extended Validation".
This is a really bad idea. All EV gets you is knowing who you're talking to.
This is somewhat orthogonal to whether you should trust them, though often it's
a prerequisite. And "trust" is not a binary proposition. Trust with what?
For example, the current EV rules would have allowed Enron to get an EV cert.
Or Bear Stearns. Or https://senate.gov. Does this mean that a user can trust
Enron, or Bear Stearns, or anything published on senate.gov? Should they trust
either of the former with $1 billion, or the latter with $300 trillion? Maybe,
and maybe not. It's probably safe to trust the latter with $20, as far as that
goes. In any case, all the user knows is who they're dealing with; whether this
party is trustworthy for purposes of the proposed transaction is an additional
matter.
For another example, consider a man who knocks on the front door. You have no
idea who this man is, but he provides fingerprints and retinal prints and a DNA
sequence. You send all those to someone you already trust; say your mother.
She replies that this is in fact the fellow she hired to take your laundry to
the laundromat, wash it, and return it. You might be more inclined to trust
this guy with your laundry than you are to trust your elected representative
with your laundry (or vice versa, of course). But you'd probably trust neither
with your credit card. Note that in the case of the gentleman knocking on your
door your trust decision is based solely on the recommendation of a third party,
not on any knowledge of who he actually is. Of course if you also knew that, it
could further inform your trust decision.
The pre-EV SSL trust model is the "my friend recommended this guy" model, except
your friend will recommend anyone who buys him a pizza. The EV model is one
where the recommender always provides the recommendee's name, has certain due
diligence they need to perform to make sure the name is correct and that such a
person really exists, and gets into big trouble if the name is wrong or if the
person doesn't exist. They also check to make sure the person being recommended
actually earns money by taking laundry to laundromats for a fee. They don't
guarantee that you can trust the guy with your laundry, much less with your
credit card.
Basically, people seem to assume a lot more about what's guaranteed in trust
terms online than they ever would in person. Encouraging that is NOT the way to go.
> Don't say "EV cert", say "Extended Validation".
Neither carries much meaning to a typical user. More importantly, EV is an
implementation detail. All it gives the user is the assurance:
"You're talking to ACME, Inc, which is a registered corporation"
The same assurance could come from other sources.
-Boris
John J. Barton
> John J. Barton wrote:
>> Alex Faaborg wrote:
>>> "if you want your users to trust the information you send them,
>>> encrypt it"
>
>> But this is exactly my problem: you can't evangelize that phrase
>> because it does not articulate the critical user value proposition.
>
> It articulates exactly what SSL promises.
Yes, well that is where I started. But Alex wants to talk about identity.
>
>> The encrypted path buys nothing if the source (site) is bogus.
>
> Please define "bogus".
Fraudulent, as in a site claiming to represent an entity that it does
not. Identifying themselves as someone they are not. Then sending
information to you with encryption.
>
>> "If you want your users to trust your site, certify its identity with
>> Extended Validation".
>
> This is not unreasonable.
>
>> or for client users:
>>
>> "Trust sites with Extended Validation".
>
> This is a really bad idea. All EV gets you is knowing who you're
> talking to. This is somewhat orthogonal to whether you should trust
Ok, but Alex's has the same problem. And the advice to sites has to
correspond to the client advice.
...
>
> Basically, people seem to assume a lot more about what's guaranteed in
> trust terms online than they ever would in person. Encouraging that is
> NOT the way to go.
I wonder if your assumption is true, but your conclusion is fine.
>
>> Don't say "EV cert", say "Extended Validation".
>
> Neither carries much meaning to a typical user. More importantly, EV is
> an implementation detail. All it gives the user is the assurance:
>
> "You're talking to ACME, Inc, which is a registered corporation"
I disagree, because the words "extended validation" convey an extra
strong procedure, in addition to being an implementation name. But I
actually think there is a *much* better way to approach this:
"This site represents ACME, Inc, according to the extended validation
by <a href="https://...>Certified Authority</a> applied by <a
href="https://mozilla.org">Firefox</a>"
That is the, chain should be links and regular folks should be able read
the pages (maybe that's already happening, seems obvious).
Boris Zbarsky
>>> But this is exactly my problem: you can't evangelize that phrase
>>> because it does not articulate the critical user value proposition.
>>
>> It articulates exactly what SSL promises.
>
> Yes, well that is where I started. But Alex wants to talk about identity.
Well, SSL + EV does make some identity promises.
>>> The encrypted path buys nothing if the source (site) is bogus.
>>
>> Please define "bogus".
>
> Fraudulent, as in a site claiming to represent an entity that it does
> not.
If a site with an EV cert is doing that, the CA issuing the cert screwed up
badly. The entity being represented is named in the cert.
Without EV, of course, this is easy. But note that there are nevertheless use
cases for SSL without EV. If you're sure that the hostname you are visiting
represents the entity you want to interact with, then SSL _does_ have some
guarantee that the site you are visiting is in fact the one that currently owns
that hostname.
Phishing attacks target the "if you're sure" part of that.
>> This is a really bad idea. All EV gets you is knowing who you're
>> talking to. This is somewhat orthogonal to whether you should trust
>
> Ok, but Alex's has the same problem.
You mean:
"if you want your users to trust the information you send them,
encrypt it"
? I don't see why. In RFC terms, if the information is not encrypted the user
MUST NOT trust it. If it's encrypted, the user MAY trust it. Perhaps the
above should be rephrased as:
"If you want to have any hope of users trusting the information you
send them, encrypt it"
> And the advice to sites has to correspond to the client advice.
The best client advice we can give about trust is:
"Absolutely do not trust any page that doesn't have X indicator"
(X indicating encryption). The hard part is to not have people think that it's
always OK to trust the pages that do have the indicator.
Which is why we want to get out of telling users whom to trust and move to
telling them what they know about who they're talking about. Then they can
decide whether to trust them.
>> "You're talking to ACME, Inc, which is a registered corporation"
>
> I disagree, because the words "extended validation" convey an extra
> strong procedure, in addition to being an implementation name.
It's only "extra strong" compared to what used to be there, really...
> But I actually think there is a *much* better way to approach this:
>
> "This site represents ACME, Inc, according to the extended validation
> by <a href="https://...>Certified Authority</a> applied by <a
> href="https://mozilla.org">Firefox</a>"
Perhaps. Exact wording like this is not my strong suit, so I'll defer to Alex
and beltzner here.
> That is the, chain should be links and regular folks should be able read
> the pages
I do wonder what the value in that is... what does mozilla.org say that would
help this trust decision?
-Boris
John J. Barton
> John J. Barton wrote:
>>>> But this is exactly my problem: you can't evangelize that phrase
>>>> because it does not articulate the critical user value proposition.
>>>
>>> It articulates exactly what SSL promises.
>>
>> Yes, well that is where I started. But Alex wants to talk about
>> identity.
>
> Well, SSL + EV does make some identity promises.
So if you want to evangelize it has to be about Extended Validation.
Evangelizing SSL alone is counter productive if you claim identity as
the user value.
>> Ok, but Alex's has the same problem.
>
> You mean:
>
> "if you want your users to trust the information you send them,
> encrypt it"
>
> ? I don't see why.
Because encryption does not help users establish the identity of the
site operators. It is still about security (Alex's A) not identity
(Alex's B).
...
>> But I actually think there is a *much* better way to approach this:
>>
>> "This site represents ACME, Inc, according to the extended validation
>> by <a href="https://...>Certified Authority</a> applied by <a
>> href="https://mozilla.org">Firefox</a>"
>
> Perhaps. Exact wording like this is not my strong suit, so I'll defer
> to Alex and beltzner here.
>
>> That is the, chain should be links and regular folks should be able
>> read the pages
>
> I do wonder what the value in that is... what does mozilla.org say that
> would help this trust decision?
Mozilla needs to stand up for that part that they are evangelizing, that
the Firefox UI surfaces evidence of identity for sites using extended
validation certificates.
Boris Zbarsky
>> Well, SSL + EV does make some identity promises.
>
> So if you want to evangelize it has to be about Extended Validation.
> Evangelizing SSL alone is counter productive if you claim identity as
> the user value.
Sure. But one problem is that some sites that have an EV SSL cert don't use SSL
for all the pages they should be using it for. That's part of what needs to be
evangelized here, and there the message to the site really needs to be "use SSL
for everything", basically.
>> You mean:
>>
>> "if you want your users to trust the information you send them,
>> encrypt it"
>>
>> ? I don't see why.
>
> Because encryption does not help users establish the identity of the
> site operators. It is still about security (Alex's A) not identity
> (Alex's B).
You're confusing what users care about with what sites care about. Encrypting
the information is an absolute prerequisite for the site to be trustable, but
one which many sites are not fulfilling. No one is claiming to the site that
encryption is _enough_, but it's certainly _needed_.
>> I do wonder what the value in that is... what does mozilla.org say
>> that would help this trust decision?
>
> Mozilla needs to stand up for that part that they are evangelizing, that
> the Firefox UI surfaces evidence of identity for sites using extended
> validation certificates.
That has nothing to do with mozilla.org, I should note.
-Boris
Mike Shaver
<johnj...@johnjbarton.com> wrote:
> "This site represents ACME, Inc, according to the extended validation
> by <a href="https://...>Certified Authority</a> applied by <a
> href="https://mozilla.org">Firefox</a>"
We provide not-dissimilar information when you click the site button
in FF3 for an EV site:
http://www.flickr.com/photos/deb-richardson/2468918727/
I disagree that "extended validation" is meaningful to anyone, since
it's a relative phrase (so you need to know what it's extended _from_)
and the definition of "validation" is perhaps-necessarily arcane.
> That is the, chain should be links and regular folks should be able read
> the pages (maybe that's already happening, seems obvious).
Regular folks are not ever going to understand what "extended
validation" means, or what they're supposed to be looking for when
they click a link and go to verisign.com. ("Am I supposed to buy a
certificate? I hear they make the web safe!")
We could do a better job of explaining what's being verified, but I
don't think linking to a CA page or using the phrase "extended
validation" is going to be part of it. The key here is that Firefox
(to anthropomorficate a bit more than I usually like to) believes that
the identity of the site owner is sufficiently verified to present it
to the user. If we thought it was reasonable to expect users to
understand the mechanics, we could just show them the ASN.1 for the
cert and spend a lot less time on it. ;)
Mike
John J. Barton
> John J. Barton wrote:
>>> that would help this trust decision?
>>
>> Mozilla needs to stand up for that part that they are evangelizing,
>> that the Firefox UI surfaces evidence of identity for sites using
>> extended validation certificates.
>
> That has nothing to do with mozilla.org, I should note.
Hmm...interesting. You are literally correct: mozilla.org does not use
https + extended validation. Neither does mozilla.com. Frankly their
home pages make identifying an org from a com difficult.
John J. Barton
> On Wed, May 7, 2008 at 10:08 PM, John J. Barton
> <johnj...@johnjbarton.com> wrote:
>> "This site represents ACME, Inc, according to the extended validation
>> by <a href="https://...>Certified Authority</a> applied by <a
>> href="https://mozilla.org">Firefox</a>"
>
> We provide not-dissimilar information when you click the site button
> in FF3 for an EV site:
>
> http://www.flickr.com/photos/deb-richardson/2468918727/
Neat.
>
> I disagree that "extended validation" is meaningful to anyone, since
> it's a relative phrase (so you need to know what it's extended _from_)
> and the definition of "validation" is perhaps-necessarily arcane.
So your theory would claim that people won't buy "Wonder Bread" and
since 2GB is only relatively better than 1GB and GB is arcane, then we
can't expect them to choose USB memory sticks. How about "WiFi" or
"HiFi"?
>
>> That is the, chain should be links and regular folks should be able read
>> the pages (maybe that's already happening, seems obvious).
>
> Regular folks are not ever going to understand what "extended
> validation" means,
I think regular folks can associate a technology name with a concept
without reading the spec. And its regular folks who decide if the
world's web sites will commit to install and maintain extended
validation certificates. I think you can be specific and clear in
evangelizing the value added:
"Protect your identity: install extended validation certificates on
your site"
Then you don't have the problems Alex originally pointed out, that
people don't understand why SSL should be used outside of data upload.
Boris Zbarsky
> Hmm...interesting. You are literally correct: mozilla.org does not use
> https + extended validation. Neither does mozilla.com. Frankly their
> home pages make identifying an org from a com difficult.
I was more saying that mozilla.org is the wrong place for _any_ user-facing
information about the Firefox UI. mozilla.com (though not the front page) isn't.
But in any case, I think shaver's take on this is far more thought-through and
worth paying more attention to than mine.
-Boris
Boris Zbarsky
>> I disagree that "extended validation" is meaningful to anyone, since
>> it's a relative phrase (so you need to know what it's extended _from_)
>> and the definition of "validation" is perhaps-necessarily arcane.
>
> So your theory would claim that people won't buy "Wonder Bread"
My theory (and Shaver's seems to match) would claim that "Wonder" in "Wonder
Bread" is an empty marketing modifier that might cause people to buy "Wonder
Bread" in preference to things that would really be better for them to buy,
including better breads. As someone interested in selling the best possible
bread to people, if we call what we have available now "Wonder Bread", when we
come up with something better (and we're trying to!) we'll have to up the
superlative ante some more. The end result looks like a lot of 20th century and
early 21st century marketing: a lot of hot air and not much substance. We don't
really want to be following that model if we can avoid it.
> and since 2GB is only relatively better than 1GB and GB is arcane
Hey, now you're confusing a numerical measurement of a quite tangible good ("how
many MP3s can I put on this thing?") with an intangible like "validation", much
less "extended validation". It's clear to anyone with a brain that you can put
twice as many MP3s on a 2GB stick, whereas explaining the "Extended" part of EV
(it actually just means, "these specific long list of steps of validation
happened"), is much more complicated.
Even then, your example is a good one: plenty of people buy a 2GB stick when all
the data they might ever want to put on it would fit on a 1GB one, simply
because they don't know what a "GB" really is, in terms of MP3s, say.
>> Regular folks are not ever going to understand what "extended
>> validation" means,
>
> I think regular folks can associate a technology name with a concept
> without reading the spec.
OK. What is the "concept" with "Extended Validation"?
> And its regular folks who decide if the
> world's web sites will commit to install and maintain extended
> validation certificates.
Not necessarily, but to some extent I agree.
> I think you can be specific and clear in evangelizing the value added:
>
> "Protect your identity: install extended validation certificates on
> your site"
That's a possible angle, yes.
> Then you don't have the problems Alex originally pointed out, that
> people don't understand why SSL should be used outside of data upload.
That's a logical non-sequitur. A site can slap in an EV cert without changing
anything about their login screen.
-Boris
chris hofmann
lagging here, not leading.
https://store.mozilla.org/signin.php?c=1
Gervase Markham
>> If I pay them enough will they let me register "Charles Schwab
>> & Co, New York, US, Tokyo Japan, and London UK"?
>
> No, unless you can construct a convincing physical site for them to visit.
To expand on Mike's point: it's single location only. And you'd have to
prove you owned a company of that name in that location.
Gerv