On Tuesday, April 19, 2005, at 12:59 PM, Bob Wyman wrote:
Bill de h�ra wrote:My proposal says that things are considered the same only if foundI'm going to think about it some more but atm I'm not sure what you're proposing helps against DOS.
in the same feed. This is, I believe, the only way to prevent someone from
maliciously erasing someone else's entries with a blocking entry having the
same ID as the entry under attack. Admittedly, the approach will lead to a
number of false negatives in comparisons if people do not consistently
publish "self" links when they build synthetic feeds. The only way I can see
to improve on this situation is to support the "rel='superset'" link that I
discussed earlier. If the superset relationship can, in fact, be expressed,
the rule would change to:
atom:feed elements MUST NOT contain atom:entry elements with identical
atom:id values unless each such entry contains an atom:source element which
is different from that of any of the other entries with which the entry
shares identical atom:id values.
Two atom:source elements MUST only be considered different if they each
contain an atom:link element with a rel value of "self" which identifies
different feed URIs and neither of the feeds identified is known to be a
'superset' of the other feed. A superset feed is identified in a subset feed
by a link element with rel value of "superset". Synthetic feed generators
and aggregators MAY use other sources of information, public or private, to
determine the relationships between feeds.
If two atom:feed elements have identical atom:id values yet only one of them
has an atom:source element with a rel value of "self", that element which
contains the atom:source element with rel value of "self" SHOULD be
preferred over the other.
This illustrates the superiority of "self" links over atom:id in identifying a feed. If one were to attempt to use atom:id the way Bob is proposing to use a "self" link above to protect again DOS attacks, it wouldn't help (or could be easily circumvented), because there's no way to resolve disputes between feeds claiming the same atom:id. But it's easy to verify whether a feed is really the owner of it's "self" link.
There would still be an attack vector, where one would use the atom:id of an entry that had left the legitimate feed's sliding window. Anyone subscribed directly to both would be protected if their feed, reader were to ignore all entries claiming to be from other feeds to which they are subscribed. But those receiving the legitimate entry via an aggregator that didn't do that or wasn't subscribed to both sources might still have trouble resolving conflicts.
Of course, a feed may move over time, so atom:feed/atom:id is useful, but really only as a hint that feeds found at two locations might be the same.
...which reminds me of PaceFeedIdOrSelf, PaceFeedIdOrAlternate and PaceCoConstraintsAreBad. Out of curiosity, are these actually going to be considered at some point in the process, or is it just too late?
