Subject: [apps-discuss] webfinger privacy question/suggestion

From: Stephen Farrell <[email-masked]>
Date: Mon, 29 Oct 2012 11:22:35 +0000

The draft says:

"  Let's assume your email client discovers that blog automatically for
   you.  After receiving the message from Bob ([email-masked]), your
   email client performs the following steps behind the scenes."

...then describes how I send out a request containing the
string [email-masked].

The net result of that appears to be that I'll be sending out details
about who I'm contacting (or want to contact) to a server with which
I've no existing relationship, and that is probably going to turn out
to be operated by one of the few very large providers.

That seems to me to have potentially serious privacy issues. (As with
all privacy issues, you never know when they're more than potential
until its too late;-)

Is that accurate?

I wondered why the wg didn't consider (even as an option) allowing
the client to send a hash of Bob's URI? That way, if the request
goes to the wrong place, things are a bit more privacy friendly.
(I think an earlier draft from James Snell suggested this, but
don't recall subsequent discussion about that.)

One argument for doing something privacy friendly here is that
it would make sense to follow the approach of the safe web
browsing mechanisms here - if its considered sensitive to tell
a large provider about the URLs I'm visiting, then why is it ok
to tell such a provider the names of the people I want to finger?
(Having said that, yes, other mechanisms, such as URL completion
take the opposite approach.)

More generally, it'd be good if webfinger privacy were discussed
more on the list since maybe there are other privacy issues or
mitigations that'd be better or easier.

(Note: I would raise a DISCUSS during IESG eval for this, but since
it could lead to a change in the protocol, I'm raising it now in the
hope that's more likely to be doable if it needs to be done.)

Cheers,
S.

---

From: SM <[email-masked]>
Date: Mon, 29 Oct 2012 13:04:04 -0700

>mitigations that'd be better or easier.

I took a look at draft-ietf-appsawg-webfinger-02.  From Section 11:

   "The easy access to user information via WebFinger was a design goal
    of the protocol, not a limitation."

The draft relies on "users [to] understand the risks".  I don't see 
any text in the draft for someone to understand the issues and assess 
the risks.  In my humble opinion the user information which will be 
made world-readable can generate enough work to keep a working group 
busy for some time.  The paragraph I quoted basically says that the 
design goal is to publish "private" information on the Internet.  I 
think that the protocol will be successful until people start asking 
for the "right to be deleted".

What's the plan to tackle the privacy issues?

Regards,
-sm

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 29 Oct 2012 17:30:17 -0400

Stephen,

> ...then describes how I send out a request containing the string
> [email-masked].
> 
> I've no existing relationship, and that is probably going to turn out to
> be operated by one of the few very large providers.
> 

Yes, though be mindful that this just an non-normative example.
 
> I wondered why the wg didn't consider (even as an option) allowing the
> client to send a hash of Bob's URI? That way, if the request goes to the
> wrong place, things are a bit more privacy friendly.
> (I think an earlier draft from James Snell suggested this, but don't
> recall subsequent discussion about that.)

The request should not go to the wrong place, though a request could get
intercepted on the wire.  It is for these reasons that we strongly recommend
use of TLS.
 
> One argument for doing something privacy friendly here is that it would
> make sense to follow the approach of the safe web browsing mechanisms
> here - if its considered sensitive to tell a large provider about the
> URLs I'm visiting, then why is it ok to tell such a provider the names
> of the people I want to finger?
> (Having said that, yes, other mechanisms, such as URL completion take
> the opposite approach.)

Whether we hash the information or not, a request received at the legitimate
WebFinger server would still know what is being requested.  I think the only
case of concern is when non-TLS connections are used.
 
> More generally, it'd be good if webfinger privacy were discussed more on
> the list since maybe there are other privacy issues or mitigations
> that'd be better or easier.

We've had only a little discussion on privacy and I've tried to insert text
to address the concerns that have been raised in Section 11 (security
considerations), though I would be happy to insert a whole section on
privacy considerations if given some text.
 
> (Note: I would raise a DISCUSS during IESG eval for this, but since it
> could lead to a change in the protocol, I'm raising it now in the hope
> that's more likely to be doable if it needs to be done.)

We should certainly cover any security and privacy concerns, but the fact of
the matter is that use of WebFinger, Google, or any other service where you
search for information is going to reveal certain information about you.
Likewise, posting any information where the public can retrieve it has its
risks, which is why servers should be controlled and access to web resources
controlled.

If the security considerations section does not have the wording to address
concerns, then please provide some words and I'd be happy to add them.

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 29 Oct 2012 18:09:51 -0400

You didn't keep quoting.  It goes on to advise that if you wish to restrict
what information can be accessed, you should take such actions.

I can (and do actually) put all kinds of contact information on my personal
web page.  If people want to find that, they could.  Likewise, I could just
not publish it.  Just because a WF server exists does not mean one has to
populate it with information -- especially private information.

Consider Google+ as an example.  Information you share there is published
via WebFinger.  However, you as the user gets to select what information is
made public and what information is not.

Paul

> -----Original Message-----
> From: [email-masked] [mailto:apps-discuss-
> [email-masked]] On Behalf Of SM
> Sent: Monday, October 29, 2012 4:04 PM
> To: [email-masked]
> Subject: Re: [apps-discuss] webfinger privacy question/suggestion
> 
> >More generally, it'd be good if webfinger privacy were discussed more
> >on the list since maybe there are other privacy issues or mitigations
> The draft relies on "users [to] understand the risks".  I don't see any
> text in the draft for someone to understand the issues and assess the
> risks.  In my humble opinion the user information which will be made
> world-readable can generate enough work to keep a working group busy for
> some time.  The paragraph I quoted basically says that the design goal
> is to publish "private" information on the Internet.  I think that the
> protocol will be successful until people start asking for the "right to
> be deleted".
> 
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 29 Oct 2012 22:51:28 +0000

Hiya,

> Yes, though be mindful that this just an non-normative example.

Sure. But one that does nicely expose the privacy concern.

> intercepted on the wire.  It is for these reasons that we strongly recommend

Use of TLS is great (though some of the text about that might
need tweaking). But the wrong place problem needs more work
I suspect. In particular the (as you say non-normative) example
quoted says that this is all happening in the background, and
you don't normatively say how a client figures out the host to
query. Now maybe you can't in general, but if not, then I think
that causes the problem and TLS is no help in that.

One danger here would be that my mail client might by default
tell BigCo about the sender header field of all the mail I
receive and when I got it and might not give me any control
over that, all to try find a sender's blog 1 RTT quicker.
That'd be a bad thing to do by accident, right?

Another might be contexts where the derivation of the host
to use is less clear. In the case of mail, should I use the
sender or From domain for example if those differ? What about
mailing lists? Are there similar ambiguities in XMPP or other
protocols? I'd love to have a warm feeling that that's all
been considered - and maybe it has, but I don't get that
warm feeling as of now from the draft and my recollection of
the list traffic on this.

> case of concern is when non-TLS connections are used.

Right, non-TLS to the wrong place is the main concern. It could
be that some re-direction cases might also be an issue but not
sure.

> privacy considerations if given some text.

I hope that discussion happens on the list.

> search for information is going to reveal certain information about you.

Personally, I think the key thing is to try make sure that the
very very few folks who care are given some way to mitigate
their concerns, or if that's not possible say then that its not
possible after the list has had the discussion that reached
that conclusion.

> risks, which is why servers should be controlled and access to web resources

Yes, you cover that already at least to some extent and
there was some discussion on the list about it. I'm
not clear if that's considered "done" or not though (can't
recall). I guess the issue is whether there are any knobs
the user could twist or not, and at present, it's "not"
so webfinger is something that, if you use it, all the
stuff you put at one host is available to anyone who
can access that host. (Is that right?)

I think that that's mostly ok, perhaps with some added
advice about publishing stuff aimed at coders, e.g. to
say "don't automatically publish users' information
since that'd be a crappy way to deal with folks who
care about privacy" or similar.

> concerns, then please provide some words and I'd be happy to add them.

I'd hope those emerge from list discussion - just
because I'd DISCUSS the current text doesn't make me
the right person to suggest new text.

Cheers,
S.

---

From: James M Snell <[email-masked]>
Date: Mon, 29 Oct 2012 16:09:48 -0700

On Mon, Oct 29, 2012 at 2:30 PM, Paul E. Jones <[email-masked]>wrote:

> [snip]
Even so, it's an example that you explicitly call out in your spec that
very clearly highlights a privacy concern. If you're going to raise such an
example and not deal with the privacy implications beyond "use TLS", then
there is a problem. See below...

> case of concern is when non-TLS connections are used.
That's not necessarily true. Some subcomponent of the server would have
access to the data, yes, but that doesn't mean every subcomponent on that
server should be allowed to have access to that information. Further, it
does not necessarily follow that the server is required to know exactly
whose data it is serving up.. just that there is some blob of data about
someone or something being requested. URLs and query string parameters tend
to wind up getting recorded in server logs that are completely unprotected
by TLS. Hashing the identities makes it significantly more difficult to
mine those for useful information (obviously not impossible, but the idea
is to make it more difficult, not impossible).

Note also, there are organizations with existing policies in place
forbidding the use of email identifiers within URI parameters. This is the
precise reason why lotus connections, for instance, provides an option to
use alternative identifiers within URIs. For such organizations, use of
WebFinger uri's is going to be quite problematic at best.

 [snip]

> concerns, then please provide some words and I'd be happy to add them.
This is not really a question about just coming up with additional language
for the security concerns section, the ability to support hashed
identifiers rather than email or acct: id's should be built into the
protocol. In fact, for a protocol such as this, privacy should be THE
default option. Meaning, hashed identifiers should always be used, IMHO.

- James

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 29 Oct 2012 20:37:31 -0400

Stephen,

There is so much information leaked around as one uses the Internet. The
mere fact that we exchanged email messages would tell BigCo that
packetizer.com had a dialog with cs.tld.ie.

If I didn't run my own mail server, the BigCo would have the complete
contents of my message to you, too -- even if I (as the user) thought it was
confidential.

Personally, I don't think we should be worrying too much about privacy
issues. Obviously, there are some things we can control (e.g., recommending
the use of TLS, so that all queries are hidden), but there are many things
outside our control (e.g., exactly what gets published, what gets queried,
and when that information gets queried).

The right approach, IMO, is what Google is going with Google+.  Ask users
what they want to make public or share with certain people.  In the case of
WebFinger, it's mostly a matter of "what's made public", but not always.  A
company, for example, can publish information about employees via WebFinger,
but they can have that server such that the information is accessible only
internally or only by authorized users.  They could elect to share some
information to the general public.

The example I gave where the client automatically looks up information is
just an example, but it is a valid example... to your point.  It is a good
example of the kinds of things people can do and, if WF is deployed widely,
probably will do.  Writing cautionary tales of any significant length in the
WF spec is not going to change anything, really. Many users like that
convenience.

So, somewhere we have to strike a balance between being overly concerned
with privacy and taking appropriate steps to ensure privacy.  People who are
insanely concerned about their privacy should first walk away from the
Internet.  People reasonably concerned should not publish anything via
WebFinger.  For most people, it is a matter of giving them the tools to
control what they publish for the world to see, WebFinger or otherwise.

If there were to be a treatise on social networking security, that might be
a good thing, but the WF document is not the right place to give it
appropriate treatment.

Paul

> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Monday, October 29, 2012 6:51 PM
> To: Paul E. Jones
> Cc: 'Apps Discuss'
> >> the client to send a hash of Bob's URI? That way, if the request goes
> >> to the wrong place, things are a bit more privacy friendly.
> > The request should not go to the wrong place, though a request could
> > get intercepted on the wire.  It is for these reasons that we strongly
> > recommend use of TLS.
> 
> Use of TLS is great (though some of the text about that might need
> tweaking). But the wrong place problem needs more work I suspect. In
> particular the (as you say non-normative) example quoted says that this
> is all happening in the background, and you don't normatively say how a
> client figures out the host to query. Now maybe you can't in general,
> but if not, then I think that causes the problem and TLS is no help in
> that.
> 
> One danger here would be that my mail client might by default tell BigCo
> about the sender header field of all the mail I receive and when I got
> it and might not give me any control over that, all to try find a
> sender's blog 1 RTT quicker.
> Another might be contexts where the derivation of the host to use is
> less clear. In the case of mail, should I use the sender or From domain
> for example if those differ? What about mailing lists? Are there similar
> ambiguities in XMPP or other protocols? I'd love to have a warm feeling
> that that's all been considered - and maybe it has, but I don't get that
> warm feeling as of now from the draft and my recollection of the list
> traffic on this.
> 
> >> One argument for doing something privacy friendly here is that it
> >> would make sense to follow the approach of the safe web browsing
> >> mechanisms here - if its considered sensitive to tell a large
> >> provider about the URLs I'm visiting, then why is it ok to tell such
> >> a provider the names of the people I want to finger?
> > Whether we hash the information or not, a request received at the
> > legitimate WebFinger server would still know what is being requested.
> > I think the only case of concern is when non-TLS connections are used.
> 
> Right, non-TLS to the wrong place is the main concern. It could be that
> some re-direction cases might also be an issue but not sure.
> 
> > We've had only a little discussion on privacy and I've tried to insert
> > text to address the concerns that have been raised in Section 11
> > (security considerations), though I would be happy to insert a whole
> > section on privacy considerations if given some text.
> 
> > We should certainly cover any security and privacy concerns, but the
> > fact of the matter is that use of WebFinger, Google, or any other
> > service where you search for information is going to reveal certain
> information about you.
> 
> Personally, I think the key thing is to try make sure that the very very
> few folks who care are given some way to mitigate their concerns, or if
> that's not possible say then that its not possible after the list has
> had the discussion that reached that conclusion.
> 
> > Likewise, posting any information where the public can retrieve it has
> > its risks, which is why servers should be controlled and access to web
> > resources controlled.
> 
> Yes, you cover that already at least to some extent and there was some
> discussion on the list about it. I'm not clear if that's considered
> "done" or not though (can't recall). I guess the issue is whether there
> are any knobs the user could twist or not, and at present, it's "not"
> so webfinger is something that, if you use it, all the stuff you put at
> one host is available to anyone who can access that host. (Is that
> right?)
> 
> I think that that's mostly ok, perhaps with some added advice about
> publishing stuff aimed at coders, e.g. to say "don't automatically
> publish users' information since that'd be a crappy way to deal with
> folks who care about privacy" or similar.
> 
> > If the security considerations section does not have the wording to
> > address concerns, then please provide some words and I'd be happy to
> add them.
> 
> I'd hope those emerge from list discussion - just because I'd DISCUSS
> the current text doesn't make me the right person to suggest new text.
> 
> Cheers,
> S.
> 
> 
> >
> > Paul
> >
> >
> >
> >

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 29 Oct 2012 20:46:17 -0400

James,

I don’t think a hash buys us a whole lot.  It obfuscates things, but it does not hide things.  So, I don’t know who users “53ae56ef33ccb9550869e58820df36c3b1cc9574712556059a3bfc716b4d9255” is, but I can see you queried for them.  I could query for them and probably get their vcard and find out their name.  I can look for something.  I can also perhaps monitor your unencrypted email traffic or just get a hold of your address book and then easily map the hashes to real identifiers.

What’s the expression… “security through obfuscation isn’t security”, or some such.  It only serves to delay discovery, really.  To truly conceal .. at least the domain level .. one needs to use TLS.  Even then, a BigCo can see the unencrypted DNS requests and see that you might be talking to somebody at packetizer.com about something.  A search via Google would reveal the identity in a hurry. :-)

Paul

From: James M Snell [mailto:[email-masked]] 
Sent: Monday, October 29, 2012 7:10 PM
To: Paul E. Jones
Cc: Stephen Farrell; Apps Discuss
Subject: Re: [apps-discuss] webfinger privacy question/suggestion

On Mon, Oct 29, 2012 at 2:30 PM, Paul E. Jones <[email-masked]> wrote:

[snip]

 

Even so, it's an example that you explicitly call out in your spec that very clearly highlights a privacy concern. If you're going to raise such an example and not deal with the privacy implications beyond "use TLS", then there is a problem. See below...

 

That's not necessarily true. Some subcomponent of the server would have access to the data, yes, but that doesn't mean every subcomponent on that server should be allowed to have access to that information. Further, it does not necessarily follow that the server is required to know exactly whose data it is serving up.. just that there is some blob of data about someone or something being requested. URLs and query string parameters tend to wind up getting recorded in server logs that are completely unprotected by TLS. Hashing the identities makes it significantly more difficult to mine those for useful information (obviously not impossible, but the idea is to make it more difficult, not impossible). 

Note also, there are organizations with existing policies in place forbidding the use of email identifiers within URI parameters. This is the precise reason why lotus connections, for instance, provides an option to use alternative identifiers within URIs. For such organizations, use of WebFinger uri's is going to be quite problematic at best.

 [snip]

This is not really a question about just coming up with additional language for the security concerns section, the ability to support hashed identifiers rather than email or acct: id's should be built into the protocol. In fact, for a protocol such as this, privacy should be THE default option. Meaning, hashed identifiers should always be used, IMHO.

- James

Paul

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 30 Oct 2012 01:20:56 +0000

Hi,

> packetizer.com had a dialog with cs.tld.ie.

Nice typo. cs.tcd.ie do have sysadmins who'd like to take
over the universe if it wasn't for those pesky tcd.ie folks.
But maybe that is actually a good lesson in mis-targetting?

> contents of my message to you, too -- even if I (as the user) thought it was

There is a real issue here, and a hard one: IMO, that is: privacy
is already so compromised that its not at all clear its worthwhile
bothering to make it less worse.

However, my take is that yes, incremental improvement is still a
good thing.

> issues. 

Hmmm. I disagree.

> Obviously, there are some things we can control (e.g., recommending
> the use of TLS, so that all queries are hidden), 

TLS has very little to do with privacy. That much ought be clear
to this list, but in case not, confidentiality != privacy ought
be a sufficient reminder.

> but there are many things

"When things get queried" ought presumably be entirely reasonable to
discuss when defining the protocol with which they are queried.

> The right approach, IMO, is what Google is going with Google+.  

I've no idea what that is. Where's it written down?

> Ask users
> what they want to make public or share with certain people.  

Isn't that only considering the publisher-user issues? And
that's (I hope clearly) not the main topic of my concern.

> In the case of

Only relevant for the publisher, not the one sending the query.

And what'd be wrong with providing tools that allow a publisher
to reflect subtlety? Why is that harder or worse and for whom?

> WF spec is not going to change anything, really. Many users like that

The above paragraph is filler, right? If not, I don't get the argument.

> with privacy and taking appropriate steps to ensure privacy. 

In the above, you begin to be be pejorative.

> People who are
> Internet.  

And now you perhaps perfect pejorative posing!

"balance" "overly" "appropriate" and "insanely" are all bad
fillers that really indicate a need for something to be fixed.

I do hope you recognise that the last few sentences would be
better not having been stated.

> People reasonably concerned should not publish anything via

Perhaps. But my question was about privacy for those whose
user agents might automatically issue queries. Ignoring the
question is not a way to answer the question.

> a good thing, but the WF document is not the right place to give it

I agree. This I-D ought not include a treatise. Neither
should discussion of this I-D base conclusions on bad
argument, such as that you've offered above.

S.

---

From: Blaine Cook <[email-masked]>
Date: Mon, 29 Oct 2012 18:32:00 -0700

A counter-argument to hashing identifiers:

one could increase privacy of casual HTTP-based browsing sessions by
hashing the URLs (host names and paths separately, for example). But
we don't, and it's fine.

b.

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 29 Oct 2012 23:09:04 -0400

Stephen,

> TLS has very little to do with privacy. That much ought be clear to this
> list, but in case not, confidentiality != privacy ought be a sufficient
> reminder.

I understand that, but privacy starts with having the doors closed and
windows shut.  My neighbors appreciate that, I can assure you. :-)

TLS at least allows one to conduct business such that it's not in full view
the neighbor peeping.

It does not hide queries made to the WF service provider, of course.  But,
that's true of any kind of request made to any service provider, including
queries to Google, Facebook, etc.
 
> > outside our control (e.g., exactly what gets published, what gets
> > queried, and when that information gets queried).
> 

I'm not opposed to it, but I'm not sure how we can specify that. It's like
telling an email client developer when they can send an email.

> I've no idea what that is. Where's it written down?

I'm not sure where it is documented, but if you have a Google+ profile, go
there.  Select "Edit Profile".  The screen is full of information about
yourself, including your contact info, those you follow, those following
you, where you work, etc.  Every single section has the option to make it
public or share it with specific "circles".  You can specify precisely what
circles can see the information.  Some information made public is published
via WebFinger so that it can be queried outside Google+.

For example, this is what Google publishes via WebFinger about me:
  http://www.google.com/s2/webfinger/?q=acct:[email-masked]

Note this only returns an XRD document, since Google's implementation has
not yet been updated with the current text in this draft.

> Isn't that only considering the publisher-user issues? And that's (I
> hope clearly) not the main topic of my concern.

There are many aspects to privacy.  What users expose to whom is one of
them.
 
> > In the case of
> > WebFinger, it's mostly a matter of "what's made public", but not
> > always.  A company, for example, can publish information about
> > employees via WebFinger, but they can have that server such that the
> > information is accessible only internally or only by authorized users.
> > They could elect to share some information to the general public.
> 

But the person sending the query *wants* to send the query and he/she knows
who he/she is sending a query about.  It's no different than looking up a
person on FB or sending an email.
 
> And what'd be wrong with providing tools that allow a publisher to
> reflect subtlety? Why is that harder or worse and for whom?

I don't understand your question.
 
> > The example I gave where the client automatically looks up information
> > is just an example, but it is a valid example... to your point.  It is
> > a good example of the kinds of things people can do and, if WF is
> > deployed widely, probably will do.  Writing cautionary tales of any
> > significant length in the WF spec is not going to change anything,
> > really. Many users like that convenience.
> 

My position is that lots of privacy-related text in the WF document is
probably not what is needed to properly cover privacy issues related to
social networking and publishing information on the Internet.
 
> > So, somewhere we have to strike a balance between being overly
> > concerned with privacy and taking appropriate steps to ensure privacy.
> 

I tend to do that sometimes, but not intentionally.  Let me be very clear in
saying that I fully agree that privacy is an issue.  What I don't think,
though, is that adding a lot of text to the WF spec to address privacy is
the right solution.  I'm happy to insert any text the group feels should be
added -- especially if somebody writes it.  Happy to play that role as
editor.

That said, what I honestly believe is needed is a IETF paper on privacy that
speaks about it in more depth.  Do people have the slightest clue what kind
of information can be mined from HTTP logs?  Or email logs?  DNS queries?

> And now you perhaps perfect pejorative posing!

No, that's actually being a realist.  Given the literal oozing of
information through every single service on the Internet, there is no
privacy.  And Google is in the world's best position to mine that, too.
Give them your name or other personal info once and they can then tell you
everywhere you've been on that machine or might have been.  Google Ads are
everywhere and everything is recorded.  You can tell this from the fact they
offer interest-based ads.  How do they know your interests.  How do they
know you are?  Google is just one example.
 
> "balance" "overly" "appropriate" and "insanely" are all bad fillers that
> really indicate a need for something to be fixed.

:-) Select a different description, but people have varying degrees of
privacy expectations.

> I do hope you recognise that the last few sentences would be better not
> having been stated.

I don't, no.  Your desire for privacy is very different than mine, perhaps.
People are different and certainly have different expectations.  It was not
intended to mean more than that.
 
> > People reasonably concerned should not publish anything via WebFinger.
> > For most people, it is a matter of giving them the tools to control
> > what they publish for the world to see, WebFinger or otherwise.
> 
> Perhaps. But my question was about privacy for those whose user agents
> might automatically issue queries. Ignoring the question is not a way to
> answer the question.

This side is even easier to control.  One does not have to automatically
query.  I recall Outlook once offered the ability (perhaps it still does) of
checking to see if a buddy is online or not.  I'm not sure if MS got a
request for status behind the scenes or not, but the idea is similar.  Users
can turn that off.

Users can control what they enter into Google.

Users can re-consider entering a URL into a browser.  Every aspect of that
page load can be recorded, from the DNS query, to the TCP connection, to
HTTP server logs.

>From the requestor's side, it's really a matter of giving users the ability
to control what their computers do autonomously.  WF is one protocol to
consider, but every protocol needs consideration w.r.t. privacy.

> > If there were to be a treatise on social networking security, that
> > might be a good thing, but the WF document is not the right place to
> > give it appropriate treatment.
> 
> I agree. This I-D ought not include a treatise. Neither should
> discussion of this I-D base conclusions on bad argument, such as that
> you've offered above.

Well, I'll immediately confess to saying that I'm not the best author for
that document.  However, I do believe the points you and others have raised
are valid concerns, but the whole social networking, blogging,
micro-blogging, web commenting, etc. movement brings about a whole lot of
privacy issues that probably do need to be considered holistically.

Paul

---

From: SM <[email-masked]>
Date: Mon, 29 Oct 2012 21:54:05 -0700

Hi Paul,
>You didn't keep quoting.  It goes on to advise that if you wish to restrict

When I mentioned quoted I meant the sentence I quoted from Section 11.

>populate it with information -- especially private information.

Ok.

>made public and what information is not.

Where can I find the privacy considerations for the above example?

If the plan for privacy consideration is to say that all personal 
information given, for example, to Google+ is a matter of user 
discretion, the proposal could be labelled with "no privacy 
considerations".  Here's how the world out there look at such issues:

   "The CNIL concluded that it is impossible for the average user who reads
    the new policy to distinguish which purposes, collected data, recipients
    or access rights are currently relevant to his or her use of particular
    Google tools or services. The CNIL also found that, even for trained
    professionals, it is extremely difficult to know exactly which data is
    combined between which services for which purposes. Since Google applies
    a single privacy policy across most of its services, including the Google
    search engine and the Gmail email service, the policy is raising 
significant
    doubts and fears." [1]

Regards,
-sm

1. europarl.europa.eu, E-2012-004040

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 30 Oct 2012 10:01:03 +0000

Hiya,

> windows shut.  My neighbors appreciate that, I can assure you. :-)

Possibly. But its really not relevant to this part of the discussion.

> queries to Google, Facebook, etc.

I think you're wrong there. If I send H([email-masked]) to any
server that doesn't know about [email-masked] then that server
has less information than otherwise, and that's independent of
whether TLS was used or not. The server can still correlate
two requests that contain H([email-masked]) and could in
principle search for the string [email-masked] and verify when
its found the right string.

Hashing the URI also makes the code a teeny bit more
complex and perhaps significantly more complex for some
kinds of client (e.g. javascript, before the webcrypto
API is deployed).

So hashing the URI as an option is not a crystal clear winner,
but is worth discussing and is different from not being able
to hash the URI.

The only place this touches on TLS usage is that it H(URI)
exposes less to intermediaries if TLS is not used.

> telling an email client developer when they can send an email.

Generic note, just in case: I'm raising things to discuss; I
don't mean that all that discussion needs to go into the draft.

In this case, I suspect there's not been so much consideration
of the non-obvious cases where you have to figure out what
server to ask, but I could well be wrong, or maybe its not been
considered but will not turn out to be a problem. Has that
been considered?

> not yet been updated with the current text in this draft.

Interesting that the acct URI looks like it shares a lot of
characteristics with a hash (long, hard to guess). Perhaps
that further indicates utility in allowing the client to
choose that feature? As is, only the service provider (Google
in the above) gets to make that choice.

> There are many aspects to privacy.  What users expose to whom is one of

Right. As is whether to enable a choice for the user or not.

> person on FB or sending an email.

It is different in the example originally quoted where the UA is
said to be doing this in the background. At that point I have
no idea if the user wants the information or not.

Which reminds me: how is caching handled here? Is the UA expected
to run the WF protocol again each time or not? From the privacy
perspective saying "no need to do it each time" would be good I
guess. I don't see any text along those lines. Did I miss that?

> I don't understand your question.

Sorry. This relates to the publisher. We're not defining a
protocol for the publisher to tell the server which bits of
information it'd like published, nor any conditions that
it'd like put on those. I was asking why that'd not be a
good thing to do. (And a fine answer might be: "go ahead
and do it if you care that much":-)

> social networking and publishing information on the Internet.

You may be right, but since I never asked for lots of text its
not very relevant is it? :-)

> of information can be mined from HTTP logs?  Or email logs?  DNS queries?

Some don't. Some do and care. Some do and don't care. Some do
and don't want to be privacy friendly. (That last is conjecture;-)

I agree that it'd be good if we had a Danvers doctrine equivalent but
right now, we don't. So we need to consider it piecemeal like this.

> No, that's actually being a realist.  

The choice of terms is not aiming at realism, but aiming to be
pejorative IMO. Go on admit it:-)

> Given the literal oozing of
> privacy.  

You appear to recognise the problem ("oozing" implies that) but
suggest just surrendering? I think we can and should try do better.

> And Google is in the world's best position to mine that, too.

Entirely true. But suggesting some walk away from the Internet is
unhelpful.

> I don't, no.  

Pity.

> Your desire for privacy is very different than mine, perhaps.

We ought therefore recognise that and give even the tin-foil hat
brigade some choices, right?

> query.  

Where is that stated in the draft?

> I recall Outlook once offered the ability (perhaps it still does) of
> that document.  

I don't know what "that document" you mean. If you mean a general
privacy draft, I suspect you're correct;-) But again, that's not
what I asking for/about.

> However, I do believe the points you and others have raised

Maybe true. But that does not mean we do nothing in the meantime.

Cheers,
S.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 30 Oct 2012 12:16:25 +0200

Just few notes: 

>> I honestly believe is needed is a IETF paper on privacy that
>> speaks about it in more depth. 

Have a look at: http://tools.ietf.org/html/draft-iab-privacy-considerations-04

>> TLS has very little to do with privacy. 

Wrong. See above document. 

| | We've had only a little discussion on privacy 

I have raised these privacy issues already last year. My comments got ignored.

---

From: James M Snell <[email-masked]>
Date: Tue, 30 Oct 2012 04:56:49 -0700

On Oct 29, 2012 5:46 PM, "Paul E. Jones" <[email-masked]> wrote:
>
> James,
>
>
>
> I don’t think a hash buys us a whole lot.  It obfuscates things, but it
does not hide things.  So, I don’t know who users
“53ae56ef33ccb9550869e58820df36c3b1cc9574712556059a3bfc716b4d9255” is, but
I can see you queried for them.  I could query for them and probably get
their vcard and find out their name.  I can look for something.  I can also
perhaps monitor your unencrypted email traffic or just get a hold of your
address book and then easily map the hashes to real identifiers.

That is a separate issue, really... and speaks to why I'd much prefer the
use of mechanisms such as oauth2 with wf to control who is authorized to
access any data. In any case, the idea is to make it more difficult by some
degree, not make it impossible. The former speaks to incremental
improvement while the latter is simply impossible.

>
> What’s the expression… “security through obfuscation isn’t security”, or
some such.  It only serves to delay discovery, really.  To truly conceal ..
at least the domain level .. one needs to use TLS.  Even then, a BigCo can
see the unencrypted DNS requests and see that you might be talking to
somebody at packetizer.com about something.  A search via Google would
reveal the identity in a hurry. :-)

We're not talking about security. We're talking about privacy. Two
different things.

- james

>> Whether we hash the information or not, a request received at the
legitimate
>> We should certainly cover any security and privacy concerns, but the
fact of
>> Likewise, posting any information where the public can retrieve it has
its
>> If the security considerations section does not have the wording to
address
> This is not really a question about just coming up with additional
language for the security concerns section, the ability to support hashed
identifiers rather than email or acct: id's should be built into the
protocol. In fact, for a protocol such as this, privacy should be THE
default option. Meaning, hashed identifiers should always be used, IMHO.

---

From: SM <[email-masked]>
Date: Tue, 30 Oct 2012 10:18:43 -0700

>Have a look at: http://tools.ietf.org/html/draft-iab-privacy-considerations-04

Hmm, that draft was mentioned several months ago [1].

>I have raised these privacy issues already last year. My comments got ignored.

The following question was asked around 11 months ago [2]:

   "What are you planning to do to ensure the draft properly addresses
    security, privacy, and netiquette issues?"

The current plan seems to be: do nothing.

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04747.html
2. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03804.html

---

From: Evan Prodromou <[email-masked]>
Date: Tue, 30 Oct 2012 13:33:05 -0400

There may be some use to having private sharing of discovery data.

However, it's such a complicated and difficult problem, that trying to 
solve it with this version of Webfinger will effectively disallow public 
discovery.

That is: it's a terrible morass, which will sink this effort.

I suggest making a note in the security considerations that Webfinger 
links are visible to all, so don't put private stuff in there, full stop.

-Evan

On 12-10-30 01:18 PM, SM wrote:
>> Have a look at: 
>> http://tools.ietf.org/html/draft-iab-privacy-considerations-04
>
> 1. 
> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04747.html
> 2. 
> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03804.html

-- 
Evan Prodromou, CEO and Founder, StatusNet Inc.
1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7
E: [email-masked] P: +1-514-554-3826

---

From: James M Snell <[email-masked]>
Date: Tue, 30 Oct 2012 10:54:43 -0700

Agreed, doing too much in this particular draft would be a mistake. What I
want, however, is an incremental strip in the right direction. Right now,
hashing the identifier is not an option. It should be. Doing so would allow
more complex solutions to be built... solutions that take privacy,
confidentiality, authorization and authentication into full account and
allow us to span from "only sharing public data" to "sharing any data".

- James
On Oct 30, 2012 10:33 AM, "Evan Prodromou" <[email-masked]> wrote:

>>> Have a look at: http://tools.ietf.org/html/**draft-iab-privacy-**
>>> considerations-04<http://tools.ietf.org/html/draft-iab-privacy-considerations-04>
>>>
>>
>> 1. http://www.ietf.org/mail-**archive/web/apps-discuss/**
>> current/msg04747.html<http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04747.html>
>> 2. http://www.ietf.org/mail-**archive/web/apps-discuss/**
>> current/msg03804.html<http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03804.html>
>> ______________________________**_________________
>> https://www.ietf.org/mailman/**listinfo/apps-discuss<https://www.ietf.org/mailman/listinfo/apps-discuss>
>>
>
>
> --
> ______________________________**_________________
> https://www.ietf.org/mailman/**listinfo/apps-discuss<https://www.ietf.org/mailman/listinfo/apps-discuss>
>

---

From: Evan Prodromou <[email-masked]>
Date: Tue, 30 Oct 2012 14:40:28 -0400

I'd suggest a mechanism like the following:

 1. Always provide some discovery data at the endpoint, even if it's empty.
 2. If some form of authentication is given, show additional items in
    full for the authenticated user.

Dialback authentication would probably work [1], but otherwise we don't 
have a lot of reasonable remote authentication systems.

Local authentication (HTTP Basic, Digest, OAuth, whatever) is also 
reasonable although I think this kind intra-domain discovery more often 
happens with e.g. directory services.

-Evan

[1] http://www.ietf.org/id/draft-prodromou-dialback-00.txt

On 12-10-30 01:54 PM, James M Snell wrote:
>
> Agreed, doing too much in this particular draft would be a mistake. 
> What I want, however, is an incremental strip in the right direction. 
> Right now, hashing the identifier is not an option. It should be. 
> Doing so would allow more complex solutions to be built... solutions 
> that take privacy, confidentiality, authorization and authentication 
> into full account and allow us to span from "only sharing public data" 
> to "sharing any data".
>
> - James
>
> On Oct 30, 2012 10:33 AM, "Evan Prodromou" <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     However, it's such a complicated and difficult problem, that
>     trying to solve it with this version of Webfinger will effectively
>     disallow public discovery.
>
>     I suggest making a note in the security considerations that
>     Webfinger links are visible to all, so don't put private stuff in
>     there, full stop.
>
>     -Evan
>
>         [email-masked] <mailto:[email-masked]>
>     E: [email-masked] <mailto:[email-masked]> P: +1-514-554-3826
>
>     [email-masked] <mailto:[email-masked]>

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 30 Oct 2012 20:36:52 -0400

Stephen,

> Possibly. But its really not relevant to this part of the discussion.

It does, actually.
 
> > TLS at least allows one to conduct business such that it's not in full
> > view the neighbor peeping.
> >
> > It does not hide queries made to the WF service provider, of course.
> > But, that's true of any kind of request made to any service provider,
> > including queries to Google, Facebook, etc.
> 
> I think you're wrong there. If I send H([email-masked]) to any server
> that doesn't know about [email-masked] then that server has less
> information than otherwise, and that's independent of whether TLS was
> used or not. The server can still correlate two requests that contain
> H([email-masked]) and could in principle search for the string
> [email-masked] and verify when its found the right string.

If I query Google for H, then Google knows I'm looking for H. If I query
example.com for H (since example.com is the domain responsible for H), then
example.com knows I searched for H. These are the same.
 
> Hashing the URI also makes the code a teeny bit more complex and perhaps
> significantly more complex for some kinds of client (e.g. javascript,
> before the webcrypto API is deployed).

Hashing hides your request from an intermediary, but the WebFinger server
queried knows what H is.  If you wish to hide from the intermediaries or
lurkers out there, you need TLS.
 
> So hashing the URI as an option is not a crystal clear winner, but is
> worth discussing and is different from not being able to hash the URI.

I just don't see how it helps, honestly, except to hide the fact you're
looking for [email-masked] when you query using plain old HTTP and you
don't want people to know you queried for Bob.  But, if the server returns
an answer, everything will be laid out in plain text, so hashing will not
help hide anything.  TLS helps hide.

> The only place this touches on TLS usage is that it H(URI) exposes less
> to intermediaries if TLS is not used.

TLS exposes only the DNS query and the TCP connection to the server.
Intermediaries see nothing, not even the fact the WebFinger service was
queried.
 
> > I'm not opposed to it, but I'm not sure how we can specify that. It's
> > like telling an email client developer when they can send an email.
> 
> Generic note, just in case: I'm raising things to discuss; I don't mean
> that all that discussion needs to go into the draft.
> 
> In this case, I suspect there's not been so much consideration of the
> non-obvious cases where you have to figure out what server to ask, but I
> could well be wrong, or maybe its not been considered but will not turn
> out to be a problem. Has that been considered?

The server to ask to resolve acct:[email-masked]?  That would be the server
identified by the A record (or CNAME pointing to an A record) for
example.com.

> > I'm not sure where it is documented, but if you have a Google+
> > profile, go there.  Select "Edit Profile".  The screen is full of
> > information about yourself, including your contact info, those you
> > follow, those following you, where you work, etc.  Every single
> > section has the option to make it public or share it with specific
> > "circles".  You can specify precisely what circles can see the
> > information.  Some information made public is published via WebFinger
> so that it can be queried outside Google+.
> >
> > Note this only returns an XRD document, since Google's implementation
> > has not yet been updated with the current text in this draft.
> 
> characteristics with a hash (long, hard to guess). Perhaps that further
> indicates utility in allowing the client to choose that feature? As is,
> only the service provider (Google in the above) gets to make that choice.

:-)  That's my account ID on Google+, not a hash.  It's not secret.
 
> > But the person sending the query *wants* to send the query and he/she
> > knows who he/she is sending a query about.  It's no different than
> > looking up a person on FB or sending an email.
> 
> It is different in the example originally quoted where the UA is said to
> be doing this in the background. At that point I have no idea if the
> user wants the information or not.

True, but any software product should always allow such things to be
configurable. It's not a WF issue, but a broader issue.

Here's a scary one to consider... Linked In will actually tell me who looks
at my profile.  I don't ask for that, but they send that info to me for some
reason.  Now, isn't that just a bit over-the-top?  I'd say it is.

This is why I say these kinds of privacy issues need broad treatment.  We
need a little text in the WF spec, and we have that, but the privacy issues
abound on the Internet and there is no way we can give it proper treatment
in WF.  The text would be larger than the WF draft.

> Which reminds me: how is caching handled here? Is the UA expected to run
> the WF protocol again each time or not? From the privacy perspective
> saying "no need to do it each time" would be good I guess. I don't see
> any text along those lines. Did I miss that?

As a service built on HTTP, all HTTP features may be used, including Cache
Control.  We do not cover all of the HTTP features, since that is covered by
HTTP. 
 
> Sorry. This relates to the publisher. We're not defining a protocol for
> the publisher to tell the server which bits of information it'd like
> published, nor any conditions that it'd like put on those. I was asking
> why that'd not be a good thing to do. (And a fine answer might be: "go
> ahead and do it if you care that much":-)

If I said that, I think you'd tell me I was being perjorative again ;-)

If I share info via Google+ and Google+ puts that in WebFinger, who is the
publisher?  Me or Google+?

In the case of Google+, I am given control over what Google+ then publishes.
That's not a protocol that we can write, but an interface that Google
provides me and then they take my input and put into their database.

We did not define a protocol that feeds into WF.  WF is defined only between
a server and an entity requesting information.  How the information gets
into the WF server is implementation-specific.  (In my own server, you
manually insert stuff into the database and the server extracts whatever it
sees when queried.)
 
> right now, we don't. So we need to consider it piecemeal like this.

Getting somewhere? :-)
 
> >>> People who are
> >>> insanely concerned about their privacy should first walk away from
> >>> the Internet.
> >>

Perhaps my words are too strong?  Would it sound better if I referred to
people who are "insanely concerned" as people who are "extremely concerned"?
It is true, though, that there is little privacy on the Internet when it
comes to as accessing information that is publicly available.  Visiting a
web site, even querying for a server, or sending an email (even if the email
was encrypted using PGP) leaks bits of information about that person.

> You appear to recognise the problem ("oozing" implies that) but suggest
> just surrendering? I think we can and should try do better.

It's certainly a problem, yes, and I am not opposed to putting a reasonable
amount of text into WF. I've tried already. However, the Internet as a whole
is "out of control" in this regard.

The one that really has my head shaking this week is Yahoo!'s and Apache's
decision to ignore the "Do Not Track" header coming from Internet Explorer
because they felt Microsoft had not right to assume its users would prefer
that little bit of privacy.  The argument was they were in violation of the
DNT spec where it says users should enable that feature.  Really
unbelievable.

> > Give them your name or other personal info once and they can then tell
> > you everywhere you've been on that machine or might have been.  Google
> > Ads are everywhere and everything is recorded.  You can tell this from
> > the fact they offer interest-based ads.  How do they know your
> > interests.  How do they know you are?  Google is just one example.
> >
> >> "balance" "overly" "appropriate" and "insanely" are all bad fillers
> >> that really indicate a need for something to be fixed.
> >

Oh! Is that what got me in trouble?  It was a bold statement, I agree.
Given the current state of affairs, though... it's true.  Consider that DNT
mess as a good example.  Microsoft cannot win for losing there.

> > People are different and certainly have different expectations.  It
> > was not intended to mean more than that.
> 
> We ought therefore recognise that and give even the tin-foil hat brigade
> some choices, right?

They should have choices.  But where you're going with WF concerns, while
valid, are issues that are much larger than WF.  The issues must and need to
be considered more broadly.  WF is, perhaps, the first _standard_ that would
allow a user to post tons of easily discoverable information about
themselves and which can be easily retrieved in via automated processes.
(That's not entirely true, since one could publish anything on the web today
via HTML and many other protocols, but WF has the express purpose of helping
to discover information about person and entities easily through a
programmatic interface.)

> WebFinger.
> >> Perhaps. But my question was about privacy for those whose user
> >> agents might automatically issue queries. Ignoring the question is
> >> not a way to answer the question.
> >
> > This side is even easier to control.  One does not have to
> > automatically query.
> 

And where does it say a client must or even should?

I could change the example in the text to which you referred to say that
Alice pushes button to retrieve information about Bob.  But, no matter how
it is worded, the text in that section will have no impact on
implementations.

If we need wording, that is what the Security Considerations is for.  There
is text there, but we can add more... if somebody suggests it.

> > Well, I'll immediately confess to saying that I'm not the best author
> > for that document.
> 
> privacy draft, I suspect you're correct;-) But again, that's not what I
> asking for/about.

You saw this posted in response:
http://tools.ietf.org/html/draft-iab-privacy-considerations-04

This is an interesting document.  I've not read it, but the abstract gives
me cause for concern.  It said:
   "This document offers guidance for developing privacy
    considerations for inclusion in IETF documents."

The kind of document I'm suggesting is needed is a blanket document that
covers privacy issues in general.  Skimming over the referenced text, it
seems to cover some of those things.  But, rather than being directed toward
the protocol developer, I really think we need a document like that that is
directed toward the application developer, network administrator, and
businesses that collects, stores, and utilizes end-user information.

We know DNS can reveal a lot.  I can tell if my son visits a web site to
play a game, for example.  If I modified the DNS server code, I could even
log each time he made a request.  We could say things like that about every
protocol we have defined today.

> > However, I do believe the points you and others have raised are valid
> > concerns, but the whole social networking, blogging, micro-blogging,
> > web commenting, etc. movement brings about a whole lot of privacy
> > issues that probably do need to be considered holistically.
> 

I never suggested we do nothing.  There is some text in the spec already.  I
solicited for text several times :-)  I cannot adequately write
considerations for privacy as evidenced from the discussion and feeling that
what is written is insufficient.

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 30 Oct 2012 20:48:42 -0400

That's not an entirely true statement.  See:
http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-02#section-11

Question is whether that is sufficient.  Thus far, I've not received any
additional text.

Paul

> Sent: Tuesday, October 30, 2012 1:19 PM
> To: Hannes Tschofenig
> Cc: [email-masked]

---

From: SM <[email-masked]>
Date: Tue, 30 Oct 2012 23:57:35 -0700

Hi Paul,

Ok.

>Question is whether that is sufficient.  Thus far, I've not received any

As far as I am aware the IETF Stream is not an open source project 
where one does "send patch".  I read a draft and I comment about 
it.  There isn't any requirement for me to "send text".  It obviously 
does not help the working group to resolve issues if I do not put in 
the effort to "send text".  However, I see the effort as one-sided if 
"send text" is the only argument to address an issue.

It was mentioned that Google+ uses Webfinger [1].  It was argued that 
the right approach is what Google is going with Google+.  Nobody has 
been able to find where the documentation is.

 From Section 11 of the draft:

   "Service providers and users should be aware that placing information
    on the Internet accessible through WebFinger means that any user can
    access that information."

I strongly doubt that service providers will be overtly concerned 
about placing information about their users on the Internet.

   "While WebFinger can be an extremely useful tool for allowing quick
    and easy access to one's avatar, blog, or other personal information,
    users should understand the risks, too."

The user can only make that decision if he/she is provided with 
enough information.  I rewrote the following sentence:

   If one does not wish to share certain information with the world, one
   must not use any service supporting WebFinger.

Quoting draft-iab-privacy-considerations-04:

   "Correlation is the combination of various pieces of information
    related to an individual.  Correlation can defy people's expectations
    of the limits of what others know about them.  It can increase the
    power that those doing the correlating have over individuals as well
    as correlators' ability to pass judgment, threatening individual
    autonomy and reputation."

Is that an issue with respect to Webfinger?

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg07685.html

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 31 Oct 2012 09:17:01 +0000

Hi SM,

On 10/31/2012 06:57 AM, SM wrote:
> As far as I am aware the IETF Stream is not an open source project where
> one does "send patch".  I read a draft and I comment about it.  There
> isn't any requirement for me to "send text".  It obviously does not help
> the working group to resolve issues if I do not put in the effort to
> "send text".  However, I see the effort as one-sided if "send text" is
> the only argument to address an issue.

I kind of agree, but am also sympathetic to Paul's position.

If, as a document editor, he's being asked to put in stuff
with which he's not fully in agreement, (which seems to be the
case here, roughly), then "send text" seems to me like a pretty
reasonable response from any wg document editor in that position
who's willing to do the right thing and add text for which
there's rough consensus even if they don't personally like it.

If none of us that are commenting, (incl. me) have the energy
to suggest some text then that's also significant.

OTOH, I don't think we're that near a rough consensus on what
text might go in, so its arguably early for the document
editor to fall back to "send text."

Maybe we should try get a few folks who care about this into
a huddle in ATL if some of those who're interested will be
there? (If the Sunday reception worked then on Monday morning
Paul might be able to say something more than "we have insane
privacy nuts" :-)

S.

PS: Not wearing any hats and all that.

---

From: Mikael Nordfeldth <[email-masked]>
Date: Wed, 31 Oct 2012 11:42:31 +0100

> PS: Not wearing any hats and all that.

Except the tinfoil one? ;-)

Either way I think it is important to remember that what Webfinger is 
basically just standardise the way humans, machines and our future 
androids will lookup information about pseudonyms. It does not in any 
way _produce_ more information.

Whatever reason you have to worry about the "hidden lookups" (which 
initiated this thread) or personal data collection/correlation, are not 
new issues created by Webfinger. The only thing WF maybe does is make it 
more obvious that such things can - and perhaps even do - occur. The 
data is already out there, on zillions of forums, communities, mailing 
lists etc, where users "ooze" their personal data.

I see a great opportunity in that transparency, the fact that maybe 
internet users can

Also, Stephen and whomever else is concerned. If you (or "normal 
people" or "privacy nuts") do not trust the service or application you 
run to handle your (or others') privacy well, I heavily recommend you to 
stop using it. Or simply don't give out data that can be correlated with 
whatever you don't want it correlated with.

If one is concerned with privacy and the service or software won't let 
you switch off this "oozing", simply stop using it (or make sure you use 
it in a privacy-minded manner). If it, say, uses Webfinger you can 
yourself verify it doesn't reveal any inappropriate data - or just stop 
using the service.

And if a third party somehow aggregates information about you without 
your consent, it's definitely a privacy issue and even illegal in many 
jurisdictions. If that is the case, it should be acted upon through 
court of law. Not by modifying suggested internet protocol standards.

-- 
Mikael Nordfeldth
http://blog.mmn-o.se/
[email-masked]
+46705657637

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 31 Oct 2012 11:56:21 +0000

Hiya,

> Except the tinfoil one? ;-)

:-)

Generic (but interesting, for me) discussion below...

> way _produce_ more information.

I could argue that aggregates are always more sensitive than
unaggregated information. I do think that may be relevant
for webfinger services, though maybe not much for the protocol
as currently specified.

> lists etc, where users "ooze" their personal data.

One of the things we try do when standardising stuff is to ensure
that appropriate (strong) security mechanisms are well-defined and
maybe mandatory to implement. That wasn't always the case, and we
still struggle with adding security more than a decade later, e.g.
with routing. (See sidr/karp for example.)

We don't have an IETF consensus that we ought also try
make things (be able to be) more privacy-friendly, and we're
IMO much less certain of what'd be right to do both in general,
and in specific cases like webfinger, but I personally reckon
we ought pay more attention to privacy and not just continue
oozing away mindlessly. But like I say, that's not a consensus
opinion by any means. It is a valid thing to question though.

> I see a great opportunity in that transparency, the fact that maybe

I agree things like webfinger create opportunities, perhaps
both good and bad. I'm not at all saying that webfinger is bad
btw.

> Also, Stephen and whomever else is concerned. If you (or "normal people"
> or "privacy nuts") do not trust the service or application you run to
> handle your (or others') privacy well, I heavily recommend you to stop
> using it. Or simply don't give out data that can be correlated with

Well, that's not always practical. And it'd also be a shame if say
adding webfinger to some site that was generally privacy-friendly
had to make that site less privacy-friendly. I'm not saying
that is the case here, its a generic argument about ooziness I guess.
(How many variants of "ooze" can we invent I wonder:-)

> court of law. Not by modifying suggested internet protocol standards.

<foo> is illegal somewhere does not imply the IETF should do nothing
about <foo>. I think that's a broken argument, though you may be
right that for some privacy issues, there's little that can be done
with our protocols. (Saying <foo> is illegal somewhere therefore we
have to standardise a way to prevent <foo> would be an equally
broken argument btw.)

Misuse of computers (e.g. via standards-track protocols) is illegal
in lots of places, as is spam, but we do quite a bit to try help
in such cases, and we do recognise that we cannot ignore the bad
actors that exist.

So I probably predictably disagree if your conclusion was either
that all's well in the world or that we're already so screwed it
doesn't matter.

And none of the above helps Paul know what to put in the draft;-)

S.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 31 Oct 2012 08:20:50 -0400

So i was at the OWASP conference in Austin last week and they had a whole
slew of Javascript hacks that pretty much demonstrate that with the Web as
it is right now, everyone gives pretty much everything away when they visit
any site.

The real culprit here is Javascript which basically was designed by people
who only cared about goosing their stock options. But being an application
conference, well 90% of the attendees make their living writing Javascript
so 'turn it off' is not an option for them.

Webfinger as currently designed is not going to make the situation any
worse, but it isn't going to make it better either.

Looking at the horrors that Javascript is committing and the refusal to
consider any changes that reduce functionality (including widely abused
functionality). I would put the chances of regulation at 100%. In a few
years those guys are going to be writing standards with more lawyers than
engineers sitting in the room unless they have a sudden change of mindset.

So rather than framing the argument as 'is Webfinger damaging privacy' I
would ask 'is Web finger helping people to do the sorts of things that
users want without unexpected privacy side effects'.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 31 Oct 2012 15:06:09 +0200

Hi Phillip, 

On Oct 31, 2012, at 2:20 PM, Phillip Hallam-Baker wrote:

> Javascript which basically was designed by people who only cared about goosing their stock options.

I do not disagree with you here but WebFinger by itself does not necessarily need to be implemented in JavaScript(*). 

> 'is Web finger helping people to do the sorts of things that users want without unexpected privacy side effects'

There are use cases where people want to use WebFinger as a discovery mechanism (such as OAuth) where the current design of WebFinger introduces privacy problems (unnecessarily). I raised this issue last year in May:  
http://www.ietf.org/mail-archive/web/oauth/current/msg08965.html

It seems that WebFinger has become a solution in search of a problem for some people. 

Ciao
Hannes

PS: (*) In the context of the use case I care about (namely identity management) implementations of JavaScript tend to have serious security problems.

---

From: SM <[email-masked]>
Date: Wed, 31 Oct 2012 07:14:35 -0700

Hi Phillip,
At 05:20 31-10-2012, Phillip Hallam-Baker wrote:
>the chances of regulation at 100%. In a few years those guys are 
>going to be writing standards with more lawyers than engineers 
>sitting in the room unless they have a sudden change of mindset.

Yes.

>So rather than framing the argument as 'is Webfinger damaging 
>privacy' I would ask 'is Web finger helping people to do the sorts 
>of things that users want without unexpected privacy side effects'.

That may be a better question.

Regards,
-sm

---

From: SM <[email-masked]>
Date: Wed, 31 Oct 2012 07:09:06 -0700

Hi Stephen,
>I kind of agree, but am also sympathetic to Paul's position.

Paul made some good arguments.

Yes.

>to suggest some text then that's also significant.

Agreed.

>Paul might be able to say something more than "we have insane

As the privacy nut, let me try to step back.  The argument up to now 
has been that there are privacy concerns.  I understand that it is 
difficult to address that as it comes out as too broad.  I'll try to 
post some text to the privacy list as a starting point.

Regards,
-sm

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 31 Oct 2012 10:53:08 -0400

On Wed, Oct 31, 2012 at 10:14 AM, SM <[email-masked]> wrote:

>> the chances of regulation at 100%. In a few years those guys are going to
>> be writing standards with more lawyers than engineers sitting in the room
>> unless they have a sudden change of mindset.
>>
>
> Yes.
>
>

Indeed, one of the pathologies here is that the apps people want to do X
but their proposal has a few minor security issues. So they are told they
can't do X and instead they work out that due to various holes in the
application layer they can do Y which is almost as good as X as far as they
are concerned but has infinitely more security issues.

So the blame here is not all on one side.

One of the reasons I wrote my draft on HTTP auth is that I see much of this
same pathology. The security side wants something that is perfect, the apps
people don't see that the security issues are relevant to their users. So
they give up on doing things through the channel with security expertise
and go find a different channel.

It is worth pointing out that if certain people had their way long long ago
(i.e. me, most others in the Web security area) then TLS would not have
happened because transport layer was the wrong place for security. Well it
was certainly a botch job at first but that might have been the only way
something could have been deployed.

http://tools.ietf.org/id/draft-hallambaker-httpauth-01.xml

A common refrain at OWASP was 'you are not going to fix Javascript because
people want to use it'. What was not really addressed was WHO wants to use
it. The fact that facebook wants to use it is of precisely zero interest to
me because I really have no use for that site. and I certainly could not
give a hoot if EU legislation ruins the business plans of certain Web
advertisers.

I have already turned off plugins (other than PDF) except for specific
sites. I am about to do the same for Javascript (but after I send this
email). What I think most users would be happiest with is a scheme that
allows that type of intelligence to be delivered to them from a third party
source that specializes in security and can work out whether a site is
likely malicious or clueless.

-- 
Website: http://hallambaker.com/

---

From: James M Snell <[email-masked]>
Date: Wed, 31 Oct 2012 09:32:01 -0700

Ordinarily I would provide a suggestion of alternative text but I've been
tied up on a few other matters. That said, a few notes...

The basic protocol itself is fine.. the way that the current resource
parameter is defined, I could in theory use a uri scheme that allows me to
hash the identifier without requiring changes to the basic protocol itself.
That itself is not so much of a problem.

What is a problem, however, is that you've mentioned a few times that TLS
could provide the necessary privacy control but there does not appear to be
any mention at all of TLS within the specification document. It really
should be called out as a specific recommendation in the text.

I also note that while you do cover some of the privacy issues in the
security considerations, one point could stand to be made clearer:
WebFinger should only be used to expose information the subject has
explicitly opted in to be shared. Or put another way, WebFinger MUST NOT be
used to provide information to any party the subject has not explicitly
authorized. This is loosely implied by the current text but, unless I
missed it, you never just come out and say it.

A couple other points that come to mind when re-reading the security
considerations...

1. There is nothing said about the validity and authenticity of the data
returned. There does not have to be an exhaustive discussion on this
matter, of course, but currently the protocol makes no guarantees and
provides no mechanisms for assuring that the information returned for a
given user is authentic, authoritative or valid in any way. It should at
least be noted that such mechanisms are out of the scope of the WebFinger
protocol.

2. A cryptographic hashed identifier could help prevent correlation style
breaches in privacy if the hash is generated based on a shared secret key
tied to the requesters authenticated identity. That is, if a WebFinger
server requires authentication to request data, the requester can generate
an hmac, for instance, using a shared secret key and specify that within
the URI request. Used in combination with TLS, for example, this would
provide a reasonable assurance of privacy between the requester and the
service provider, keeping prying eyes in the middle from knowing whose
information is being requested. Again, it is possible to do with currently
without any changes to the WF protocol as defined so no normative changes
would be necessary, but it might be worthwhile to draw out as an
informative example.

- James

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 31 Oct 2012 15:13:37 -0400

> >Question is whether that is sufficient.  Thus far, I've not received
> >any additional text.
> 

No, but it is an open standards process where anyone can contribute text.
I've contributed text and I've tried to address the issues raised w.r.t.
privacy.  If it is not sufficient, then I need to be told what to put in
there.
 
> been able to find where the documentation is.

I do not know that it is documented.  However, I described how it works.
Just use your gmail.com ID and you can query Google's servers using that URL
I posted earlier.  It will show some of the content you had marked as
"Public" via Google+.
 
> I strongly doubt that service providers will be overtly concerned about
> placing information about their users on the Internet.

Yeah, likely not.  This is why I don't think having extensive material in a
WF draft will make any difference.  A few comments on privacy make sense,
but a more complete treatment of the subject is needed elsewhere.

> The user can only make that decision if he/she is provided with enough
> information.  I rewrote the following sentence:
> 

I think we should address post making info available and accessing it.  How
is this:

    If one does not wish to share certain information with the world,
    do not allow that information to be freely accessible through
    WebFinger and do not use any service supporting WebFinger.

That said, I do think it's going a bit far.  Following this logic, we should
go back and revise the DNS specs, too, to say "if one does not want the
world to know what one is accessing, do not use DNS."  It's the same issue,
really.
 
> Is that an issue with respect to Webfinger?

This can certainly be said of Google advertising, for example.  It can be
said of any web user habits, your email exchanges with me, blog posts,
comments on web sites, etc.  WebFinger is just one more service like so many
others.  The only thing that is perhaps strikingly different is that with
WebFinger, one is publishing information about themselves in a concentrated
place.  So, rather than visiting my home page to get some contact info, one
can query it via WebFinger in a nice automated way.  This can be abused, of
course, but so can posting profile information in one's Facebook account.

Paul

---

From: Evan Prodromou <[email-masked]>
Date: Wed, 31 Oct 2012 15:25:18 -0400

On 12-10-31 12:32 PM, James M Snell wrote:
> What is a problem, however, is that you've mentioned a few times that 
> TLS could provide the necessary privacy control but there does not 
> appear to be any mention at all of TLS within the specification 
> document. It really should be called out as a specific recommendation 
> in the text. 
>
> explicitly opted in to be shared. Or put another way, WebFinger MUST 
> NOT be used to provide information to any party the subject has not 
> explicitly authorized. This is loosely implied by the current text 
> but, unless I missed it, you never just come out and say it.
>
That seems exceptionally strong. It also doesn't reflect current 
practice for Web services which often provide profile pages or other 
human-readable endpoints that include by default at least some of the 
profile data provided by the user.

The best services let users choose what profile data to share with whom 
(show my phone number only to friends and family) and most just let the 
user choose whether to share the data at all or not.

For machine-readable endpoints, I think it's untenable. I can say right 
now that there's no way I'll /ever/ create user interfaces to ask that a 
user explicitly opt in to e.g. publishing their Salmon protocol endpoint.

Maybe a better way to say it is: the implementor SHOULD let users opt 
out of sharing personally-identifying information, or data that 
correlates to other accounts or identities, and SHOULD inform users that 
the data is being shared in e.g. a terms of service agreement.
> 2. A cryptographic hashed identifier could help prevent correlation 
> style breaches in privacy if the hash is generated based on a shared 
> secret key tied to the requesters authenticated identity. That is, if 
> a WebFinger server requires authentication to request data, the 
> requester can generate an hmac, for instance, using a shared secret 
> key and specify that within the URI request. Used in combination with 
> TLS, for example, this would provide a reasonable assurance of privacy 
> between the requester and the service provider, keeping prying eyes in 
> the middle from knowing whose information is being requested. Again, 
> it is possible to do with currently without any changes to the WF 
> protocol as defined so no normative changes would be necessary, but it 
> might be worthwhile to draw out as an informative example.
James, could you give an explicit example of the problem and what the 
solution is? I see at least two or three things here that you're laying out.

-Evan

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 31 Oct 2012 15:26:43 -0400

Stephen,

> Maybe we should try get a few folks who care about this into a huddle in
> ATL if some of those who're interested will be there? (If the Sunday
> reception worked then on Monday morning Paul might be able to say
> something more than "we have insane privacy nuts" :-)

Now that was funny ...

I'll be around most of the week and would be happy to take whatever text
folks want to provide and insert it into the document.  I really am at a
loss for words on this.  I do not know what to write.  While I don't share
the same privacy concerns, I do respect those who have privacy concerns.

I don't think anyone is insane, though.  I tend to use exaggerated language,
but I'm really more down-to-earth than that language might suggest. ;-)

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 31 Oct 2012 17:38:01 -0400

James,

HTTPS is recommended and shown throughout the document.  We do not say TLS, as HTTPS implies that.

In the security section at the end of “Service providers and users…” how about this?

Further, WebFinger servers MUST NOT be used to provide any personal information to any party unless authorized by the person whose information is being shared.

As a final paragraph in that section, how about this?

Finally, a WebFinger server has no means of ensuring that information provided by a user is accurate.  Likewise, neither the server nor the client can be absolutely guaranteed that information has not been manipulated either at the server or along the communication path between the client and server.  Use of HTTPS helps to address some concerns with manipulation of information along the communication path, but it clearly cannot address issues where the server provided incorrect information, either due to being provided false information or due to malicious behavior on the part of the server administrator.  As with any information service available on the Internet, users should wary of information received from untrusted sources.

Paul

From: James M Snell [mailto:[email-masked]] 
Sent: Wednesday, October 31, 2012 12:32 PM
To: Paul E. Jones
Cc: IETF Apps Discuss; Hannes Tschofenig; SM
Subject: Re: [apps-discuss] webfinger privacy question/suggestion

Ordinarily I would provide a suggestion of alternative text but I've been tied up on a few other matters. That said, a few notes...

The basic protocol itself is fine.. the way that the current resource parameter is defined, I could in theory use a uri scheme that allows me to hash the identifier without requiring changes to the basic protocol itself. That itself is not so much of a problem. 

What is a problem, however, is that you've mentioned a few times that TLS could provide the necessary privacy control but there does not appear to be any mention at all of TLS within the specification document. It really should be called out as a specific recommendation in the text. 

I also note that while you do cover some of the privacy issues in the security considerations, one point could stand to be made clearer: WebFinger should only be used to expose information the subject has explicitly opted in to be shared. Or put another way, WebFinger MUST NOT be used to provide information to any party the subject has not explicitly authorized. This is loosely implied by the current text but, unless I missed it, you never just come out and say it.

A couple other points that come to mind when re-reading the security considerations...

1. There is nothing said about the validity and authenticity of the data returned. There does not have to be an exhaustive discussion on this matter, of course, but currently the protocol makes no guarantees and provides no mechanisms for assuring that the information returned for a given user is authentic, authoritative or valid in any way. It should at least be noted that such mechanisms are out of the scope of the WebFinger protocol.

2. A cryptographic hashed identifier could help prevent correlation style breaches in privacy if the hash is generated based on a shared secret key tied to the requesters authenticated identity. That is, if a WebFinger server requires authentication to request data, the requester can generate an hmac, for instance, using a shared secret key and specify that within the URI request. Used in combination with TLS, for example, this would provide a reasonable assurance of privacy between the requester and the service provider, keeping prying eyes in the middle from knowing whose information is being requested. Again, it is possible to do with currently without any changes to the WF protocol as defined so no normative changes would be necessary, but it might be worthwhile to draw out as an informative example.

- James

Paul

---

From: James M Snell <[email-masked]>
Date: Wed, 31 Oct 2012 14:38:51 -0700

On Wed, Oct 31, 2012 at 12:25 PM, Evan Prodromou <[email-masked]> wrote:

> That seems exceptionally strong. It also doesn't reflect current practice
> for Web services which often provide profile pages or other human-readable
> endpoints that include by default at least some of the profile data
> provided by the user.
>
> now that there's no way I'll *ever* create user interfaces to ask that a
> Maybe a better way to say it is: the implementor SHOULD let users opt out
> of sharing personally-identifying information, or data that correlates to
> other accounts or identities, and SHOULD inform users that the data is
> being shared in e.g. a terms of service agreement.
>
>
The critical points here are A) a user should never be surprised about what
data a particular service provider is offering up about them and B) a user
should never be surprised about which services are offering up data about
them.

> solution is? I see at least two or three things here that you're laying out.
Very straightforward really... Org A wishes to access information about Org
B's users without all the parties in between knowing what's being
requested. For example... IBM has their SmartCloud for Social Business
service.. which is essentially a multi-tenant hosted version of our
Connections product. We have third party ISV's that integrate with that
product and provide extended services to our customers. This is just an
example, but what I want is to be able to provide secure Webfinger services
so that those ISV's can access non-public information about specific users.
It's the same basic WF protocol but with an added layer of security that
the privacy and confidentiality of potentially sensitive business
relationships.

- James

---

From: James M Snell <[email-masked]>
Date: Wed, 31 Oct 2012 14:56:18 -0700

On Wed, Oct 31, 2012 at 2:38 PM, Paul E. Jones <[email-masked]>wrote:

> James,****
>
> ** **
>
> HTTPS is recommended and shown throughout the document.  We do not say
> TLS, as HTTPS implies that.****
>
> **
>

>From the security considerations, I see...

"Of particular importance is the recommended use of HTTPS to ensure that
information is not modified during transit. Clients should verify that the
certificate used on an HTTPS connection is valid."

Why not make this a "SHOULD use HTTPS" (note the capitalized SHOULD) and
provide a normative reference to TLS? Why not make use of TLS the default?
Showing it in examples without a strong normative recommendation or
requirement is a good way to have it ignored or supported as an
afterthought.

>  **
>
> In the security section at the end of “Service providers and users…” how
> about this?****
>
> ** **
>
> Further, WebFinger servers MUST NOT be used to provide any personal
> information to any party unless authorized by the person whose information
> is being shared.****
>
> **
>

Perhaps something along the lines of...

  "Further, WebFinger servers MUST NOT be used to provide any personal
information to any party unless explicitly or implicitly authorized by the
person whose information is being shared. Implicit authorization can be
determined by the users voluntary utilization of a service as defined by
that service's relevant terms of use or published privacy policy."

Would have to fiddle with the wording there but basically... if a user is
voluntarily providing their information to a service that makes it know in
advance what information is going to be provided via WebFinger (e.g. within
a Terms of Service or Privacy Policy document) then we're good. Again, to
reiterate the point I made in another note, a user should never be
surprised what information is being shared and by whom.

> **
>
> As a final paragraph in that section, how about this?****
>
> ** **
>
> Finally, a WebFinger server has no means of ensuring that information
> provided by a user is accurate.  Likewise, neither the server nor the
> client can be absolutely guaranteed that information has not been
> manipulated either at the server or along the communication path between
> the client and server.  Use of HTTPS helps to address some concerns with
> manipulation of information along the communication path, but it clearly
> cannot address issues where the server provided incorrect information,
> either due to being provided false information or due to malicious behavior
> on the part of the server administrator.  As with any information service
> available on the Internet, users should wary of information received from
> untrusted sources.****
>
> **
>

That works.

- James

> **
>
> Paul****
>
> ** **
>
> *From:* James M Snell [mailto:[email-masked]]
> *Sent:* Wednesday, October 31, 2012 12:32 PM
> *To:* Paul E. Jones
> *Cc:* IETF Apps Discuss; Hannes Tschofenig; SM
>
> *Subject:* Re: [apps-discuss] webfinger privacy question/suggestion****
>
> ** **
>
> tied up on a few other matters. That said, a few notes...****
>
> That itself is not so much of a problem. ****
>
> should be called out as a specific recommendation in the text. ****
>
> missed it, you never just come out and say it.****
>
> considerations...****
> protocol.****
> informative example.****
> - James****
> On Oct 30, 2012 5:48 PM, "Paul E. Jones" <[email-masked]> wrote:***
> *
>
> https://www.ietf.org/mailman/listinfo/apps-discuss****
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 31 Oct 2012 18:36:07 -0400

James,

Comments in green:

From: James M Snell [mailto:[email-masked]] 
Sent: Wednesday, October 31, 2012 5:56 PM
To: Paul E. Jones
Cc: IETF Apps Discuss; Hannes Tschofenig; SM
Subject: Re: [apps-discuss] webfinger privacy question/suggestion

On Wed, Oct 31, 2012 at 2:38 PM, Paul E. Jones <[email-masked]> wrote:

James,

>From the security considerations, I see...

"Of particular importance is the recommended use of HTTPS to ensure that information is not modified during transit. Clients should verify that the certificate used on an HTTPS connection is valid."

Why not make this a "SHOULD use HTTPS" (note the capitalized SHOULD) and provide a normative reference to TLS? Why not make use of TLS the default? Showing it in examples without a strong normative recommendation or requirement is a good way to have it ignored or supported as an afterthought.

PEJ: In Section 5.1 (“performing a query), we have:

It is strongly RECOMMENDED that WebFinger servers return content using secure (HTTPS) connections.  Clients MUST first attempt queries using HTTPS before attempting a query using HTTP.

I think that is as strong as we can make it.  We cannot mandate the use of HTTPS.

 

  "Further, WebFinger servers MUST NOT be used to provide any personal information to any party unless explicitly or implicitly authorized by the person whose information is being shared. Implicit authorization can be determined by the users voluntary utilization of a service as defined by that service's relevant terms of use or published privacy policy."

Would have to fiddle with the wording there but basically... if a user is voluntarily providing their information to a service that makes it know in advance what information is going to be provided via WebFinger (e.g. within a Terms of Service or Privacy Policy document) then we're good. Again, to reiterate the point I made in another note, a user should never be surprised what information is being shared and by whom.

PEJ: Thanks!  I’ll insert that wording and then folks can propose changes, if desired.

Paul

 

That works. 

- James

Paul

- James

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 31 Oct 2012 19:01:14 -0400

Hannes,

I'm not sure if it is possible to use OAuth with
/.well-known/host-meta.json.

Can OAuth be used to protect any resource on the Internet?  If so, it could
be used to control access to /.well-known/host-meta.*.  For certain, all of
the link relations provided could be protected with any authentication
scheme.  Just because my WF server provides the link to my address book does
not mean anyone would have authorization to retrieve it.

Sometimes I wonder if people have forgotten or not considered that fact.
Certain information is revealed just from the JRD document itself (e.g., the
very fact I have some piece of data published), but the actual referenced
document can be tightly controlled.

Within a corporate environment, I would even expect an internal WF query to
return different results than an external one.  That would not require
OAuth, but would be controlled based on whatever mechanism is used to
determine if a person has access rights as an employee.

Paul

> [email-masked]] On Behalf Of Hannes Tschofenig
> Sent: Wednesday, October 31, 2012 9:06 AM
> To: Phillip Hallam-Baker
> Cc: General discussion of application-layer protocols
> I do not disagree with you here but WebFinger by itself does not
> necessarily need to be implemented in JavaScript(*).
> 
> > 'is Web finger helping people to do the sorts of things that users
> want without unexpected privacy side effects'
> 
> There are use cases where people want to use WebFinger as a discovery
> mechanism (such as OAuth) where the current design of WebFinger
> introduces privacy problems (unnecessarily). I raised this issue last
> year in May:
> PS: (*) In the context of the use case I care about (namely identity
> management) implementations of JavaScript tend to have serious security
> problems.

---

From: William Mills <[email-masked]>
Date: Wed, 31 Oct 2012 19:36:41 -0700 (PDT)

>The best services let users choose what profile data to share with
>whom (show my phone number only to friends and family) and most just
>let the user choose whether to share the data at all or not.

Yes, allowing the user to control what information is shared is key.  Note that we have multiple classes of informaiton, so that personal information like a vcard will be handled differently than service information like what OAuth endpoint is used ot authenticate the user.

>________________________________
> From: Evan Prodromou <[email-masked]>
>To: IETF Apps Discuss <[email-masked]> 
>Sent: Wednesday, October 31, 2012 12:25 PM
That seems exceptionally strong. It also doesn't reflect current practice for Web services which often provide profile pages or other human-readable endpoints that include by default at least some of the profile data provided by the user.
>
>The best services let users choose what profile data to share with
    whom (show my phone number only to friends and family) and most just
    let the user choose whether to share the data at all or not.
>
>For machine-readable endpoints, I think it's untenable. I can say
    right now that there's no way I'll ever create user interfaces to ask that a user explicitly opt in to e.g. publishing their Salmon protocol endpoint.
>
>Maybe a better way to say it is: the implementor SHOULD let users
    opt out of sharing personally-identifying information, or data that
    correlates to other accounts or identities, and SHOULD inform users
    that the data is being shared in e.g. a terms of service agreement.
>2. A cryptographic hashed identifier could help prevent correlation style breaches in privacy if the hash is generated based on a shared secret key tied to the requesters authenticated identity. Tha…
James, could you give an explicit example of the problem and what the solution is? I see at least two or three things here that you're laying out.

---

From: William Mills <[email-masked]>
Date: Wed, 31 Oct 2012 19:39:52 -0700 (PDT)

While I agree with the privacy language and drive toward being completely aware of this I think it's unrealistic to put too much verbiage in on what would be a company terms of service or privacy policy.

> From: James M Snell <[email-masked]>
>To: Paul E. Jones <[email-masked]> 
>Cc: IETF Apps Discuss <[email-masked]> 
>Sent: Wednesday, October 31, 2012 2:56 PM
>>From:James M Snell [mailto:[email-masked]]

---

From: William Mills <[email-masked]>
Date: Wed, 31 Oct 2012 19:42:40 -0700 (PDT)

It is probably up to the service to determine whether they return different information to an authenticated context.  Auth method and behavior is outsied the scope of WF I think.

> From: Paul E. Jones <[email-masked]>
>To: 'Hannes Tschofenig' <[email-masked]>; 'Phillip Hallam-Baker' <[email-masked]> 
>Cc: 'General discussion of application-layer protocols' <[email-masked]> 
>Sent: Wednesday, October 31, 2012 4:01 PM

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Wed, 31 Oct 2012 22:45:35 -0400

+1

Not to say it isn't important, I just think it is outside the scope of WF and current draft under discussion.

--G