Possible consideration of hiding email addresses from sites?
James King
I was just wondering if there was any possible consideration for hiding your email from a site you are authenticating to?
In other words, the site you are authenticating to only knows that a user with a unique ID has authenticated to it; that the user has a real email address (as claimed by the authenticator/issuer).
Under some circumstances it may be undesirable for a third-party site to get my email address, especially if I am trying out their service for the first time -- or if there is no real reason for them to contact me (as perceived by me).
Using the browser ID system, it may be possible to 'ensure' that I am not a spam bot trying to gain access to that third-party site, as I have been vouched for by the issuing authority -- without necessarily giving that third-party my email address.
Anyways, just curious if this might be a possibility.
Thanks!
Lloyd Hilaiel
Pardon my top posting. One thing along these lines that has been talked about is the ability of a primary to provide anonymized emails on a user's behalf.
As a technical user, I frequently do this anyway: give companies a custom email, like "com...@hilaiel.com". Doing this I have a simple way of auditing how companies I do business with use my email address.
The theory at this point in time is that this feature (on-demand anonymized email addresses) could be completely implemented by a primary. There are quite a few open questions about exactly how to build out the mechanism, and ideally we'll see competition and innovation in this area?
Now this is not precisely what you describe: instead of no email endpoint being provided, your identity provider is providing an ephemeral endpoint who's lifetime (and delivery details even?) *you* control. But I feel like it solves similar problems. What do you think?
(at the risk of typing too much, you could even imagine a provider of this type of service who lets you bring your own VM, and bring your own domain name. So that you become your own primary. The size of the audience for such features seems dependent on how well the user experience can be crafted, and how well the service can be explained).
best,
lloyd
> _______________________________________________
> dev-identity mailing list
> dev-id...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-identity
Pete Rowley
> Hi James,
>
> Pardon my top posting. One thing along these lines that has been talked about is the ability of a primary to provide anonymized emails on a user's behalf.
>
>
> The theory at this point in time is that this feature (on-demand anonymized email addresses) could be completely implemented by a primary. There are quite a few open questions about exactly how to build out the mechanism, and ideally we'll see competition and innovation in this area?
>
This is a rather elaborate scheme to solve a problem that need not
exist in the the first place. As soon as the relying party has
verified signatures and the cert chain your user is 'authenticated' -
that is the act of authentication - the delivery of the email address
is protocol prescribed information leakage, nothing more.
The description of your practice regarding revealing your email
address demonstrates why that information leakage is undesirable.
Tom Lowenthal
sorts of strategies to mask their email address and avoid spam. BrowserID is
based on<http://identity.mozilla.com/post/7616727542/introducing-browserid-a-better-way-to-sign-in>the
idea that an email address is a great user identifier, and allows a
service to contact users, all wrapped up together. The problem is that that
users want to be able to control how sites contact them, and using elaborate
address schemes has historically been part of that process. I don't see an
obvious solution given the design of BrowserID, but I do think that this is
something that merits further thought.
-Tom Lowenthal
Ben Adida
> The problem is that that
> users want to be able to control how sites contact them, and using elaborate
> address schemes has historically been part of that process.
Can you give examples of these elaborate address schemes?
As best as I can tell, users almost always give sites one of their email
addresses. Email addresses can easily be minted for one-off purposes,
e.g. springfiel...@emailprovider.example.com.
-Ben
Ben Adida
> This is a rather elaborate scheme to solve a problem that need not
> exist in the the first place.
Maybe it need not exist, but it does. Every web site we've seen that
does OpenID immediately asks for an email address. (We're not picking on
OpenID here, this would likely apply to any directed-identity system.)
So we're not causing any leakage. If anything, once the email address
exchange is mediated by the browser, then the browser can facilitate the
creation of aliases, which means we'll likely be facilitating pseudonymity.
> The description of your practice regarding revealing your email
> address demonstrates why that information leakage is undesirable.
But... Lloyd exlained that we can very easily deliver aliased email
addresses. So how is that undesirable?
What's going on is that web sites *need* a way to recontact their users.
If you don't give them a way, they will ask the user for a way. So, we
give them a way. But since we do it with browser mediation, we have the
opportunity to put that recontacting mechanism more under the user's
control, with aliases that forward.
If you disagree with the premise that web sites want email addresses
because it's a universal re-contact mechanism, I think you may be
wishing for a different world than the one we have.
-Ben
James King
Thanks for getting back to me; I had to read up a little more on the
identity project before I could reply here.
I like that you guys have considered that as a potential solution,
however I am worried that unless something like this is in the
specifications, primary providers may not actually do this.
Additionally, as an end-user, I want to be in full control over when
(and if) I provide an anonymized ID or otherwise. Also, I think that
for developers, this can be a confusing thing if primary providers
don't notify us when an email address is anonymized, working, or not.
If there's still room for the specifications to change, I would think
that one solution is to have a unique identifier (per relying-party,
per end-user) which can be authenticated and given to the relying-
party. If the user decides to share further information, then their
email address (or a primary-provided anonymized one) could be given.
For example, if I want to log into some relying-party -- I get to the
dialog where I pick my email/identity and maybe have a few checkboxes
present:
a) Share email address with relying-party
b) Allow relying-party to contact me
If a) is checked, then the user's true email address is shared with
the relying-party. This could be kept unchecked by default, and
overrides (b).
If b) is checked, then if an anonymized email address can be provided
(e.g., by gmail.com or some other PIA) it will be shared instead of
the user's true email. Otherwise, no email is shared, and only the
unique identifier is shared.
This way, relying-parties can manage unique users with 'some
guarantees' that these users are not spam-bots (for instance). This
site-wide unique identifier could be a new field in the certificate
section, e.g., "suid" followed by some string. If a relying-party
wants to prohibit anonymous users, then it could require that a user
authenticates using a visible email -- but it would be unable to
[automatically] tell the difference between an anonymized email or a
true one.
Is there any chance that something like this might still be
considered?
Thanks!
-James
On Jul 16, 2:43 pm, Lloyd Hilaiel <ll...@hilaiel.com> wrote:
> Hi James,
>
> Pardon my top posting. One thing along these lines that has been talked about is the ability of a primary to provide anonymized emails on a user's behalf.
>
> As a technical user, I frequently do this anyway: give companies a custom email, like "comc...@hilaiel.com". Doing this I have a simple way of auditing how companies I do business with use my email address.
>
> The theory at this point in time is that this feature (on-demand anonymized email addresses) could be completely implemented by a primary. There are quite a few open questions about exactly how to build out the mechanism, and ideally we'll see competition and innovation in this area?
>
> Now this is not precisely what you describe: instead of no email endpoint being provided, your identity provider is providing an ephemeral endpoint who's lifetime (and delivery details even?) *you* control. But I feel like it solves similar problems. What do you think?
>
> (at the risk of typing too much, you could even imagine a provider of this type of service who lets you bring your own VM, and bring your own domain name. So that you become your own primary. The size of the audience for such features seems dependent on how well the user experience can be crafted, and how well the service can be explained).
>
> best,
> lloyd
>
> On Jul 16, 2011, at 2:14 PM, James King wrote:
>
>
>
>
>
>
>
> > Hi all,
>
> > I was just wondering if there was any possible consideration for hiding your email from a site you are authenticating to?
>
> > In other words, the site you are authenticating to only knows that a user with a unique ID has authenticated to it; that the user has a real email address (as claimed by the authenticator/issuer).
>
> > Under some circumstances it may be undesirable for a third-party site to get my email address, especially if I am trying out their service for the first time -- or if there is no real reason for them to contact me (as perceived by me).
>
> > Using the browser ID system, it may be possible to 'ensure' that I am not a spam bot trying to gain access to that third-party site, as I have been vouched for by the issuing authority -- without necessarily giving that third-party my email address.
>
> > Anyways, just curious if this might be a possibility.
>
> > Thanks!
> > _______________________________________________
> > dev-identity mailing list
> > dev-ident...@lists.mozilla.org
> >https://lists.mozilla.org/listinfo/dev-identity
Brian Smith
> If you disagree with the premise that web sites want email addresses
> because it's a universal re-contact mechanism, I think you may be
> wishing for a different world than the one we have.
I agree.
With the currently-common email confirmation scheme ("Click a link in the email I just sent you"), the user is likely to choose an email account that they're already signed into or which is easy to sign into--which is often the user's primary email account. The user could make up a new account or the user could use an account that they never check, but that is often more work.
If I were an RP that really wanted to make sure I could successfully reach somebody by email, I would continue to use the currently-common email confirmation scheme *in addition* to VEP, and/or I would whitelist certain IdPs for VEP-only signup.
With VEP, the user doesn't have to do any extra work to choose an email account that they never open. Further, an account that is rarely/never used is likely to become inaccessible to the user--either because they forgot their password for it, or because the account got garbage collected by the email provider for inactivity. This is especially problematic when a secondary identity authority is being used, because the secondary identity authority may not even be aware that the email address that it is certifying has become unusable.
Cheers,
Brian
Tom Scavo
<mozill...@flamsmark.com> wrote:
>
> The concern with BrowserID is that it conflates email-as-identifier and
> email-as-communication, in a way which flummoxes a class of defenses which
> users have developed to mitigate the practices of a minority of
> service-providers. While I'd agree that having a persistent online
> identifier is valuable for a great many users, email addresses pose specific
> challenges when used this way, and BrowserID has yet to resolve these
> concerns.
Well said, Tom.
Thanks,
Tom
Tom Lowenthal
> The concern with BrowserID is that it conflates email-as-identifier and
>>
> email-as-communication,
>>
>
> No, BrowserID doesn't do that: web sites already do it. We're just helping
> mediate that transaction to make it easier and more secure.
>
> in a way which flummoxes a class of defenses
>> which users have developed to mitigate the practices of a minority of
>> service-providers.
>>
>
> I don't think we flummox existing defenses. How do you figure? You can have
> as many emails as you want in your BrowserID. There are *tons* of
> optimizations we have yet to explore to make it even easier by, say,
> reminding you which email you used the last time you visited the site, or
> integrating with services that provide you with aliases automatically.
>
> Doesn't that make BrowserID an even better way to keep your online personas
> distinct?
>
The problem is that I don't use email aliases because I want to keep
personas distinct, I do so because I want to keep sites' ability to
communicate with me separate. Many different addresses of the form
mynam...@home.whatever are the same persona/identity, but they have
different email addresses. If I have one BrowserID with multiple emails, how
do my interactions on different sites bind together to form a single
identity?
-Tom
Ben Adida
> The problem is that I don't use email aliases because I want to keep
> personas distinct, I do so because I want to keep sites' ability to
> communicate with me separate. Many different addresses of the form
> mynam...@home.whatever are the same persona/identity, but they have
> different email addresses. If I have one BrowserID with multiple emails,
> how do my interactions on different sites bind together to form a single
> identity?
In our current proposal, they don't. We're not trying to solve the
complete identity problem with BrowserID. We think BrowserID will
*help*, but it won't solve everything.
-Ben
Tom Lowenthal
So, here's my understanding of what BrowserID is currently able to do:
- for users, it can effectively replace a password manager and Gravatar at
the same time;
- for users, it'll also remove the need to verify email addresses for each
site (though, if each email site gets their own address, that doesn't help
very much right now);
- for site developers, it makes it somewhat easier to deploy a log-in
system;
- for users who have a supporting browser, it's harder to be phished,
because the browser chrome gets in on the login action;
- it preserves privacy better than OpenID &c because the IdP doesn't have to
be in on every login transaction.
Have I got that right, or am I missing some features?
-Tom
Ben Adida
> So, here's my understanding of what BrowserID is currently able to do:
> - for users, it can effectively replace a password manager and Gravatar
> at the same time;
Yes, in a sense.
> - for users, it'll also remove the need to verify email addresses for
> each site (though, if each email site gets their own address, that
> doesn't help very much right now);
Yes.
> - for site developers, it makes it somewhat easier to deploy a log-in
> system;
From our brief experience so far, I'd say *much* easier, but sure.
> - for users who have a supporting browser, it's harder to be phished,
> because the browser chrome gets in on the login action;
Yes.
> - it preserves privacy better than OpenID &c because the IdP doesn't
> have to be in on every login transaction.
Yes.
> Have I got that right, or am I missing some features?
You've got it right! One more thing: when we start supporting primary
identity providers, then you won't need to do the mailback thing.
Visiting gmail (if gmail becomes an id provider) will automatically drop
a cert in your BrowserID bucket that lets you use that gmail address to
log into other web sites.
-Ben
Pete Rowley
> On 7/19/11 12:54 PM, Tom Lowenthal wrote:
>
> > The problem is that I don't use email aliases because I want to keep
> > personas distinct, I do so because I want to keep sites' ability to
> > communicate with me separate. Many different addresses of the form
> > different email addresses. If I have one BrowserID with multiple emails,
> > how do my interactions on different sites bind together to form a single
> > identity?
>
> In our current proposal, they don't. We're not trying to solve the
> complete identity problem with BrowserID. We think BrowserID will
> *help*, but it won't solve everything.
The problem is, if BrowserID becomes the de-facto standard in its
current form,
it helps to ensure that the primary single-sign on mechanism for the
internet
leaks information by design. There is no going back from that without
breaking
backward compatibility.
It does not have to be that way. BrowserID is so close to not being
that way that
it seems a shame to not just do that. People are just as used to
having a profile
username as an email address. Sit back and think about why you would
never
make that identifier a phone number, and you have the same reasons it
should
not be an email address.
On verified emails and my own world: verified email is the norm right
now for
pretty much one reason - password reset. But BrowserID means the
relying
party never sees a password, nor should care about it. Authentication
should
not be about providing a line of communication through a side channel,
that
ought to be considered a bug - a security bug at that.
Sure, I have no doubt that many relying parties using OpenID continue
to
request this information. There are lots of poorly designed and
information
greedy systems on the internet, but in general that is not designed
into
the protocols they use. As a relying party I would want the
opportunity to
do the right thing by my users. Or in other words, on behalf of
relying parties
I would like to assert their right not to know who their users are or
have any
way to contact them outside of their system unless they choose
otherwise.
Regards
Pete
Jordi Boggiano
> On verified emails and my own world: verified email is the norm right
> now for
> pretty much one reason - password reset. But BrowserID means the
> relying
> party never sees a password, nor should care about it. Authentication
> should
> not be about providing a line of communication through a side channel,
> that
> ought to be considered a bug - a security bug at that.
Couldn't agree more. Please consider Pete's mail. It should be enough
to provide a numeric id of sorts, for RPs that can live with that.
What could be done is adding a set of flags that can be passed to
navigator.id.getVerifiedEmail() - which should be renamed to
getVerifiedUser() or something by the way. Those flags would allow the
RP to specifically prompt the user for his email ("Do you want to let
this site contact you?"), or require one ("This site requires your
email address, do you accept?"). Something like
getVerifiedUser(callback, navigator.id.REQUIRE_EMAIL).
I hope you get the idea, and that the current model can be altered one
way or another.
Cheers,
Jordi
Jordi Boggiano
> now for
> pretty much one reason - password reset. But BrowserID means the
> relying
> party never sees a password, nor should care about it. Authentication
> should
> not be about providing a line of communication through a side channel,
> that
> ought to be considered a bug - a security bug at that.
Couldn't agree more. Please consider Pete's mail. It should be enough
Jordi Boggiano
I'm not sure my message went through, while browsing the archives,
posting through groups.google.com didn't seem to produce any result. See
the quoted bits please.
Cheers
--
Jordi Boggiano
@seldaek - http://nelm.io/jordi
Dan Mills
> Couldn't agree more. Please consider Pete's mail. It should be enough
> to provide a numeric id of sorts, for RPs that can live with that.
> What could be done is adding a set of flags that can be passed to
> navigator.id.getVerifiedEmail() - which should be renamed to
> getVerifiedUser() or something by the way. Those flags would allow the
> RP to specifically prompt the user for his email ("Do you want to let
> this site contact you?"), or require one ("This site requires your
> email address, do you accept?"). Something like
> getVerifiedUser(callback, navigator.id.REQUIRE_EMAIL).
Hi Jordi,
Thanks for the feedback. We care deeply about giving users the tools
to be in control of their identity, and that includes the ability to
use pseudonyms. We think that verified email is quite compatible with
those goals--you can create pseudonyms manually *right now*, and we
can imagine systems for creating them automatically for each site if
so desired.
Also note that the verified email spec doesn't assume email addresses
are actually SMTP routable. Secondary authorities (such as
browserid.org) do require it as that's how they verify you control the
address, but primary authorities can drop certs in your browser for
any address @ that domain, regardless of whether it's a real (smtp
routable) address or not.
Dan
Ben Adida
> It does not have to be that way. BrowserID is so close to not being
> that way that it seems a shame to not just do that.
I want to follow up on this point because I think it shows some
miscommunication.
We *want* a web site to receive an email address for the user when they
log in. That's not an unfortunate side-effect of a separate. That's our
goal. We think this can be quite privacy-preserving in the way Dan Mills
just mentioned. And we also think an identity system that doesn't
provide a message-the-user mechanism is close to useless.
So, what you see as a small change here would, in fact, undo the very
goal we're trying to achieve.
Hopefully Dan's email indicates why we think that's not at odds with
pseudonymity, something we strongly believe in.
-Ben
Francois Marier
> On 7/19/11 2:13 PM, Tom Lowenthal wrote:
> >So, here's my understanding of what BrowserID is currently able to do:
> >- for users, it can effectively replace a password manager and Gravatar
> >at the same time;
>
> Yes, in a sense.
I've tried to find how BrowserID is supposed to "replace Gravatar", but I
haven't been able to find anything in the documentation about it.
As far as I can tell, BrowserID-enabled applications are simply using the
users' email addresses to display avatars using Gravatar. Am I missing
something?
Cheers,
Francois
--
Francois Marier identi.ca/fmarier
http://feeding.cloud.geek.nz twitter.com/fmarier