[moe]

but I'm saying that compromising the sandbox can be looked as well as an additional step to achieve

You're making no sense. The previous attack vectors don't go away when you put your keys into Chrome. Chrome becomes an additional option for the attacker, not an additional "step".

A house with two doors is less secure than the same house with one door.

[tmzt]

There is also no reason that private keys have to be loaded in the same process (or even the sandbox) when an ssh agent is used.

[moe]

I'm a bit baffled to what degree some people here try to deny the obvious.

Yes, you can use ssh-agent with chrome (if they have that implemented, I don't know). Yet you are still in trouble when the chrome sandbox gets compromised, because all your keystrokes are passing through it.

[BitMastro]

From what I know they don't impement ssh-agent. Do you consider ssh-agent as another attack vector or additional security?

If the sandbox is compromised to have file system access, a process can read your keys from ~/.ssh as well as chrome storage files. Otherwise a webpage has to escape its own sandbox, bypass the native client's sandbox (in a different process) composed of the inner and outer sandbox and then access the native client.

I'm not saying that it's impossible, I'm saying that using a simple analogy as "a house with two doors" might not be the best.

[moe]

Otherwise a webpage has to escape its own sandbox, bypass the native client's sandbox (in a different process) composed of the inner and outer sandbox and then access the native client.

Or there could be just some really dumb bug that somehow enables cross-process access. With javascript. You know, one of these silly brown-paper-bag bugs that are not supposed to happen.

Either way, this is the second door. It may be a shiny steel door, but it's an additional door.

[BitMastro]

The other process might as well be ssh itself at this point. Anyway, we are just speculating, also the wall is another door if you smash through it. Just don't use it then.