You and I have OpenPGP keys and know that system, but the vast majority of the web users out there don't and aren't ever likely to. "Does not require public key exchange" is, for better or worse, a pretty compelling feature when trying to reach the mass market.
To attempt to answer your question a bit more directly: OpenPGP and i-names provide completely different things. OpenPGP is about signing and encryption, i-names (XRI) is a system of identifiers. Perhaps you would even use them together, adding your i-name to the comment or email field of your public key. An i-name is more like a URL than a key ID. Key IDs aren't really addressible by themselves.
Of course, you can use an i-name for a nym too. And registering an i-name exposes far less details about who you are to the world at large than registering a domain name does.
Well, the hope is, that instead of your information living on lots of customer sites which know lots about their product and jack about online security, your information lives on one server that's actually very invested in having good security. Their reputation as an i-broker (to use the i-names terminology) will depend on it. There's only one registry for i-names and i-numbers, but there are a number of organizations that will provide the associated contact services and whatnot. It's those i-brokers you will be trusting your data with, and as a consumer you should have freedom to switch providers if one doesn't meet your standards.
Naturally, your information will still have to pass through other sites from time to time as they need it, but hopefully those sites appreciate the liability of retaining sensitive information and will flush it whenever possible.
In fairness, this is also true of all decentralized identifier schemes, OpenID and XRI included. I don't know how it would be possible to both keep the system open and limit the creation of accounts. Some reputation schemes, such as the one Raph Levien developed and deployed over at Advogato, are pretty effective at addressing the attack you describe; reputation only counts if that reputation is contributed by someone who is already trusted. However, I don't know of anyone who has figure out how to scale that up to a system of millions of identifiers distributed across a large number of sites.
Your question may have been tongue-in-cheek, but it's really not so far-fetched. Slashdot could certainly become an OpenID server, in which case you could sign in as http://slashdot.org/~jamesh (or, I guess, slashdot.org/87723, if you really want to). Or/. could buy the @slashdot community i-name, and perhaps then you could be @slashdot/~jamesh.
All we need is for someone to integrate OpenID with slashcode. There's already a perl library. And a $5,000 bounty if it gets into the slashcode main distribution.
I regret to say that we do not currently have a Smalltalk/Seaside implementation of OpenID available. (For some reason, the guys who do the numbers here don't think there's that big a market for it.) However, we do have Ruby (on Rails, if you like), Python, Perl, and maybe some C# and Java, in addition to the PHP.
OpenID is an authentication system for web applications.
The advantage of OpenID over email ID authentication is that you generally don't want to have to click through your email box every time you log in anywhere. OpenID can provide something like that in a more usable fashion.
OpenID authenticates an identifier. For many people (e.g. LiveJournal users, WikiTravel users, myopenid.com users, etc) this identifier is a URL (e.g. http://frank.livejournal.com/ ). The i-names people would like that identifier to be an i-name instead. (e.g. =frank or @livejournal/frank).
OpenID is one service, an authentication service, that may be used with i-names. The i-brokers plan to offer others as well.
I'm not sure where multiple openid.server links enter into the conversation at this point, but it's true that would be out of spec. However, future versions of the spec are expected to use Yadis for server discovery and Yadis allows defining multiple services. That should be happening Real Soon Now.
myopenid.com's front page may not always redirect to HTTPS, but www.myopenid.com/signin does, which is what you'll see if you use your OpenID to log in to another web site.
HTTPS has not been encouraged for consumer-server communication because it seems as if many web hosts are sadly lacking SSL-enabled http fetching libraries. So if you can poison the DNS server of the consuming site (not just the user agent's), you can attack accounts on that consumer. Solutions there would be to use HTTPS for that communicaton (but, as you say, likely to break with things as they are) or use more secure DNS (what ever happened to DNSSEC?).
So, uh, how likely is someone to launch a successful DNS poisoning attack in order to crack accounts on your photo sharing host? No, it's not impossible, so maybe you shouldn't use it on that swiss bank account, but it's far from trivial. And is it any easier to do that than it is to attack the current standard for web service login, the e-mail confirmation? No, SMTP uses unsigned communication and DNS too.
Which means you get something that's as secure as the current system, is *more* resistant to phishing in some ways (since you should only ever be giving your credentials to your OpenID server and not sharing your password with every blog and phpBB you run across), relieves users of the headache of password management, relieves a lot of the headache of account management for small web applications (I can authorize http://frank.livejournal.com/ to edit pages on my Instiki *without* requiring Frank to go through a sign-up process at my site), provides a namespace for account identifiers that we can build some cool trust systems on top of... and yes, it's vulnerable to some of the same attacks as the current technology. That still sounds like a win to me.
There's nothing preventing your OpenID server from using a SSL or TLS certificate in just the way you say your bank does. Zooomr's partner OpenID service MyOpenID does in fact just that.
We do highly discourage use of "a window with no location bar" for the reasons you mention. You and I will probably remember that when using the service, but it is a difficult user eduction issue, granted. It would help a lot if things like Petname Tool take off.
The Tile Cache Size is in the "Environment" section of the Preferences dialog. It should be set to about as much RAM you system is ready and willing to dedicate to GIMP.
You are correct in thinking that such a thing would have to be licensed. The phrase I hear most often for Pantone support is "patent minefield". Such a thing would be pricey, and would require a commercial sponsor with deep pockets, and the resulting plug-in would be non-free... So far, no one's offered to sponsor this.
How many people are working on this thing. Is it just the original creator??? Will they have to hire a larger team when they hit the "releasable" 2.0?
The "how many people" question is answered by Sven in the interview, I think. As for the original creator, well, that's an interesting story. And "will they hire a larger team"? Umm, AFAIK, no-one (including distributions and start-ups) has any programmers on payroll for GIMP at this time, so I'm not sure who would be doing the hiring...
Eek! This is not what GIMP expands to. Rather, it is the GNU Image Manipulation Program. In some times past, people have used the "G" for "Graphical", but the "P" has never been Photoshop.
Someone else started a SourceForge project with the intention of doing this. I haven't seen many signs of life from over there lately, but you could try waking them up...
piGIMP is a project to benchmark GIMP against Photoshop...
I also think that rather argue about the video card, it would be more productive to come up with a benchmarking suite, to decide what and how the benchmark will measure instead of where.
Photoshop plug-ins like AlienSkin can't be used with gimp. However, the "Filter Factory" filters (.afs and.8bf) files can be used with the User Filter plug-in.
Does the GIMP currently have (or likely to add in the very near future): editable text layers, layer effects, in-layer text editing, magnetic selection tools, multiple-level undo, integration with optimising tools, etc?
Editable text layers: yes.
In-layer text editing:...not sure of the status on this one.
Magnetic selection tools: Selections may snap to guides, is that what you mean?
Layer effects: We do have different layer modes (multiply, overlay, value, etc). We do not have things like "drop shadow layers".
Multiple-level undo: has been there for at least three or four years.
Intergartion with optimizing tools: Not quite sure what this one refers to.
Don't waste time with so many plug-ins and filters, and refine implementation of the fundamentals. The plug-ins should be a later priority.
The thing is, it's not mostly the same people working on the plug-ins as are working on the core. A plug-in is relatively small and easy to control, so individuals can pick whatever effect they're interested and go do a plug-in for it. These are not usually the same people who have working knowledge of gimp's more complex internals...
Slashdot Mirror
You and I have OpenPGP keys and know that system, but the vast majority of the web users out there don't and aren't ever likely to. "Does not require public key exchange" is, for better or worse, a pretty compelling feature when trying to reach the mass market.
To attempt to answer your question a bit more directly: OpenPGP and i-names provide completely different things. OpenPGP is about signing and encryption, i-names (XRI) is a system of identifiers. Perhaps you would even use them together, adding your i-name to the comment or email field of your public key. An i-name is more like a URL than a key ID. Key IDs aren't really addressible by themselves.
Of course, you can use an i-name for a nym too. And registering an i-name exposes far less details about who you are to the world at large than registering a domain name does.
Well, the hope is, that instead of your information living on lots of customer sites which know lots about their product and jack about online security, your information lives on one server that's actually very invested in having good security. Their reputation as an i-broker (to use the i-names terminology) will depend on it. There's only one registry for i-names and i-numbers, but there are a number of organizations that will provide the associated contact services and whatnot. It's those i-brokers you will be trusting your data with, and as a consumer you should have freedom to switch providers if one doesn't meet your standards.
Naturally, your information will still have to pass through other sites from time to time as they need it, but hopefully those sites appreciate the liability of retaining sensitive information and will flush it whenever possible.
In fairness, this is also true of all decentralized identifier schemes, OpenID and XRI included. I don't know how it would be possible to both keep the system open and limit the creation of accounts. Some reputation schemes, such as the one Raph Levien developed and deployed over at Advogato, are pretty effective at addressing the attack you describe; reputation only counts if that reputation is contributed by someone who is already trusted. However, I don't know of anyone who has figure out how to scale that up to a system of millions of identifiers distributed across a large number of sites.
(Some problems are hard.)
Your question may have been tongue-in-cheek, but it's really not so far-fetched. Slashdot could certainly become an OpenID server, in which case you could sign in as http://slashdot.org/~jamesh (or, I guess, slashdot.org/87723, if you really want to). Or /. could buy the @slashdot community i-name, and perhaps then you could be @slashdot/~jamesh.
All we need is for someone to integrate OpenID with slashcode. There's already a perl library. And a $5,000 bounty if it gets into the slashcode main distribution.
I regret to say that we do not currently have a Smalltalk/Seaside implementation of OpenID available. (For some reason, the guys who do the numbers here don't think there's that big a market for it.) However, we do have Ruby (on Rails, if you like), Python, Perl, and maybe some C# and Java, in addition to the PHP.
OpenID is an authentication system for web applications.
The advantage of OpenID over email ID authentication is that you generally don't want to have to click through your email box every time you log in anywhere. OpenID can provide something like that in a more usable fashion.
OpenID authenticates an identifier. For many people (e.g. LiveJournal users, WikiTravel users, myopenid.com users, etc) this identifier is a URL (e.g. http://frank.livejournal.com/ ). The i-names people would like that identifier to be an i-name instead. (e.g. =frank or @livejournal/frank).
OpenID is one service, an authentication service, that may be used with i-names. The i-brokers plan to offer others as well.
I'm not sure where multiple openid.server links enter into the conversation at this point, but it's true that would be out of spec. However, future versions of the spec are expected to use Yadis for server discovery and Yadis allows defining multiple services. That should be happening Real Soon Now.
myopenid.com's front page may not always redirect to HTTPS, but www.myopenid.com/signin does, which is what you'll see if you use your OpenID to log in to another web site.
... and yes, it's vulnerable to some of the same attacks as the current technology. That still sounds like a win to me.
HTTPS has not been encouraged for consumer-server communication because it seems as if many web hosts are sadly lacking SSL-enabled http fetching libraries. So if you can poison the DNS server of the consuming site (not just the user agent's), you can attack accounts on that consumer. Solutions there would be to use HTTPS for that communicaton (but, as you say, likely to break with things as they are) or use more secure DNS (what ever happened to DNSSEC?).
So, uh, how likely is someone to launch a successful DNS poisoning attack in order to crack accounts on your photo sharing host? No, it's not impossible, so maybe you shouldn't use it on that swiss bank account, but it's far from trivial. And is it any easier to do that than it is to attack the current standard for web service login, the e-mail confirmation? No, SMTP uses unsigned communication and DNS too.
Which means you get something that's as secure as the current system, is *more* resistant to phishing in some ways (since you should only ever be giving your credentials to your OpenID server and not sharing your password with every blog and phpBB you run across), relieves users of the headache of password management, relieves a lot of the headache of account management for small web applications (I can authorize http://frank.livejournal.com/ to edit pages on my Instiki *without* requiring Frank to go through a sign-up process at my site), provides a namespace for account identifiers that we can build some cool trust systems on top of
There's nothing preventing your OpenID server from using a SSL or TLS certificate in just the way you say your bank does. Zooomr's partner OpenID service MyOpenID does in fact just that.
We do highly discourage use of "a window with no location bar" for the reasons you mention. You and I will probably remember that when using the service, but it is a difficult user eduction issue, granted. It would help a lot if things like Petname Tool take off.
The Tile Cache Size is in the "Environment" section of the Preferences dialog. It should be set to about as much RAM you system is ready and willing to dedicate to GIMP.
--
Created for just such occasions, the Straight Line Tutorial.
--
You are correct in thinking that such a thing would have to be licensed. The phrase I hear most often for Pantone support is "patent minefield". Such a thing would be pricey, and would require a commercial sponsor with deep pockets, and the resulting plug-in would be non-free... So far, no one's offered to sponsor this.
--
The "how many people" question is answered by Sven in the interview, I think. As for the original creator, well, that's an interesting story. And "will they hire a larger team"? Umm, AFAIK, no-one (including distributions and start-ups) has any programmers on payroll for GIMP at this time, so I'm not sure who would be doing the hiring...
--
Eek! This is not what GIMP expands to. Rather, it is the GNU Image Manipulation Program. In some times past, people have used the "G" for "Graphical", but the "P" has never been Photoshop.
Opinions on how to capitalize it are varied.
--
Someone else started a SourceForge project with the intention of doing this. I haven't seen many signs of life from over there lately, but you could try waking them up...
I also think that rather argue about the video card, it would be more productive to come up with a benchmarking suite, to decide what and how the benchmark will measure instead of where.
--
Photoshop plug-ins like AlienSkin can't be used with gimp. However, the "Filter Factory" filters (.afs and .8bf) files can be used with the User Filter plug-in.
--
Plug-ins: They make GIMP do stuff. http://gimp-plug-ins.sourceforge.net/
--
The thing is, it's not mostly the same people working on the plug-ins as are working on the core. A plug-in is relatively small and easy to control, so individuals can pick whatever effect they're interested and go do a plug-in for it. These are not usually the same people who have working knowledge of gimp's more complex internals...
Plug-ins: They make GIMP do stuff. http://gimp-plug-ins.sourceforge.net/
--