Plus editor deletes custom stylesheets

[jmason888]

For years, I have been loading custom stylesheets into my notes to format them the way I like, and using custom classes and custom attributes on some of the tags to refer to them.

Recently, the Plus editor has started to strip these on loading. This entirely breaks my use cases, and what's more it constitutes a loss of data, since the custom classes and attributes contained meaningful metadata. Fortunately, I can retrieve the pre-mangled versions from backup.

I used the Plus editor as a full-featured HTML editor, making changes in code view as I go, then using Plus to render the resulting HTML when I am reading the notes. This is absolutely essential to me: if I didn't need my custom styles, I would have switched to the Bold editor, as it provides basic HTML editing.

Can we please keep Plus as the "advanced" editor, and treat the user's HTML as the user's data, not to be "sanitized" at random times, and have Bold be the simplified editor? I really don't want to have to fork an earlier version of Plus and host it myself... but there have been a rash of changes in the Standard Noted world that have been simplifying/dumbing-down too many features that I make use of daily.

EDIT:
This seems to be a side-effect of #43

[johnny243]

Hey @jmason888, thanks for reaching out to us!

I'm sorry that the recent changes caused you issues. The reason we are sanitizing the content is to prevent executing Javascript code from within a note (this is a potential security risk). This is just a temporal solution until an official fix from summernote.org is out.

On the other hand, custom styles are a valid use case and shouldn't be sanitized, though. So we will be allowing this element!

[jmason888]

@johnny243
Thank you for that. I'm not simply using a custom stylesheet (hosted in Listed), but I am also adding custom classes and attributes to tags, for example
<tr day="Wednesday">,
<p class="meta" time="13:12">, or
<div class="quote">

These were also being purged, and I'm hoping that the DOM editor can be instructed to leave those alone, because not only are they things I use in the css to render specific things, but also because they are contain information that I don't want to lose.

Additionally, I noticed that comments are being purged. I have comments in my Plus notes that I don't want to lose. I supposed I could convert them to <div style="display: none"> or something... but I'd have to do that in the Plain editor, since if I load the note in Plus and then switch to Code view, the comments will be gone. Also, with search not working in protected notes, there are a lot of notes I will have to go through one-at-a-time (or export them unencrypted and grep through the results).

Overall, I'm a bit worried what other things are going to be stripped out of my HTML because dompurify doesn't like it. So far, I can see that comments, some custom classes/attributes, and stylesheets and JS have been stripped. Until this point, I have considered the source code for my Plus notes to be what Standard Notes is preserving, rather than the appearance. Ideally, opening an old Plus note, adding a space at the end, and then deleting it should be a NO-OP, and the source code of the updated note should be identical to the previous one (except for whitespace, of course). If I can no longer rely on that, would I be better off using the Plain or Code editor for these notes, and writing my own extension to display them?

[jmason888]

Additionally, I am using some of my own custom JS to make sections of a note (which are stored in a table row) collapsible. (Hosted in Amazon S3 because, unlike CSS, Listed doesn't have a metatype for JS.)

I guess I can live without that JS though; it's not as essential as the CSS and related classes/attributes. But it was helpful.

I'm trying to figure out what the security risk is in allowing be to run JS in my own notes: I'm the one who wrote the JS, so I'm not concerned about a security risk to my browser: If I write stupid JS, it's my own fault, just the same as if I pasted it into Chrome's developer tools. I guess if there's a security risk to the SN platform that would be another matter.

Again, am I doing this wrong? I want a place to store, edit, and view essentially arbitrary HTML content with a little JS (mostly click handlers on various elements) for interactively controlling the display of the note. I can do that easily of course by putting the notes as raw HTML in S3 and rendering them in my browser, of course, but I'm doing this in Standard Notes because of the convenience, the encryption, and the version history. If I want the source code for these notes to remain (mostly) preserved, should I be editing them in the the Code editor? And maybe thing about a side-by-side render of the resulting HTML, as is done for some of the Markdown editors?

Or should I self-host a custom version of the Plus editor with the dompurify removed, since it did pretty much everything I wanted?

[moughxyz]

@jmason888 we went back and forth on the proper solution to this internally, and chose the filtration method because the Bold Editor seemed to already be doing this and no one had complained about it. However there was a very strong argument for the "libertarian" approach of not meddling with people's notes and giving them the freedom they deserve. SN should be about freedom afterall, and not "censoring" user's notes for their own safety. So in the next release (sometime today hopefully), we're going to take the approach of instead warning the user if we detect the potential for "unsafe content", and giving them the option to proceed or cancel. If they choose to proceed, this preference will be remembered on a per note basis, so you don't have to worry about seeing it over and over again.

[jmason888]

@jmason888 we went back and forth on the proper solution to this internally, and chose the filtration method because the Bold Editor seemed to already be doing this and no one had complained about it. However there was a very strong argument for the "libertarian" approach of not meddling with people's notes and giving them the freedom they deserve. SN should be about freedom afterall, and not "censoring" user's notes for their own safety.

I am very glad to hear that. I was getting worried about the direction that SN was taking, between this change and the inability to search Protected notes (both for reasons that I understand but wish to do anyways). This decisions to take the "libertarian" approach and let the user decide goes a long way towards putting me at ease. (I was never too worried, of course, since SN gives me daily encrypted backups, and also because it's open source...)

In terms of the Plus editor, I deleted the old Plus editor from my extensions list because it was modifying notes on open -- removing it prevents it from opening, so then the Plus notes are forced to open in the Plain editor, which is safe. I'm currently looking to see if Smart Tags are able to query which editor a note uses, so I can search for all my "old-Plus" notes and switch them to Plain.

I'd already forked the Plus editor (and reverted the change on my fork), and was about 30 minutes away from hosting my own local version of Plus without that feature. (It's great that the SN architecture makes that so easy to do...) But if a new release is coming soon, then I might just wait for that and then re-add the "official" Plus editor from the Extensions Repository. I'm totally OK if this delete-and-re-add has the side-effect that I need to re-select Plus as the configured editor for all those Plus notes... in fact I would consider that side-effect a feature.

(In terms of the search thing, it was noted on another thread that this functionality will be re-added in a future release, with an additional authentication prompt. In the meantime, I've found a workaround--which I hope will remain in place, even after the search-in-protected-notes is re-added--a Smart Tag that queries a note's "text" can search inside Protected notes.)

[johnny243]

@jmason888 we have reverted this change. Instead of stripping content from the note, an alert is shown when potentially dangerous code is found. Clicking on Confirm will continue rendering the note (and the alert will not be shown again for the particular note).