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.
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).
> 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.
On Jul 16, 1: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?
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.
I agree with James that this is a legitimate user concern. People use all sorts of strategies to mask their email address and avoid spam. BrowserID is based on<http://identity.mozilla.com/post/7616727542/introducing-browserid-a-b...>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
On Mon, Jul 18, 2011 at 1:34 PM, Pete Rowley <p.a.row...@gmail.com> wrote: > On Jul 16, 1: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?
> 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. > _______________________________________________ > dev-identity mailing list > dev-ident...@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-identity
> 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. springfieldbabysit...@emailprovider.example.com.
> 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.
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:
> 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.
Ben Adida wrote: > 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.
> 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.
On Tue, Jul 19, 2011 at 3:21 PM, Ben Adida <b...@adida.net> wrote: > 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 myname+s...@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?
> 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 > myname+s...@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.
On Tue, Jul 19, 2011 at 4:49 PM, Ben Adida <b...@adida.net> wrote: > On 7/19/11 12:54 PM, Tom Lowenthal wrote:
>> 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.
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
> 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.
On Jul 19, 1:49 pm, Ben Adida <b...@adida.net> wrote:
> 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 > > myname+s...@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.
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.
On Jul 20, 4:30 pm, Pete Rowley <p.a.row...@gmail.com> wrote:
> 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.
On Jul 20, 4:30 pm, Pete Rowley <p.a.row...@gmail.com> wrote:
> 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.
> On Jul 20, 4:30 pm, Pete Rowley <p.a.row...@gmail.com> wrote: >> 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.
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.
On Fri, Aug 5, 2011 at 1:45 PM, Jordi Boggiano <j.boggi...@seld.be> wrote: > 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.
> 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.
> 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?
