Possible consideration of hiding email addresses from sites?

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!
0
James
7/16/2011 8:14:45 PM
mozilla.dev.identity 1643 articles. 4 followers. Post Follow

19 Replies
237 Views

Similar Articles

[PageSpeed] 4

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. =20

As a technical user, I frequently do this anyway: give companies a =
custom email, like "comcast@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? =20

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=20

On Jul 16, 2011, at 2:14 PM, James King wrote:

> Hi all,
>=20
> I was just wondering if there was any possible consideration for =
hiding your email from a site you are authenticating to?
>=20
> 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).
>=20
> 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).
>=20
> 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.
>=20
> Anyways, just curious if this might be a possibility.
>=20
> Thanks!
> _______________________________________________
> dev-identity mailing list
> dev-identity@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-identity

0
Lloyd
7/16/2011 8:43:30 PM
On Jul 16, 1:43=A0pm, Lloyd Hilaiel <ll...@hilaiel.com> wrote:
> Hi James,
>
> Pardon my top posting. =A0One thing along these lines that has been talke=
d about is the ability of a primary to provide anonymized emails on a user'=
s behalf. =A0
>
> As a technical user, I frequently do this anyway: give companies a custom=
 email, like "comc...@hilaiel.com". =A0Doing this I have a simple way of au=
diting how companies I do business with use my email address.
>
> The theory at this point in time is that this feature (on-demand anonymiz=
ed email addresses) could be completely implemented by a primary. =A0There =
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? =A0
>


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.
0
Pete
7/18/2011 5:34:22 PM
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-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

On Mon, Jul 18, 2011 at 1:34 PM, Pete Rowley <p.a.rowley@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-identity@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-identity
>
0
Tom
7/18/2011 6:28:48 PM
On 7/18/11 11:28 AM, Tom Lowenthal wrote:
> 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. springfieldbabysitter@emailprovider.example.com.

-Ben
0
Ben
7/19/2011 2:01:40 AM
On 7/18/11 10:34 AM, Pete Rowley wrote:
> 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
0
Ben
7/19/2011 2:09:03 AM
Hi Lloyd,

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=A0pm, Lloyd Hilaiel <ll...@hilaiel.com> wrote:
> Hi James,
>
> Pardon my top posting. =A0One thing along these lines that has been talke=
d about is the ability of a primary to provide anonymized emails on a user'=
s behalf. =A0
>
> As a technical user, I frequently do this anyway: give companies a custom=
 email, like "comc...@hilaiel.com". =A0Doing this I have a simple way of au=
diting how companies I do business with use my email address.
>
> The theory at this point in time is that this feature (on-demand anonymiz=
ed email addresses) could be completely implemented by a primary. =A0There =
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? =A0
>
> Now this is not precisely what you describe: =A0instead of no email endpo=
int being provided, your identity provider is providing an ephemeral endpoi=
nt who's lifetime (and delivery details even?) *you* control. =A0But I feel=
 like it solves similar problems. =A0What do you think?
>
> (at the risk of typing too much, you could even imagine a provider of thi=
s type of service who lets you bring your own VM, and bring your own domain=
 name. =A0So that you become your own primary. =A0The size of the audience =
for such features seems dependent on how well the user experience can be cr=
afted, 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 us=
er 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 t=
o 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 per=
ceived by me).
>
> > Using the browser ID system, it may be possible to 'ensure' that I am n=
ot a spam bot trying to gain access to that third-party site, as I have bee=
n vouched for by the issuing authority -- without necessarily giving that t=
hird-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

0
James
7/19/2011 2:59:30 AM
On Mon, Jul 18, 2011 at 10:01 PM, Ben Adida <ben@adida.net> wrote:

> On 7/18/11 11:28 AM, Tom Lowenthal wrote:
> > 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. springfieldbabysitter@emailprovider.example.com.
>

Users with supporting mail providers -- like Gmail -- often use plus
addressing, as in user+sitename@mailprovider.example.com, to silo mail from
one site (and anyone they share info with). Those with their own domains may
use dedicated addresses like sitename@mail.example.com which get delivered
to a catchall mailbox. Savvy users sometimes use semi-persistent dedicated
addresses through the use of throwaway mail providers like spamgourmet. The
aim of all these schemes is to give each service an unique address so that
mail from them can easily be blocked if it becomes problematic, or if a
service looses, shares, or sells email addresses.

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.

-Tom
0
Tom
7/19/2011 2:17:51 PM
On Tue, Jul 19, 2011 at 10:17 AM, Tom Lowenthal
<mozilla-lists@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
0
Tom
7/19/2011 6:58:13 PM
On 7/19/11 7:17 AM, Tom Lowenthal wrote:
> Users with supporting mail providers -- like Gmail -- often use plus
> addressing, as in user+sitename@mailprovider.example.com
> <mailto:user%2Bsitename@mailprovider.example.com>, to silo mail from one
> site (and anyone they share info with). Those with their own domains may
> use dedicated addresses like sitename@mail.example.com
> <mailto:sitename@mail.example.com> which get delivered to a catchall
> mailbox. Savvy users sometimes use semi-persistent dedicated addresses
> through the use of throwaway mail providers like spamgourmet. The aim of
> all these schemes is to give each service an unique address so that mail
> from them can easily be blocked if it becomes problematic, or if a
> service looses, shares, or sells email addresses.

Right, and these are great examples of how users, from the simplest to 
the more advanced, *already* use various anonymization / 
pseudonymization techniques around email.

We need to do more work to show how we'll make that process even easier 
with BrowserID, but to me this seems like exactly the reason why 
BrowserID and proving email possession is *exactly* what you want.

> 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?

-Ben
0
Ben
7/19/2011 7:21:44 PM
On Tue, Jul 19, 2011 at 3:21 PM, Ben Adida <ben@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+site@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
0
Tom
7/19/2011 7:54:32 PM
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+site@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
0
Ben
7/19/2011 8:49:32 PM
On Tue, Jul 19, 2011 at 4:49 PM, Ben Adida <ben@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
0
Tom
7/19/2011 9:13:16 PM
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.

> - 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

0
Ben
7/20/2011 2:41:53 AM
On Jul 19, 1:49=A0pm, 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 singl=
e
> > 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
0
Pete
7/20/2011 2:30:50 PM
On Jul 20, 4:30=A0pm, 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.

Cheers,
Jordi
0
Jordi
8/5/2011 8:40:44 PM
On Jul 20, 4:30=A0pm, 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.

Cheers,
Jordi
0
Jordi
8/5/2011 8:45:25 PM
On 05.08.2011 22:40, Jordi Boggiano wrote:
> 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.

Cheers

-- 
Jordi Boggiano
@seldaek - http://nelm.io/jordi
0
Jordi
8/5/2011 8:47:18 PM
On Fri, Aug 5, 2011 at 1:45 PM, Jordi Boggiano <j.boggiano@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.

Dan
0
Dan
8/6/2011 11:25:04 PM
On 7/20/11 7:30 AM, Pete Rowley wrote:
> 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
0
Ben
8/7/2011 6:30:38 PM
Reply:

Similar Artilces:

hiding and email address on a web site...Please Help
I got this email from my boss today. I am fairly new at ASP.NET and i am using C#. Can anybody help me out? -- Austin, Please figure out how to put an email address on a website that is not readable by a computer program. I think this is done using a JavaScript program but I am not sure. I need to move the ***** and ****** sites because I am getting a hugh amount of garbage mail from the address being posted. I will also change the email address slightly. -- Also, I am using Dreamweaver to build my C# ASP.NET programs if that helps. Maybe there is a be...

What is the best way to hide email addresses in a web site from SpamBots?
Hi, i have some email addresses in a web site of a client. Can you tell me what are the best ways to somehow hide the email addresses from the SpamBots. Can you give the a list of: 1. What To Do 2. What Not To Do Thanks, Miguel Hello - here is a good article on some of the ways... http://www.netmechanic.com/news/vol4/design_no21.htm good luck take care tony I am sure this will depend on your technical requirements...however I find it best to not display the email address at all. Providing a simple form that allows the user to send a quick e...

using SMTP localhost in the webconfig is it possibale to hide our outgoing email address and change it so that a message appears to have been sent from our members email address rather then what is in
Hi there Can any one help me. I am asking this question for our .net guy who is a little busy at the moment. We have a website which has two online forms which get sent direct but to us using localhost which work fine. We also allow members to create and send their profiles to companies to apply for jobs. The members profile is sent via the webconfig file (code below). <mailSettings> <smtp from="support@ourdomain.co.uk"> <network host="localhost"/> </smtp> </mailSettings>At the top of every profile...

hide email addresses from email after using smtp.send()
hello , I have some kind of subscribe feature , the emails are saved in database so am using a sqldatareader and a loop , inside loop am adding the emails with msg.to.add() , but what is happening that all the emails are being shown ( in the to place) when a subscriber receives an email , but I dont want that , cause the subscriber shall not know email addresses of other subscribers , how to fix this thing ?!? thanks alot place all the recipients on the BCC of the email. this prevents them from seeing the email of other BCC recipients  Mike Banavige~~~~~~~~~~~~Need...

How do I add another email address (Identity?) in the From Address List
I have done this before as I have 5 email addresses and can use any of them to send mail. I've just added a new email address and it's NOT appearing in the from drop down list. How do I add this new Identity??? ...

How do I add another email address (Identity?) in the From Address List #2
I have done this before as I have 5 email addresses and can use any of them to send mail. I've just added a new email address and it's NOT appearing in the from drop down list. How do I add this new Identity??? (Please ignore my last post as chetdude@pacbell.net -- I no longer have that email account) chet_misc@cox.net wrote: > I have done this before as I have 5 email addresses and can use any of > them to send mail. I've just added a new email address and it's NOT > appearing in the from drop down list. How do I add this new > Identity??? > &...

possible to place conditions on outgoing email addresses being added to Collected Addresses?
I find addressbook management to be frustrating in thunderbird, and this mostly comes back to how Thunderbird automatically adds outgoing email addresses to the Collected Addresses list. This in itself is fine and useful, but I wish Thunderbird could exercise discretion (or be set to do so) in how it adds outgoing email addresses. As things stand now, a lot of redundancy develops between address books. What I would like to see: Thunderbird adds outgoing email addresses to Collected Addresses (or whatever other addressbook has been set to receive outgoing addresses) only if the email...

hiding an email address
hi all does anyone know how to hide a email address using vb script hide it from who and us eit for what?...

Inbound distribution list with Internet email address
Hello, we're using GW7SP2. We have quite a few distribution lists assigned Internet email addresses via nicknames which distribute fine to users in our GroupWise system. Now we also want to include the distribution to an email address that is outside of our system. So for instance we have Alerts@mycompany.com going to several people at MYCOMPANY, but we need to include joe@othercompany.com so that any emails received by our GWIA for Alerts@mycompany.com to go the people at MYCOMPANY and Joe. As a test I setup an external user under an external post office and extern...

Hiding an email address
In the corner of my clients master page they want an "Email Us". This was going to be setup like this. <asp:HyperLink ID="HyperLink" runat="server" Font-Size="X-Large" ForeColor="#336600" Text="Email Us" Font-Underline="True" NavigateUrl=mailto:blahblahblah@whatever.com></asp:HyperLink> I was concerned about putting their real email address on the master page as this could be easily stolen by web crawlers. I read about ReCaptCHA mailhide and through how it works. I placed it on the master page to show th...

hiding Email addresses
I need to be able to hide mail addresses so that server can send email but html page replaces @ with # any ideas You mean hide when you mouse over an email address as a link or hide at the server level? BrianBrian"Trust in the Lord and do what is good; dwell in the land and live securely. Take delight in the Lord, and He will give you your heart's desires" (Psalm 37: 3-4). I don't believe you're going to be able to do that - - what I've finally done, is create a form for every location on my web sites that I previously had an email link -David WierMCP/ASPInsiderASPNe...

Hiding Email Addresses
Hello, I sometimes uses sneakemail (http://www.sneakemail.com/) when filling out forms to hide my real email address. This is fine for sites that use a form but how can I hide my email address if the site doesn't use a form and gives an email address to write to? I use Thunderbird if that is any help. Thanks, Chris (Hunt) I use the Temporary Inbox extension in Firefox. It generates a random email address for you to use. the website, http://www.temporaryinbox.com/ also lets you set up temporary email forwarding. Chris (Hunt) wrote: > Hello, > > I som...

hiding email addresses
One of my clients wants to know if it would be possible to make sure any email addrss is hidden from span bots. I thought a good way to do this would be to make a common javascript that would accept a Name and Domain variable and that any module that lists email adresses (Contacts) could use. Something like this perhaps? <script language=javascript type="text/javascript"><!-- var name = "BillyBob"; var domain = "myDomain.com"; document.write('<a href=\"mailto:' + name + '@' + domain + '\">'); document.write(name + &...

Insert Email Address as a Link When Composing and Email Address
I see how to insert links to url's when I composw emails in Mozilla 1.6. I can't figure out how to insert an email address which will allow the recipient the option of composing a message to the inserted address without copying and pasting. Is it possible? Thanks, John John Baum wrote: >I see how to insert links to url's when I composw emails in Mozilla 1.6. I can't figure out how to insert an email address which will allow the recipient the option of composing a message to the inserted address without copying and pasting. Is it possible? > > I thoug...

Web resources about - Possible consideration of hiding email addresses from sites? - mozilla.dev.identity

Antenna height considerations - Wikipedia, the free encyclopedia
At VLF , LF and MF the radio mast or tower is often used directly as an antenna. Its height determines the vertical radiation pattern. Masts ...

Five Key Considerations For Facebook Page Promotions
The holiday season has already begun. Brands and retailers have been hard at work rolling out their holiday campaigns for weeks now, aiming to ...

New comScore Study Shows Facebook Ads Increase Vehicle Consideration, Decrease Competitor Consideration ...
A new comScore Action Lift study initiated by Facebook shows Facebook’s impact on new vehicle consideration.

YouTube - DISNEY INFINITY GAMEPLAY TRAILER: For Your Consideration
Veröffentlicht am 09.06.2013 Now the Disney Infinity E3 2013 Trailer experience of a lifetime is the Disney Infinity E3 2013 Trailer event of ...

Canterbury Bulldogs forward David Klemmer says power and passion needs some consideration
&nbsp;Canterbury enforcer David Klemmer&nbsp;said the NRL needed to take into account the passion that underpins the game when a player such ...

Light rail extension to Russell under consideration
Companies bidding to build and operate Canberra's light rail line will be asked to include costs for a possible extension from the city to Russell, ...

Brumbies captain Stephen Moore says player welfare important consideration with sabbaticals
Australia's most capped hooker Stephen Moore has backed sabbaticals for Wallabies.

Victorian environment report suggests consideration of congestion tax, more buses
Victoria should investigate traffic congestion taxes, overhaul its energy supply and change its approach to planned burns for bushfire prevention ...

Five considerations when choosing a cloud security provider
Security is a leading concern in the cloud environment. Fear of data breaches or outages continue to keep executives up at night.

Russian vodka ban under consideration by Sask. Premier Brad Wall
Saskatchewan Premier Brad Wall is considering a move to pull Russian vodka off the government store shelves.

Resources last updated: 1/2/2016 1:34:10 AM