RE: Compulsory feed ID?
Antone Roundy wrote re the issue of DOS attacks: > I've been a bit surprised that you [Bob Wyman] haven't > been more active in taking the lead on pushing the conversation > forward and ensuring that threads addressing the issue don't die > out, given the strength of your comments on the issue in the past > and the obvious significance to your business. ... Perhaps > you, who are probably in a better position than any of us to speak > from experience on how to deal with this, could refresh our memories > of specifically what you think the best solution is. Yes, this issue is very important to us at PubSub and should be very important to others as well. However, as I've learned from other recent discussions, my viewpoint is not commonly held in this Working Group. Thus, what I've been trying to do is pick carefully the issues that I work on. For instance, I've put a great deal of effort into multiple ids since that allows us the freedom to either work out proprietary solutions to the DOS problem on our own or allows us to punt the problem forward to the end-users' aggregators if we can't come up with a decent solution. Clearly, the best solution here would be for folk to use signatures. But, that is going to take either a great deal of work to get adopted or something really creative (and simple)... The history of attempts to get signatures used does not make pleasant reading... We are putting effort into working out methods to make signatures more acceptable to the community and I hope to have some proposals soon... If we successful (wish us luck!) that will at least provide a solution for some people... Basically, it doesn't make sense for me to keep demanding that people deal with issues that they clearly don't want to address. I've been mentioning the DOS problem for months now and getting nowhere. So, the reason I'm not pushing harder is that it is clear that implementable work-arounds will be more useful than never agreed-to "solutions"... bob wyman
Re: Compulsory feed ID?
On May 22, 2005, at 3:13 AM, Martin Duerst wrote: >> We suggest that there may be WG consensus in favor of changing the >> format spec to make atom:id a required child of atom:feed. (Text not >> provided, we trust the editors to figure out the correct way to say >> this). Please indicate agreement or disagreement with this proposition >> in the next day or two. > >wth, +1 +1 here too.Regards, Martin. Having reviewed the commentary over the last three days, I observe a couple of +1's, a few "not my favorite approach but OK", and no objections. I see rough consensus in favor of making atom:id a compulsory child of atom:feed. -Tim
RE: Compulsory feed ID?
At 2:30 AM -0400 5/21/05, Bob Wyman wrote: I think it would be both wise and appropriate to provide text in a Security Concerns section that describes the vulnerability of systems that rely on Atom documents to this particular attack. That's why we have signed documents, which are described fully in the document already. It is fine to add text to the signatures section explaining why they are useful against this attack, and a short mention in the Security Considerations section pointing back to that one. Please note that every format that the IETF has ever come out with that isn't inherently signed has either this exact problem or one very close to it. The fact that the format document specifies a signing mechanism in the document itself instead of in a companion document that is read by only 25% of the implementers is a giant leap forward. --Paul Hoffman, Director --Internet Mail Consortium
Re: Compulsory feed ID?
At 08:47 05/05/20, Eric Scheid wrote: > >On 19/5/05 10:41 PM, "Tim Bray" <[EMAIL PROTECTED]> wrote: > >> We suggest that there may be WG consensus in favor of changing the >> format spec to make atom:id a required child of atom:feed. (Text not >> provided, we trust the editors to figure out the correct way to say >> this). Please indicate agreement or disagreement with this proposition >> in the next day or two. > >wth, +1 +1 here too.Regards, Martin.
Re: Compulsory feed ID?
On Saturday, May 21, 2005, at 12:30 AM, Bob Wyman wrote: Tim Bray wrote: I think the WG basically decided to punt on the DOS scenario. -Tim I believe you are correct in describing the WG's unfortunate disposition towards this issue. (Naturally, I object...) I've tried to get discussion of this moving a few times with very little success. Honestly, I've been a bit surprised that you haven't been more active in taking the lead on pushing the conversation forward and ensuring that threads addressing the issue don't die out, given the strength of your comments on the issue in the past and the obvious significance to your business. In the flurry of discussion of various issues that's been going on recently, I can't remember whether you've stated a specific opinion on the best way to solve the problem or not, and if so, whether it has been affected at all by discussion or related changes that have occurred since it's original expression. Perhaps you, who are probably in a better position than any of us to speak from experience on how to deal with this, could refresh our memories of specifically what you think the best solution is.
Re: Compulsory feed ID?
On 21/5/05 4:30 PM, "Bob Wyman" <[EMAIL PROTECTED]> wrote: >> I think the WG basically decided to punt on the DOS scenario. -Tim > I believe you are correct in describing the WG's unfortunate > disposition towards this issue. (Naturally, I object...) In any case, given > that a significant DOS attack has been identified -- yet not addressed -- I > think it would be both wise and appropriate to provide text in a Security > Concerns section that describes the vulnerability of systems that rely on > Atom documents to this particular attack. +1 to putting something into Security Concerns. I'm inclined to think the DOS problem is peculiar to super-aggregators - if any of the publishers of the feeds I've individually subscribed to and actively monitor/read were to wake up one day and decide to be a bad actor, I'm sure to notice something wacky and take action (excoriate them on a blog, unsubscribe, etc). In addition to the DOS problem, I believe there are other issues inimical to super-aggregators, especially those that re-publish. Mostly to do with tracking provenance, enveloping and attribution of mid-stream meta-data or meta-content, and so on. It deserves a deeper treatment, but not in the Atom 1.0 core spec. e.
Re: Compulsory feed ID?
On 19 May 2005, at 23:02, Robert Sayre wrote: On 5/19/05, Sam Ruby <[EMAIL PROTECTED]> wrote: Of course, breaking any link in my complicated chain of logic above would cause the whole argument to collapse, which would be fine with me. Maybe the requirement is useless. "If multiple atom:entry elements with the same atom:id value appear in an Atom Feed document, they describe the same entry and software MUST treat them as such." "MUST treat them as such" isn't particularly meaningful, and two atom:entry elements occuring anywhere are supposed to be describing the same entry. When I get CCed on an atom-syntax message, some of my email programs show two messages, and some show one. It's a security/annoyance trade-off, and I don't see why the format should be making that decision. +1 How you deal with different representations of entries with the same id is up to the software and user's discretion. Some software may want to keep a full history of all the representations, some may only be able to keep the latest. Some users may wish to see all represenations others may wish to see only some of them. The same user may have different preferences at different times. The requirement of treating entries with the same id as the same does not add anything more than saying that the entries are representations of the id resources. Henry Story
RE: Compulsory feed ID?
Tim Bray wrote: > I think the WG basically decided to punt on the DOS scenario. -Tim I believe you are correct in describing the WG's unfortunate disposition towards this issue. (Naturally, I object...) In any case, given that a significant DOS attack has been identified -- yet not addressed -- I think it would be both wise and appropriate to provide text in a Security Concerns section that describes the vulnerability of systems that rely on Atom documents to this particular attack. bob wyman
Re: Compulsory feed ID?
On May 19, 2005, at 1:38 PM, Sam Ruby wrote: ... MUCH text elided ... This proposal seemed to have enjoyed some support, yet it did not seem to have made it into the current draft, despite being crucial to the solving the issue that PaceDuplicateIDs was designed to address. However, for it to work, the re-aggregator would need to have access to a "self" link, which is not required by the current draft. I do not agree that PaceDuplicateIDs was primarily designed to address the DOS-attack scenario, or even pretends to ameliorate that situation. I think it primarily exists to support a bunch of scenarios where, for different reasons, people wanted to be able to generate feeds where entries might appear more than once. I think the WG basically decided to punt on the DOS scenario. -Tim
Re: Compulsory feed ID?
On May 19, 2005, at 12:36 PM, Robert Sayre wrote: On 5/19/05, Tim Bray <[EMAIL PROTECTED]> wrote: (Text not provided, we trust the editors to figure out the correct way to say this). The editors request that text be provided. In section 4.1.1, change the bullet point that reads atom:feed elements MUST NOT contain more than one atom:id element. to read atom:feed elements MUST contain exactly one atom:id element. Plus, take the ? off the atomId in the RNC immediately above. Editorial oversight from anyone is welcome, I'm kind of tired. -Tim
Re: Compulsory feed ID?
On Thursday, May 19, 2005, at 06:41 AM, Tim Bray wrote: We suggest that there may be WG consensus in favor of changing the format spec to make atom:id a required child of atom:feed. (Text not provided, we trust the editors to figure out the correct way to say this). Please indicate agreement or disagreement with this proposition in the next day or two. Since I've already expressed my opinions on this issue, I'll be brief just to register my opinion in this thread. I don't think atom:id is the most useful possible identifier, so this isn't my first choice. But if we can't agree to use a better one, it'll be better than nothing.
Re: Compulsory feed ID?
On 19/5/05 10:41 PM, "Tim Bray" <[EMAIL PROTECTED]> wrote: > We suggest that there may be WG consensus in favor of changing the > format spec to make atom:id a required child of atom:feed. (Text not > provided, we trust the editors to figure out the correct way to say > this). Please indicate agreement or disagreement with this proposition > in the next day or two. wth, +1
Re: Compulsory feed ID?
On 19 May 2005, at 9:38 pm, Sam Ruby wrote: What should we do? One way to solve this is to require "id" *and* update Graham's original proposal accordingly, *and* incorporate it into the next (and presumably final draft). The original proposal actually relied on ids: http://www.intertwingly.net/wiki/pie/PaceDuplicateIDWithSource Just to be clear, the idea wasn't that an entry would have a concatenated entry:id-source:id as its identifier. The entry:id would still be primary, its just multiple versions received from different sources could be represented. If multiple atom:entry elements with the same atom:id value appear in an Atom Feed document, they represent the same entry. It seems to me that this does not solve the problem that Bob described. More specifically, if pubsub were to republish data from TheServerSide, Artima, or other places, then the "erasure" that Bob fears would come to pass. I don't really believe this to be so. An aggregator can treat them as the same entry without having one overwrite the other. It can easily present to the user "Here's the version from Site A" and "Here's the version from Site B". That was kind of the idea of PaceDuplicateIDWithSource. Of course, the atom:source element is as fakeable as the entry's id. The only reliable origin is the URI it was directly fetched from. Oh, and compulsory feed:ids are fine with me. Certainly better than the hybrid proposals. Graham
Re: Compulsory feed ID?
On 5/19/05, Sam Ruby <[EMAIL PROTECTED]> wrote: >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 believe it makes sense to give the notional "atoms" (entries) individual identifiers which will be preserved globally, irrespective of the source, irrespective of where the entries are found - so yes, duplicate IDs in a feed seem an acceptable scenario. I don't personally care how it's done, but a reference back from the feed document to the URI from whence it is begetted is pretty essential for the easier one-click subscription strategies, and should come in handy later for aggregate-republish processing. I think a reference back to the source (original better, intermediate better than nothing) is also desirable to help reduce duplicate posts appearing in any end-of-chain UI. Take this scenario - two entries identical in every respect *except* for their ID. Any resource on the Web may have any number of different URIs, which suggests any entry might /potentially/ have any number of IDs. Should the two entries be allowed in the same feed? If you change the name of an entry, do you change its nature? Sorry, slipping, it's a bit late here - scratch the philosophy, ;-) Basically I reckon duplicate IDs in a feed are ok - leave it to the (final or intermediate) consumer to filter out if required according to local rules/heuristics. Cheers, Danny. -- http://dannyayers.com
Re: Compulsory feed ID?
/ Sam Ruby <[EMAIL PROTECTED]> was heard to say: | What should we do? One way to solve this is to require "id" *and* update | Graham's original proposal accordingly, *and* incorporate it into the next | (and presumably final draft). | | - - - | | That's what I meant by "There is a danger of looking at changes in | isolation.": | |http://www.imc.org/atom-syntax/mail-archive/msg15292.html | | Of course, breaking any link in my complicated chain of logic above would | cause the whole argument to collapse, which would be fine with me. | | Does anybody see something that I am missing? I have to say that the DoS issue hadn't occurred to me before Bob raised it and I've been a bit depressed about it ever since it came up. Is there really anything that we can do here, short of providing a mechanism for signing entries and telling aggregators that a duplicate is an entry with the same id and the same signature? Seems to me if I'm unscrupulous enough to attempt DoS, I can fake all of the required parameters. /me shrugs Be seeing you, norm -- Norman Walsh <[EMAIL PROTECTED]> | Happiness is a how, not a what; a http://nwalsh.com/| talent, not an object.--Herman Hesse pgpm9pkr2fBDr.pgp Description: PGP signature
Re: Compulsory feed ID?
On 5/19/05, Sam Ruby <[EMAIL PROTECTED]> wrote: > Of course, breaking any link in my complicated chain of logic above > would cause the whole argument to collapse, which would be fine with me. Maybe the requirement is useless. "If multiple atom:entry elements with the same atom:id value appear in an Atom Feed document, they describe the same entry and software MUST treat them as such." "MUST treat them as such" isn't particularly meaningful, and two atom:entry elements occuring anywhere are supposed to be describing the same entry. When I get CCed on an atom-syntax message, some of my email programs show two messages, and some show one. It's a security/annoyance trade-off, and I don't see why the format should be making that decision. Robert Sayre
Re: Compulsory feed ID?
Tim Bray wrote: On May 18, 2005, at 9:11 AM, Sam Ruby wrote: There seemed to be consensus that feeds needed something to identify them. What there wasn't consensus on is which element should be that identifier. The solution selected was to make none of the identifiers required - something I don't think has much support, and furthermore creates problems with the ability to cite a source. Paul and I talked this over, and while we're not sure (the email trail was confusing) Sam may be right; so let's find out. Note that it seems pretty clear that the cost of requiring atom:id is nearly zero, since anyone who's generating Atom has to have an ID generator around for entries. So, let's find out if Sam is right: Permit me to provide some more background. I *think* that there is some desire that if the SAME entry appears in multiple places (say, TheServerSide, Java.net, Artima, etc.) that it not appear multiple times. This specific example was called out here: http://www.tbray.org/ongoing/When/200x/2005/04/03/Atom-Now#p-1 I appologize for referencing something outside of the mailing list, and if the item I cited does not represent the consensus of the working group, then the following text should be removed from PaceDuplicateIDs: If multiple atom:entry elements with the same atom:id value appear in an Atom Feed document, they represent the same entry - - - If, however, this above is what we desire (and I certainly support it), let's see what Bob's objection was: http://www.imc.org/atom-syntax/mail-archive/msg14470.html In that, he said: 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. Now, lets take a look again at that text from PaceDuplicateIDs: If multiple atom:entry elements with the same atom:id value appear in an Atom Feed document, they represent the same entry. It seems to me that this does not solve the problem that Bob described. More specifically, if pubsub were to republish data from TheServerSide, Artima, or other places, then the "erasure" that Bob fears would come to pass. What's most puzzling is that it appears that PaceDuplicate IDs was specifically written in response to Bob's concerns: http://www.imc.org/atom-syntax/mail-archive/msg14731.html What is missing in all this is the following, again from Bob's original statement of the problem: 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. This proposal seemed to have enjoyed some support, yet it did not seem to have made it into the current draft, despite being crucial to the solving the issue that PaceDuplicateIDs was designed to address. However, for it to work, the re-aggregator would need to have access to a "self" link, which is not required by the current draft. What should we do? One way to solve this is to require "id" *and* update Graham's original proposal accordingly, *and* incorporate it into the next (and presumably final draft). - - - That's what I meant by "There is a danger of looking at changes in isolation.": http://www.imc.org/atom-syntax/mail-archive/msg15292.html Of course, breaking any link in my complicated chain of logic above would cause the whole argument to collapse, which would be fine with me. Does anybody see something that I am missing? - Sam Ruby
Re: Compulsory feed ID?
On 5/19/05, Tim Bray <[EMAIL PROTECTED]> wrote: > > (Text not > provided, we trust the editors to figure out the correct way to say > this). The editors request that text be provided. Robert Sayre
Compulsory feed ID?
On May 18, 2005, at 9:11 AM, Sam Ruby wrote: There seemed to be consensus that feeds needed something to identify them. What there wasn't consensus on is which element should be that identifier. The solution selected was to make none of the identifiers required - something I don't think has much support, and furthermore creates problems with the ability to cite a source. Paul and I talked this over, and while we're not sure (the email trail was confusing) Sam may be right; so let's find out. Note that it seems pretty clear that the cost of requiring atom:id is nearly zero, since anyone who's generating Atom has to have an ID generator around for entries. So, let's find out if Sam is right: We suggest that there may be WG consensus in favor of changing the format spec to make atom:id a required child of atom:feed. (Text not provided, we trust the editors to figure out the correct way to say this). Please indicate agreement or disagreement with this proposition in the next day or two.
