Identity in the Open Web

hi my name is Devan Bailey I'm from Mozilla I'm gonna be talking a little bit today about identity protocols and fun and stuff like that I'm over here can you guys hear me no okay I'm gonna say right here so my name is Yvonne Bailey I work in our security assurance team at Mozilla and so I've been doing a lot of work over the last year about with identity protocols primarily focused on our new identity protocol called browser ID so we're gonna talk a little bit about the history of identity protocols and why identity and privacy are kind of intertwined and some of the problems with using existing identity protocols online so a little bit of

terminology that'll probably end up repeating a lot during this talk is a relying party a relying party is simply a service or a website that relies on a third party identity provider to generate assertions and say just user who they say they are an identity provider is just the other side of that relationship they provide assertions to somebody else so an example would be anything that consumes a Facebook log on to set up an account would be a relying party anything that and Facebook Twitter Google that offer services to other sites so that they can log in our identity providers so there's a bunch of different identity protocols that people can use in when they're setting up a

website different ways they can interact with services the I'm going to talk about two of the big ones open ID and o'a open ID is pretty convoluted protocol that is implemented and intended to function primarily within the browser so you basically the way that it works is you as a user supply a user through your browser or through whatever application you're using to log into a site a URL or some token that you're a service provider that supplied you with that can be resolved by the application into a URL to be able to authenticate to a site that your identifier will be confused by the relying party in order to establish a session with the I identity Authority

and from there you have the ability to go through a whole bunch of redirects and bounces back and forth in order to establish the fact that you are indeed the user by leveraging an authenticated session on the identity provider eventually you end up back at the relying party and have the ability to enter an authenticated session at which point the identity relying party has the ability to call back to the original identity provider and verify that assertion so it's there's a lot more to open ID than that but I could also spend the entire talk talking about how open ID works and that's not the point of today so some of the concerns about how

open ID works is that even if you initiate a logon with an open ID site if you choose to back out after you're presented with your authentication page your identity provider has been notified that you tried to login so they can build that into your profile they can collect that data aggregate it figure out other stuff and just generally figure out more about what you are doing online in addition to that once you actually commit to using that service provider and establish that identity that that's the fact that you use that assertion will by most open ID Pro and consumers be used to verify that you've actually done that and you get an actual positive confirmation that you're using

the service that's communicated again back to your identity provider it's a bit of an issue because if you have a single monolithic identity provider that works in a lot of countries and is subject to a bunch of different legal jurisdictions anybody who has the ability to force them to hand over information about you now knows what your behavioral profile is online so it's a bit of a concern o auth is a little bit different it's not designed as an identification or an identity protocol it's designed as an authorization protocol so the intention for this protocol was to allow a service to provide tokens to a client so that an authorized user could use a third party

service to perform operations on the primary service so in this case it's it doesn't really matter into the identity provider and relying party role but basically it's a pretty straightforward process you go through an OAuth dance and you've set up access to an application so for example when you go into web page that relies on Twitter you get challenged to log in with Twitter then Twitter will you get redirected to the Twitter site you application then you get bounced back and then you have the ability to from within your application access different Twitter resources using the OAuth token that the Twitter service provided the client there's a couple of different ways you can use a lot the two the two most

common mechanisms for doing it are using three-legged OAuth which is a full walk through the process and it's typically used in a proper web-based client there's another method which is called two-legged OAuth where you basically just go through the first and last step and you treat the whole differentiation between an authorization server and a resource server as being the same step so you just collapse everything you're only doing two of the actual steps and just proceeding with the token that you get that's a really radical oversimplification again OS is one of these huge protocol so you spend a lot of time talking about this so the biggest privacy concern with OAuth is that unlike an identity protocol where

you're just looking to have somebody say this is who I am and oh oh ah token actually lets you say this is what I'm doing and it communicates that between each of the parties the party that you're working with to perform an operation and the party who's actually doing something on your behalf so if you're using a tool from a third party that lets you manage tweets like an auto tweeter yes

yes um so the digging into the yeah digging into a little bit more about oh uh there's a couple of different versions with OAuth and a watch 2.0 and in order to have a lot be secure you asked for especially for a lot 2.0 whether or not using storm crypto you do have to keep it over an SSL session a lot neither of those two spiels I just gave about OAuth they're open ideas anywhere near enough to make decisions about using those two protocols they're really worth reading a lot about so basically there's no way to if you're using that an auto tweet program to update your Twitter stream then you don't have there's no way to isolate the

fact that you're using that service and you have a relationship with that service from the relationship that you have with Twitter there's no way to break that communication so some of the big character that what the most important common characteristic of these two protocols is that when you actually use them you're leaking information about that relationship so every time you communicate with the third party details are being shared and that is all information that can be either used internally by the organization to increase the amount of knowledge they have about you or given to third parties based on their privacy policies or contractual obligations or given to the government whichever government happens to ask for it and has jurisdiction over

that data so it pretty significant privacy impact with a lot of people don't really consider when they're combining services so that's basically the situation everybody himself in so I want to talk a little bit about three of the different major service providers that offer these services so I'm gonna spend a few minutes talking about Twitter Facebook and Google they all have some different characteristics about what they do and each of them has different privacy impacts depending on how users might use their services so starting with Twitter there's actually two different ways at consuming a service that consumes Twitter can function they can use OAuth which is I just talked about this a little straightforward protocol or they can use

their own kind of half-baked twitter solution for called exile where instead of using OAuth so that you don't have to share your credential with consuming service you share your credential with a consuming service and they give you an OAuth token anyway so basically instead of just authorizing an application to act on your behalf you give them the information they need to actually access your Twitter account and they can according to the rules of getting access to X auth you're not supposed to do this but they can basically do anything with your credential that they want to so it's the only positive thing about this is that you can't just go and directly sign up for an X auth token or xx off access

from Twitter you actually have to go through an application process and they vet those applications to what degree I'm not sure but it's not it's not even their recommended approach they prefer people to use a lot one interesting aspect about Twitter is that their permission model is really simple they don't give you access if you have sorry if you have an OAuth token you don't have access to any of that users actual data only their Twitter streams now that said those Twitter streams are really the information most people are interested in anyway there's only three different permission levels read-only gives you the ability to read the entire Twitter stream which is public unless somebody's Twitter stream is marked

private anyway then you have readwrite which is the ability to both read and tweet from on behalf of that user and the third one which was implemented after much consideration from users was the segregation between the ability to read write public tweets and the ability to send and receive send and read direct messages as well the it's an interesting distinction that they block direct messages in X off but you have access to do pretty much anything you want to anyway so it's arbitrary but that's the design they went with so the big area of concern around Twitter is that when you attend Takai twith twitter it's not it's not an actual identification it's actually an authorization you know once

you give Twitter that authorization unless you go back and explicitly revoke it that can do anything they want whether or not you're there so if they've got that auth token stored on their server they could do stuff in the background and do whatever they want it's not really just saying this is this user and let them do stuff also if you have a private Twitter stream and you just want to log into a site so you can look into that look at the service or you want to for for example there's a new site in Canada that gives you the option to log in via Twitter if you just want to read an article all of a sudden you're giving

that news that new site the ability to read your private tweets Twitter stream and finally it's I find it very interesting and I haven't found any rationale from anybody at Twitter and there's been a little bit of discussion within the team at Mozilla about this but we haven't figured it out just yet the minimum access that Twitter gives to people is read-only but there's no right only permission so if I want to use a retweet or app why do I have to give them access to anything why can't I just say you're allowed to tweet so it would be interesting to see something like that but there's no finer control than that the advantage is that as a service

Twitter doesn't really have a whole lot more that they offer other than the ability to send and review tweets so they have some more marketing oriented stuff but for the average user that doesn't come into play so while they can aggregate data and build a social graph based on who you follow who you're interacting with stuff like that it's not to the same degree as Facebook or Google where you're dumping basically all of your information into these gigantic repositories so I'm actually a big fan of the low levels of permissions that they have and the fact that you don't get the ability to configure any of the user settings via the API so I think everybody knows whom about to talk

to you now and talk about now they I before I start talking about this none of these companies are companies that I actually have a problem with I use all of their services for pretty much everything I use Google Docs I use Gmail everybody in my family does I always recommend their services that said people shouldn't use services like that unless they're actually aware and understand what the privacy implications are so with that aside I'm going to kind of jump in and talk a little bit about Google Google is it very interesting because they're very powerful and they're very flexible they want everybody to use their stuff and they're very open about it so they support

everything you can use OAuth you can use OAuth 1.0 which is an older version that uses strong crypto to protect things but with the advantages you don't have to eat in theory you don't have to use SSL but you should anyway because the tokens can be copied and used somewhere else and then they support a hybrid model where they use open ID for Ana to initiate the authentication process so you log in with your Google account and then when you're using a third party site then they can step up from that open ID authorization to get a sorry at Open ID identification to get an OAuth token and they still have to go through the authorization dance where they

present a dialog that says do you want to give Google access to this stuff that from there they can go in and start performing actions on behalf of a user and then optionally if you don't want to get any of that stuff and have access to a person's services that Google provides you can simply use open ID and just use them as the ability to log in to a site an example of how that how open ID is used there is if you anybody Stack Exchange or Stack Overflow they they're one of the open ID providers that's built right into that platform the key issue that I have from a privacy concern here is that when you give Google access

or something when you give a third party service access to your Google account you're presented with a dialog that says this is what the application can do with your account the dialog doesn't necessarily give the user a full profile of how other services are interacting with that which of the more than forty different API endpoints that that application may be interacting with other than the one that the specific user has specifically authorized and it doesn't give an easy way to view all of the different interactions that that user has with other components so if you have a gmail account and you're using something that for whatever reason has an OAuth token for Gmail and then you're

using Google+ and you then they have it the ability to see both of those they can see a much more complete version of your social graph than they'd be able to if they only had access to one or the other the other challenge is that each of those different API endpoints has radically different permissions and systems and capabilities over what kind of data that that you have access to through them so if you have an app engine account that has an eight that you can make API calls to do things then you could have an application that's actually creating stuff on your app engine account based on information that's in your email or whatever the

case may be it all depends on what permissions a user gives and there's no easy way for a user at any at the point in time of authorization to simply step up and see what level of access a provider has yes but in in a lot of different ways Google has done a really good job of dumbing down technology and making it accessible to people what they haven't been so good at is giving a full view of what people can do and that's not to say that Google isn't trying like they I mean the big area of concern that I have is the way that Google looks at stuff is kind of set up by their leaders I mean everybody

likes to say Oh Google's gonna get better at privacy because you know Eric spent and all the horrible things he used to say about privacy or he's not running the show completely anymore so the problem is Eric Schmidt left and now we have this which shows up on every single Google service these days that's because Google is collapsing all of your disparate user profiles and user data into a single and a single pool of data that they're going to use to collect metrics and collect information and it's not a negotiable decision there's no way you can opt out of that collapsing of all of that data you there officials Google Google's official response is take it or leave it

so and the reality is for most people it's actually okay if they take it unless they're doing something that you know you don't want other people to know about so and the last one is Facebook and Facebook gets a lot of heat about privacy and rightly so they have access to different aspects and different and and much more visibility into the interpersonal relationships a lot of people have from an authentication perspective they make heavy use of OAuth to virtually every API that facebook offers is delivered through OAuth and has a fairly comprehensive permission set so the issue that I have here is with Facebook is primarily the same one as with Twitter it's not an actual login

you're creating a relationship in the background one thing that's really interesting is that Facebook has the ability through there since that too I've lost a page here sorry I'm not sure what happened there but the permission set for Facebook it gives you a lot more granular control and of all of the api that i've looked at from any of these three providers it's the only one that gives a user any degree of control beyond accept or deny so with the facebook permission model there are a set of user and friends permissions that an app or that you can grant when you combined a service so you have the ability to request any of these permissions when you're configuring an

app but it's actually really easy to set up so the there's a whole pile of different permissions that are all related to the user's profile on Facebook it gives you a bunch of different information and then they have a bunch of extended permissions and these ones are really interesting because the user can opt out of these permissions and the app can still function it will still allow them to proceed and go forward and configure and start using the app so it's kind of an interesting approach and something that I'd like to see a lot more of in different permission models would be really interesting to see something like this say on my mobile phone where I can

say yes I want to use this app but I don't want to give an actual GPS data or stuff like that so that's one thing that's really cool about the Facebook API that said they have a lot of the same problems that other identity providers have in that you know they're all of these different services are building these huge catalogues of data and there's not really much we can do about that once we most of these services are things that we have started to use or use heavily because of the fact that you know we're active in the tech community we want to be we want to be on top of things learn about how all

of the new things that are going on or we have family that's spread out all over the world we need to talk to people stuff like that or we run a small business and it just doesn't make sense to run our own infrastructure so we run everything on Google Apps so I mean there's all of these different very very valid valid reasons for using these different services but unfortunately there doesn't seem to be much that we can do about giving up our privacy and doing that so one of the big challenges here too is the the recommended usage for each of these is they want to see as much data from their users as possible

so they recommend that when you apply this service to your the service that you're offering to your end-users that you include these like buttons and tweet buttons and share but share buttons or whatever the case may be on every single page in some way or another if you have a login button it should be on every single page and then each time that gets loaded if it's loaded from facebook site Facebook gets to see more about how their users whether they're logged in or not and based on the information that they're collecting are actually interacting with different sites on the web not just Facebook and not just the people they interact with directly within Facebook so one of the things

that I wanted to take a look at here was we have at Mozilla some different projects we have a privacy policy that says we're not allowed to do this we don't post links to social media sites directly within our page if you come to one of our websites it shouldn't actually just leak to Twitter or Facebook that you were on our page just because we want you to have the ability to do stuff so there's a couple of different ways that you can do this so we have set up some of our pages and we're moving towards getting it available on all of them so that if you go to click on like something instead of

taking you directly to Facebook why didn't sorry the like thing is internal to this site to share it but unless the one I was looking for so if you choose to share it on Twitter it hasn't actually communicated with Twitter it's not loading in a Twitter button it's at it won't do that until I actually explicitly have that user grant that I want to do that and then it'll take me to the Twitter page same thing for Facebook and you're just going to see login fronts because this is a dummy profile that doesn't actually have anything set up in it but once you once you've actually given that user intent that I want to communicate with this

service we don't give away any information to those other service providers so we have been working on a way to kind of generalize it and it's not that original of an idea I mean there's some guys from hives that did a bunch of work about this so there's a bunch they have a jQuery plugin that handles a lot of this so you have a to click interface when you click on that Facebook icon it'll load the Facebook icon and add it to the Dom at that point only after you've signaled intent to share that data with that third party so there's a bunch of different ways that you can accomplish this but there's no real single

generally acceptable way to do this via a library and to have services that enable the other social media things like some marketing come teams want to have things like tweet button that shows how many times that thing has been tweeted or how many times it's been shared stuff like that and pull that data through the API so we're kind of trying to figure out and solve that problem so that we can be compatible with our marketing team without tracking and leaking our users data all over the place so kind of get back into the mainstream of the presentation Lisa oh shoot I forgot at the beginning of the presentation I've forgot to tweet the slides this at the end of the

presentation I'll go through so if you're walking watching and you can't see the slides just wait a couple of minutes and you'll see them the so this link will be up there if you want to track the work that we're doing around improving privacy of sharing and stuff like that that's the bug number in Bugzilla so you can go there and take a look that'll be online on my Twitter feed after so one of the other things that we're trying to work on at Mozilla is overall we want to improve privacy and we want to allow people to do stuff on different websites and different services without leaking information about what they're doing so that we've

done a lot of work in the identity space and all of that work has kind of culminated in browser ID now there's been a little bit of press because it was announced that we're rebranding browser ID as Mozilla persona but the underlying technology is still called browser ID so I'll talk a little bit about that and I'll show some links to the persona stuff and talk maybe talk to some more about the identity other identity stuff that we're working on so a little bit more terminology because I'm gonna show you another diagram and this one I will talk about a little bit more because it's new and a lot of people don't have experience with it we

in in addition to the identity authorities that are common to other identity protocols we have the concept of a primary identity Authority which is the actual identity provider so it's Google or Facebook or some other provider that actually maintains a user profile and all these sorts of things the second one is a secondary identity Authority and this is an identity Authority that doesn't actually deliver an online profile but it has confirmed that you are the owner of an online profile and the way that we do that in the context of a browser ID is to use something called verified email protocol which was designed by a couple of our guys from Mozilla and our identity team to provide

a concrete mechanism by which you can use an email check to confirm that somebody actually owns an identity and there's nothing groundbreaking about it it's just a formalization of the workflow that everybody's already familiar with when you go to a site you sign up you get an email back it says hey you own that email so you must be who you claim to be that's all it is but it's a little bit more formal than that and there's explanations of why we made the decisions and all that bit and we also have the context the additional term term of an implementation provider now an implementation provider is the engine that actually provides the work that browser ID does in order to

identify a user because we've decoupled the assertion generation process from the identification process of a user so to explain that a little bit more when you log in with a browser ID page you click on that sign-in button and it loads the identity it caught makes a call into the Navigator ID dot get verified email API which will trigger a series of calls that will load in content and get the ability to talk to an identity provider that will allow you to select which identity you're going to use and present a group of different identities so that you can select which identity you want to use on a particular site and I'll demonstrate that in just a

minute all right so the way that this works though is the implementation provider instead of talking bouncing the the user agent back and forth between a relying party and an identity provider it actually collects a little bit of information from the identity provider verifies that the user has authenticated and has the right to act on behalf of that account gets an assertion uses that to actually build an authorization or authentication bundle that will then get transmitted back to the relying party without using or without building an actual connection between them so there's no refer that gets shared there's no leakage about who's using what it's just the identity provider knows that hey I was asked to

verify that this person is going to do something online and they are who they say they are and then they pass that back to the browser the browser handles a little bit more work and then sends an assertion and says to the relying party here you go this is an identity you can use it and the relying party has a couple of options on how they can verify that the first one is that they can go from they can take that token and communicate back with the original identity provider and get a public key and then they can verify that the identity assertion was generated by the provider and that way they can say okay

my Google knows that somebody from that using a Google identifier has logged in to this site from the site I'm going to show you in a minute it's called my favorite here it's just a demo site so the they know that you logged into that service or that somebody from that for my favorite beer has logged in but they don't know which user and the traffic analysis argument kind of falls apart because when my favorite beer grabs that certificate they can cache it and then they can use it for future checks so they in a poorly designed application the first user or the first user after a key update might get leaked through some analysis but a properly designed

application will pull that key and store it on the production server before that actually happens so once they verify that token its authenticated if consuming service doesn't want to go through that complexity and they're willing to disclose that they're willing to leak a little bit of privacy information about their user then they can actually bundle that assertion up and send it off to the verifier to check that still doesn't leak the users identifier but the way that that check is done could potentially do that we don't have any control about that because that is server executed code on the part of the verifier so in a nutshell that's how the browser ID protocol works and the way that we're

going to demonstrate it it's called my favorite beer I'm always terrified about doing actual live presentations demos during a presentation so you can go in and you can click sign in and it takes me to browser ID and I've never used it before so I'm not actually set up with anything

so if I what I'm gonna do here is demonstrate that you it's not actually using a profile on browser ID org to generate that token I'm going to use a second service that implements a primary identity Authority called ID meat meat and it is a service that we have stood up to demonstrate to Google and Facebook and all of these other identity providers that you can actually do this and it works and you can protect user privacy while still allowing them to log in as a user so this site just generates a dummy email address and it'll verify it'll grant an assertion and allow somebody to login so if I set up demo user

remember the password and now I can go into here select to sign in which is already open in another window

Oh

so it gives you exactly give and the intention is so the way let me backtrack a couple of things there so you still end up with and I defied identifier for a user so they can still track that and build profile data based on on that but the identity provider only knows that a user signed in from their service the without actually knowing specifically that it was demo user because that assertion never ends up going to ID me t me only the the identification token that was generated that was passed back to the client is trackable by the identity Authority and I'm not going to get too much into the mechanics of this protocol but if you I'll retweet it

after the presentation but we did a public security review presentation back in November about how this all works there's tons of presentations by the people who have done this that all this stuff has been developed in public the source code for everything like most of what we do at Mozilla pretty much everything is available on one of our various repos so if you can't find information if you have questions about this feel free to send me an email after the factor or even track me down and come and talk to me after the presentation but basically the whole design of this protocol is to decouple the actual authentication process or sorry identification process from the

primary identity authorities author authentication process so you don't have that leak on use problem for the strictly for the purpose of identifying a user I don't know that it'll ever be possible to come up with a similar solution for authorization but at least in this case we're dealing with one aspect of the problem so the basically the some things that I want to talk about with in relation to this is that this isn't something that's a theoretical project it's not something that we've been talking about and you know this is something that's really neat that we can do this is an actual available running service it's being 10 over 10,000 relying parties that have been configured and set up to use this

now in the context of the internet that's actually a really tiny number it doesn't really matter how many until but we in we need to get some of the major identity providers on board but you know this is an option it's viable and the way that it's working currently right now is not the way that we want it to work right now it gets loaded via JavaScript so that when you my favorite beer actually loads some code from browser ID org when it loads that code it implements what's called a polyfill which is basically a dynamically loaded replacement for an API that should be in place in the browser and then that that API can be

used very soon this is going to be implemented within Firefox so the browser ID org component won't even be in place and we're also moving forward with testing this directly for ourselves as an organization because we're in the process of switching over so that we can have the capability to run all of our internal services that use Mozilla comm Mozilla org accounts to use this protocol it's something that we have a lot of faith in and we've done a lot of really hard work to make sure it's secure and so I mean this is a really powerful way to improve the privacy of any service that using federated identities the really cool thing is that that IDM site if you go

and download the source code for it it's basically a blueprint for how to set up a primary identity Authority this very clearly documented protocol for how that all works basically involves exposing some well-known URLs that publish an API and the browser ID inflamation implementation provider will query an identity to find out whether or not it has that information available before it tries to fall back to browser IDs org in a perfect world the functionality that we provide as a secondary implementation provider would go away so we wouldn't be an identity that kind of caps off the whole browser ID bit the advantage that you have from a privacy perspective with that protocol is that you start moving in the

direction of decoupling the behavior that the user has from the ability to authenticate users across different services so it provides a basic step forward to improve the security and improve the identity and privacy of users all over the world just by adopting a single new protocol for that purpose and it's only the beginning of the efforts that we're starting to put into place in identity most as I mentioned earlier on Mozilla browser ideas being rebranded as as Mozilla persona which is a collection of all of our identity related efforts we've got a bunch of other things that we're going to be coming out with fairly soon to show that it's possible to have strong privacy while having a fully

connected world to support doing mashups to be able to share different services online and have users have a single sign-on without building all that entire graph data that depending on which part of the world you live in can be a very serious risk to your own personal safety so it got cut off on my screen so the the last bit is you know we have a really cool new tool that was announced at one of the Ted taught a TED talk today called collusion I'll put the website up here and what this tool does is it allows you to take a look at how the different websites are using interact with each other and share data based on tracking

cookies and fun stuff like that it's it's an add-on for Firefox and it's it's pretty cool so does anybody have any questions yeah

yeah this is not a replacement in any way for OAuth we don't right now I haven't done any of the research and I don't I'm sure somebody else is probably working on it in their head at Mozilla cuz that's what they like to do there but we have I'm not sure what you could do to move away from something like Olaf when you're talking about combining services and performing operations on behalf of a user you have an implicit information leakage it's just a fundamental problem in access control models so as far as it goes I mean this is purely an identity protocol

yep I just got to actually get it i reused the window hey go somebody else had had a question yeah absolutely we have it we have a bunch of different servers and services that are using it so I I can't access from this computer because I don't have everything set up properly to pull up the list but we had like I said there's over 10,000 sites that are using it if you log in to our developer site it uses browser ID to sign in if you log in to am oh and you're not and if you don't have a privileged account if you're just a regular user it prompts you to use browser ID this is not something that's

not theoretical this is actually fully fully in production all of the codes that we're running on our production servers publicly available you can take a look at everything that we're doing from this perspective yep

so I can you were people I'm having trouble hearing you

okay so the the way that browser ID works is its intended around the idea of the email address as the identifier that doesn't necessarily mean that you have a that that the email address is the key to authentication one experiment that we've kind of been tossing around and this is just me and a couple of other guys at Mozilla it's not an official thing but we've been kind of tossing around the idea of creating a browser ID identity Authority that is backed by a public key server so in order to log in to this identity Authority or in order to leverage this identity authority you have to actually be able to sign a chunk of data that we present you and verify

that you own the key so it mean as far as actually implementing anything beyond that you'd have to take a look at some of the compatibility issues it's an interesting question I haven't really thought too much about how to kind of bridge the gap but you do have to have a support for browser ID the well-known domains or the well-known URLs on the domain or you have to use a secondary identity Authority not very well give it a chance though ya know the big issue is that it is running in in a regular client context in Firefox so if you have anything that's blocking script it breaks and of course as I mentioned in the review back in November if we allow

a cross-site scripting vulnerability to exist on this site it basically pones the entire identity process so this is why I said this is the the short-term objective right now is to actually get this as a first class component of Firefox built into the browser and we hope that the other browsers will follow suit because it makes it a actual proper standard yes sorry I saw him first though we'll come right back to you

sorry this is the question so I'm I'm actually having a bit of difficulty hearing because I can hear the traffic behind me better than I can hear you guys so the question was about is this generating more passwords less passwords yes this is the whole goal is the whole goal of federated identity is to take multiple user accounts out of the hands of users so they don't have to remember a different password for every single site so the goal here is to establish an easy to use easy to implement standard it's actually some of the feedback that some of the other developers have gotten is that it takes minutes for a new site to set up browser ID you don't have to

go through any enrollment process with browser IDs or servers you can just download the code we have a components for WordPress for Django this Ruby components for it so you can literally just merge it in get it running and you're done it's really easy to adopt so you had he had a question first he was he had to signed up before oh

so check this out so if I go in and I sign in and this is a feature that will be preserved when we make this a first-class browser feature as well if I create demo and user two because I want to have a separate identity and sign in and then I pop back over to

lockout sign back in I want to use a different email address

so now it's gonna sign me in so that's not the interesting part the fact that I changed identities is no big deal what's interesting is that the way that the browser ID polyfill works is that it comes back and it says hey these are the identities he's used before which one do you want to use to log into this site and this is going to be a compare this is feature comparable to how we plan to implement this in the browser so when you go to a browser ID enabled site or a Mozilla persona enabled site you will select the identity that you want to use so if Twitter support system Facebook support system Google supports this and

Yahoo supports this you'll see a catalogue of all of your different accounts and Clickbank and you're done

yes yes there's a couple of different ways Google really didn't like do-not-track when it was released but they just made a big announcement about that there's a lot it's all about market pressure right shame doesn't work well I mean it works well but it's not a it's not a positive interaction right we want Google and Twitter and puttan yeah if we get it adopted in browsers if we get people starting to make heavy use of it the vendors will come they'll support it because ultimately if the if people are leaving their services because they don't have the support or because they're concerned about privacy then their value that social graph starts to diminish hang on

they implemented do-not-track okay so you're asking me a question that's getting more into the overall mission of Mozilla and from that I'm gonna kind of fall back the reason why we're concerned about this is because the only thing that Mozilla cares about is what's good for the users and good for the web that's it like we have our like poll principle thing that guides like literally I've seen some really cool business decisions made and I come from a finance and government background where like oh no we're gonna do this and we're not gonna fix that because it's too expensive or blah blah blah I've seen really cool decisions where Mozilla like we've done a big amount of work and

said hey this isn't good for our users so let's stop doing that and they fix it so it's pretty cool our focus is on making things better for the user and we believe this makes things better for the user

there so there is some work underway there we have some that's a question that we have to take offline it is currently the current implementation is tied to the browser but much in the same way that the original implementations of open ID and OAuth were intended to be used from a browser as well people figured out the right ways to do it and you just in we hope to get better than hey implement a browser in your tool but I mean there's some discussion about that and we do actually have people working on that we had there is an an LDAP extension for browser to support browser ID so if you if you want to

learn some more about that feel free to drop me an email I think I'm gonna run out of time right away but I'm gonna be around and stuff so if oh one last thing we also have lots of really cool open jobs so if you're not satisfied with where you're working come talk to me figure out the right people for you to talk to it most a letter to get something new going for you so with that thanks for your time [Applause]