It's still a work-in-progress, but thanks to the incredible efforts of Felix Roos, the strudel tidal-in-javascript experiment is really coming on:
There's a tutorial here:
Have fun!
18 Likes
It's awesome! For the moment there are only a few elements implemented but it gives an overview of the huge offered possibilities.
If I can submit an idea, it would be great to use sample as in wags/purescript where you can define a variable and download a sample from the desktop in order to use it in the code like in tidal/superdirt.
2 Likes
Love this!
1 Like
Very impressive! Love it 
I wonder whether [strudel] [/strudel] tags work here now..
aha ! The above is created with this:
[strudel]
"a3 [g3 f3]".every(3,fast("1.5")).chunk(4,add("3"))
[/strudel]
2 Likes
Yeah! Very nice.
It works! I made a new thread for sharing patterns: Strudel pattern thread
and a thread category: Strudel - Tidal Club
1 Like
I had some fun with strudel in this streamed performance:
6 Likes
Over on lines, someone asked a security question about the REPL embed:
I'm guessing based on the smidge of reading I did about shift-ast, that the code typed into the REPL gets parsed before being stored, and I'm assuming that what gets echoed back to other users has been re-generated from an ast, resulting in only "approved" or "safe" code.
But since that's merely an assumption, I thought it might be a good idea to ask!
Hmm, good question..
Ouch, see? That's what I get for making assumptions!
Probably there really is a safety concern here then.
It's true that the executed code is re-generated from an ast, but that does not mean it's safe. There are currently no blacklisted functions or anything like that because I think it's rather easy anyway to circumvent those, e.g. you could call a blacklisted alert function like window['ale'+'rt']('hello') Having any kind of online REPL always allows for remote code execution, but there are important things to keep in mind:
- the embedded REPL runs inside an iframe on the domain strudel.tidalcycles.org which means you cannot steal any data from the site it's embedded. From the strudel site, there is nothing to steal from. In other words, iframes are pretty tightly sealed from the site where it is used. try entering
console.log(document.cookie)in both the REPL and the browser console, and you will see a different result. - the code is only executed when the user presses play, so there is at least the chance to read the code before executing
I am just a frontend developer and not a security expert, but I wonder which kinds of attacks could be a problem..
- stealing client storage (cookies / local storage), which should not be a problem because there is none on that domain
- stealing public browser data (see
console.log(navigator)) sending that to some remote server - generally making
fetchrequests to remote servers to get the users IP
That's all I can think right now.. Would be nice if security experts that potentially read this could comment on that. In the end, we have to use some form of eval to let the user enter and run code, which always comes with a risk. When it comes to deciding if this is enough security to allow it to be part of a forum should be decided by the maintainers of it.
I don't see an alarming security risk at this point, and there is always the possibility to block people who try to abuse this tool, which is meant to make music in peace!
some more info eval() - JavaScript | MDN! (strudel uses Function in strict mode and not eval directly, see https://github.com/tidalcycles/strudel/blob/main/packages/eval/evaluate.mjs#L33 )
What you are saying seem sensible, but I wonder if a whitelist might serve as a kind of padlock, not the be-all, end-all of security, but a clear communication of intent that removes some ambiguity from the situation.
But what I just said is non-trivial, and depending on your threat model, may be excessive.
Forums do introduce new threats though. Bots come up with all sorts of ways to take advantage of this read/write medium.
Even if theft or damage is not necessarily easy to accomplish, I can think of a myriad number of ways a troll could use an unfiltered eval() to do trollish things that can be a real nuisance.
Not fun to contemplate, sorry for the bummer vibe.
I'm still very stoked about strudel!
Having a blacklist / whitelist would definitely help, it wouldn't even be too much of a hassle to implement, but also not too much of a hassle to break. Maybe there is also a way to intercept potentially harmful functions like fetch, but at the same time those functions are actually needed, e.g. to load samples.
Anyway it's worth digging deeper into this and find ways to at least make it harder to be a bad actor.
It would also be interesting to know how others do it, like https://codesandbox.io/ .
Of course, as an alternative to embed, you can always send shortened links like this Strudel REPL . But that's of course not as much fun
Yes that seems fine really.
- getting someone's IP could be a concern, but that's possible just by adding a link and getting people to click it
- adding some javascript to mine crypto could be a problem, but you'd only get them to keep the javascript running by embedding it in some really awesome music code, and TBH that seems a fair trade.
- then there's other general griefing/trolling, but that'd be caught by admins immediately, and the discourse forum software is pretty good at keeping spammers out.
If it's really a problem, we can just limit the strudel tag to more trusted users.. Discourse is really good at codifying trust based on how long you've been around, interacted etc.
I would be interested in adding a vim option (as it's hard for me to live code without it at this point), has this already been started or can I start going for it ?
that would be awesome! there is this issue but it did not progress any further Error enabling VIM mode in CodeMirror · Issue #137 · tidalcycles/strudel · GitHub . You should be able to add this package: @replit/codemirror-vim - npm . also related: Use vim mode · Issue #331 · uiwjs/react-codemirror · GitHub feel free to ask any questions here or in tidal discord (strudel channel)
Stack Exchange has a similar solution for the security concerns: Introducing Runnable JavaScript, CSS, and HTML Code Snippets - Stack Overflow Blog
Other than that, adding a Content Security Policy might have some benefits as well.
thanks for that link! looks like they do it similarly + they use the sandbox attribute of iframe which was unknown to me. So if we add that, we should have the same security level as stack exchange which sounds good to me
1 Like
for all the people wondering what happened in the last year of strudel, here is a recap:
2 Likes