Talk:Papers:Sending the Right Signals

beltzner, Jan 25th, 3am PST

• first draft completed and ready for comment
  • feel free to make grammatical/spelling edits inline, I haven't bothered to do that check yet
  • if you find it easier to insert comments in the text itself, again, feel free
• with screenshots, this will be 4 pages in length
• I used "trustworthiness" a lot, instead of "authentication"; is that OK?
• dbaron said that the goal of these meetings was to generate discussion, and that was the approach I took as opposed to attempting to design the perfect UI, since the underlying technologies aren't neccessarily finalized, and since it's not yet determined if there will be multi-level authentication or preferred CAs. As a result, I tried to keep the position paper at a general level, commenting on what's needed as criteria for success for any solution. That said, I tacked on some simple proposals at the end :)
• On a re-read, I think I might need to tie together the idea that I'm approaching this from a "how do we make online authentication as close as possible to the real world equivalent" or "what can we learn about how we already make these judgements in order to apply that to the UI" perspective.
• I'm rambling, aren't I? I'll stop now.

Hecker 09:24, 25 Jan 2006 (PST)

This is a useful beginning. Some quick comments:

• Using "trustworthiness" and similar terms is I think OK, as long as you are taking the perspective of the end user, who ultimately is the one making the decision on whether a particular service can be trusted (as in your RL examples).
• You write, "A connection to an entity should be said to be 'secure' when the connection is encrypted and it can be reasonably assured that communication is restricted to the user and the entity." One key question is, what does "reasonably assured" mean in this context? For example, by one interpretation connections made using self-signed certificates could be referred to as "secure", at least if there is some reason to believe that the certificate in question is in fact associated with the entity in question. (For example, the self-signed cert may have been exchanged out-of-band, or the user may have identified it as being associated with the entity based on other signals.) Another key question is, what does "entity" mean in this context? For example, some might interpret 'entity' as referring to the web site itself (i.e., a web server accessible at the particular domain name) and others might interpret 'entity' as referring to the web site operator (i.e., an identified individual or organization).
• In general I prefer using the phrase "identified by" to "signed by". My only caveat is that it doesn't read as smoothly in cases where the certificate is associated with a domain name rather than an individual's or organization's name.

A general comment: Let's make sure that this discussion doesn't solely focus on the SSL UI and related PKI-enabled features. In my opinion in the context of the overall problem PKI/crypto are both overkill, because of the technical complexity underlying PKI/crypto-related features, and also at the same time don't necessarily address the problem at hand, because of the ambiguity underlying what PKI purportedly attempts to do.

I think that the "signals" approach is the best way to go: Figure out what signals can provide relevant information to the user who's trying to make a trust determination, and come up with a reasonably unified way to present such signals to the user. The signals themselves could be based on various back-end mechanisms: real-time site checks (as in the various anti-phishing toolbars), crypto-based mechanisms like X.509v3 certs or PGP-style signing, and so on. The front-end UI should be designed to accommodate multiple such mechanisms, both present and future, with such mechanisms either built-in to the core products or addable via extensions.

shaver

In the case of a FOAF or web-of-trust signal, there's no "organization that accepts responsibility for that judgement".

There isn't much in here about letting people federate credentials, reuse them with different sites, or any piece of the authentication/trust space other than "helping users know if they should trust sites". I think the other side of the equation is very important too, perhaps obviously. ("How does Jane know which card the ATM will accept? How does the ATM verify her card and account?")

from call

• the last section is the weakest, and narrows the discussion back to SSL style security which is orthogonal to the rest of the discussion
  • perhaps remove it, or generalize it out some more
• ignores non-browser clients (email, news aggregators, calendar, etc.)
• keep the focus on framing the discussion instead of coming up with prematurely-specified proposals

dria

• Minor quibble: you use "entity" and "object" interchangeably throughout. I found it slightly jarring. I'll leave it to you to decide whether this is actually a valid complaint :)
• The paragraphs about 'consistency' and 'clarity' are a bit jumbled. You start talking about consistency then sort of fade into talking about clarity...maybe talk about why clarity is important earlier in the piece before stating our position (which is about consistency), then just focus on why consistency is awesome in the "Position" section?

Random thoughts from a caffeine-addled mind (Johnath)

• Agree with posters above, SSL has a lot of history to it, and many smart people have put their thinking into the current certificate/signing authority model of things, but why not keep things open for the moment -- security folk don't often have a usability focus, so their models might be provably more secure, but by failing to consider the humans involved, become less secure through misuse and ignorance. Indeed this is really what the whole discussion is about, so I'll stop talking now.
• "Recommended" is a word (from the last section) that will likely give you trouble, since no one wants to put their ass on the line, much less have a third party web browser do it on their behalf. Verisign sure as hell doesn't want to be sued when you don't get your ebay item, and the participants of a web of trust aren't really recommending that YOU buy any of the products at undergroundpharmacy.net, even if they have had reason to trust the operators themselves, in the past. I know you're trying to de-jargon things because "recommended" is better than "identity verified by X509 cert" but "recommended" is jargon too, it's legal jargon for "sue me."
• Consider that the real-world analogues for mimic sites used in phishing attacks are things like mag stripe "skimmers." One problem people have online is that they don't know which sites to trust because there isn't a century or twelve of brand development yet, but the reason skimmers work in real life is because they hijack all the signals of trustworthiness (heavy doors, cameras, etc) and that's how mimic sites work. Nothing is ever new, so maybe there is something to be learned from how real world companies cope with skimming (how do they, I wonder?)
• Bruce Schneier. Is anyone from your camp talking to him yet? Buy him 7 comely lasses of virtue true if you have to - he is a guy whose brain you want in on this, I would think.
• Has an effort been made to scope this? How good do we want to make things? Is it okay if the online experience is as trustworthy as, say, mail order ads in the back of magazines? Does it have to be as trustworthy as a convenience store bulk bin? Does it have to be as trustworthy as a bank? Security is usually a tradeoff against ease of use, so how much is enough?
• The article as is talks about three concepts: encryption, authentication, and recommendation. I would argue that while, on the one hand, we want to capture the language of recommendation because that's what users want to hear (and it's *ALL* users want to hear: "Yes, smart people have made sure that this site is fine. Go ahead.") the problem is that neither encryption nor authentication (nor both!) provide that, indeed none of the current stack does. And maybe firefox/w3 doesn't want to be in that business anyhow. On the other hand, it is clearly the browser's business, as conduit between user and site, to inform the user about the encryption and authentication state of their interactions. Maybe you want to, again in the interest of using words people are comfortable with, talk about a conversation being "private" or not (encryption) and a site being "identified" or not (authentication). I think people understand that calling a conversation "private" doesn't have implications as to whether it's a safe transaction or not - "secure"/"safe" concepts do carry those connotations. A "private" conversation with Vinny "The Ladykiller" Corleone is not necessarily a "secure" one.

That's all until I come up with more. Glad to see this work happening.