Re: Some implementations don't process the HEAD element correctly

View: New views

4 Messages — Rating Filter: Alert me

	Re: Some implementations don't process the HEAD element correctly by Andrew Arnott :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Thanks, Thomas. I hadn't meant to drop the list with my reply. You're points are all correct too. I guess my only argument is: a fully compliant HTML parser in an OpenID RP library would be very heavyweight, and anything less would mean it's buggy. So far, the community seems satisfied with "mostly there" implementations. I agree it's not perfect, but in the next major OpenID spec, HTML discovery is likely to be removed anyway, so I don't think any implementers have motivation to fix these bugs that can easily be worked around. BTW, missing HEAD tags is just one bug, and it seems disproportionate to stress this one over all the others. Some of which are perhaps more serious. I imagine many RPs don't ignore LINK tags that appear within HTML <!-- comments -->. And to properly respect comments requires Javascript parsing (I think!) in order to avoid ending the comment when a javascript function contains a string with "-->" in it. Just some more thoughts. As an RP implementer myself, I do fix some HTML discovery bugs that come in, but not all of them for the reasons given above. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre On Wed, Aug 26, 2009 at 7:39 AM, Thomas Hühn <huehn@...> wrote: [you mailed off-list, was that intentional?] Andrew Arnott schrieb: > The difference is "<LINK>" might appear somewhere in the <BODY> of the > page Not in a valid HTML document. :-) Of course you have to think about invalid ones as well, because browsers accept them. But that doesn't have anything to do with whether there is a <HEAD> tag. The security implications are totally independent from having or omitting HEAD tags. Look, it's perfectly clear at any point in the HTML text whether this point belongs to HEAD or to BODY. The HEAD tags are irrelevant. Google even recommends omitting them: http://code.google.com/speed/articles/optimizing-html.html I agree with Shade. It's sub-optimal security for OpenID RPs to try grokking HTML in the first place. I'm sure if you tried everything Of course parsing HTML is hell, but you have specified it. "legal", you'd likely find dozens of ways that RPs are imperfect. But since delegation is a relatively rare scenario anyway (hundreds of millions of OpenIDs out there today, only a few actually delegate since it's an advanced user scenario) I think it's very reasonable to put a few restrictions on it so that RPs can be more secure and written more easily. That doesn't change anything. Everything you're saying is absolutely right. But it doesn't have anything to do with whether the HEAD element is surrounded by HEAD tags. My example is valid, by the OpenID specification. I have placed LINK elements inside the HEAD element. That's what the OpenID spec demands. The implementation is buggy. Yes, that's a fringe case. I can't really blame the author for not thinking about this. And the spec is fine by itself but could be improved for the benefit of developers and users. So there are several ways to handle it: 1. The status quo -- don't do anything: perfectly okay, but probably many more implementations will be buggy, without the developers even knowing about the pitfall. 2. making clear in the spec that the HEAD element does not necessarily correspond to HEAD tags and that a simple grep is wrong. 3. re-wording the spec so that it is clear that only a subset of HTML is supported, requiring the HEAD tag(s). I'd prefer 2., just adding a non-normative note to the spec. Thomas _______________________________________________ specs mailing list specs@... http://lists.openid.net/mailman/listinfo/openid-specs
	Re: Some implementations don't process the HEAD element correctly by John Bradley-7 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message There is talk of removing HTML discovery in future. It is a known security problem. Yadis requires the X-XRDS meta tag to be inside the <head> element. OpenID 2.0 is silent on it. Getting rid of the meta http-eqiv tag from the HTML will be a challenge, and a point for debate. I think the other elements will go except for backwards compatibility with older RPs. John B. On 26-Aug-09, at 10:51 AM, Andrew Arnott wrote: Thanks, Thomas. I hadn't meant to drop the list with my reply. You're points are all correct too. I guess my only argument is: a fully compliant HTML parser in an OpenID RP library would be very heavyweight, and anything less would mean it's buggy. So far, the community seems satisfied with "mostly there" implementations. I agree it's not perfect, but in the next major OpenID spec, HTML discovery is likely to be removed anyway, so I don't think any implementers have motivation to fix these bugs that can easily be worked around. BTW, missing HEAD tags is just one bug, and it seems disproportionate to stress this one over all the others. Some of which are perhaps more serious. I imagine many RPs don't ignore LINK tags that appear within HTML <!-- comments -->. And to properly respect comments requires Javascript parsing (I think!) in order to avoid ending the comment when a javascript function contains a string with "-->" in it. Just some more thoughts. As an RP implementer myself, I do fix some HTML discovery bugs that come in, but not all of them for the reasons given above. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre On Wed, Aug 26, 2009 at 7:39 AM, Thomas Hühn <huehn@...> wrote: [you mailed off-list, was that intentional?] Andrew Arnott schrieb: > The difference is "<LINK>" might appear somewhere in the <BODY> of the > page Not in a valid HTML document. :-) Of course you have to think about invalid ones as well, because browsers accept them. But that doesn't have anything to do with whether there is a <HEAD> tag. The security implications are totally independent from having or omitting HEAD tags. Look, it's perfectly clear at any point in the HTML text whether this point belongs to HEAD or to BODY. The HEAD tags are irrelevant. Google even recommends omitting them: http://code.google.com/speed/articles/optimizing-html.html I agree with Shade. It's sub-optimal security for OpenID RPs to try grokking HTML in the first place. I'm sure if you tried everything Of course parsing HTML is hell, but you have specified it. "legal", you'd likely find dozens of ways that RPs are imperfect. But since delegation is a relatively rare scenario anyway (hundreds of millions of OpenIDs out there today, only a few actually delegate since it's an advanced user scenario) I think it's very reasonable to put a few restrictions on it so that RPs can be more secure and written more easily. That doesn't change anything. Everything you're saying is absolutely right. But it doesn't have anything to do with whether the HEAD element is surrounded by HEAD tags. My example is valid, by the OpenID specification. I have placed LINK elements inside the HEAD element. That's what the OpenID spec demands. The implementation is buggy. Yes, that's a fringe case. I can't really blame the author for not thinking about this. And the spec is fine by itself but could be improved for the benefit of developers and users. So there are several ways to handle it: 1. The status quo -- don't do anything: perfectly okay, but probably many more implementations will be buggy, without the developers even knowing about the pitfall. 2. making clear in the spec that the HEAD element does not necessarily correspond to HEAD tags and that a simple grep is wrong. 3. re-wording the spec so that it is clear that only a subset of HTML is supported, requiring the HEAD tag(s). I'd prefer 2., just adding a non-normative note to the spec. Thomas _______________________________________________ specs mailing list specs@... http://lists.openid.net/mailman/listinfo/openid-specs _______________________________________________ specs mailing list specs@... http://lists.openid.net/mailman/listinfo/openid-specs
	Re: Some implementations don't process the HEAD element correctly by Josh Hoyt-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message On Wed, Aug 26, 2009 at 8:24 AM, John Bradley<john.bradley@...> wrote: > Yadis requires the X-XRDS meta tag to be inside the <head> element. > OpenID 2.0 is silent on it. This is a little unfair to the OpenID 2.0 specification, since in order for a document to BE valid HTML[1] or XHTML[2], META tags are only allowed to be in the HEAD. It might have been nice for implementers if that relevant bit of information were duplicated in the OpenID 2.0 specification, but even without it, the requirement is well-specified. Josh 1. http://www.w3.org/TR/html401/sgml/dtd.html 2. http://www.w3.org/TR/xhtml1/dtds.html _______________________________________________ specs mailing list specs@... http://lists.openid.net/mailman/listinfo/openid-specs
	Re: Some implementations don't process the HEAD element correctly by John Bradley-7 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Sorry I was unclear. I wasn't criticizing openID 2.0 for being silent on where the meta tag for X-XRDS. Only that there is no requirement in the spec to place the other tags in the HEAD. That is the only unfortunate part. John B. On 26-Aug-09, at 4:48 PM, Josh Hoyt wrote: > On Wed, Aug 26, 2009 at 8:24 AM, John > Bradley<john.bradley@...> wrote: >> Yadis requires the X-XRDS meta tag to be inside the <head> element. >> OpenID 2.0 is silent on it. > > This is a little unfair to the OpenID 2.0 specification, since in > order for a document to BE valid HTML[1] or XHTML[2], META tags are > only allowed to be in the HEAD. > > It might have been nice for implementers if that relevant bit of > information were duplicated in the OpenID 2.0 specification, but even > without it, the requirement is well-specified. > > Josh > > 1. http://www.w3.org/TR/html401/sgml/dtd.html > 2. http://www.w3.org/TR/xhtml1/dtds.html _______________________________________________ specs mailing list specs@... http://lists.openid.net/mailman/listinfo/openid-specs

	Re: Some implementations don't process the HEAD element correctly by Andrew Arnott :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Thanks, Thomas. I hadn't meant to drop the list with my reply. You're points are all correct too. I guess my only argument is: a fully compliant HTML parser in an OpenID RP library would be very heavyweight, and anything less would mean it's buggy. So far, the community seems satisfied with "mostly there" implementations. I agree it's not perfect, but in the next major OpenID spec, HTML discovery is likely to be removed anyway, so I don't think any implementers have motivation to fix these bugs that can easily be worked around. BTW, missing HEAD tags is just one bug, and it seems disproportionate to stress this one over all the others. Some of which are perhaps more serious. I imagine many RPs don't ignore LINK tags that appear within HTML <!-- comments -->. And to properly respect comments requires Javascript parsing (I think!) in order to avoid ending the comment when a javascript function contains a string with "-->" in it. Just some more thoughts. As an RP implementer myself, I do fix some HTML discovery bugs that come in, but not all of them for the reasons given above. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre On Wed, Aug 26, 2009 at 7:39 AM, Thomas Hühn <huehn@...> wrote: [you mailed off-list, was that intentional?] Andrew Arnott schrieb: > The difference is "<LINK>" might appear somewhere in the <BODY> of the > page Not in a valid HTML document. :-) Of course you have to think about invalid ones as well, because browsers accept them. But that doesn't have anything to do with whether there is a <HEAD> tag. The security implications are totally independent from having or omitting HEAD tags. Look, it's perfectly clear at any point in the HTML text whether this point belongs to HEAD or to BODY. The HEAD tags are irrelevant. Google even recommends omitting them: http://code.google.com/speed/articles/optimizing-html.html I agree with Shade. It's sub-optimal security for OpenID RPs to try grokking HTML in the first place. I'm sure if you tried everything Of course parsing HTML is hell, but you have specified it. "legal", you'd likely find dozens of ways that RPs are imperfect. But since delegation is a relatively rare scenario anyway (hundreds of millions of OpenIDs out there today, only a few actually delegate since it's an advanced user scenario) I think it's very reasonable to put a few restrictions on it so that RPs can be more secure and written more easily. That doesn't change anything. Everything you're saying is absolutely right. But it doesn't have anything to do with whether the HEAD element is surrounded by HEAD tags. My example is valid, by the OpenID specification. I have placed LINK elements inside the HEAD element. That's what the OpenID spec demands. The implementation is buggy. Yes, that's a fringe case. I can't really blame the author for not thinking about this. And the spec is fine by itself but could be improved for the benefit of developers and users. So there are several ways to handle it: 1. The status quo -- don't do anything: perfectly okay, but probably many more implementations will be buggy, without the developers even knowing about the pitfall. 2. making clear in the spec that the HEAD element does not necessarily correspond to HEAD tags and that a simple grep is wrong. 3. re-wording the spec so that it is clear that only a subset of HTML is supported, requiring the HEAD tag(s). I'd prefer 2., just adding a non-normative note to the spec. Thomas _______________________________________________ specs mailing list specs@... http://lists.openid.net/mailman/listinfo/openid-specs
	Re: Some implementations don't process the HEAD element correctly by John Bradley-7 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message There is talk of removing HTML discovery in future. It is a known security problem. Yadis requires the X-XRDS meta tag to be inside the <head> element. OpenID 2.0 is silent on it. Getting rid of the meta http-eqiv tag from the HTML will be a challenge, and a point for debate. I think the other elements will go except for backwards compatibility with older RPs. John B. On 26-Aug-09, at 10:51 AM, Andrew Arnott wrote: Thanks, Thomas. I hadn't meant to drop the list with my reply. You're points are all correct too. I guess my only argument is: a fully compliant HTML parser in an OpenID RP library would be very heavyweight, and anything less would mean it's buggy. So far, the community seems satisfied with "mostly there" implementations. I agree it's not perfect, but in the next major OpenID spec, HTML discovery is likely to be removed anyway, so I don't think any implementers have motivation to fix these bugs that can easily be worked around. BTW, missing HEAD tags is just one bug, and it seems disproportionate to stress this one over all the others. Some of which are perhaps more serious. I imagine many RPs don't ignore LINK tags that appear within HTML <!-- comments -->. And to properly respect comments requires Javascript parsing (I think!) in order to avoid ending the comment when a javascript function contains a string with "-->" in it. Just some more thoughts. As an RP implementer myself, I do fix some HTML discovery bugs that come in, but not all of them for the reasons given above. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre On Wed, Aug 26, 2009 at 7:39 AM, Thomas Hühn <huehn@...> wrote: [you mailed off-list, was that intentional?] Andrew Arnott schrieb: > The difference is "<LINK>" might appear somewhere in the <BODY> of the > page Not in a valid HTML document. :-) Of course you have to think about invalid ones as well, because browsers accept them. But that doesn't have anything to do with whether there is a <HEAD> tag. The security implications are totally independent from having or omitting HEAD tags. Look, it's perfectly clear at any point in the HTML text whether this point belongs to HEAD or to BODY. The HEAD tags are irrelevant. Google even recommends omitting them: http://code.google.com/speed/articles/optimizing-html.html I agree with Shade. It's sub-optimal security for OpenID RPs to try grokking HTML in the first place. I'm sure if you tried everything Of course parsing HTML is hell, but you have specified it. "legal", you'd likely find dozens of ways that RPs are imperfect. But since delegation is a relatively rare scenario anyway (hundreds of millions of OpenIDs out there today, only a few actually delegate since it's an advanced user scenario) I think it's very reasonable to put a few restrictions on it so that RPs can be more secure and written more easily. That doesn't change anything. Everything you're saying is absolutely right. But it doesn't have anything to do with whether the HEAD element is surrounded by HEAD tags. My example is valid, by the OpenID specification. I have placed LINK elements inside the HEAD element. That's what the OpenID spec demands. The implementation is buggy. Yes, that's a fringe case. I can't really blame the author for not thinking about this. And the spec is fine by itself but could be improved for the benefit of developers and users. So there are several ways to handle it: 1. The status quo -- don't do anything: perfectly okay, but probably many more implementations will be buggy, without the developers even knowing about the pitfall. 2. making clear in the spec that the HEAD element does not necessarily correspond to HEAD tags and that a simple grep is wrong. 3. re-wording the spec so that it is clear that only a subset of HTML is supported, requiring the HEAD tag(s). I'd prefer 2., just adding a non-normative note to the spec. Thomas _______________________________________________ specs mailing list specs@... http://lists.openid.net/mailman/listinfo/openid-specs _______________________________________________ specs mailing list specs@... http://lists.openid.net/mailman/listinfo/openid-specs
	Re: Some implementations don't process the HEAD element correctly by Josh Hoyt-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message On Wed, Aug 26, 2009 at 8:24 AM, John Bradley<john.bradley@...> wrote: > Yadis requires the X-XRDS meta tag to be inside the <head> element. > OpenID 2.0 is silent on it. This is a little unfair to the OpenID 2.0 specification, since in order for a document to BE valid HTML[1] or XHTML[2], META tags are only allowed to be in the HEAD. It might have been nice for implementers if that relevant bit of information were duplicated in the OpenID 2.0 specification, but even without it, the requirement is well-specified. Josh 1. http://www.w3.org/TR/html401/sgml/dtd.html 2. http://www.w3.org/TR/xhtml1/dtds.html _______________________________________________ specs mailing list specs@... http://lists.openid.net/mailman/listinfo/openid-specs
	Re: Some implementations don't process the HEAD element correctly by John Bradley-7 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Sorry I was unclear. I wasn't criticizing openID 2.0 for being silent on where the meta tag for X-XRDS. Only that there is no requirement in the spec to place the other tags in the HEAD. That is the only unfortunate part. John B. On 26-Aug-09, at 4:48 PM, Josh Hoyt wrote: > On Wed, Aug 26, 2009 at 8:24 AM, John > Bradley<john.bradley@...> wrote: >> Yadis requires the X-XRDS meta tag to be inside the <head> element. >> OpenID 2.0 is silent on it. > > This is a little unfair to the OpenID 2.0 specification, since in > order for a document to BE valid HTML[1] or XHTML[2], META tags are > only allowed to be in the HEAD. > > It might have been nice for implementers if that relevant bit of > information were duplicated in the OpenID 2.0 specification, but even > without it, the requirement is well-specified. > > Josh > > 1. http://www.w3.org/TR/html401/sgml/dtd.html > 2. http://www.w3.org/TR/xhtml1/dtds.html _______________________________________________ specs mailing list specs@... http://lists.openid.net/mailman/listinfo/openid-specs