W3C home > Mailing lists > Public > www-html@w3.org > August 2006

Re: Security Markup

From: Ahmed Saad <ahmed.lists@gmail.com>
Date: Sat, 26 Aug 2006 01:33:29 +0300
Message-ID: <d334e39d0608251533n539b1b2ej5775d1298c42fb14@mail.gmail.com>
Cc: www-html@w3.org

Hello David,

Allow me to get back to your first post because I didn't know you were
talking about the 'nofollow' value of attribute 'rel' ..

On 22/08/06, David Woolley <david@djwhome.demon.co.uk> wrote:
> I think this has the same flaw as the recent Google invention of
> an attribute that prevents third party content links being followed
> in that it is a command to the browser, rather than description
of the content.

Actually it's a command to search engine robots (that's the part where
I got confused) but yes I agree it's "flawed" in some sense that it's
not content description .

> One needs to consider what happens if the attribute is dynamically
> modified by scripting.

It can be blocked from on-the-fly modification as in the case with the
<input type="file" ... /> element ..

On 25/08/06, David Woolley <david@djwhome.demon.co.uk> wrote:
> Google actually set an attribute on their links, but one of the
> criticisms is that it is a specific command to the technology,
> rather than descriptive,

I agreed above and after reading Mark's blog entry [1] and feedback on
this thread, I think that role="userinput" might be more appropriate
in that it's "content description" in some sense and hints the browser
that it shouldn't trust any code contained within

> and the other is that what they really
> should be signalling is that the whole of the third party blog
> comment is unsafe, not just that the links are unsafe.

I  fail to see how this attribtute value is "security-related". What
type of vulnerabilities it  was desinged to protect users from?  I
think it just helps search engines produce quality results ..


[1] http://internet-apps.blogspot.com/2006/08/using-role-attribute-to-extend-xhtml.html
Received on Friday, 25 August 2006 22:40:36 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:06:14 UTC