Peter -- I think I like your proposal for this use case but I suspect people need to study it more. Overall I think we're in violent agreement, and I don't mean to minimize your concerns about privacy, just to make sure we're putting things in the right context -- everything is a trade-off.
Regarding the below: On Thu, Dec 17, 2009 at 8:57 AM, Peter Watkins <[email protected]> wrote: > On Thu, Dec 17, 2009 at 08:19:01AM -0800, John Panzer wrote: > > > The question is how much of an actual additional phishing risk this > > type of information leak is. > > I think unexpected and unintended information leaks are always bad. > Yes; the question is, how bad, and how to balance out against good things that might result. And how to mitigate the bad without destroying the good. All other things being equal, I would argue against leaking this type of information. But all other things are never equal. Of course users should be in control; but in reality most of them are going to take the defaults we provide (or click through permission screens to get what they want without reading them) so the same debate is going to take place about defaults and warnings. So we might as well figure it out now, under the assumption that we're talking about defaults and opt-in vs. opt-out. [As a case in point, OpenID for years did not add email addresses at least partly to avoid leakage of people's possibly secret email identifiers. I think that was in retrospect a mistake, and served users poorly, and I hope we can address it via Webfinger acct: URIs. At the moment ~every proprietary system uses email addresses, so they're being exposed _anyway_, but there's no universal standard for user centric email address based identity -- except, again, for Webfinger, which isn't widely deployed yet.] > Phishing is just one current (mis)use of leaked information, and I'm > sure that in the future we'll see other (mis)uses that have not yet > been imagined or articulated. > Agreed. On the other hand, we can definitely see and articulate the problems caused by RP's inability to know what OPs their users might be using. This doesn't have to be known to the RP and if there's a way to actually deploy this say to browsers without requiring people to install plugins I'm all ears. I'm very interested especially in hybrid systems that can take advantage of plugins/new browser capabilities but can fall back to less-smart or centralized-selector-service models if it absolutely has to. > > > The browsers have accidentally conducted > > an experiment for us. The result so far appears to indicate that this > > information provides little additional benefit to phishers as they > > haven't used it for known successful attacks. Additional data most > > welcomed. > > As I think Breno said, we don't want to throw the usability out with > the privacy bathwater, but it bothers me how your recent messages > seem to downplay the importance of privacy protection. Maybe I'm just > misreading again. > > Anyway, I'd prefer that we not have abstract arguments about the > merits of privacy protection. Clearly some users value "privacy." > Clearly the spec could provide mechanisms that empower users (and OPs) > to provide privacy protections. Clearly too many MUST clauses and > complex mechanisms will hamper development and acceptance by those > who have to build and run systems. > > So let's talk about concrete proposals, eh? I made a proposal a couple > days ago that nobody responded to -- perhaps the In-Reply-To header > buried it too deep in the long-running thread, so I'll re-post. Perhaps > we can devise something that seems to appease privacy concerns without > overburdening implementors. > > This sounds good, but I do want to have the general discussion as well (because it is the same discussion as we had about email identifiers and the same one we're going to have about Webfinger exposing the identities of the services you use, and if we can figure out the Right Way to do these sorts of things in general it will save many kilowatts of email.) > -Peter > >
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
