tl;dr Alice can reveal payments she made to Bob. She cannot reveal payments that others made to Bob, or reveal what (if anything) Bob does with the ZEC that Alice sent.

Revealing the pre-image of the note commitment only proves that Alice knows the pre-image. It does not prove that Alice sent the transaction, because the proof is replayable: once revealed, anyone can take the randomness and note data, and show it to someone else.

In order for Alice to prove to someone that she sent the transaction, she can do the following:

• Write a message that contains:
  • The private key esk used to encrypt the note (randomness and value) to Bob.
  • Bob's payment address.
  • A challenge string chosen by the person Alice is convincing.
• Sign the message using the private key joinSplitPrivKey corresponding to the joinsplitPubKey that was originally used to sign the transaction.

The signed message is proof that Alice currently has access to joinSplitPrivKey (because the challenge string is fresh). Assuming that joinSplitPrivKey is never revealed, Alice is indistinguishable from the person who created the transaction (i.e. either she or someone with her spending keys made the payment). This is what we call a payment disclosure, and is how e.g. you would prove to an exchange (or a third party dispute resolution service) that you did indeed pay them.

What you are describing is fundamentally the same issue that messaging apps have with end-to-end encryption: someone with intended access to the data can accidentally or intentionally reveal it. Removing this potential privacy leak would by definition mean that Alice cannot see some or all details about her own outgoing transactions, which is either a contradiction (in the Zcash model, Alice needs to be able to calculate a commitment from its pre-image in order to create valid transactions), or a completely unusable payment system!

Note however that even though Alice can prove that she sent a transaction to Bob, she cannot reveal anything about what Bob does with the note he received (because she does not have Bob's spending key, and thus can't calculate the nullifier that will would be revealed at spend time). Alice's ability to reveal information is limited to information she was ever able to view.

To add to @str4d's answer, here are links to public documentation and discussion of the payment disclosure feature:

• Selective Disclosure & Shielded Viewing Keys - Zcash blog
• Payment Disclosure (Experimental Feature)
• An Introduction to Payment Disclosure in Zcash - Gareth Davies

Note that if Bob were concerned about this possibility, he could have given Alice a unique address to pay him, so that a revealed payment to that address could not be linked to his other addresses. This is suggested in section 3.1 of the protocol spec.

In Sapling, there is a new feature called "diversified payment addresses" that makes this usage more efficient: Bob can give out a unique diversified address to each potential payer, and can still scan the block chain for incoming payments as efficiently as if he had only one address. We're planning for this to be integrated into the Zcash equivalent of BIP 32 (Hierarchical Deterministic Addresses), so that all secrets associated with a wallet can be backed up using a single seed.