Re: [whatwg] The iframe element and sandboxing ideas
Frode Børli wrote: Yeah, I thought about that also. Then we have more complex attributes such as style='font-family: expression#40;a+5#41;;'... So your sanitizer must also parse CSS properly - including unescaping entities. The way HTML Purifier handles this is unescaping all entities (hex, dec and named) before handling HTML. Output text is always in UTF-8 and thus never has entities. The sanitizer seems very good. I see that your purifier does not allow : in urls (which is an important part of for example Wikipedia urls) - but still it makes it difficult to use javascript: style links. Anyway: how many hours have you spent developing the sanitizer? The discussion was not wether it could be done server side or not. Imagine fetching content from another site using a client side javascript (which it seems HTML 5 will allow). Should the HTML Purifier be implemented in pure javascript as well then - or must the content still do a round trip to the server for sanitasion? A bank want a HTML-messaging system where the customer can write HTML-based messages to customer support trough the online banking system. Customer support personell have access to perform transactions worth millions of dollars trough the intranet web interface (where they also receive HTML-based messages from customers). A few problems with this theoretical situation: 1. Why does the bank need an HTML messaging system? Because the bank wants to be percieved as innovative by its customers? It is not my place to question WHY somebody need a feature. Why is there a manufactorer logo on most cars? It isnt strictly required... 2. Why is this system on the same domain as the intranet web interface? Content is submitted from the banks public website - but customer support handles the mails in the internal webmail system which may be on the same domain.. 3. Why do customer support personell have access to the transaction interface? Better question: is it good that since html-sanitizing cannot be done securely we need more employees? If I contact my account manager he most likely have access to perform tasks on my account, as well as on other customers bank accounts. Security depends on on a perfect sanitizer. Would you sell your sanitizer to this bank without any disclaimers, and say that your sanitizer will be valid for eternity and for all browsers that the bank decides to use internally in the future? Well, it's an open-source sanitizer. But that aside, say, I was selling them a support contract, I would not say valid for eternity. However, Then we need client side sandboxing. Today I would not allow HTML-based messages since I could never be sure enough that the sanitizer was perfect. I encourage you to try out HTML Purifier http://htmlpurifier.org. It's certainly not perfect (we've had a total of two security problems with the core code (three if you count a Shift_JIS related vulnerability, and four if you count an XSS vulnerability in a testing script for the library)), but I hope it certainly approaches it. I really appreciate it and will possibly use it depending on its license. It is a problem (for me) that it cannot use : in its urls. PS: Note that PHP is not perfect, and if you rely on PHP-functions for unescaping etc then a future version of PHP might introduce new bugs. I know from experience... -- Best regards / Med vennlig hilsen Frode Børli Seria.no Mobile: +47 406 16 637 Company: +47 216 90 000 Fax: +47 216 91 000 Think about the environment. Do not print this e-mail unless you really need to. Tenk miljø. Ikke skriv ut denne e-posten dersom det ikke er nødvendig.
Re: [whatwg] The iframe element and sandboxing ideas
A bank sporting a site with a form encouraging the customer to enter arbitrary HTML code would be perceived innovative indeed, albeit in the Monty-Pythonic sense. I can envision the logo: The First Alternative Reality Bank. Hopefully, all its accounts would be run in lindendollars... And no wonder it could afford only one employee. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frode Borli Sent: Saturday, July 26, 2008 9:40 AM To: Edward Z. Yang Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [whatwg] The iframe element and sandboxing ideas Frode Borli wrote: A bank want a HTML-messaging system where the customer can write HTML-based messages to customer support trough the online banking system. Customer support personell have access to perform transactions worth millions of dollars trough the intranet web interface (where they also receive HTML-based messages from customers). A few problems with this theoretical situation: 1. Why does the bank need an HTML messaging system? Because the bank wants to be percieved as innovative by its customers? It is not my place to question WHY somebody need a feature. Why is there a manufactorer logo on most cars? It isnt strictly required... 2. Why is this system on the same domain as the intranet web interface? Content is submitted from the banks public website - but customer support handles the mails in the internal webmail system which may be on the same domain.. 3. Why do customer support personell have access to the transaction interface? Better question: is it good that since html-sanitizing cannot be done securely we need more employees? If I contact my account manager he most likely have access to perform tasks on my account, as well as on other customers bank accounts. Security depends on on a perfect sanitizer. Would you sell your sanitizer to this bank without any disclaimers, and say that your sanitizer will be valid for eternity and for all browsers that the bank decides to use internally in the future? Well, it's an open-source sanitizer. But that aside, say, I was selling them a support contract, I would not say valid for eternity. However, Then we need client side sandboxing.
Re: [whatwg] pushState
It is not customary for desktop applications to change the window title in response to current state of the document it displays. A Web browser is a desktop application and it should not exhibit such behavior either. The place to store information about the latest user action is the Edit menu, although it is optional. The page content can change after page reload thereby making some elements of session state useless or not applicable. This would still be the same page but different content. You can still make arbitrary data into JSON data using e.g. XPath or another moniker convention but, while technically possible, it would hardly be a success in lack of application-dependent intricate logic (consider e.g. the Alias Manager and its lame substitute in Microsoft Windows). Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonas Sicking Sent: Friday, July 25, 2008 11:45 PM To: Ian Hickson Cc: whatwg Subject: Re: [whatwg] pushState Ian Hickson wrote: On Fri, 25 Jul 2008, Jonas Sicking wrote: What is the purpose of the 'title' argument? Is the idea that the UA will show that where it usually shows the title of the page? If so the title isn't purely advisory as it should probably affect document.title as well. This would seem like a good idea to me. The idea is to use this title in the session history. It's distinct than the title and document.title because when the session history might need to say something like Mail - after opening 'compose mail', Mail - after typing paragraph ending in 'JSON-ifyable object.', and so forth, while the whole time the actual page title just says Mail - New Mail. So the idea is that this is the title that we'd display for example in the drop down where you can select a history entry to navigate to? If so, why wouldn't you want document.title to also say Mail - after opening 'compose mail' as well? Seems like good UI to keep the two in sync. What is the purpose of the url attribute? Why would you want to reload a separate page when returning to a given state, then what was used to load that state initially? If the Document gets discarded (e.g. it gets evicted from the bfcache), the URL allows the client to still pretend it has the state, allowing the server to regenerate it based on the data in the URL. But why would you want to recreate the same document using a different page than the page that originally created the document. I.e. if I have a single page that I use to show various views, why would I all of a sudden want to use another page to render one of those views just because the user restarted the browser?
Re: [whatwg] The iframe element and sandboxing ideas
Yes, lets all go back to Word Perfect for DOS and hinder innovation. Besides, this is not the proper arena for this discussion:) 2008/7/26 Kristof Zelechovski [EMAIL PROTECTED]: A bank sporting a site with a form encouraging the customer to enter arbitrary HTML code would be perceived innovative indeed, albeit in the Monty-Pythonic sense. I can envision the logo: The First Alternative Reality Bank. Hopefully, all its accounts would be run in lindendollars... And no wonder it could afford only one employee. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frode Borli Sent: Saturday, July 26, 2008 9:40 AM To: Edward Z. Yang Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [whatwg] The iframe element and sandboxing ideas Frode Borli wrote: A bank want a HTML-messaging system where the customer can write HTML-based messages to customer support trough the online banking system. Customer support personell have access to perform transactions worth millions of dollars trough the intranet web interface (where they also receive HTML-based messages from customers). A few problems with this theoretical situation: 1. Why does the bank need an HTML messaging system? Because the bank wants to be percieved as innovative by its customers? It is not my place to question WHY somebody need a feature. Why is there a manufactorer logo on most cars? It isnt strictly required... 2. Why is this system on the same domain as the intranet web interface? Content is submitted from the banks public website - but customer support handles the mails in the internal webmail system which may be on the same domain.. 3. Why do customer support personell have access to the transaction interface? Better question: is it good that since html-sanitizing cannot be done securely we need more employees? If I contact my account manager he most likely have access to perform tasks on my account, as well as on other customers bank accounts. Security depends on on a perfect sanitizer. Would you sell your sanitizer to this bank without any disclaimers, and say that your sanitizer will be valid for eternity and for all browsers that the bank decides to use internally in the future? Well, it's an open-source sanitizer. But that aside, say, I was selling them a support contract, I would not say valid for eternity. However, Then we need client side sandboxing. -- Best regards / Med vennlig hilsen Frode Børli Seria.no Mobile: +47 406 16 637 Company: +47 216 90 000 Fax: +47 216 91 000 Think about the environment. Do not print this e-mail unless you really need to. Tenk miljø. Ikke skriv ut denne e-posten dersom det ikke er nødvendig.
