[erlang-questions] Two beautiful programs - or web programming made easy

[Joe Armstrong]

2011/2/14 Frédéric Trottier-Hébert <fred.hebert@REDACTED>

> Replies are still in between bits of text.
> On 2011-02-13, at 15:43 PM, Edmond Begumisa wrote:
>
> > On Mon, 14 Feb 2011 05:59:19 +1100, Frédéric Trottier-Hébert <
> fred.hebert@REDACTED> wrote:
> >
> >>
> >> On 2011-02-12, at 06:33 AM, Joe Armstrong wrote:
> >>
> >>>
> >>> The Javascript equivalent is:
> >>>
> >>>  function onMessage(evt) {
> >>>     eval(evt.data);
> >>>  }
> >>>
> >>> Where the data comes from a websocket.
> >>>
> >> This is rather risky. Eval will take any code whatsoever and run it for
> you.
> >
> > Likewise the browser will take any static js (<script> tags) whatsoever
> from your server and run it for you.
>
> Right. This is why ideally you want to pass in very precise function and do
> something RPC-like (despite Joe not liking it) or have your own parser (as
> it is the case with JSON). It's not that it's impossible to make the other
> ways safe, but I wouldn't trust most people (including myself) to get it
> right most of the time.
> >
> >> If you have dynamic content, without proper escaping and being very
> careful, users could run arbitrary code in your page, including stuff to
> steal session data and send it over to either some other site, or perform
> actions for the user which they do not necessarily approve on (making their
> profile public, closing their account, worms, etc.)
> >>
> >
> > Likewise if you have any dynamic content in js code on your server
> without proper escaping and not being very careful, users could...
>
> Exactly. You're always as safe as your weakest link. Some frameworks (like
> JQuery on some methods) handle it for you, but usually there is no such
> thing for 'eval'.
>
> > ... Don't the "same source" XXS rule for non-evaled code apply to evaled
> code? Doesn't the same duty of care to end-users for protecting privacy,
> properly escaping data, etc, apply in both cases? Don't you have to be
> careful either way?
> >
>
> Yes. But some ways to do things are safer than others by default. The
> problem with 'doing things right' is how much trust you put in yourself and
> your team of developers. I'm of the opinion that most people who feel good
> enough to handle security actually overlook a lot of it. Have you always
> checked everything for XSS in all encodings? CSRF? Ever used something like
> MD5 or SHA to hash passwords? Sent such passwords over e-mail, etc? Those
> are very basic options and I can tell you that most developers to have
> worked on the web had a problem with at least one of these at some point or
> another one. Hell, even gmail had sever CSRF holes at some point that let
> people randomly inject themselves into your forwarded email adresses.
>
> Security is hard, and stepping clear of the risky line is often a good
> option if you're not 100% sure of what you're doing. A cook skilled enough
> can likely prepare a meal while juggling with knives safely, but it's often
> not necessary to do so, and often not appropriate for everyone to follow
> that line either.
>
> >> In fact, this is a reason why people like Douglas Crockford prefered to
> write JSON parsers rather than just evaluating them. It's just not safe
> enough.
> >>
> >
> > Indeed you are correct, but...
> >
> > From http://www.json.org/js.html ...
> >
> > "...The use of eval is indicated when the source is *trusted* and
> *competent*..."
>
> The *competent* part is the one that worries me. I think most developers
> (myself included) tend to overestimate their competence when it comes to
> security.
> >
> > "...In web applications over XMLHttpRequest, communication is permitted
> only to the same origin that provide that page, so it is *trusted*. But it
> *might not be competent*. If the server is not rigorous in its JSON
> encoding, or if it does not scrupulously validate all of its inputs, then it
> could deliver invalid JSON text that could be carrying dangerous script..."
> >
> > So it boils down to the competence of the code on the server. You have to
> be careful how you construct your pages and javascript. But then, this
> should *always* be the case.
>
> Yes, agreed. Again, I'm supporting the position of 'why risk it?' not the
> line of 'it's impossible to be safe!'
>
> >> Plus you have to call the javascript parser and whatnot, which is
> usually rather slow.
> >
> > One could send core of the app logic in a static js file then have the
> eval only making simple calls like "appui.getInvoinces()". That will perform
> fairly well.
>
> Yes, if the invoices do contain fairly limited and well-defined data that
> you know can *never* cause a problem.
> >
> >> The whole idea is pretty bad on the web, where you have to assume that
> people will actively try to break your stuff and steal data from other users
> (or you).
> >>
> >
> > That assumption is a bit dramatic. Questions on security cannot be viewed
> in isolation of application. One of my favorite quotes from Bruce Schneier
> is applicable here. He was once asked about the possibility of chaos ensuing
> due to internet security breaches...
> >
> > "No. Chaos is hard to create, even on the Internet. Here's an example. Go
> to Amazon.com. Buy a book without using SSL. Watch the total lack of chaos."
>
> The idea is fairly dramatic, but the concept is basically that once
> someone's got an axe to grind against you or your applications, then someone
> actively trying to break your stuff is *actually* going to happen. A lax
> attitude is what made one of our products (at some previous job) vulnerable
> to Russian hackers who ended up emailing customers with addresses stolen
> straight out of our databases. When it happens, it's already too late to
> react.
> >
> > I don't see how you can canvas the "whole idea" as being bad. It may
> require adjustments here and there. e.g For particular pages where paranoid
> security is needed, nothing stops you from doing it differently there. You
> could crypto what's sent. You could even serve those pages the standard way
> with static files and SSL if it makes you feel safer.
>
> SSL is protecting you against things like man-in-the-middle attacks.
> Encryption helps you on other points. There is nothing there regarding
> problems with application-level security. The whole idea is not bad, but I
> would certainly want a serious specialist to look over my application if I
> were to use that trick in many places.
>
>
> >
> >>>
> >>> This technique is amazingly powerful.
> >>>
> >>> So now I only need one generic web page. Think of that.
> >>>
> >>> Only one page is needed - forever.
> >>>
> >> This is a problem when it comes to bookmarks, sharing the link with a
> friend, searchability, browser history, etc. The web wasn't exactly intended
> to be a stateful thing and you'll have to resort to hacks such as hash-bangs
> to get around it. I suggest reading  Tim Bray's Broken Links to see why that
> isn't a good solution anyway.
> >>
> >
> > True. But this problem is an age-old general AJAX/dynamic-markup problem.
> I agree it might be very visible in this case.
> >
> > However, I've written XULRunner apps with no back buttons -- no need for
> them with easy-to-navigate UIs. Most Adobe AIR apps I've seen have no
> browser history. It's made me question: How badly do end-users really need
> those things? If they do, couldn't we give them better application-specific
> versions inside our web-app UI?
>
> If I'm using a browser, I'd enjoy being able to use the web. What
> constitutes a 'very easy to use' application to you might  not be the same
> for everyone. I do remember many flash pages falling pray to the same
> problem. I think this is mostly a deeply rooted problem in the web where
> you're piggy-back riding sessions on a protocol that was absolutely not made
> for that. It sometimes works well enough (I'm thinking of chat applications
> or even grooveshark here), so it's certainly not black and white, but I
> figure you know what I mean.
> >
> >> Plus I'd argue that javascript and Erlang should be kept separate and
> you shouldn't try to generate one with the other,
> >
> > Good point. I thought about sending the js in static files and reducing
> the calls from Erlang to simple one-liners. But also note that the more
> powerful aspect of this (IMO) is not just sending js, but sending UI
> elements. Sending blocks of UI to an empty page! How can anyone not like
> that?
> >
> Separation of concerns. JS is about behaviours on the page, dynamic
> content. UI is both HTML (structure) and CSS (presentation). One very simple
> question I like to ask to sort this out is "would I be able to hire a
> designer to work on my site without guiding them around too much?" "Could I
> hire someone to just work on my javascript and HTML without them needing to
> know anything else?"
>
>
Ok so "separation of concerns" is good but having different notations for
expressing the concerns
is crazy- to make a web thing that interacts with a server you need to learn
something like

        HTML
        Javascript
        CSS
        PHP
        MySQL

And to be able to configure Apache and MySQL - other combinations are
possible.

Then you have to split the flow of control to many places.

All of this is crazy madness. There should be *one* notation that is
powerful enough to express all
these things. In the browser is seems sensible to forget about css and html
only use Javascript
The only communication with the browser should be by sending it javascript.

How you generate the javascript is irrelevant - by hand or by program - who
cares. If you make it by
program the chances are that it's right.

Security is orthogonal to this - send encrypted js over the wire and make
sure your key-rings are secure
this is a completely different problem.

/Joe


> If you say no to these, you might have some overlapping domains in what
> you're doing.
>
> Then again, I'm a fan of really well-separated components in my
> applications, which is why I like Erlang's processes and OTP applications in
> the first place :)
>
> Another advantage of keeping things separate is caching -- this is however
> pretty application and audience specific in terms of needs and requirements.
>
> > - Edmond -
> >
> >> but at this point, I figure it's more of a matter of who wants to give
> himself the trouble than anything.
> >>
> >>
> >> --
> >> Fred Hébert
> >> http://www.erlang-solutions.com
> >>
> >>
> >
> >
> > --
> > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>
>
> --
> Fred Hébert
> http://www.erlang-solutions.com
>
>