Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error display let's you get outside the iframe and affect the main site #373

Open
lionleaf opened this issue Aug 7, 2018 · 3 comments
Open
Labels
contributions welcome Feel free to assign this issue to yourself and work on it dweet-breaking good first issue security

Comments

@lionleaf
Copy link
Owner

lionleaf commented Aug 7, 2018

While I'm on the security side; it is possible to post dweets that, while maybe not a real security threat, can really affect the flow of the website by throwing exceptions with interesting strings. For instance hundreds of newlines.

One way to solve it is to deal with those specific instances, ie. don't allow it to grow with newlines etc.

But I suggest we simply disable the viewing of errors when you are not editing the code. Now this breaks some old dweets that relied on throw "text" as a cheap way to print text, but there aren't too many of them. How do people (especially authors of such dweets) feel about this change? As far as I have seen, most of those dweets are fun small ones; not big efforts with hours of golfing (but I could be wrong).

You'd still be able to show of clever throw tricks, you would just have to have the users edit the dweet first.

@MiraR
Copy link

MiraR commented Sep 1, 2018

I think it is a good idea, and the trade-off is worth it. However, that might be easy for me to say since I don't personally have any dweets with throw.

@joeytwiddle
Copy link
Collaborator

joeytwiddle commented Sep 3, 2018

The error message medium has gained some popularity in the last week, and if it isn't shut down I imagine it will eventually be explored in depth(*). I appreciate it was not in the original concept of Dwitter, just a quirky side-effect. I won't mind much if it is muted, but somebody should advocate for it, so...

Here are some downsides to muting the errors:

  • The few classic Dweets which currently use this trick won't be able to show themselves so easily.
  • If a dweet is broken on a particular device, a viewer cannot clearly see and report that error to the author.
  • Malicious dweets can still be malicious, it will just take an extra step to get annoyed by them!

Here is why I like the error messages:

  • I think it's a cute trick people have discovered. It was used a while back: for example, some dweets which calculated PI and displayed it there. And then this battle:

    For a while, throw t was the "shortest animated dweet", until someone beat it with c.x[t].

Suggestion:

The proposal to hide error messages is a simple solution, and simplicity is a virtue. But on the other hand, it should be relatively simple to limit the error output too:

var sanitizedErrorMessage = String(error).split('\n').slice(0,12)
                              .map(line => line.substring(0, 80)).join('\n');

That should limit error messages to at most 80 x 12. But that still might not fix the issue yonatan raised or the kipkat attack: throw '\n'.repeat(6+6*S(t*9))

So I haven't even fully convinced myself we should keep the errors visible. 😢

(*) It appears I was wrong about that. Nobody has touched it for over a week!

@lionleaf
Copy link
Owner Author

lionleaf commented Sep 7, 2018

Alright, I've made up my mind. Even though there's been a good amount of fun error-dweets lately, I want to hide the error display until you edit (you can still view the dweets if you edit it).

If anyone is interested in implementing that fix, just assign yourself to this issue. If not I'll do it whenever I have some time to sit down properly with dwitter again. (I'm basically busy for the next 3-4 weeks, so you'll have some time)

That would also fix #389

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
contributions welcome Feel free to assign this issue to yourself and work on it dweet-breaking good first issue security
Projects
None yet
Development

No branches or pull requests

3 participants