property "innerHTML" stopped working in 0.19

[panthershark]

This used to work in elm 0.18 and it doesn't show in the DOM. It looks like a bug

[evancz]

This change was to start ruling out XSS attack vectors in Elm.

If you need help updating some code, folks on slack or discourse can help you find a way to get things going nonetheless!

[panthershark]

I know y'all made your decision and I know that probably will not change, but I'm still gonna take a moment and explain why I think there should be a way to use this... even if it is behind some weird flag or something emits a warning or whatever..

Elm is great. The flame wars on hacker news are dumb and this is not one of them. Please read this with an open mind and consider the trade-offs made here and how they hurt application developers.

The main reason is this: this does not prevent XSS, just obfuscates this and there is no reasonable workaround for application developers that need to inject formatted content. Here are the options that have been proposed:

• ports - this just won't work b/c using a port to manually patch the DOM after elm diff/patch is going to cause side effects.
• iframes - this is an option for some problems, but doesn't work for other scenarios. Also, it is a lot of extra work to make it happen b/c frames must be loaded from the server on a separate url.
• custom element - this is an option, but it has the same problems as innerHTML. Any app that needs to support safari or ie11, must load giant piles of polyfills to use web components..

1. these polyfills are larger than our entire elm apps.
2. these polyfills do not support shadowDOM, only shadyDOM which does not priovide any separation from the main browser context, thus it does not protect from XSS

The assertion that it prevent XSS is at the very least partially untrue. If the goal is prevent package authors from using it, maybe a static analysis tool that must pass before publishing would be preferable to removing a feature of the browser.

Thank you for your time and for making Elm.

[evancz]

What is your specific scenario? What is the nature of the formatted content? Where is it from? How is it created?

[panthershark]

There are 2 scenarios currently in mind:

1. When a server api fails on the server, it formats the error message as html to go with the error code. This can be worked around, but it requires a bunch of elm to take error codes, convert them to error models, then render a template for each error type.

2. Content is authored in a system and presented in elm. The content comes from that system as html. The workaround here is a bloated custom element or iframe that has to round trip to load the content from a special endpoint.

[panthershark]

It seems that custom elements are the preferred way to divert the responsibility away from elm, but with the sad state of IE11 and Safari WRT web components, this doesn't isolate the runtime from XSS. It pushes the work to the application developer.

I think I understand where y'all are coming from with the change. With the state of browsers and compatibility, it might just be a little early to make it impossible to inject html.

[evancz]

Is it true that case (1) can be done by sending JSON over? Maybe with { code : Int, message : String } or something a bit more elaborate? How elaborate would it be? Would the resulting code be harder or easier to maintain than having the server produce raw HTML? I'd imagine the current risk is that changes on the frontend require changes on the backend as well, but it may be pretty non-obvious.

Can you say more about case (2) though? What is the nature of this content? Are you saying that it is produced in some other context that can only produce HTML? What parts of HTML does it produce? Arbitrary tags, or some subset for documents?

[panthershark]

Scenario 1 triggers a backend refactor when upgrading to elm 0.19. While this is extra work for our small team, our architecture allows for reasonable mitigation.

Scenario 2 is a little more problematic. Here are 2 situations:

• In our community, posts are created with a RTE. The content is html and the posts are rendered.

• Document management system - Users upload documents in word, pdf, etc. An offline process converts them to html previews (open office, pdf-to-html utils, etc) so previews can be made available on devices (pdfs are not iOS friendly for inlining). The custom element deficiency is really annoying here and this has been mitigated with iframes.

We can go through all of my use cases, but it seems that we could also look at the proposed alternatives and decide whether those are acceptable solutions, specifically citing the deficiency in safari and ie11.

While I'm not sure I totally agree, I would accept the custom element as a viable solution if the browsers supported it natively.

[panthershark]

This came from a chat in slack earlier about this:

My position is that this solution is akin to hunting a deer with a bazooka. Sure, you get the deer, but you also get a bunch of other stuff .
application developers are the collateral damage.
a rifle with a scope would just ensure XSS is not in packages, but keep compatibility with the underlying platform.

[evancz]

Thank you for sharing more information about your situation. In our 2 month period with the community pre-release, I do not recall anyone raising a situation like this. It is very hard to anticipate scenarios that neither your nor anyone you know has ever done, so again, I appreciate you explaining things in more detail.

For future reference, the slack message you shared is not the kind of evidence that typically goes into a decision. It seems like it is an emotionally satisfying way to vent the root frustration, but ultimately, we try to make decisions based on concrete technical considerations. If that person also has a situation like yours, it would be great to hear that example as well. Again, we did not know this sort of scenario existed for companies using Elm.

I will try to find you on Slack to discuss a bit further. In the meantime, if you find other people in the same scenario, please encourage them to share their technical details here!

[panthershark]

There is nothing emotionally satisfying about the slack situation. We are all respectfully working through our points of view and this is healthy.

We are a 25 person company with 6 engineers (frontend, backend, devops). We build things very quickly and we have an aggressive product roadmap. Elm has been so good for us as a team as a result reduced our team size by 4 front end engineers (from 9 down to 5) and we actually got way better at building things. The unfortunate side effect of this is that we haven't been able to spin up Elm 0.19 ahead of release.

While my position gives me the authority redirect our resources to address the new limitation, this might cause a lot of friction for others as they would have to convince managers or others..

We love Elm and will continue to be a stanch advocate. Again, thank you for making a great language / platform.

Here is another thread about innerHTML if anyone else wants to follow along there as well. elm/virtual-dom#131

[evancz]

I was thinking a bit about the ports idea. You ruled it out in your comment, but I think it is actually a viable path. Here is a rough brainstorm on that route:

type alias Model =
  { previews : Dict String String  -- key is an ID and value is the HTML string
  }

port setPreviews : List (String, String) -> Cmd msg

viewPreview : String -> String -> Html msg
viewPreview key html =
  div [ id key, attribute "data-html" html ] []

And then in JavaScript having something like:

var app = Elm.Main.init();
app.ports.setPreviews.subscribe(function(previews) {
  for (var i = 0; i < previews.length; i++) {
    var node = document.getElementById(previews[i][0]);
    node.innerHTML = previews[i][1];
  }
});

Now I am not 100% sure what virtual DOM will do when people use innerHTML at different times. (It was not written with that as a feature, and I am surprised that what you seem to be describing works in the first place.) But if diffing is causing problems, it seems possible to do a trick like using Html.Keyed.node "div" [] [ ( String.concat (Dict.keys previews), viewPreviews previews ) ] to make sure things get deleted whenever there is a change to the content.

I understand that this is not the ideal path for you, but on the other side of things, we do not want packages out there that insert <script> tags under the guise of a date picker or a credit card entry view. I also understand that in npm there are no protections against that sort of thing and AFAIK there has been no high-profile use of this particular exploit. They pay the cost of having a "reporting" infrastructure where people are doing a bunch of things by hand, and for the money we have to spend on Elm, I don't think it makes sense to use it in that way. I need to balance a bunch of competing concerns like this, so given that we have one concrete example so far, I think it makes sense to pursue this seemingly tractable workaround for now.

[evancz]

Yeah, based on saying it all out loud, I think you could do something like this:

type alias Model = { previews : List Preview }

type alias Preview = { id : String, html : String }

port resetPreviews : () -> Cmd msg

view : Model -> Html msg
view model =
  div []
    [ ...
    , Html.Keyed.node "div" []
        [ ( String.concat (List.map Tuple.first model.previews)
          , viewPreviews model.previews
          )
        ]
    ]

viewPreviews : List Preview -> Html msg
viewPreviews previews =
  div [ id "previews" ] (List.map viewPreview previews)

viewPreview : Preview -> Html msg
viewPreview preview =
  div [ id preview.id, attribute "data-html" preview.html ] []

Now on the JavaScript side you need to handle resetPreviews messages at some interval.

var app = Elm.Main.init();
app.ports.resetPreviews.subscribe(function() {
    var kids = document.getElementById('previews').childNodes;
    for (var i = 0; i < kids.length; i++) {
      kids[i].innerHTML = kids[i].getAttribute('data-html');
    }
  }
});

I'm not 100% all the code here will work as stated, but I think this is closer than the last idea.

[panthershark]

Sure, implementing a thunk with a port is an option. I assume this port needs to be called on every update.. yeah?

Also, does Elm guarantee the port run immediately after DOM patch?

Also, what about using requestAnimationFrame? I'm sure elm is using it internally and what side effects come out of it?