W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2009

[whatwg] updateWithSanitizedHTML (was Re: innerStaticHTML)

From: Kornel Lesiński <kornel@geekhood.net>
Date: Tue, 1 Dec 2009 16:03:47 +0000
Message-ID: <2502AF94-5039-4729-9C47-7489D06AB196@geekhood.net>

>> And even whitelist for CSS properties couldn't be used to implement  
>> "No
>> external access" policy (allow images with data: urls, allow http:  
>> links,
>> but not http: images). This would be useful for webmails and other  
>> places
>> where website doesn't want to allow 3rd parties tracking views.
>
> I don't think an no external access policy is worth supporting
> explicitly.  If it falls out of a general design, that's great, but I
> don't think the use case is compelling enough to accept the design
> constraints required to support it.

I think it is quite important for privacy. Otherwise "web bugs" can be  
placed and used to track every use of content in every mashup.

Most often I'd like formatted text in applications to be just text,  
_completely_ passive.

>> "No clickjacking" option might be useful as well.
>
> I don't have a clear idea how this would work.  Did you have something
> different in mind than X-Frame-Options (already supported by WebKit)?


On a second thought clickjacking is probably not the right term for  
what I have in mind, although it's a similar issue.

The problem is that content added in DOM could use styles to overlay  
web application's "chrome" and steal data with forms or redirect  
standard links/buttons to phising site, e.g. <form action=evil  
style="position:fixed; top:0; right:0"> that's positioned on top of  
website's standard login form.

Position:fixed escapes elements with  
"position:relative;overflow:hidden", so AFAIK this cannot be prevented  
without removal of all position:fixed styles from untrusted content.

Such hack has been used on auction site allegro.pl, where auctions'  
descriptions are allowed to use CSS. In that particular case content  
should have been filtered server-side, but I imagine webmails, web- 
based feed readers and all kinds of mashups dynamically loading  
untrusted content could face similar problems, and having <iframe> for  
every bit of content is sometimes problematic.

-- 
regards, Kornel
Received on Tuesday, 1 December 2009 08:03:47 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:19 UTC