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 |
- PubSub CAN NOT support Atom with existing "no duplicate... Bob Wyman
- Re: PubSub CAN NOT support Atom with existing "no ... Bill de hÓra
- Re: PubSub CAN NOT support Atom with existing "no ... Sam Ruby
- Re: PubSub CAN NOT support Atom with existing "... Robert Sayre
- Cleanup phase Tim Bray
- Re: Cleanup phase Robert Sayre
- Re: Cleanup phase Bill de hÓra
- Re: Cleanup phase Graham