The paper, On the Privacy Provisions of Bloom Filters in Lightweight Bitcoin Clients has this to say about Bloom filters in SPV:
...Indeed, in current implementations of SPV clients [BitcoinJ], both the addresses and their public keys are inserted in the outsourced Bloom filter. As such, if the adversary knows both the address and its public key, then she can trivially test whether an address is a true positive of the filter by checking whether both the address and its public key are inserted within the filter. If not, then it is highly likely that the address is a false positive of the filter. We believe that the inclusion of both the address and its public key in the Bloom filter is a severe flaw in the current SPV client implementations—and can be easily countered; we thus do not exploit this flaw in our analysis. In fact, more than 99% of all Bitcoin transactions consist of payments to Bitcoin addresses (or the public key hash); moreover, only 4587 out of 33 million total addresses in the system received transactions destined for both their public keys and their public key hashes. This means that for the vast majority of Bitcoin clients, there is no need to include both the public keys and their hashes (i.e., the Bitcoin addresses) in the Bloom filters; inserting one or the other would suffice (in more than 99% of the cases). [my emphasis]
The idea behind this attack was re-iterated in Privacy in BitcoinJ:
The vulnerability is that if a pubkey is truly in the filter then querying both pubkey and pubkeyhash must return true. Because the pubkeyhash is just another almost uniformly random string, the probability of a false positive for the attacker is fp' = fp^2 = 0.0000000021555. I obtained around 56 million pubkeys from the blockchain (mid-January), which theoretically results in 56 million * fp' = 1.29 expected false positives when scanning the blockchain.
In other words, a simple attack is enough to pick out all of the public keys from a BitcoinJ Bloom filter.
Does the current release of BitcoinJ add both a public key and its hash value to its Bloom filters? If not, which release stopped it from occuring?
Also, why were both public keys and hashes added in the first place?