Why do web wallets using multi-signature need 1 of N keys? I've been researching multi-signature transactions and am wondering, as the title says, why a web wallet offering multi-signature transactions (2-of-3, for example) like blockchain.info would need any of your private keys at all. From what I understand, it looks like multi-signature 2-of-3 addresses require three public keys to generate, and are spent via raw transactions. 

So why do these services not allow you to keep all three keys? 

Is there some reason that one of the keys must be kept by the wallet provider? It doesn't seem like any of the keys are required to be in the provider's wallet so long as they are available to sign the raw transaction before sending -- and in theory the raw transaction could be created by the client in the browser and submitted for transmission via sendrawtransaction without involving the provider in any sense other than raw connectivity to the network.

What am I missing?
From what I understand, it looks like multi-signature 2-of-3 addresses require three public keys to generate


The requirement is for private keys, the public keys are well, public: everybody knows them. A 2 of 3 script requires that any two of the three mentioned keys is needed, and you can use variations of this such as 2 of 2, 3 of 3, 1 of 3, etc. 


  are spent via raw transactions


It's also worth nothing that "raw transactions" is just a term used in Bitcoin Core when taking about anything which is not Pay to Pubkey Hash, it's pretty meaningless unless you're talking about the client itself. 


  So why do these services not allow you to keep all three keys? 


The intention in multi signature wallets is that you can have a requirement for multiple parties to authorize a transaction. In the case of this model, you would have a 2-of-2 system, where there are two parties and both are required to sign in order to spend the related funds. This has the following properties:


The service can not outright steal the money from the user, as the user needs to sign the transaction as well. 
The user can have restrictions placed on them by the third party, say, they won't sign transactions which spend more than $10 a day, or without the requirement of additional authorization. 
Transactions can be authored in such a way that if the service refuses to sign any transactions (randoms the user, or goes out of business), after a significant passing of time the requirement is reduced to just a single signature from the user. 


With these properties you can author very powerful systems with arbitrary spending requirements without risking the loss of money by giving complete of your money to anybody else. 

In the case of web wallets however, this system is almost completely snake oil cryptography as the third party is also the one serving the code to the users. At any time they can alter this to different code which just sends the private keys back to them, or blindly signs any transaction they want. There's absolutely no way of making web wallets safe in light of this property. 


  So why do these services not allow you to keep all three keys? 


Then it would be pointless having multisignature transactions where one party holds all the keys, it would cost a lot less to just use regular transactions. Multisignature scripts tend to have significantly higher costs for use compared with regular transactions.