-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
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, eng
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 :)
I'm +1 on the pace, particularly now that the prescriptive text has been
removed.
It seems to me that we have an obligation to either (1) disallow HTML,
o
-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 Consortiu
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
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 type
I had updated PaceFormatSecuruty based on feedback, removing all
the proscriptive prose about removing elements and just pointing out
potential security problems.
-joe
--
Joe Gregoriohttp://bitworking.org
On Feb 2, 2005, at 12:31 AM, Robert Sayre wrote:
10.1 HTML and XHTML Content
I've dressed this up as PaceSecuritySection:
http://www.intertwingly.net/wiki/pie/PaceSecuritySection
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.
Tim Bray wrote:
There was a huge amount of discussion around PaceFormatSecurity, with
input from our AD, and what smelled like converging language on the
list. Is someone going to update the Pace to take that into account?
-Tim
---
10.1 HTML and XHTML Content
Text Constr
* Dan Brickley wrote:
>> Considering the large amount of (X)HTML that are being syndicated via RSS
>> and Atom today and will be in the future, I think we should. (X)HTML will
>> be the main markup used inside all Atom Text Constructs, and while MathML,
>> SVG and other markup languages we d
* Tim Bray wrote:
>At this point we should appeal to our designated IETF culture/process
>experts; Scott/Ted/Paul, any guidance?
http://www.ietf.org/rfc/rfc3552.txt
--
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www
* 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 a
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 Con
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 and
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
> 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
thr
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
On Friday, January 28, 2005, at 02:40 PM, Robert Sayre wrote:
Tim Bray wrote:
On Jan 28, 2005, at 12:55 PM, Robert Sayre wrote:
> I would strike all the details on HTML, leave the first paragraph,
> and refer to the security sections of RFC 2854 and HTML 4.01.
Whereas you could technically get b
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
On Fri, 28 Jan 2005 15:55:10 -0500, Robert Sayre <[EMAIL PROTECTED]> wrote:
> 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 th
Tim Bray wrote:
On Jan 28, 2005, at 12:55 PM, Robert Sayre wrote:
> I would strike all the details on HTML, leave the first paragraph,
> and refer to the security sections of RFC 2854 and HTML 4.01.
Whereas you could technically get by with warning-by-reference, I
think that it's OK and fact pro
On Friday, January 28, 2005, at 01:55 PM, Robert Sayre wrote:
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 o
On Jan 28, 2005, at 12:55 PM, Robert Sayre wrote:
I would strike all the details on HTML, leave the first paragraph, and
refer to the security sections of RFC 2854 and HTML 4.01.
Whereas you could technically get by with warning-by-reference, I think
that it's OK and fact probably essential to po
On Jan 28, 2005, at 12:09 PM, 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 eac
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 dea
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 n
27 matches
Mail list logo
