PubSub CAN NOT support Atom with existing "no duplicate id" constraint

[Bob Wyman]

I know that nobody seems to like this issue… However, I have explained on numerous occasions that the existing prohibition against duplicate ids in a feed simply cannot be supported by PubSub or any other feed aggregator. The problem is, once again, that prohibiting duplicate ids provides an easy to use attack vector for those wishing to effectively “erase” entries written by another author. (i.e. by publishing an entry with an id identical to one published earlier, one can force the earlier entry to be flushed from Atom feeds.) If synthetic feed generators such as PubSub implement the current prohibition against duplicate ids, they will simply become open channels for attack. We’ll soon see anti-abortionists publishing entries with ids identical to those of entries whose content they disapprove of. We’ll see ex-boyfriends attack critical entries written by girls whom they displeased on Saturday night. We’ll see skinheads “flush” from the system any entries that might have been written by jews and blacks. This is not good and I will not allow the system I build to be used in this manner. Graham Park has proposed that we loosen the existing language to permit duplicate ids in the case where the entries have atom:source elements which identify different URI’s in “self” links. I support this compromise and believe it should be supported by the WG and incorporated into the Atom Draft. I don’t believe the issue here is one of taste and I don’t see any responsible option other then modifying the existing constraint. No one has been able to provide any argument which explains why the attack vector I describe is *NOT* a problem. If the WG refuses to modify this constraint, then it should at least feel compelled to include text in the security considerations section that clearly describes the attack and lets people know that no atom entry is “safe” from trivial attacks as a result of this constraint. If the WG refuses to modify this constraint, then they should expect that responsible feed aggregators and generators of synthetic feeds will simply be forced to deny support for Atom as specified. If anyone has a clear argument explaining why the attack is not possible or not a problem, they should make it. Alternatively, if you have a better method then that proposed by Graham for defending against the attack, please describe it. Otherwise, Graham’s compromise should be accepted and the specification revised.   bob wyman