As you know, a system is only as secure as its weakest component. (Yes, everything is fundamentally broken and insecure, but that's no excuse for writing more crap software.) As a browser, it's impossible to secure all parts of the system (and that's not your job), but it's not okay to be the weakest component and not care about this. By virtue of providing a clear listing of all passwords and neither warning about this nor giving the user a choice, Chrome clearly is the weakest part in this.
Passwords added that way require confirmation for access, do not require entering the keychain password, and the application adding the password is auto-whitelisted (which overrides confirmation for access) -- which matches what I see on Chrome passwords.
This means that the default way of creating internet passwords in the Keychain provides only weak security (sigh, Apple), because the creating application can always access the password. (Same applies to Safari, only it doesn't provide a nice list of passwords as far as I can tell.)
-----
I agree that trying to add access control inside Chrome is nonsense – Chrome can access the passwords and you'll (probably) always be able to trick it into revealing things. But that's not the only thing you can do – it's relatively easy to fix the bad default behavior and disallow access for Chrome unless the user (via Keychain prompt) explicitly allows it.
When storing a new password, offer to always require the keychain password for access.
If the user chooses this option, use the lower-level API to create the entry (or use the default function and modify / add modified / delete old – there's code for that in the chrome repo) and use an ACL that has (1) an empty (but not NULL!) trusted application list, (2) the $blah_REQUIRE_PASSPHRASE bit in the prompt selector set. As a result, Chrome will not be able to access the password without the user explicitly allowing it.
If the user always chooses the secure option when saving passwords, no one can access them without entering the keychain password or significantly mucking with the system. If that breaks, it's not your fault.
That's a fundamentally different situation – it's hard to fail to protect passwords that you cannot access(^1)!
(^1) at least not without other parts failing first
Well, if the machine has only two states, it has only a single bit of internal memory. This means (almost) all information is in the picture.
Brain dump:
A one-state TM has no hidden state -- this means that it has no way to look at the surroundings (only the current field), which makes them rather boring. (All you'll get is lines or planes of one color, they cannot sensibly navigate the second dimension.)
Two-state TMs are 'clever' enough to change the color after moving, which means they can draw corners and thereby use the whole 2d plane. They still have to put all information into the picture, meaning you get to see all the gory details of information flow. You don't have the transition table, but you can read most of it off the image. You'll see all paths or areas in which movement in a single direction can happen without changing the color. Everything else has to be left in the picture, which means it will constantly overwrite stuff. This, in turn, means that it'll likely use groups of colors for one purpose.
The start is boring: red - turn green & go up, green - turn black & go down, black - turn pink & move right (so far this could be done by a 1-state TM.) Pink does some state changes and introduces cyan, shortly after you'll see it 'sewing' to the left, leaving a thick structured line across the image, which is then expanded into a yellow-green covering of the whole black area (see how black/pink move right and cyan/yellow give turning directions and create yellow/green?) and then... ah, well just look at it.
Three-state TMs can hide quite a lot of information. As an example, the extra state can be used as a movement state, allowing non-destructive movement in one direction. (On jump mark (say, white), change to state #3 and keep going until you hit the next jump mark.) It can also be used to non-destructively look in one direction (e.g. for testing what color the left neighbor has). Combinations thereof can do pretty crazy stuff.
Adding more states basically just allows 'compressing' the picture more, which makes it more likely that you'll only see noise - especially if the TMs are randomly generated.
Just picking your last question out of context to (re-)state what should be obvious:
Committees are bad, because you will never know what color the bikeshed should be.
You have exponentially many possible interactions between people in a group and any important information will almost surely get lost in the noise. Big committees are a wonderful stage for personal feuds, intrigues and outright sabotage (already in the formation phase).
The results you'll get will mostly be based on lobbying, popularity and whoever barked the loudest, not on benefit, cost, feasibility, let alone constitutionality.
OTOH, I don't really know what would be better. Smaller "committees", more like expert groups, can give better results if the right people are selected. Which is unlikely, given the present state of governments. At the moment it seems as if the best strategy is oversizing and over-bureaucratizing to slow down the process and limit the amount of damage done in that way. Meh. :-/
Shouldn't everyone know by now that this plain text concatenation scheme is insecure?
By using this scheme, you're trusting $domainName to securely scramble the password.
Once a single password is known in plain, an attacker has a nice password template that he can try on any site. The last few bits of security would be your user name (which is often similar to the one you use elsewhere) or nothing at all if you can log in by email address (which is usually possible these days; and that email address is often among the leaked information as well). Instant login anywhere!
At least hash that '$domain+$masterpass' string...
-----
More problems: I heard some people still truncate passwords down to unreasonable lengths on the server side, which might make hash compression (e.g. base 16 -> base 64) necessary and which will totally break the simple concatenation scheme, leaving a prefix of $domainName as the actual password. Ouch.
-----
From the source, it seems Chrome adds password using `SecKeychainAddInternetPassword` (see http://developer.apple.com/library/mac/documentation/Securit... ).
Passwords added that way require confirmation for access, do not require entering the keychain password, and the application adding the password is auto-whitelisted (which overrides confirmation for access) -- which matches what I see on Chrome passwords.
This means that the default way of creating internet passwords in the Keychain provides only weak security (sigh, Apple), because the creating application can always access the password. (Same applies to Safari, only it doesn't provide a nice list of passwords as far as I can tell.)
-----
I agree that trying to add access control inside Chrome is nonsense – Chrome can access the passwords and you'll (probably) always be able to trick it into revealing things. But that's not the only thing you can do – it's relatively easy to fix the bad default behavior and disallow access for Chrome unless the user (via Keychain prompt) explicitly allows it.
When storing a new password, offer to always require the keychain password for access.
If the user chooses this option, use the lower-level API to create the entry (or use the default function and modify / add modified / delete old – there's code for that in the chrome repo) and use an ACL that has (1) an empty (but not NULL!) trusted application list, (2) the $blah_REQUIRE_PASSPHRASE bit in the prompt selector set. As a result, Chrome will not be able to access the password without the user explicitly allowing it.
If the user always chooses the secure option when saving passwords, no one can access them without entering the keychain password or significantly mucking with the system. If that breaks, it's not your fault.
That's a fundamentally different situation – it's hard to fail to protect passwords that you cannot access(^1)!
(^1) at least not without other parts failing first