Re: Accidental and intentional atom:id collisions (was Re: Consensus call on last raft of issues)

[Antone Roundy <antone@xxxxxxxxxxxxxx>]

On Wednesday, May 18, 2005, at 09:12  AM, Henry Story wrote:
> I supposed the surest way to make it impossible to fake the id, is to 
> specify that
> by dereferencing the id and doing a GET (whatever the correct method 
> of doing that for the
> protocol happens to be) one should be able to retrieve the entry.
The unlikelihood of anyone actually retrieving each entry to verify 
that it's accurate would make this method only trivially effective.

> > An oddity this language introduces is that if the entries don't 
> > appear in the same Atom Feed Document, they apparently don't have to 
> > be treated as the same entry, but if they're aggregated together, 
> > they do. Going a little further, if I'm subscribed to both original 
> > feeds and an aggregation that includes both, then I have potentially 
> > four <entry>s with the same id.  Which are the same entry and which 
> > aren't?  Only the two in the aggregation, which really aren't, are 
> > required to be treated as the same.
>
> I always thought that two entries with the same id should be treated 
> as the same entry.
> What makes you thing otherwise?
Consider the following three simplified feed documents (or any two of 
them, or just the last one):

// this is the legitimate one
<feed>
	<id>http://a.com/feeda</id>
	<entry>
		<id>http://a.com/feeda/entry1</id>
		<updated>2005-01-01T05:00+00:00</updated>
		<title>I am the legitimate entry</title>
		<content type="html">&lt;a href="https://a.com/feedback.php"&gt;Use 
this form to submit your credit card number&lt;/a&gt;</content>
	</entry>
</feed>

// this one is phishing
<feed>
	<id>http://b.com/feedb</id>
	<entry>
		<id>http://a.com/feeda/entry1</id>
		<updated>2005-01-01T10:00+00:00</updated>
		<title>I am the legitimate entry</title>
		<content type="html">&lt;a href="https://b.com/feedback.php"&gt;Use 
this form to submit your credit card number&lt;/a&gt;</content>
	</entry>
</feed>

// this is an aggregation
<feed>
	<id>http://c.com/feedc</id>
	<entry>
		<source>
			<id>http://a.com/feeda</id>
		</source>
		<id>http://a.com/feeda/entry1</id>
		<updated>2005-01-01T05:00+00:00</updated>
		<title>I am the legitimate entry</title>
		<content type="html">&lt;a href="https://a.com/feedback.php"&gt;Use 
this form to submit your credit card number&lt;/a&gt;</content>
	</entry>
	<entry>
		<source>
			<id>http://b.com/feedb</id>
		</source>
		<id>http://a.com/feeda/entry1</id>
		<updated>2005-01-01T10:00+00:00</updated>
		<title>I am the legitimate entry</title>
		<content type="html">&lt;a href="https://b.com/feedback.php"&gt;Use 
this form to submit your credit card number&lt;/a&gt;</content>
	</entry>
</feed>

This is already bad enough.  Now how about if the phishing feed claims 
that it's atom:id is http://a.com/feeda.  Worse still.  With the 
current spec text, an Atom consumer that does a little extra work, 
somehow figures out that the phishing version of the entry is not the 
same as the legitimate version, and tells the user that would be 
violating the spec.