Created ticket here: https://issues.apache.org/jira/browse/FLEX-35246 to track this.
Thanks, Om On Wed, Jan 4, 2017 at 6:31 PM, OmPrakash Muppirala <bigosma...@gmail.com> wrote: > > > On Wed, Jan 4, 2017 at 6:08 PM, Alex Harui <aha...@adobe.com> wrote: > >> >> >> On 1/4/17, 3:40 PM, "omup...@gmail.com on behalf of OmPrakash Muppirala" >> <omup...@gmail.com on behalf of bigosma...@gmail.com> wrote: >> >> >> >> >> However, I disagree with the notion that everything we do must be >> >> bullet-proof. >> > >> > >> >I never presented that notion. It seems to me that you are using the >> >slippery-slope argument. I am suggesting a very basic protection from a >> >very common type of security risk. I gave you several examples where >> >other >> >frameworks provide same or similar protection in their UI components. >> >> Well, you wrote "My goal is to not allow a developer to inadvertently add >> a bad piece of HTML to the DOM (IAaBPoHTML2DOM)." That sounds like a big >> goal to me. > > > Ah I see. But if you think about it, that is not such a big goal given > that FlexJS nearly makes it impossible to write HTML content directly. > Which is why I started this thread. > > >> Plus you proposed changes to both Express and Basic >> libraries. If your goal is just to make sure folks don't use Express >> HTMLText with bad HTML, that makes sense to me. >> >> > >> > >> >> Not everybody wants to or needs to ride around in a >> >> military-grade vehicle. Go make the changes you want in the Express >> >> component set, but please let others like myself create a low-level >> >>direct >> >> access to the DOM for those who have appropriately sanitized their code >> >> some other way. I will name it UnsecuredHTMLText. >> >> >> > >> >What in my proposal will prevent you from making your own component with >> >low-level direct access to the DOM? >> >> Because I am proposing a way for a developer to IAaBPoHTML2DOM. >> >> >> Realize that when you >> >> build the team page, if we sanitize the team data some other way, all >> of >> >> the security code you write will run and never catch anything. To me, >> >> that's not a great example of PAYG. >> >> >> > >> >We are not writing the component set for one use case. I have previously >> >provided examples where the user has no control over where the HTML comes >> >from. I thinking running a sanitizer on a HTML string is a very good >> >tradeoff. I guess this is where we disagree. >> >> No, we don't disagree on what you wrote above, but IMO, your proposal is >> not the only possible solution, and in many cases, it will not perform as >> well as other solutions. I am in favor of allowing other solutions, even >> though improper use of them will allow someone to IAaBPoHTML2DOM. Do you >> agree there is more than one way to secure an application? If so, then >> let's allow those different ways. >> >> > >> >Even if that is not acceptable, if the user uses the >> >InsecureNoHTMLSanitizer, it is a simple function call which returns the >> >same string back, essentially a no-op. There is no time spent on >> >analyzing >> >the HTML string. >> > >> >Is this also a not acceptable as a tradeoff? What is your definition of >> a >> >trade-off? >> >> You write HTMLText the way you want to. I think your proposal for it is >> exactly what I would do. I will write UnsecuredHTMLText. >> UnsecuredHTMLText will be smaller and faster. Will it matter to someone? >> Don't know, but the whole point of Basic is to be, well, basic. >> > > Okay, sounds good to me. It wasn't clear you meant this in your previous > email. If you are going to call your component 'UnsecuredHTMLText', any > usage of it is not going to be inadvertent. I think my goal still holds > good. > > I think we are good here. I will start coding this soon. > > Thank you for your patience in working this out :-) > > Regards, > Om >
