PullJosh wrote:

one thing that could help mitigate the concern is to prevent new users from sharing projects containing Javascript.

djdolphin wrote:

embed it in an iframe to prevent it from screwing with the main frame… some mechanism to ensure that projects can only access the parts of the Snap! cloud they're supposed to… But then there's the question of what to do when the someone wants to edit the project they're viewing, since the editor would need full cloud privileges.

One problem is that “sharing” is an elastic concept. People now share a project in order to make it available to one other person, as well as to make it widely available. (The site will distinguish the former, “sharing,” from the latter, “publishing.”) I hate to put obstacles in the way of the former, although someone could share a project and then tweet the URL, which is where the elasticity comes in. It occurs to me that we might want a third (zeroth, really) notion of “inviting” a specific other user to see your project, although there's also a lot to be said for simplicity.

I'm not sure an iframe will help; the worry is less about messing up the page than, e.g., deleting files or reading passwords. I don't know enough about the JS security model to know what to worry about, and I'd really rather not learn. I hope Jens is on top of this…

About editing vs. viewing, I'm less worried about what happens in the window right away than about what happens a month later when the project is now owned by the user running it but still has code written by the evil original author, and the user no longer remembers having seen a warning dialog about it.

… just had a nice flashback memory to the BYOB 2.99 days, when we plowed through forum pages at this rate every day.

The way text-based sites do it (EDIT: sandbox running highly untrusted code) is that they place the viewing bit in a separate domain to the editing bit. The editing bit has access to the code, and can save it and the like; and the viewing bit is completely sandboxed away because it's on its own domain.

This doesn't work very well because when you click the run(JavaScript()) script, you should see – next to it – a bubble come up showing the return value of your anonymous function. The bit that runs the code needs to tell the editor what to show.

What if we use window.postMessage()

So, we have two things which usually can't access each other.

• The editor (top-level)
  
• The viewer (framed)
  

Whenever the editor wants to run JS code, it sends it to the viewer, who will run it, and then send back the result (it could send back the result multiple times, not at all, etc. because it's running untrusted code, be aware of this).

window.postMessage will send data to another Window object (such as an iframe's) – by emitting a “message” event on that other Window. I threw something together to show roughly what the code would probably look like if this idea were to be used.

Remember, subdomains are dangerous. For example, https://subdomain.example.com can read cookies (and possibly send them?) for https://example.com. However, https://subdomainONE.example.com is safe from https://subdomainTWO.example.com if I'm not mistaken. Be very careful when using them for sandboxing.

jokebookservice1 wrote:

The way text-based sites do it (EDIT: sandbox running highly untrusted code) is that they place the viewing bit in a separate domain to the editing bit. The editing bit has access to the code, and can save it and the like; and the viewing bit is completely sandboxed away because it's on its own domain.

This doesn't work very well because when you click the run(JavaScript()) script, you should see – next to it – a bubble come up showing the return value of your anonymous function. The bit that runs the code needs to tell the editor what to show.

I'm confused. I get that in the current Scratch world, there is a page that has the stage, the notes, and the comments; and there is a page that has the stage and the code. The former is the viewer and the latter the editor. But the editor is also a viewer. (Right now in Snap!, it's the only viewer there is.) So, in your understanding, are there two copies of the code, one to be edited and one to be viewed? And by “code” I mean Snap! code, which includes JSFunction blocks. There would also be two copies of Snap! itself (Javascript code). When you run a JSFunction block, though, it would have to run in both of those copies, since one thing JSFunction blocks do is modify the code of Snap! itself.

So, the two versions have to have a common stage, common blocks, and common Javascript code bases. I'm not seeing how to make this helpful in sandboxing.

oh my! I've missed so much while working!

bharvey wrote:

The problem is that the entire mechanism of likes and comments and followers and rankings and all that was developed for a reason, and the reason isn't to improve human communication. It's to make a lot of money by commodifying people.

I don't think that's totally true though. Certainly, it's partially true, but a completely unfiltered and unorganized list of communications isn't useful either.
For all the stuff we can say about Facebook or other modern social media companies, I don't think they're the originators of all these ideas either – lots of people have wanted to build communities, and in any community people need ways of sorting info.


Other things:

On recommendations: I don't think we need to go “full ML” for doing anything like that – and in any event, unless we actually were to collect tons of data about users' interests and log all their actions and such we're not going to beat any big site. (Even then, Amazon invests millions in trying to make recommendations work, and we obviously aren't going to do that….)

As far as JS security:
The iframe model can help for the viewing of pages, but it really doesn't help tons, IMO. The security issues are the same as when a user opens Snap! in it's own window and runs JS. In that environment, users are already signed into the cloud. We'd need to be able to separate JS in the Snap! IDE that we write (i.e. consumes our cloud API) from JS executed during a script. Plus, the bad things we want to prevent are more than just messing with a user's credentials – like crypto mining or downloading illegal stuff, or who knows what else.

I guess, we could iframe the IDE and use `postMessage` just for the cloud API calls, but then we'd need to prevent scripts from also using `postMessage` which gets tricky because everything in JS is global, and Snap! is open source so I think it'd be fairly easy to circumvent most measures.

This leads me to believe the only sensible thing for JS functions is to maintain whitelists and blacklists, and a warning for stuff in the middle.

Also should we try discussing some of these things on the actual Snap! forum? It seems easier to have actual threads.

Ah, sorry. Where I say “viewer” read “stage”; and, where I say “editor” read the script area (where one drags blocks).

I guess I was thinking that if a JS block has the ability to modify scripts in a project, it can override it (EDIT: override the project in the cloud). Hence, make the script area separate from the stage (in terms of sandboxing), and shove the interpreter into the stage. Then, have the script area send the stage messages like “the user just changed the script to say ‘move 10 steps’, interpreter, please react accordingly”. If the script area needs to know a return value, the stage can send it to the script area. However, the script area should never run unsafe JS. (EDIT: and then the script area's job is to save the project and the like)

Do you know of any JS blocks that are used to change the way the script area looks or works? If there are, sandboxing feels impossible because there's no way to stop evil JS from discarding your changes in a remix.

I suppose we could make it so that when you open a project, that project is only allowed to modify itself when saving. If it needs to override another project, you have to open a page in a new tab and give it permission?

But also, I worry: if JS has the power to modify stuff other than the stage, couldn't it show a nice pop-up saying “We need your username and password, your session expired” and look very convincing?

jokebookservice1 wrote:

Ah, sorry. Where I say “viewer” read “stage”; and, where I say “editor” read the script area (where one drags blocks).

I guess I was thinking that if a JS block has the ability to modify scripts in a project, it can override it (EDIT: override the project in the cloud). Hence, make the script area separate from the stage (in terms of sandboxing), and shove the interpreter into the stage. Then, have the script area send the stage messages like “the user just changed the script to say ‘move 10 steps’, interpreter, please react accordingly”. If the script area needs to know a return value, the stage can send it to the script area. However, the script area should never run unsafe JS. (EDIT: and then the script area's job is to save the project and the like)

Do you know of any JS blocks that are used to change the way the script area looks or works? If there are, sandboxing feels impossible because there's no way to stop evil JS from discarding your changes in a remix.

I suppose we could make it so that when you open a project, that project is only allowed to modify itself when saving. If it needs to override another project, you have to open a page in a new tab and give it permission?

But also, I worry: if JS has the power to modify stuff other than the stage, couldn't it show a nice pop-up saying “We need your username and password, your session expired” and look very convincing?

Yeah, JS can basically do anything. I think this is where moderation + tooling comes in.

I think separating / trying to sandbox the interpreter isn't going to happen because a) I don't think Jens wants to deal with complexities in building that, and b) that seems like it makes keeping Snap! lively more difficult, since you'd need to invite some interface for nearly everything.

Plus, we at least want to be able to write libraries which do lots of modifications, like the bignums library.

It seems like the solution may be to only allow some specific API calls from the Snap! editor URL – that could possibly work? Maybe from within the IDE you can no longer delete projects or make API calls for projects which don't come from the current URL?
It seems like browsers prevent XHR's from spoofing the Referrer header, so perhaps we could specially handle API requests from the IDE?

This still only solves the problem of our own cloud, and not of malicious behavior overall.

cycomachead wrote:

I don't think that's totally true though. Certainly, it's partially true, but a completely unfiltered and unorganized list of communications isn't useful either.
For all the stuff we can say about Facebook or other modern social media companies, I don't think they're the originators of all these ideas either – lots of people have wanted to build communities, and in any community people need ways of sorting info.

You keep posing this either-or, in which we have to choose Facebook or anarchy.

Long before there was Facebook, there was email, and there was Usenet, and we all managed information just fine, and we were mostly nice to each other too.

But Facebook et al aren't the least bit interested in community, or information, or sorting, or organization! And the mechanisms Facebook et al invented – those stars and hearts and votes and followers and “friends” and all that – have absolutely nothing to do with community, or information, etc. They don't help with those goals at all. They are only and entirely about selling you to advertisers. Read the book already!

About security, I'll just let you and @jokebookservice1 work that out.

bharvey wrote:

technoboy10 wrote:

Discourse/bad-spirited posts

Is this saying that Discourse encourages bad-spirited posts? Should we be looking at alternate platforms?

No, sorry, that's sort of a Mastodon-specific phrase. Basically it's a tongue-in-cheek way to refer to intense (and angry and generally unproductive) discussion about controversies. Discourse the forum platform is probably fine, as long as you have decent moderation.

bharvey wrote:

Read the book already!

Is Jaron paying you to market his book here? (Not that it isn't working… )

BTW minor bug, all dates say “Invalid date” in Safari, but work fine in Chrome. https://imgur.com/a/x9pZMQk

Hardmath123 wrote:

Is Jaron paying you to market his book here? (Not that it isn't working… )

I didn't say to buy it! I got it at the library.

BTW minor bug, all dates say “Invalid date” in Safari, but work fine in Chrome. https://imgur.com/a/x9pZMQk

Bug in what? I'm having trouble parsing that picture.

Plus, we at least want to be able to write libraries which do lots of modifications, like the bignums library.

Doesn't bignums just have a special representation for numbers? If so, can we store that representation in the interpreter part – and/or return a safe object to represent each number. I might be misunderstanding something.

If it's that it has to do a lot of back-and-forth in the sandboxing-the-stage model, I personally don't see why it should – but we could use the idea of restricting which API calls you can make – but an evil script will then be able to discard the word of someone remixing a project, though I suppose this is okay.

jokebookservice1 wrote:

Doesn't bignums just have a special representation for numbers? If so, can we store that representation in the interpreter part – and/or return a safe object to represent each number. I might be misunderstanding something.

The issue is that the library replaces a lot of Snap!'s JS code (all the arithmetic primitives!) with its own versions. Once that's done, there's no special problem about the representation.

Of course the best solution to this particular problem would be for all the Snap! users to send Jens an email saying he should make bignum arithmetic the default, as it is in real programming languages.

bharvey wrote:

I didn't say to buy it! I got it at the library.

Okay, a slightly more serious answer: I'm not saying that I agree with every word in the book. He has a bee in his bonnet about copyright and micropayments, and he seriously misunderstands the connection (namely, none) between the free software movement and the free services business plan. But what he says on his main topic, social media, I do support wholeheartedly.

Not Snap! related, but a question for the types of people who spend time here:

I've got an interesting little algorithm puzzle that I'm struggling with, and I want to see if anybody here has a recommendation. Before the school year begins, I'd like to create for myself a small calendar app which helps me evenly distribute a homework workload across multiple days.

Here are the requirements:

• I have a finite list of tasks. The list will generally be small enough (usually < about 12 items) that the speed of the algorithm is not a concern.
  
• Each task has a span of days in which it can be completed. (A task assigned on Monday and due Thursday could be worked on Mon-Wed)
  
• Each task has an estimated time to complete, which is always a multiple of 15 minutes. (A task can be expected to take 15mins, 30mins, 45mins, 1 hour, 1:15, etc…)
  
• The goal is to display, on the calendar, how much time to spend working on each task per day in order to complete everything on time. Each task should have its 15 minute periods spread across its available work days so that the days are as evenly distributed as possible. (However, tasks can not be broken down to finer periods than 15 minute chunks. If I have a 30 minute task over 3 days, it should be split into two 15 minute chunks with one empty day, not three 10 minute chunks). The trick is that I'd like to do so optimally. This means:
  
  1. To the best possible degree, spread out the workload evenly between days.
  2. When possible, equally distribute a task between multiple days (rather than doing it all at once), as long as this does not disturb the even spread per day.
  

Examples:
While attempting to create an algorithm, I did a few of these problems by hand. Perhaps they can be useful examples of the rules above in practice.

Example 1:

• Task #1 can be worked on Monday-Tuesday, and is expected to take 1:15 to complete (five 15 min periods)
  
• Task #2 can only be worked on on Monday, and is expected to take 30mins (2 periods)
  

(Hopefully cubeupload image above loads.)

The final result was to spend 2 periods (30 mins) on task 1 on Monday, and 2 periods (30 mins) on task 2 on Monday (no choice). Then spend 3 periods (45 mins) on task 1 on Tuesday. With a total of 7 periods, the 4/3 split was the best possible.

Example 2:
Image first this time:


All the tasks in this example were split as evenly as possible. (The 5-period task can't be perfectly split, as it's an odd number, but it's the best it can be). It doesn't always work out this fortunately, but it does this time, because the overall day split is 5/5/4 – also the best possible.

Example 3:



The per-day split here is 4/4/3. Notice that the 3-period task is completed all on Wednesday. Generally you'd like to split that task up across more days, but having an even workload per day takes priority, and since nothing can else can happen on Wednesday, the compromise is made.

——————————————

Anybody have any ideas for how to approach this? I'm feeling stuck.

The date bug on the Social Site has a fix in the works, but I don't like any of the ways of fixing it. (Rant omitted about cool but obscure web frameworks.)

Does anyone want to learn Lua? I need someone to verify my fix is stable.
https://github.com/bromagosa/snapCloud/pull/98

Also, does anyone want to help maintain an electron wrapper for Snap!. I'm jumping between 50 million different Snap! things and not really succeeding at completing anything.
Discuss here: https://forum.snap.berkeley.edu/t/maintaining-and-supporting-a-snap-electron-wrapper/114

—

bharvey wrote:

You keep posing this either-or, in which we have to choose Facebook or anarchy.

Long before there was Facebook, there was email, and there was Usenet, and we all managed information just fine, and we were mostly nice to each other too.

But Facebook et al aren't the least bit interested in community, or information, or sorting, or organization! And the mechanisms Facebook et al invented – those stars and hearts and votes and followers and “friends” and all that – have absolutely nothing to do with community, or information, etc. They don't help with those goals at all. They are only and entirely about selling you to advertisers. Read the book already!

I don't think I'm posing things as either-or. Or I'm not trying to. The point that I'm trying to make is though I agree there are problems with following and hearts and such is that they also serve useful purposes that are totally benign. I don't see following someone on Twitter is fundamentally different than following that person's RSS feed, I guess.

I wish I were old enough to be on usenet so I could have a personal frame of reference, but this is what I suspect: traffic on usenet was low enough that you could reasonably follow a topic and get a gist of what's happened. With Reddit, where you have more activity (both by users and by the rate at which users interact), a voting system becomes a useful method of filtering.

The thing that I haven't seen proposed for web apps are tools for people to limit their own use, much like some of the “digital health” stuff that Apple and Google are beginning to add to phones and Facebook is dipping their toes into (because it will get them good PR…). I guess it seems like you can have these things in moderation.

And ok, I probably will just read the book now.

PullJosh wrote:

Here are the requirements:

• I have a finite list of tasks. The list will generally be small enough (usually < about 12 items) that the speed of the algorithm is not a concern.
  
• Each task has a span of days in which it can be completed. (A task assigned on Monday and due Thursday could be worked on Mon-Wed)
  
• Each task has an estimated time to complete, which is always a multiple of 15 minutes. (A task can be expected to take 15mins, 30mins, 45mins, 1 hour, 1:15, etc…)
  
• The goal is to display, on the calendar, how much time to spend working on each task per day in order to complete everything on time. Each task should have its 15 minute periods spread across its available work days so that the days are as evenly distributed as possible. (However, tasks can not be broken down to finer periods than 15 minute chunks. If I have a 30 minute task over 3 days, it should be split into two 15 minute chunks with one empty day, not three 10 minute chunks). The trick is that I'd like to do so optimally. This means:
  
  1. To the best possible degree, spread out the workload evenly between days.
  2. When possible, equally distribute a task between multiple days (rather than doing it all at once), as long as this does not disturb the even spread per day.
  

1) I guess you work differently than I do, but even workloads across days doesn't work that great for me. I'm a do-it-in-one-sitting person, because I usually allocate work time in large uninterrupted chunks where I can focus on the task. Similarly I'd rather spend an hour on Monday doing math and an hour on Tuesday writing an English paper, than spending half an hour on both each day. Things left unfinished leave me uneasy. But that's just me.

2) Use a SAT solver! Ask me if you need help. I'm a solver-aided programming nerd. https://github.com/kach/recreational-rosette

cycomachead wrote:

The date bug on the Social Site has a fix in the works, but I don't like any of the ways of fixing it.

Thanks! Just wanted to make sure you were aware. Sorry it's giving you trouble — sadly, I'm not sure I can help, because I don't remember much Lua (set metatable? *shudder*).

I'm jumping between 50 million different Snap! things and not really succeeding at completing anything.

This is how I feel about my education… college is hard.

Hardmath123 wrote:

college is hard.

Okay, I'll do it, I guess…

College is easy. Comedy is hard!

Hardmath123 wrote:

This is how I feel about my education… college is hard.

Story of my life!

Once I discovered it was physically impossible for me to do even ⅔ of all the required work, survive life, teach and see friends, I felt better about myself. but then I played too much game theory with my grades…but it all worked out!

…and now I miss it…which is why I hang around here / Snap! / etc. I think I might actually do a better job of reading papers now that I'm not required to.

Hardmath123 wrote:

Thanks! Just wanted to make sure you were aware. Sorry it's giving you trouble — sadly, I'm not sure I can help, because I don't remember much Lua (set metatable? *shudder*).

Hah! And no worries. (I'm feel I'm one of the few people around here who seems to not mind bug reports, or even dupes. I'd much rather know all the issues than miss something.)