[23:27] fern: for 413, i just added another comment. [23:28] dsample: cool, I'll check it out [23:28] atul: fern: cool! you should totally blog about ubiq's community, that would be awesome [23:28] fern: doing it right now [23:28] atul: i will link to it from my blog if you do. [23:28] atul: nice! [23:28] fern: great. [23:28] fern: im not a good blogger, but ill try [23:28] dsample: ok, you say you can't see the HTTPRealm? [23:29] fern: nops [23:29] fern: i added a screenshot [23:29] dsample: 4th line down on that screenshot [23:29] dsample: the (Twitter API) [23:29] fern: oh. yep. [23:29] fern: [23:29] fern: didnt realized that [23:29] dsample: what you can't see is the formSubmitURL [23:30] dsample: (as I explained in my comment) [23:30] fern: yes [23:30] fern: that, i saw [23:30] fern: a thing is. i never even looked at that window before today [23:30] dsample: if you have a go with my Ubiquity command you'll see what I mean [23:30] dsample: ah, ok [23:30] fern: i think most of the users never do. [23:31] dsample: I do, all the time, checking passwords for sites I hardly ever use and Firefox hasn't auto-filled for me [23:32] fern: to be honest, i didnt even knew it existed. i thought that to see those passwords you had to go throught those strange windows like about:config [23:32] dsample: if you see the first line in your screenshot, that's a ubiquity login, but what command is it for??? that's the point I'm making [23:32] fern: yes [23:33] fern: i saw it... [23:33] fern: as i said before, i just used formSubmit url cause the tutorial didnt used it. [23:33] fern: didnt used the httpReaml [23:33] fern: *httpReaml [23:33] fern: *httpRealm [23:34] dsample: I would have liked it to be ubiquity:. [23:34] dsample: or ubiquity: with httprealm of whatever the commands wants [23:34] fern: i was thinking about ubiquity:commandname [23:34] fern: its easier, cause all the verb creator have to do is pass his verb name [23:35] dsample: httpRealm is used in HTTP Basic authentication, the pop-up login you get for normal htaccess login pages [23:35] fern: yes, i know. [23:35] fern: i had to use it to login w ubiquity on a rails app [23:38] dsample: if you just have ubiquity:commandname without any other 'name' then it wouldn't be possible for a command with multiple logins (eg. mine) to use it [23:38] fern: umm.. [23:38] dsample: since I need to save a password for delicious and ma.gnolia [23:39] fern: you're right. but, asking for the dev to add another thing name to a thing is more error prone.. [23:40] dsample: which is where the httprealm would come in, so the command name is the main URL, then the descriptive name that the command wants to use would go in the brackets [23:40] fern: and, you can pass anything as the verb name. like "myverb.delicious" [23:40] dsample: not really, if they leave it null then it would just not use it, you don't HAVE to use it I don't think [23:40] dsample: true, but what if there was some way to 'detect' the verb? [23:40] dsample: then it would be more secure [23:41] fern: i dont think thats possible right now... [23:41] fern: cause it would have to introspect into the callers object... and, no, i don't think so... [23:41] dsample: because currently, with your suggestion, within my command I could use retreivePassword('anyotherverb') [23:41] fern: yes. unfortunately, yes. [23:41] dsample: it's quite a big security risk [23:42] fern: but, using the password manager is a security risk [23:42] dsample: oh? [23:42] dsample: how so? [23:42] fern: any ff extension can just get all your password and email it to anyone [23:42] dsample: at least if you have 'master password' enabled it all gets encrypted [23:42] fern: and if you don't? [23:43] dsample: hmmm, there's no protection from doing that? [23:43] fern: well, im doing that right now. im getting my own delicious password from the password manager. [23:43] dsample: well, if you don't use master password (I don't either) it saves it all in plain text, just like the prefs file [23:43] fern: i could email it to you, for example [23:43] dsample: hmmm [23:44] fern: as i said before, password manager is a security risk. [23:45] dsample: hmmm [23:46] dsample: has anyone attempted to look at this in the past? [23:46] fern: i.e. ? [23:46] dsample: I noticed that the nsPasswordManager of whatever stuff said it hadn't been touched since 2001, is that true? [23:46] Unfocused: i see being able to use retreivePassword('anyotherverb') as a GOOD thing - users shouldn't be asked to enter their login info more than once for the same service, if two commands use the same service [23:46] fern: yes. [23:47] fern: Unfocused: that's true. [23:47] davida left the chat room. (Quit: davida) [23:47] Unfocused: and actually, most cases the login info should be accosated with a service, rather than any specific commaqnd [23:47] dsample: Unfocused: true, but then the 'verb' shouldn't be the verb, it should be the service [23:47] dsample: and password manager should be saving 'service' passwords rather than site passwords [23:47] fern: like, delicious or jaiku [23:47] Unfocused: i have a draft blog post on this topic, actually - i should get around to finishing it [23:48] fern: we can start that, but how? [23:48] dsample: then it could use the same password for the http, https sites as well as any extension [23:48] fern: that == save service passwords. [23:49] dsample: do you think we could create a parallel to Password Manager, maybe a Service Acount Manager? [23:49] fern: well, we can use the password manager infrastructure to do that. [23:50] • Unfocused disapears again... real life to deal with [23:50] dsample: but let's face it, the UI sucks for that kind of use [23:50] fern: yes [23:50] fern: for sure [23:50] dsample: at least if we were to do it properly [23:50] fern: but we can use it for now.. [23:50] dsample: I don't think it would be hard to create an addon that replaced password manager with another database [23:51] fern: ummm.. [23:51] fern: use a sqlite database with cryptographed passwords. [23:51] dsample: we 'could' use it for now, but then how would be integrate for example the 'delicious' password so that it auto-filled for http as well as https for example? [23:52] dsample: (at the moment they would be stored as 2 passwords) [23:52] fern: two urls. [23:52] Unfocused left the chat room. (Quit: ) [23:52] fern: but its ugly as hell [23:53] dsample: so we'd need to make something to add every combination of a service's URL and save them all? [23:53] fern: urgj [23:53] dsample: exactly [23:53] fern: that's really ugly. [23:53] fern: imagine? ftp, http, https [23:53] dsample: which is why I'm thinking it would actually be as easy, and MUCH nicer to the user if we just replaced the password manager properly [23:54] fern: but that's not easy [23:54] dsample: yeah, then extensions have to find the right one for their use, etc. [23:54] dsample: not easy, but we should be thinking about the User [23:54] fern: yes.. [23:54] dsample: if we stop thinking of the user then we're building IE [23:54] fern: lol [23:55] fern: but then, the security issue [23:55] fern: would you use an extension that replaced the password manager? [23:56] dsample: as long as it came from 'mozilla' or an organisation that was well known for being nice, then use [23:56] dsample: yes [23:56] ubiquitron: ubiquity-firefox: Added a temporary workaround so that Ubiquity running on FF 3.0 doesn't die when it attempts to load the nsUbiquity XPCOM binary component that was compiled for FF 3.1/Gecko 1.9.1. [23:56] dsample: eg. I'm using Password Safe on my windows machine to save all my work passwords [23:56] fern: i really dont do that [23:57] fern: in fact, i really dont like to save passwords on any other place than my head [23:57] dsample: it's open source, and all the security people say it's safe [23:57] fern: yes, but its the same as saving your bank account pin number on a paper inside your wallet. [23:58] dsample: [23:58] fern: i would never do that. [23:58] fern: but some people really do [23:59] dsample: but then saving your passwords anywhere has that same issue [23:59] fern: yes [23:59] fern: for sure [23:59] • dsample points to the 'show passwords' button on the firefox password manager [23:59] fern: yes! [23:59] fern: anyone that looks at it can see my twitter password, for example [00:00] dsample: which is why we need a new password manager [00:00] dsample: one with security built around it [00:00] fern: bruce schneier has some essays about passwords. [00:00] fern: trying to find those [00:00] dsample: ah yes, that's the guy that's build Password Safe [00:00] fern: lol [00:01] fern: he's good. but even he said that you should save passwords on your mind. [00:01] fern: and never on a post-it on your monitor [00:02] dsample: My opinion would be that the password manager should be an encrypted 'box' of it's own, and anything that wants to use it should have to authenticate. Maybe using OAuth [00:02] fern: yes [00:02] fern: password managers SHOULD have an obligatory password. [00:03] fern: i never set mine. ever (im always forgetting) [00:03] dsample: So the extension's API Key would be used to work out if it's a genuine extension and to provide the user with details about it so they can make an informed decision [00:03] fern: yes [00:03] fern: like a security certificate [00:04] dsample: yes, but the problem with security certificates is that they're not free [00:04] fern: yes [00:04] fern: but for us, a security certificate would be a "mozilla certificate" [00:04] fern: or a community certificate. [00:04] dsample: with something like the addons.mozilla.org publishing process it could automatically check within the code for accesses to the password manager and make sure it's identifying itself properly [00:05] fern: yes [00:08] dsample: so... is the task now to completely re-engineer the password manager? [00:08] fern: lol [00:08] fern: well, the idea is to improve it. [00:09] fern: we can blog about it and them, maybe, submit these ideas to firefox.. [00:09] dsample: ok, sounds like a first step [00:09] fern: yes. [00:10] dsample: I think I might post the transcript of this chat so people can follow along [00:10] fern: yes. [00:10] fern: good idea. [00:11] ubiquitron: ubiquity-firefox: merged || took off a debug statement [00:13] dsample: I'm trying to sketch out an architecture [00:14] fern: great. [00:18] dsample: hmmm, now I'm sketching I'm wondering... how would we define a 'service' without requiring every site developer to provide some sort of mapping to their different access-points [00:19] fern: requiring some kind of metadata would be not good [00:19] dsample: ie. how would we be sure that https://delicious.com should actually use the same password as http:delicious.com [00:19] fern: yes.. [00:20] dsample: unless we require the addon developers to do that part of the work [00:20] fern: umm. [00:20] fern: how? [00:20] dsample: or... would we need to create a new community site for linking and 'configuring' the 'service manager'? [00:21] fern: that would not be ideal [00:22] dsample: perhaps if it's flexible enough it could save passwords for sites while they're 'orphans' but when they are included in an established 'service' through the site then it changes from a site to a service and merges any of the passwords they had saved for any of the access-points into one unified account detail? [00:22] fern: good point. really good. [00:22] vladimir joined the chat room. [00:24] dsample: Firefox is a community effort anyway, so there's no reason why it wouldn't be possible [00:24] fern: yes [00:24] dsample: if it advances the browser into a more... dare I say it... web 2.0 way, then maybe it's worth it