+1. But let's add something to the effect of consumers MAY ignore
unrecognized CSS/(X)HTML and any CSS/(X)HTML that they are not
confident will not result in security problems.
-1. If the current security documents that cover the material are
insufficient, they should be fixed, and not have it listed in our
document. We should only point to where generic information can be
found and list things that are Atom-specific.
--Paul Hoffman, Director
--Internet Mail
Sam Ruby wrote:
It seems to me that we have an obligation to either (1) disallow HTML,
or (2) mitigate allowing HTML by providing a security section such as
this one.
If (2) can be solved by reference, then that clearly would be preferred.
But to date, no such reference has been found.
So,
-1, agree with Robert.
Graham
On 7 Feb 2005, at 6:35 pm, Robert Sayre wrote:
-1. Covers HTML in too much detail, though it's still inadequate
coverage. This is isn't our problem. I blame the W3C :)
Robert Sayre
On Wednesday, February 2, 2005, at 01:31 AM, Robert Sayre wrote:
Every Atom Processor should carefully consider their handling of every
type of element when processing incoming (X)HTML in Atom documents.
...and might wish to remove all unrecognized elements.
Joe Gregorio wrote:
On Wed, 02 Feb 2005 03:31:18 -0500, Robert Sayre [EMAIL PROTECTED] wrote:
10.1 HTML and XHTML Content
Text Constructs and atom:content allow the delivery of HTML and XHTML
into a client application. Many elements are considered 'unsafe' in that
they open clients to one or more
* Asbjørn Ulsberg [EMAIL PROTECTED] [2005-01-29 06:05+0100]
On Fri, 28 Jan 2005 17:01:06 -0500, Robert Sayre [EMAIL PROTECTED]
wrote:
I guess the question is whether we can and should outline HTML security
issues. I don't think we can or should.
Considering the large amount of
I looked at format-05 and found that the security section is still
pretty anemic. Here is my stab at fleshing out that section:
http://www.intertwingly.net/wiki/pie/PaceFormatSecurity:
===
== Abstract ==
Fill out the security section of the format spec
I don't like stuff like:
All SCRIPT elements should be stripped from Text Constructs or all
native
scripting support of the (X)HTML display engine should be disabled.
I don't think you need to should do any more than outline the threat
model from each tech. Proscribing how to deal with it is
Graham wrote:
I don't like stuff like:
All SCRIPT elements should be stripped from Text Constructs or all
native
scripting support of the (X)HTML display engine should be disabled.
I don't think you need to should do any more than outline the threat
model from each tech. Proscribing how to deal
Joe Gregorio wrote:
Those two references are woefully inadequate, just compare the threats
they outline versus the ones I outline in the Pace. If there were a
good reference of all the problems that HTML can cause when used in
email, *that* would be more in line with what we need, but I was
unable
At 12:56 PM -0800 1/28/05, Tim Bray wrote:
At this point we should appeal to our designated IETF
culture/process experts; Scott/Ted/Paul, any guidance? -Tim
It's up to the WG. If we do a long list, we will probably be told to
make it much longer. If we do security-by-reference, we will probably
Given the two choices, I actually prefer
security-by-reference because it points out the similarity of
what we are doing to other protocols.
I agree. It's also a good practice to have only one authoritative source
that talks about a topic, especially when that source has already been
On Fri, 28 Jan 2005 17:01:06 -0500, Robert Sayre [EMAIL PROTECTED]
wrote:
I guess the question is whether we can and should outline HTML security
issues. I don't think we can or should.
Considering the large amount of (X)HTML that are being syndicated via RSS
and Atom today and will be in
On Fri, 28 Jan 2005 13:21:08 -0800, Tim Bray [EMAIL PROTECTED] wrote:
Whereas you could technically get by with warning-by-reference, I think
that it's OK and fact probably essential to point out that img and
script and object and so on; are potentially lethal;
I agree. However, it is
On Fri, 28 Jan 2005 17:13:26 -0800, Paul Hoffman [EMAIL PROTECTED] wrote:
Many elements are consider 'unsafe' in that they open clients to one or
more types of attack. Every client should consider carefully their
handling of every type of element when processing incoming (X)HTML in
Text
16 matches
Mail list logo
